Security Updates

soaringowl2145 · 2017-01-26 13:14:29

How long does it typically take for Arch to patch/fix security updates?

ayekat · 2017-01-26 13:22:15

You may be used to distributions like Debian, where they freeze a package/software version to something, then backport selected updates/patches/fixes on their own, because they can't or don't want to follow upstream releases.

But given the rolling release nature of Arch Linux, there is no need for such distribution-specific tinkering - the most recent (stable) software is simply taken as-is from upstream, which usually includes all "security fixes"¹.

___
¹ I'm putting this in quotes, because the distinction between "security fixes" and "regular bug fixes" seems pretty arbitrary to me.

Trilby · 2017-01-26 13:51:11

As an example, I follow tech news pretty well, and as soon as I heard about the big bash bug a few years ago, I immediately got on my computer to check whether the patched bash was in testing or was somewhere in the pipeline to make it to our repos. However, I found that I already had the 'fixed' version of bash installed which came with a normal update at least a day or two *before* this "shellshock" bug ever made it into the media.

So in addition to the comments above about how "security update" doesn't mean all that much, I'd question the meaning of "how long". How long from what to what? How long from when any security vulnerability is announced in any popular media (even mainstream tech-news media)? How long until the fix is in our repos? I'd not be surprised if the average number for this metric was negative.

soaringowl2145 · 2017-01-26 14:19:32

Basically I am trying to compare the amount of time it takes for the update from the length of time it takes Arch vs Debian to update.

soaringowl2145 · 2017-01-26 14:20:30

With Arch specifically I am looking for the length of time it takes from the time a package is flagged to the time it updates.

Trilby · 2017-01-26 14:28:10

Flagged by whom? Flagged correctly?

Most of our distro devs do not need packages flagged as outdated in order to update them. Most of our distro devs have good communication with upstream and are fully aware when new releases or updates are available - especially for any core/critical packages that could have any noteworthy security issues.

In contrast, a large portion, if not a vast majority, of user-submitted "outdated flags" are just complete crap. Frankly I'm amazed the option to flag packages out of date hasn't simply been removed yet. It is so horrifically abused that there remains virtually no signal in the noise. It's about as useless as a social media "thumbs down". It might mean the package is legitimately out of date, it might mean there is a bug, it might mean some idiotic user didn't read the manual and couldn't get the software to work, hell it might mean the user is constipated and cranky.

As for updates that actually affect security - I'd be surprised if you could find any instances where the package had to be flagged out of date by a user before the arch dev updated the package. As noted above, we get updates often *before* the security issue is general public knowledge.

soaringowl2145 · 2017-01-26 14:51:33

As noted above, we get updates often *before* the security issue is general public knowledge.

Do you know if this is the same for Debian?

Trilby · 2017-01-26 15:03:38

I have no idea. Go ask on a Debian forum.

soaringowl2145 · 2017-01-26 15:04:39

Thanks.

Head_on_a_Stick · 2017-01-27 08:08:17

soaringowl2145 wrote:

Basically I am trying to compare the amount of time it takes for the update from the length of time it takes Arch vs Debian to update.

They are *very* similar, important security updates get pushed in a matter of hours for both.

Stebalien · 2017-01-27 16:55:34

Usually, Arch gets "security" updates before anyone else because it gets updates before anyone else. It's important to note that not all security updates are marked as such and Debian maintainers have neither the time nor expertise to read through every upstream commit and see if it's a new feature or a bug fix. Worse, new features often include bug fixes (because they replace old, buggy code) so "stable" distros are doomed to miss some (security) bug fixes.

(The?) One case where Arch has problems is abandoned projects. Debian, Red Hat, etc. have time to nurse these old projects along and fix security bugs as they arise but Arch usually doesn't have the man power to do so. Instead, Arch usually pulls in patches from Debian etc. but this can take some time. Arch mitigates this by deprecating and removing old software when possible but that isn't always the case (*cough* libtiff *cough*).

Steef435 · 2017-01-31 00:55:31

I would like to point out that while Arch gets all the security updates "first", it also gets all new vulnerabilities and regressions first. If what you're trying to build is a very secure system, you might want to consider that. Stable distros with security patches don't mutate as much over time as an Arch system does, while they may very well be almost equally secure.

The quite big disclaimer here is that I'm not a security expert.

Arch Linux

#1 2017-01-26 13:14:29

Security Updates

#2 2017-01-26 13:22:15

Re: Security Updates

#3 2017-01-26 13:51:11

Re: Security Updates

#4 2017-01-26 14:19:32

Re: Security Updates

#5 2017-01-26 14:20:30

Re: Security Updates

#6 2017-01-26 14:28:10

Re: Security Updates

#7 2017-01-26 14:51:33

Re: Security Updates

#8 2017-01-26 15:03:38

Re: Security Updates

#9 2017-01-26 15:04:39

Re: Security Updates

#10 2017-01-27 08:08:17

Re: Security Updates

#11 2017-01-27 16:55:34

Re: Security Updates

#12 2017-01-31 00:55:31

Re: Security Updates

Board footer