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