[arch-general] gnupg 2.1 not stable

Wed Dec 17 20:46:46 UTC 2014

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 at 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 at 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.html
[3] https://cve.mitre.org/
[4]
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=shortlog;h=refs/heads/master
[5] https://bugs.g10code.com/gnupg/index

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20141217/2800d53b/attachment-0001.bin>