Distrowatch weekly taking a dig at Arch

dyscoria · 2008-02-18 12:47:46

Distrowatch Weekly wrote:

The vmsplice() system call... vulnerability was first made public on February 8th. According to the Linux kernel changelog, it was fixed the same day and a new kernel, version 2.6.24.2, was made available on February 11th.
Linux distributions started releasing patches on February 11th, the same day the news became widely known. But how fast were they? ... A number of security advisories were published last week, shortly after the vmsplice() exploit became widely known. Debian GNU/Linux was the first to issue a fix, but within a day or two most major distros followed suit with their own announcements.
Other users might be even less lucky. Some developers of Arch Linux have previously argued that security announcements are redundant for their distribution as it uses the "rolling package update" mechanism with continuous package updates. But a quick look at their core tree reveals that six days after the vmsplice() vulnerability was published, it still only lists the vulnerable 2.6.24.1 kernel.

Any thoughts? I'm not entirely sure what my standpoint is. Security announcements don't mean much to me, but when dealing with security, surely the Kernel should be one of the things one should focus on to keep up to date.

bangkok_manouel · 2008-02-18 12:50:43

Announcement on home page + kernel patched on Feb. 10.

xsdnyd · 2008-02-18 12:51:52

am i wrong or is this just incorrect?
the same day i read of this exploit the arch devs already fixed it by releasing a kernel 2.6.24.1-2...

faster than anyone else

dyscoria · 2008-02-18 12:52:54

The announcement refers to "Kernel 2.6.24.1 in Core" which is the kernel version with the vulnerability. The "Attention!" section appears to have been appended at a later date.

bangkok_manouel · 2008-02-18 12:55:01

Check out the date, you are safe here...
http://cvs.archlinux.org/cgi-bin/viewcv … 24.2.patch

dyscoria · 2008-02-18 12:55:14

Either that or Distrowatch are amazingly incorrect Maybe someone snuck insane amounts of caffiene into the arch developers' taco's

Pierre · 2008-02-18 12:56:11

Distrowatch is wrong! We fixed the vmsplice security whole at Sun Feb 10 15:44:59. So Arch was one of the first, if not THE first, which provides a security update. And in addition to this we did an announcement! Well our kernel has version 2.6.24.1, but it includes the fix. it is not named 2.6.24.2 because it was relased BEFORE the upstream update.

So I would conclude that Distrowatch do not know what they are talking about!

dyscoria · 2008-02-18 12:56:53

bangkok_manouel wrote:

Check out the date, you are safe here...
http://cvs.archlinux.org/cgi-bin/viewcv … 24.2.patch

Hmm it appears Distrowatch are in fact wrong. Unless they're referring to how long it took for this change to leave the Testing repository.

dyscoria · 2008-02-18 12:58:15

Pierre wrote:

Distrowatch is wrong! We fixed the vmsplice security whole at Sun Feb 10 15:44:59. So Arch was one of the first, if not THE first, which provides a security update. And in addition to this we did an announcement! Well our kernel has version 2.6.24.1, but it includes the fix. it is not named 2.6.24.2 because it was relased BEFORE the upstream update.
So I would conclude that Distrowatch do not know what they are talking about!

Ah thanks for the confirmation that Distrowatch have no idea what they're talking about Distrowatch weren't even slightly wrong too. Tut tut

dyscoria · 2008-02-18 13:00:51

Distrowatch Weekly wrote:

But a quick look at their core tree reveals that six days after the vmsplice() vulnerability was published, it still only lists the vulnerable 2.6.24.1 kernel (correction: Arch Linux released a fix on February 10th).

Did this just get fixed, or did I completely oversee this before? At least its corrected now

They should really change the table so that Arch are at the top, before the might Debian

Last edited by dyscoria (2008-02-18 13:01:24)

Pierre · 2008-02-18 13:02:02

dyscoria wrote:

bangkok_manouel wrote:
Check out the date, you are safe here...
http://cvs.archlinux.org/cgi-bin/viewcv … 24.2.patch
Hmm it appears Distrowatch are in fact wrong. Unless they're referring to how long it took for this change to leave the Testing repository.

The kenrel was moved to [core] after a few hours of intensive testing. So the one who wrote that article did not even read the news on our front page. (right, this makes me a little angry :-))

FeatherMonkey · 2008-02-18 13:08:01

I agree I was monitoring Suse and Arch whipped there butts by a day or 2.

security announcements are redundant ... So it seems they must be for Suse

Last edited by FeatherMonkey (2008-02-18 13:09:30)

dolby · 2008-02-18 13:09:41

they added (correction: Arch Linux released a fix on February 10th) but the original article still stands there. i am not happy

dyscoria · 2008-02-18 13:12:18

They've just added an explanation for the dig too in the comments section:

ladislav 2008-02-18 13:08:42 wrote:

OK, my mistake, I didn't see the forum post.
Still, a random developer's post on a forum is not quite the same as GPG-signed, detailed advisory published on a mailing list dedicated to security. Arch has a mailing list already - why can't they just add another one?
The point here is that a user shouldn't have to LOOK for security advisories, they should be delivered to the user via mailing lists or RSS feeds. The Arch way is not right - what if I don't visit their forum or if I only visit once a month? Then I am excluded from finding out about any security problems.
Some distributions do this right, some don't. Those that don't should consider fix it. That's the point of the story.

I agree with dolby, this article should be ammended properly, especially with such a big error.

Last edited by dyscoria (2008-02-18 13:20:25)

FeatherMonkey · 2008-02-18 13:14:25

^^ Dismal do security guys really rely on Distro security notices seems poor to me.

I personally think you would of had to live in a bubble to miss this, then you might of needed a mailing list.

Last edited by FeatherMonkey (2008-02-18 13:20:49)

Mardukas · 2008-02-18 13:19:46

Me neither. Let's DoS distrowatch.com! \o/

Pierre · 2008-02-18 13:22:45

...and btw: we have sent an announcement to the ml. How should we contact users which do not visit our homepage, nore read rss, nor mailing-lists nor irc etc.?

FeatherMonkey · 2008-02-18 13:24:33

esp lol

dyscoria · 2008-02-18 13:25:06

Pierre wrote:

...and btw: we have sent an announcement to the ml. How should we contact users which do not visit our homepage, nore read rss, nor mailing-lists nor irc etc.?

Easy, send a letter by post! Maybe even call them personally!
There's no such thing as lack of resources

VikM · 2008-02-18 14:07:43

Let me put some gas on fire, the distrowatch article is wrong but there are some things that might keep some security conscious people away from Arch:
- change logs. For example php 5.2.5-4 was released a few days ago. Why? Is there a critical bug-fix, so I should upgrade as soon as possible, or can I wait until my regular update schedule? (Otherwise php is a great package in arch, thanks Pierre)
- some packages are quickly updated, some not. See http://bugs.archlinux.org/task/8613, from 2007-11-20 to 2008-02-11 to apply some simple patches. Even 2007-11-20 was quite late. Is someone looking on others distros security changelogs or security sites to see what is happening around?
- the arch way, as vanilla as possible, config files as default as possible is not always the best approach. The denyhosts problem, the xorg default config listening on the net are two examples fixed as result of users requests, great, but they where obvious...
- since when is iptables 1.4.0 out? 2007-12-22. Not crucial, but again this raises the question "how much does Arch care about security?"
Not to mention Fedora/RedHat/Gentoo/OpenBSD (at least) usage of hardening gcc switches for theirs packages. These switches are in vanilla gcc since 2005. Fedora/RedHat also uses the vanilla kernel's selinux.

Pierre · 2008-02-18 14:23:41

You're right, but that was not really the topic of the article. I think we should discuss this in a separate thread. (imho an important topic, too)

VikM · 2008-02-18 14:41:37

Ok, let's move to http://bbs.archlinux.org/viewtopic.php?pid=332109

fwojciec · 2008-02-18 15:23:20

I just posted a comment about this on the Distrowatch comments section. I encourage everyone to post there also until the article is revised to be somewhat closer to reality. Ladislav made a correction in the text, that's true, but Arch is still listed as one of the "trouble" distros, the text of the article targets Arch developers specifically as having an incorrect idea about security updates, and a later comment by Ladislav (in the comment section) suggests that Ladislav is still not fully aware of the extent of his misrepresentation of Arch.

Personally I think that we should complain until Arch is *recognized* as one of the *fastest distros* to provide the fix to this security issue to their users!!!

tlaloc · 2008-02-18 16:11:51

I am more concerned with ladislav's expression "random developer" (quoted above). I haven't checked yet who was meant/attacked there - and frankly, I don't care. I would stubbornly cling to my belief that Arch devs are not chosen at random.
(And please, don't tell me: That's what you WOULD LIKE to believe ...)

Pudge · 2008-02-18 16:46:52

I have been using the Archlinux site for updating lately because the mirror I usually use is out of date. I JUST NOW changed back to my usual mirror and did a pacman -Syu. Here are my results:

:: Synchronizing package databases...
core 23.7K 255.0K/s 00:00:00 [#####################] 100%
extra 303.3K 949.9K/s 00:00:00 [#####################] 100%
community 335.9K 1071.0K/s 00:00:00 [#####################] 100%
:: Starting full system upgrade...
warning: firefox: local (2.0.0.12-2) is newer than extra (2.0.0.11-2)
warning: flex: local (2.5.33-4) is newer than core (2.5.33-3)
warning: kernel26: local (2.6.24.1-2) is newer than core (2.6.23.14-1)
warning: lib32-cairo: local (1.4.14-1) is newer than community (1.4.12-2)
warning: lib32-gcc-libs: local (4.2.3-3) is newer than community (4.2.2-3)
warning: lib32-gtk2: local (2.12.7-1) is newer than community (2.12.5-1)
warning: lib32-libtasn1: local (1.3-1) is newer than community (1.1-1)
warning: lib32-libxmu: local (1.0.4-1) is newer than community (1.0.3-1)
warning: lib32-pcre: local (7.6-2) is newer than community (7.5-1)
warning: licenses: local (2.3-1) is newer than core (2.2-2)
warning: mplayer-plugin: local (3.50-3) is newer than extra (3.50-1)
warning: nvidia: local (169.09-2) is newer than extra (100.14.19-6)
warning: nvidia-utils: local (169.09-1) is newer than extra (100.14.19-2)
warning: pcre: local (7.6-2) is newer than core (7.5-1)
warning: sshfs: local (1.9-1) is newer than extra (1.8-1)
warning: truecrypt: local (4.3a-12) is newer than extra (4.3a-11)
local database is up to date

The mirror in question is:
ftp://locke.suu.edu/linux/dist/archlinu … /os/x86_64

There are sixteen packages that I have installed that are not up to date, INCLUDING kernel26. So for anyone who uses this mirror exclusively and did not read the front page in order to change mirrors, this important change is STILL not available.

In all fairness, perhaps someone from distrowatch checked one of our mirrors that is out of date. I realize that Arch Linux is not responsible for the actions of the mirror sites, but what the mirror sites do affects Arch's image. Do we need to exercise more control over the mirrors? Is it even possible to control the mirror sites?

Pudge

Arch Linux

#1 2008-02-18 12:47:46

Distrowatch weekly taking a dig at Arch

#2 2008-02-18 12:50:43

Re: Distrowatch weekly taking a dig at Arch

#3 2008-02-18 12:51:52

Re: Distrowatch weekly taking a dig at Arch

#4 2008-02-18 12:52:54

Re: Distrowatch weekly taking a dig at Arch

#5 2008-02-18 12:55:01

Re: Distrowatch weekly taking a dig at Arch

#6 2008-02-18 12:55:14

Re: Distrowatch weekly taking a dig at Arch

#7 2008-02-18 12:56:11

Re: Distrowatch weekly taking a dig at Arch

#8 2008-02-18 12:56:53

Re: Distrowatch weekly taking a dig at Arch

#9 2008-02-18 12:58:15

Re: Distrowatch weekly taking a dig at Arch

#10 2008-02-18 13:00:51

Re: Distrowatch weekly taking a dig at Arch

#11 2008-02-18 13:02:02

Re: Distrowatch weekly taking a dig at Arch

#12 2008-02-18 13:08:01

Re: Distrowatch weekly taking a dig at Arch

#13 2008-02-18 13:09:41

Re: Distrowatch weekly taking a dig at Arch

#14 2008-02-18 13:12:18

Re: Distrowatch weekly taking a dig at Arch

#15 2008-02-18 13:14:25

Re: Distrowatch weekly taking a dig at Arch

#16 2008-02-18 13:19:46

Re: Distrowatch weekly taking a dig at Arch

#17 2008-02-18 13:22:45

Re: Distrowatch weekly taking a dig at Arch

#18 2008-02-18 13:24:33

Re: Distrowatch weekly taking a dig at Arch

#19 2008-02-18 13:25:06

Re: Distrowatch weekly taking a dig at Arch

#20 2008-02-18 14:07:43

Re: Distrowatch weekly taking a dig at Arch

#21 2008-02-18 14:23:41

Re: Distrowatch weekly taking a dig at Arch

#22 2008-02-18 14:41:37

Re: Distrowatch weekly taking a dig at Arch

#23 2008-02-18 15:23:20

Re: Distrowatch weekly taking a dig at Arch

#24 2008-02-18 16:11:51

Re: Distrowatch weekly taking a dig at Arch

#25 2008-02-18 16:46:52

Re: Distrowatch weekly taking a dig at Arch

Board footer