No flame war called for or implied, I'm just genuinely curious to get opinions.
You're assuming that new releases == new bugs, my assumption is new releases == new bugs fixed.
Yes, granted. Although, I think where security is concerned it would be nice for developers of the software to have their own "LTS" releases that only get security bug-fixes and not new releases. And, as below, that's because otherwise maintainers of stable OS branches have to make their own LTS codebases which deviate from the actual developers'!
What I really hate is the "I'm better than developers" mentality. What I want is using the lastest version from official developers (e.g. lastestes version of OpenSSL, right now at 1.0.1i) and not an old version patched with pieces of code taken from later releases (e.g. OpenSSL 1.0.1e in Wheezy). The focal point is really simple: I do not trust packagers which heavily edit the software they are packaging (Debian, Arch, Mint.. no differences here) because I consider the software developers the only ones which can "safely" (<-- take it with a grain of salt) make modifications to their software.
Well, yes; there were occasions where bad maintainers removed the entropy-gathering code from major crypto libraries, thinking them to be use-after-frees! So, in general it's true that the developers should also be the packagers. But, what to do, then? If the devs must also facilitate packaging, that means they must have a nod to multi-arch build/install pipelines, and that they must support an LTS that doesn't include new "features" but only focuses on bug-fixes and security. How many projects do this already? Reading Smári's recent post about working with GnuPG, and the rapidly changing, highly unstable API he has to work with, and seeing that OpenSSL (lacking the resources, I'll grant you!) don't seem to support a "mini-OpenSSL" with only the safe, well-audited code, it seems that most of the fundamental code we rely on isn't ready for LTS packaging by the developers. So, instead the package maintainers who've volunteered for the job try to do a patchy job of making LTS releases, and we end up with epic fail. So what do you suggest? Arch seems to use the latest code from devs, with all the new "features" alongside bugfixes, whereas Debian leans toward patchy ad-hoc-LTS because official LTS is rarely available. Neither approach is ideal for security or reliability, but the latter approach invariably appeals more to the companies that are tasked with handling our data! On 14/10/14 09:03, danimoth wrote:
Hi Cathal,
I do not want to start a flame-war, just my opinions inline.
On 13/10/14 at 08:08pm, Cathal Garvey wrote:
What's the security trade-off of using Arch, which gets the latest patches and seemingly likes to rely on developers' repos, versus getting the latest builds with new and exciting bugs?
You're assuming that new releases == new bugs, my assumption is new releases == new bugs fixed. You're right (in a general sense) when the updated software has new features; new features have always new bugs (but major number version advancement does not often happen).
That is, Debian has a "stable" branch that is, to most people, excessively so. But security wise, you're pretty sure it's got less vulns than their "testing" branch. How does this compare to Arch, which goes for bleeding edge and unashamedly breaks now and then?
What I really hate is the "I'm better than developers" mentality. What I want is using the lastest version from official developers (e.g. lastestes version of OpenSSL, right now at 1.0.1i) and not an old version patched with pieces of code taken from later releases (e.g. OpenSSL 1.0.1e in Wheezy). The focal point is really simple: I do not trust packagers which heavily edit the software they are packaging (Debian, Arch, Mint.. no differences here) because I consider the software developers the only ones which can "safely" (<-- take it with a grain of salt) make modifications to their software.
D.
-- Twitter: @onetruecathal, @formabiolabs Phone: +353876363185 Blog: http://indiebiotech.com miniLock.io: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM