Thanks to Adam for your ongoing work on the stable releases! I just wanted to clarify a few points here.
On Tue 2018-10-23 08:57:08 +0100, Adam D. Barratt wrote:
> An issue is that the gnupg update itself doesn't really qualify for
> stable-updates any more than it qualifies for stable-security. The
> changes to gnupg itself are at best security improvements, which isn't
> justification for forcing all stretch users to install the new version
> as a matter of urgency - indeed, if the new version of enigmail weren't
> relying on new functionality no-one would be suggesting pushing gnupg so
> urgently - nor, I imagine, backporting all of the mentioned features.
I would be pushing for a stable point release for GnuPG at least for the
cryptographic defaults refresh, and the series of minor bugfixes that
resolve outstanding problems.
I brought up the idea of a cryptographic defaults refresh nearly a year
ago [0], and it's overdue (my fault). i don't think it's responsible
for us to ship a new stable installation in 2019 that by default creates
2048-bit RSA keys that claim to be valid through 2021.
The problems with bugs like handling import of malformed keys (#906545),
for example, are bad enough to have already caused extra labor in the
form of stretch-backports maintenance to work around the fact that these
bugs are present in debian stretch. Thanks are due to Roger Shimizu
(cc'ed) for handling that ongoing task! Note that malformed keys are
significantly more present today than they were when stretch was
released, due to ongoing attacks on the keyserver infrastructure. :(
The fact that the upstream-supported version of enigmail that works with
the upcoming stretch version of thunderbird depends on these fixes is,
as you say, another reason to suggest inclusion in debian stretch.
> It's also going to need a d-i sign-off, because gnupg produces a udeb.
I've added debian-boot@lists.debian.org in the hopes that someone from
there can supply a d-i sign-off.
I've done my best with this series of patches to minimize disruption to
this critical part of debian stretch while still supporting the shifting
network ecosystem that depends on it. If these changes cause any
significant disruption, please point it out to me so that i can try to
repair it.
But if debian's policies and practices don't have a way to get these
fixes to stable users who might depend on them for matters of critical
security (even if the gnupg updates are not in themselves deemed to be
critical security updates), then we're failing our stable users.
If that's the case, then either debian's policies or practices need to
change, or debian needs to get a more capable maintainer for GnuPG who
can figure out how to effectively navigate or avoid what feels like a
buck-passing deadlock between two (maybe three)
overworked/underresourced teams. I welcome any help in that regard.
All the best,
--dkg
[0]
https://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/2017-October/006148.html
signature.asc
Description: PGP signature
