I'd like to see this version unmasked so I can start creating non-interoperable keys as soon as possible. ;-) diggin' me some eliptical curves! Reproducible: Always Steps to Reproduce: 1. emerge -av gnupg 2. no ecc 3. cry Thanks!
For your viewing pleasure... https://www.gnupg.org/faq/whats-new-in-2.1.html
No keywords for gnupg 2.1.0 is intentional at this point while it undergoes more testing and some issues, including bug 528460 that blocks a proper upgrade path is solved. There are also minor issues such as http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19002 that have been reported. We welcome testing and bug reports by simply adding "app-crypt/gnupg **" to the local package.accept_keywords.
do we have a list of blockers on this (upstream or here). also, I thought gnupg had format changes on minor releases as a mater of course.
(In reply to Matthew Thode ( prometheanfire ) from comment #3) > do we have a list of blockers on this (upstream or here). also, I thought > gnupg had format changes on minor releases as a mater of course. The largest issue I consider blocking atm is the HKPS SNI issue[0]. Except for that it is very nice if people start using GnuPG 2.1 and report issues, but there isn't anything in 2.1 that should indicate a too swift of a move over to it, in particular until some other bugs are fixed, e.g. LDAP support is not yet implemented in dirmngr for OpenPGP keyservers that disables interoperability with enterprise systems such as Symantec Encryption Server that publish employee public keys in LDAP, and it is still possibility of format changes for ECC keys as the EdDSA I-D is not formally accepted or IANA registrered for algoid 22. References: [0] http://lists.gnupg.org/pipermail/gnupg-users/2014-November/051471.html
I forgot about this bug report. keywordreq is now active in bug 546478 *** This bug has been marked as a duplicate of bug 546478 ***
