Re: [arch-general] gnupg 2.1 not stable
Ido Rosen i...@kernel.org on Wed, 2014/12/17 09:03:
From gnupg.org:
2.0.26 is the stable version suggested for most users,
2.1.1 is the brand-new modern version with support for ECC and many
other new features,
and 1.4.18 is the classic portable version.
Marking version 2.1 stable would include some new features like elliptic
curves. Possibly these features do include bugs and issues - that is why the
modern branch is not yet ready for every day use in enterprise distributions,
etc.
What I like about Arch Linux is its early adoption of new features,
releases, ...
For package file verification we do not rely on elliptic curves and the like.
So I think we are perfectly fine with this.
Some rough edges need to be fixed in gnupg and other software. But that is
what happens if the software is actively used by early adopters.
I did fix some problems with git test suite (that is why git 2.2.0 took
longer to enter our repositories) - now it is ready for everybody to use it
with gnupg 2.1.
--
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c ./sig*/b/42*2-3)*42);}
pgp1ydvvIjkXK.pgp
Description: OpenPGP digital signature
Re: [arch-general] gnupg 2.1 not stable
On 17/12/14 16:46, Jacob Joseph wrote: On Thu, 18 Dec 2014 07:43:52 +1100 Gaetan Bisson bis...@archlinux.org 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 As Gaetan Bisson told you in the tracker, file the bug against emacs, where it obviously belongs. -- Pedro Alejandro López-Valencia http://about.me/palopezv/ Every nation gets the government it deserves. -- Joseph de Maistre
Re: [arch-general] gnupg 2.1 not stable
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
Re: [arch-general] gnupg 2.1 not stable
On Thu, 18 Dec 2014 05:11:00 -0500 P. A. López-Valencia vorb...@outlook.com wrote: On 17/12/14 16:46, Jacob Joseph wrote: On Thu, 18 Dec 2014 07:43:52 +1100 Gaetan Bisson bis...@archlinux.org 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 As Gaetan Bisson told you in the tracker, file the bug against emacs, where it obviously belongs. I didn't file this bug, but did point out the upstream fix. The bug remains open in the tracker, and certainly involves this change to gnupg. ~Jacob pgprpqPCVltA1.pgp Description: OpenPGP digital signature
[arch-general] gnupg 2.1 not stable
From gnupg.org: 2.0.26 is the stable version suggested for most users, 2.1.1 is the brand-new modern version with support for ECC and many other new features, and 1.4.18 is the classic portable version. The 2.1 series of gnupg is not stable, it still has many major bugs, not the least of which is backwards compatibility with various key sizes previously supported (introduced by the new gpg to gpg-agent IPC layer restrictions). On the gnupg-devel mailing list I've seen a few potentially serious security issues with it. Given that it's not marked as stable upstream, and that it's such a critical core component of Arch's infrastructure, I find it questionable for Arch to have upgraded so soon. In the future, can we avoid upgrading gnupg proper to non-stable releases? Instead, how about creating a gpg21 or gpg-modern package would be appropriate for those wishing to try the unstable version and then updating the gnupg package once that branch gets marked stable?
Re: [arch-general] gnupg 2.1 not stable
On Wed, 17 Dec 2014 09:03:31 -0500, Ido Rosen wrote: Given that it's not marked as stable upstream, and that it's such a critical core component of Arch's infrastructure, I find it questionable for Arch to have upgraded so soon. Ido, thanks for the heads up :)! I considered Arch's core as something comparable to FreeBSD's world. The base system should be apart of the Arch's philosophy to follow upstream, even if upstream releases something as stable that is well known as completely broken as e.g. ... ok, I resist ... ;). Everything in core has to be as stable and as proved as possible. 2 Cents, Ralf
Re: [arch-general] gnupg 2.1 not stable
Ralf, On Wed, Dec 17, 2014 at 9:20 AM, Ralf Mardorf ralf.mard...@rocketmail.com wrote: On Wed, 17 Dec 2014 09:03:31 -0500, Ido Rosen wrote: Given that it's not marked as stable upstream, and that it's such a critical core component of Arch's infrastructure, I find it questionable for Arch to have upgraded so soon. Ido, thanks for the heads up :)! I considered Arch's core as something comparable to FreeBSD's world. The base system should be apart of the Arch's philosophy to follow upstream, even if upstream releases something as stable that is well known as completely broken as e.g. ... ok, I resist ... ;). Everything in core has to be as stable and as proved as possible. 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.) 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). 2 Cents, Ralf
Re: [arch-general] gnupg 2.1 not stable
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
Re: [arch-general] gnupg 2.1 not stable
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. 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. [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
Re: [arch-general] gnupg 2.1 not stable
On Wed, Dec 17, 2014 at 11:00 AM, P. A. López-Valencia vorb...@outlook.com 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
Re: [arch-general] gnupg 2.1 not stable
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: 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? 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. thanks in advice, cheers, Levente signature.asc Description: OpenPGP digital signature
Re: [arch-general] gnupg 2.1 not stable
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. 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. -- Pedro Alejandro López-Valencia http://about.me/palopezv/ Every nation gets the government it deserves. -- Joseph de Maistre
Re: [arch-general] gnupg 2.1 not stable
On Wed, Dec 17, 2014 at 12:41 PM, P. A. López-Valencia vorb...@outlook.com 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
Re: [arch-general] gnupg 2.1 not stable
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. Also I wanted to address your last sentence re the 2.1.1 point release since it is in general good advice, but not a good idea in this case unfortunately: In the release email for gnupg 2.1.1 it says it is not fit for general use and is not a stable release (latest development). **We should not upgrade to this point release, instead we should downgrade to 2.0.x.** http://lists.gnupg.org/pipermail/gnupg-announce/2014q4/000360.html [...] Three different versions of GnuPG are actively maintained: - GnuPG modern (2.1) is the latest development with a lot of new features. This announcement is about the first release of this version. - GnuPG stable (2.0) is the current stable version for general use. This is what most users are currently using. - GnuPG classic (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install modern (2.1) and stable (2.0) at the same time. However, it is possible to install classic (1.4) along with any of the other versions. [...]
Re: [arch-general] gnupg 2.1 not stable
On Wed, Dec 17, 2014 at 12:05 PM, Levente Polyak anthr...@archlinux.org 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
Re: [arch-general] gnupg 2.1 not stable
Also, since it was mentioned regarding 2.1.x: ECC support is nice to have, but is a new feature that's not required for Arch db/package verification. That's why I suggested that we downgrade gnupg to 2.0.x and, for those users who are willing to take the risk with gnupg 2.1.x before it is marked stable, we can create a gnupg21 package (perhaps in AUR?), and then once gnupg 2.1 is marked as stable, we can rename gnupg21 to gnupg and add conflicts= and replaces= as appropriate... Gaetan, since you maintain gnupg, your word is law, so what are your thoughts?
Re: [arch-general] gnupg 2.1 not stable
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
Re: [arch-general] gnupg 2.1 not stable
On Wed, Dec 17, 2014 at 1:46 PM, P. A. López-Valencia vorb...@outlook.com wrote: 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. Your comment about stability in Arch is yet another straw man. I'm concerned about continuity and security against distribution channel being hijacked: Arch has no continuity if it can't reliably verify the authenticity of its distribution channel (i.e. if database and package signatures stop working properly, or someone compromised them). If it were any other piece of Arch, like libc or even the kernel, I wouldn't care as much, but this is the piece of Arch that is responsible for telling an Arch user that he is really getting Arch and not some backdoored malicious lookalike. 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. 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. As for downgrading being painful: I just downgraded that way and it was painless (and pacman, all pacman keys, keyring, etc. still work for me). 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. This is what the 2.1.1 point release says, verbatim: - GnuPG modern (2.1) is the latest development with a lot of new features. This announcement is about the first release of this version. - GnuPG stable (2.0) is the current stable version for general use. This is what most users are currently using. So, it does directly imply that you should not use gpg modern (not stable) yet for general use, as opposed to development. It goes as far as calling modern a development release, and to draw the distinction between it and the stable release. It also implies that modern is not yet suited for general use, by saying that stable is for general use.Whether or not we parse these words verbatim or add some interpretation, the meaning is clear: 2.0 is for general use and is stable, 2.1.1 is not stable and is a development release.
Re: [arch-general] gnupg 2.1 not stable
[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. -- Gaetan
Re: [arch-general] gnupg 2.1 not stable
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 secur...@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,
Re: [arch-general] gnupg 2.1 not stable
On Thu, 18 Dec 2014 07:43:52 +1100 Gaetan Bisson bis...@archlinux.org 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 pgpfSBpVTl1C9.pgp Description: OpenPGP digital signature
Re: [arch-general] gnupg 2.1 not stable
On Wed, 17 Dec 2014 14:19:09 -0500 Ido Rosen i...@kernel.org 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.
Re: [arch-general] gnupg 2.1 not stable
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. Fortunately, now that I _know_ about this, due to the surrounding philosophy of simple composability and user-centric control, it may become possible for me to tweak my systems like earlier in the thread if I decide the main packagers are playing too fast and loose with GnuPG versioning. The upstream release cycle seems a bit unclear and does not play particularly cleanly with the notion of rolling-release Linux software distribution; the wording on the website doesn't distinguish well how comparatively stable the modern branch can be expected to be. I do certainly think GnuPG is a special case and should be more carefully integrated, even if it requires bending the general principle of avoiding lagging upstream. It's not clear to me whether falling back to the stable GnuPG is a good way to do this. I think _if_ modern can be demonstrated to be a /de facto/ development branch right now then it should be relegated to a more-experimental package, but there's potential follow-on problems surrounding how many users test the rest of the system with a newer GnuPG. Has upstream actually been contacted about this to ask what they think? --- Drake Wilson
Re: [arch-general] gnupg 2.1 not stable
On Wed, 17 Dec 2014 21:32:26 -0600 Drake Wilson dr...@dasyatidae.net 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.
