Ubuntu's QA and skills at patching

[Cathal Garvey]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x988B9099.asc
Type: application/pgp-keys
Size: 6176 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20141014/e17004be/attachment-0002.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20141014/e17004be/attachment-0002.sig>