Re: gnupg RC bugs

[James Troup <james@nocrew.org>]

Steve Langasek <vorlon@debian.org> writes:

> I would be doubly wary of letting a new upstream version of a package into
> testing as an NMU.  If James agrees that 1.4.1 is the way to go for sarge,

I've uploaded 1.4.1-1 to unstable.  On balance, I think we should put
it into sarge.  1.4.0 has been in unstable for sometime without any
major problems and upstream thinks we should go with 1.4.1 for sarge
too.

I checked and everything in main that depends on gnupg is either in
testing with the same version as unstable or not in testing at all so
introducing a new major version shouldn't be a problem in terms of
backwards compatibility.

1.4.x does introduce a couple of new dependencies, namely on
libusb-0.1-4 and libreadline5.  Again these are both already in
testing with the same version as unstable.  libusb-0.1-4 is currently
only optional and will need to jump to priority standard.

I deliberately left the urgency at low so that the new upstream
micro-version can get some testing, but (obviously) feel free to
override that as you see fit.

If you don't want to put a new upstream version in sarge, AFAICS there
are three other options:

 (1) downgrade the bugs - FWIW, I'm not at all convinced they're
     actually RC, never mind grave, anyway[1].

 (2) if the new libraries/dependencies are a problem, I can disable
     USB and readline support either directly in unstable or via a
     t-p-u upload.

  or

 (3) backport the fixes to the version in sarge.  (Though I won't have
     time to do this myself in the foreseeable future, I'm afraid)

-- 
James

[1] #299814: it's data "loss" in very specific and not common
             circumstances and with fairly obvious workarounds (->
             generate a new key).
    #300859: "It's not exploitable in regular gnupg operation with a
              human endpoint." ...