On Wed, 17 Dec 2014 09:32:20 -0500, Ido Rosen wrote:

Agreed that everything in "core" should be maximally stable. Given that gpg is such a crucial core component of Arch's infrastructure and that gpg 2.1 is NOT stable. Could we switch back to gnupg 2.0.x (stable release)

"GnuPG modern (2.1) is the brand new [snip] It will eventually ^^^^^^^^^^^^^^^^^^ replace the current stable (2.0)" - https://www.gnupg.org/download/ ^^^^^^^^^^^^^^ IOW Ido isn't a troll. [root@archlinux rocketmouse]# downgrade gnupg Available packages: 1) gnupg-2.1.0-7-x86_64.pkg.tar.xz (local) 2) gnupg-2.1.0-6-x86_64.pkg.tar.xz (remote) 3) gnupg-2.1.0-4-x86_64.pkg.tar.xz (remote) 4) gnupg-2.0.26-1-x86_64.pkg.tar.xz (remote) 5) gnupg-2.0.25-1-x86_64.pkg.tar.xz (remote) 6) gnupg-2.0.23-1-x86_64.pkg.tar.xz (remote) 7) gnupg-2.0.22-2-x86_64.pkg.tar.xz (remote) select a package by number: 4 [snip] add gnupg to IgnorePkg? [y/n] y gnupg is security stuff, fellows, consider to care about it. I wasn't aware about this issue, so again, thank you Ido for the heads up :)! Regards, Ralf

On Wed, Dec 17, 2014 at 11:00 AM, "P. A. López-Valencia" wrote:

On 17/12/14 09:32, Ido Rosen wrote:

...

Agreed that everything in "core" should be maximally stable. (Also, following upstream stable releases rather than unstable releases fits just fine with Arch's philosophy of following upstream releases, since unstable releases are really just poorly named release candidates, which we don't usually follow.)

TBH, your argument is a red herring. Arch is about K.I.S.S. and following upstream as close to current as *upstream stable releases* allow. There have been occasions when what you propose has happened, mostly due to the chronic lack of developer hands and time. I can recall the headache it was to move from guile 1.8 to 2.x a little longer than a year ago.

We seem to be in agreement: 2.1.x is not yet in the set of upstream *stable* releases, but 2.0.x is in that set. Therefore, Arch should follow 2.0.x until upstream has marked 2.1.x as stable. Someone made a mistake in upgrading to 2.1, so let's correct the mistake by downgrading back until it's safe, rather than leaving all of Arch's users at great security risk. Let's not forget that gnupg underlies all of Arch's security/integrity (i.e. pacman db and pkg signing) - it's how our users know that Arch is Alice-rch and not Eve-rch. IMO, downgrading is the responsible, smart (not stupid) thing to do, and let's not forget the last "S" in K.I.S.S... :-)

...

Given that gpg is such a crucial core component of Arch's infrastructure and that gpg 2.1 is NOT stable. Could we switch back to gnupg 2.0.x (stable release) and create a gnupg-modern or gnupg21 package to track gnupg 2.1.x, which should be installable side-by-side with gnupg stable (perhaps with gpg21 as the binary name).

Instead, why not donate to gnupg.org so that the software is truly stable and evolves quickly? One underpaid (and underfed!) developer doesn't give any assurance about the future of the project and the software itself.[1] TL;DR: gnupg's situation is such that the OpenSSL project before the Heartbleed incident looks like a bunch of rich kids clubbing in Ibiza.

I donated, but I do not see your name on the donation list? [0] It can be "in addition to", not "instead". Also, your argument is a straw man: Upstream funding has nothing to do with whether Arch should follow what upstream has marked as a stable release vs. what upstream marked as unstable, not recommended for general use, feature development release; this is especially true of such a critical core component which underlies all of Arch's package distribution security/integrity (i.e. pacman-key). That one underpaid and underfed full time developer you refer to has marked 2.0 as stable and 2.1 as unstable, so upstream has not marked 2.1.x as stable yet. [0] https://www.gnupg.org/donate/kudos.html

[1] https://news.ycombinator.com/item?id=8761896

-- Pedro Alejandro López-Valencia http://about.me/palopezv/

Every nation gets the government it deserves. -- Joseph de Maistre

On Wed, Dec 17, 2014 at 12:05 PM, Levente Polyak wrote:

besides the "upstream stable release" discussion (which i will leave out here) i have two small questions:

On 12/17/2014 03:03 PM, Ido Rosen wrote:

...

On the gnupg-devel mailing list I've seen a few potentially serious security issues with it.

No offense, but out of interest:

No offense taken at all, these are good questions to ask.

Could you please point them out with some references and links what exactly you consider "potentially serious security issues" on that mailing list? If its something that was not noticed to be potentially a serious security issue, did you raise awareness about that on the list or privately to the dev?

Several security patches went into 2.1 after its release, and there continue to be patches submitted for minor issues that are borderline security/usability issues in the "bug fix" category. Most of those bugs at worst result in DoSes, but two of them in particular could result in invalid signature verification output. The 2.1.x codebase is still under relatively heavy active development (in code coverage terms) and new features seem to be going into it with every point release. This is my interpretation from following the gnupg-devel mailing list and having some familiarity with how gnupg releases have come out in the past. (Werner Koch does an excellent job of making the releases as secure as he can, but I think he has a good security reason why 2.1 isn't marked as ready for general use or stable yet. I trust him to mark 2.1 stable when he thinks it is ready for public consumption.)

On 12/17/2014 05:28 PM, Ido Rosen wrote:

...

[...] Someone made a mistake in upgrading to 2.1, so let's correct the mistake by downgrading back until it's safe, rather than leaving all of Arch's users at great security risk.

out of curiosity, what exactly and specifically do you consider a "great security risk" in 2.1. I would appreciate if you provide a concrete reference in 2.1 what you mean with "great security risk".

The great security risk is in reference to the fact that Arch uses gnupg to validate package repository authenticity and package authenticity, as well as other places. In practice, I see several security patches went into 2.1 after 2.1.0 was released, including some to fix bugs that only affected 2.1.0 and not 2.0.x. Some of those bugs are immediately exploitable, but it would be irresponsible to disclose which publicly (and I'm not a security researcher). For me, the bigger issue is that the developers themselves do not consider 2.1 ready for general use, and that it's the only thing preventing an Arch mirror compromise from turning into an Arch compromise.

thanks in advice, cheers, Levente

On 12/17/2014 07:32 PM, Ido Rosen wrote:

Several security patches went into 2.1 after its release, and there continue to be patches submitted for minor issues that are borderline security/usability issues in the "bug fix" category. Most of those bugs at worst result in DoSes, but two of them in particular could result in invalid signature verification output. The 2.1.x codebase is still under relatively heavy active development (in code coverage terms) and new features seem to be going into it with every point release. This is my interpretation from following the gnupg-devel mailing list and having some familiarity with how gnupg releases have come out in the past.

thanks for the explanation, but you misunderstood my question: can you please provide references in form of links or commit hashes that are pointing to those, because thats actually what i asked for. For what i currently see there is nothing that needs should mark this explicitly as highly unsecure and "potentially a serious security issue" because if we can't point at specific things, then this statement can be applied to probably any software that is under development. Don't get me wrong, i totally get your point and roughly looked up the tree, but i asked for specific references that back those statements up. Its just hardly overreacted to speak about "potentially a serious security issue" in general.

(Werner Koch does an excellent job of making the releases as secure as he can, but I think he has a good security reason why 2.1 isn't marked as ready for general use or stable yet. I trust him to mark 2.1 stable when he thinks it is ready for public consumption.)

So it's only your assumption that he has "good security reason" to hold that back? Can you proof that he did such a security concerns related statement please? I still get your point, but please back up your statements with links and references, thats all i ask for.

...

On 12/17/2014 05:28 PM, Ido Rosen wrote:

...

[...] Someone made a mistake in upgrading to 2.1, so let's correct the mistake by downgrading back until it's safe, rather than leaving all of Arch's users at great security risk.

out of curiosity, what exactly and specifically do you consider a "great security risk" in 2.1. I would appreciate if you provide a concrete reference in 2.1 what you mean with "great security risk".

The great security risk is in reference to the fact that Arch uses gnupg to validate package repository authenticity and package authenticity, as well as other places. In practice, I see several security patches went into 2.1 after 2.1.0 was released, including some to fix bugs that only affected 2.1.0 and not 2.0.x. Some of those bugs are immediately exploitable, but it would be irresponsible to disclose which publicly (and I'm not a security researcher).

Yep I agree that it is a critical part of the infrastructure, but there are also problems which do appear in "stable" versions. As an example there is CVE-2014-4617 [0] affecting 2.0 and sometimes you also have to deal with libs that are not your own code-base but make you vulnerable, like libksba CVE-2014-9087 [1]. I asked for very specific references because if you want that things get fixed, you should point out specific problems so they can be issued and mitigated in our packages. In cause of libksba CVE-2014-9087 [1] the specific problem got tracked and mitigated as fast as possible and interested users got notified [2].

those bugs are immediately exploitable, but it would be irresponsible to disclose which publicly

If that is true, you should contact someone and point out the issues in a private conversation so a specific problem can be backported and mitigated for Archlinux. You can also contact security@archlinux.org in such situation or coordinate a responsible disclosure/mitigation with MITRE [3] if you spotted a serious issue which no one is aware of. To be honest, it is explicitly *irresponsible* if you just keep that "secret" for yourself because its not only security through obscurity but you may also held something vulnerable which we could mitigate. Especially related to this particular situation with GnuPG i would call it controversial, because you raised the security concern topic for GnuPG 2.1 (which we are in fact currently using) and on the other side you are speaking about "those bugs are immediately exploitable", which means that you are holding back information that may affect people *right now*. If you are really interested in reducing the current security concerns, please follow one of the above recommended ways to raise awareness about a specific issue. Right now we already have gnupg 2.1.1-1 in testing that fixes several bugs since 2.1.0-7, but from the git logs [4] or bugtracker [5] i currently can't spot something that could potentially compromise a mirror. To be clear: I have asked for specific and explicit issues to be able to push mitigation and track it. To do so I need clear references, links and evidences rather then a "meta" debate about the theoretical security differences between "in-development" software compared to "old" ones. Exactly because of this reason I'm leaving this "meta debate" until its about specific and referenced issues and evidences (that I'm able to work with) because until then its just another abstract meta version of "upstream stable release discussion" (which was by the way the first statement that I explicitly do not wanted to hold). TL;DR: If something is *really* fucked up with the currently released version and its "super secret" please contact security@archlinux.org but currently i cant spot anything that justifies overreaction. Over and out, Levente [0] https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-4617 [1] https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9087 [2] https://lists.archlinux.org/pipermail/arch-security/2014-December/000159.htm... [3] https://cve.mitre.org/ [4] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=shortlog;h=refs/heads/... [5] https://bugs.g10code.com/gnupg/index

On Wed, Dec 17, 2014 at 12:41 PM, "P. A. López-Valencia" wrote:

On 17/12/14 11:28, Ido Rosen wrote:

...

We seem to be in agreement: 2.1.x is not yet in the set of upstream *stable* releases, but 2.0.x is in that set.

Not really. You missed the "as close to current".

I didn't miss the as close to current. You said "as close to current as *upstream stable releases* allow." 2.1.x is not an upstream stable release while 2.0.x is, therefore we are closer to current than upstream stable releases allow. So, as I said, we are in agreement, and IMO a mistake was made and should be rectified by a downgrade rather than leaving Arch users at risk of security breaches.

...

Therefore, Arch should follow 2.0.x until upstream has marked 2.1.x as stable. Someone made a mistake in upgrading to 2.1, so let's correct the mistake by downgrading back until it's safe, rather than leaving all of Arch's users at great security risk. Let's not forget that gnupg underlies all of Arch's security/integrity (i.e. pacman db and pkg signing) - it's how our users know that Arch is Alice-rch and not Eve-rch. IMO, downgrading is the responsible, smart (not stupid) thing to do, and let's not forget the last "S" in K.I.S.S... :-)

The usual practice is to wait until there is a first point release that catches the most glaring bugs, see for example how the kernel and the main desktop environments are updated. The first point release was yesterday (2014-12-16) and it is already in testing. This transition would have occurred sooner or later because the benefits outweigh the cost of moving to the newer version---e,g., the ability to use elliptical curve keys---, but it would've been reasonable to wait for this first point release.

...

I donated, but I do not see your name on the donation list? [0]

Do not stoop to personal attacks. Thank you.

Besides that, I never make public my acts of charity. Have you read Matthew 6:3? Even good atheists practice it.

It was not a personal attack. You encouraged me to donate, so I did, and was encouraging you to practice what you preach (i.e. to donate as well). I'm not Christian, but I think that's covered later on in Matthew 7:2...? Did you read the rest of that paragraph? You disregarded my points as a red herring, then made a straw man argument that we should donate instead of downgrading (and leave Arch users vulnerable). In the same paragraph, you quote Arch policy which agrees with the downgrade... I guess you are just trolling. Happy holidays, either way. :-)

-- Pedro Alejandro López-Valencia http://about.me/palopezv/

Every nation gets the government it deserves. -- Joseph de Maistre

On 17/12/14 13:04, Ido Rosen wrote:

Did you read the rest of that paragraph? You disregarded my points as a red herring, then made a straw man argument that we should donate instead of downgrading (and leave Arch users vulnerable). In the same paragraph, you quote Arch policy which agrees with the downgrade... I guess you are just trolling. Happy holidays, either way. :-)

I did read the rest of the paragraph but considered it not relevant to the discussion. The donation was not a strawman argument but rather a statement of fact about the actual situation with the gnupg.org project and its higher relevance to your concerns about security of the software. I did use the opportunity to try and have the discussion go outside the box and not focus completely on your arguments, which as presented might cause panic in some users. I do understand your concerns about stability but, honestly, using Arch is a guarantee to be bitten sooner or later. Also, I agree that gnupg would have been better kept at 2.0.x for sometime and have 2.1.x in community or AUR even for at least 2 or 3 point releases. But considering the changes in keyring management and the higher security (like disabling all pgp keys with md5 hashes), I can live with the changes. Those same changes make downgrading a painful process. Addressing your observations in the follow up message to the one I'm responding to, notice that nowhere in the release message says that you must not use gpg "modern", only that gpg "stable" is what most users use and perhaps the one with less bugs. As Arch uses current software in most cases, we the users are QA testers for more upstream projects that we can believe, so I wasn't surprised by the move to gnupg, but see above. Happy Holidays to you too. :-) -- Pedro Alejandro López-Valencia http://about.me/palopezv/ Every nation gets the government it deserves. -- Joseph de Maistre

On Wed, 17 Dec 2014 14:19:09 -0500 Ido Rosen wrote:

The correct response is indeed for users to panic and demand that Arch devs be more responsible about reading release notes before upgrading such important core components of the system.

LOL, are you serious? Do you know how long Arch operated without package signing? You now expect users to panic? You're taking this way, way to far.

On Wed, 17 Dec 2014 21:32:26 -0600 Drake Wilson wrote:

Doug Newgard wrote:

...

LOL, are you serious? Do you know how long Arch operated without package signing? You now expect users to panic?

That's actually why I didn't run Arch before despite liking a lot of the philosophy. The big sticking point. The only real reason.

That's fine, but we haven't gone back to the days of no signing. This entire thread is about the possibility that a vulnerability *could* exist. Not that one does, but that there's some possibility that it could happen. Blowing this way out of proportion. To suggest that users panic because of the possibility of an unknown vulnerability seems ludicrous.

On Thu, 18 Dec 2014 07:43:52 +1100 Gaetan Bisson wrote:

[2014-12-17 09:03:31 -0500] Ido Rosen:

...

2.0.26 is the stable version suggested for most users, 2.1.1 is the brand-new modern version

Arch is not stable, it's modern.

Besides, there are no open bugs regarding gnupg on our tracker.

https://bugs.archlinux.org/task/42972 ~Jacob

Just to add a link showing the need for help for the gnupg developers it may be worth having a quick look at https://gnupg.org/blog/20141214-gnupg-and-g10.html -- mike c