[pkg-gnupg-maint] gnupg2-revert-rfc4880bis.patch

Julian Andres Klode jak at debian.org
Tue Feb 27 15:48:43 GMT 2024


On Sun, Feb 25, 2024 at 01:51:29PM +0100, Andreas Metzler wrote:
> On 2024-02-19 NIIBE Yutaka <gniibe at fsij.org> wrote:
> > NIIBE Yutaka <gniibe at fsij.org> wrote:
> > > If the intention of the patch were stopping use of the specification
> > > RFC4880bis as default, I don't think this reverting is not good (and
> > > incomplete).  For me, the reverting is only makes sense when the use of
> > > the option --rfc4880bis itself is important, instead.
> 
> > Sorry, I meant:
> 
> > 	I don't think this reverting is good
> 
> Hello,
> 
> Thanks for the analysis!
> 
> Daniel suggested [1] to merge the discussion about 2.2.42 into this
> thread. Which makes a lot of sense, imho there is not much point
> discussing implementation unless we have documented the goals.
> 
> Disclaimer: I have not read/compared draft-koch-librepgp-00
> ("draft-koch") with draft-ietf-openpgp-crypto-refresh ("draft-ietf")
> and therefore cannot judge their respective *technical* merits and
> weaknesses. Afaiui both a) formally extend the algoritm list (which
> common practice has already extended far beyond rfc4880) and b) offer
> a mutually incompatible new wireformat ("v5").
> 
> I think our wishlist looks like this:
> #1 Stay as close as possible to upstream gnupg. Our versions should not
>   be limited, but might use different defaults. We do not want either
>   gnupg22 or gnupg24 to not be able to "talk" to vanilla gnupg22 and
>   gnupg24.
> #2 Limit the consequences of the schism. By default do not generate
>   messages/signatures/key-signatures that cannot decrypted/verified with
>   pre-schism-toolset.
> #3 Do #2 without sacrificing security.
> #4 Define the "safe" pre-schism-toolset. (e.g. gpg <= 2.2.* && rnp 0.17)
> #5 We might apply stricter criteria to gnupg22 than gnupg24, implicitely
>   assuming that we will keep gnupg24 in experimental and paln on using
>   gnupg22 as default for longer timeframe.


GnuPG 2.2 is reaching its end of life at the end of the year, and APT
will soon rely on GnuPG 2.4 + git patches to keep its users safe from
bad decisions, so I'd really like to see 2.4 in unstable and testing
ASAP as otherwise APT won't be able to deny 1024-bit RSA singatures.

That 1024R deprecation is the reason I picked up 2.4 for Ubuntu 24.04,
as I could not easily backport the patch to 2.2.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en



More information about the pkg-gnupg-maint mailing list