the way to enigmail: gnupg 2.1 backport considerations

[Antoine Beaupré]

Hi,

So I've been looking at Enigmail again, after a long journey helping
people in stable getting that stuff fixed. It's pretty obvious there's
no way to upload that without first doing a GnuPG 2.1 backport into
jessie.

That, it turns out, requires *four* more source package
backports. Fortunately for us, *all* of those are already in
jessie-backports. They would, unfortunately, probably need to be
uploaded straight into jessie-security, however, if only for
consistency's sake.

That would mean, however, a more or less forced update on the following
libraries in jessie:

* libassuan (part of GPG, 2.1 -> 2.4)
* libgcrypt20 (part of GnuTLS, 1.6 -> 1.7)
* libgpg-error (GPG, 1.17 -> 1.26)
* npth (GPG, 1.0 -> 1.3)

How should we handle this? I haven't looked at each backport in detail
to see if ABI changes are significant, but the version numbers seem to
indicate they are not (for what that's worth of course).

That said, with minor changes (to keep "gpg" pointing at the legacy 1.4
version, most notably), I've got a GPG 2.1 backport ready for jessie, at
the usual location:

https://people.debian.org/~anarcat/debian/jessie-lts/

I would very much welcome testing of this. There are still some clunky
things in there, for example critical lintian warnings I need to fix. I
haven't even tried to installed the thing yet, but I figured I would
share my work early and get feedback before going on a wild goose chase
after the dependencies.

Any feedback appreciated.

Thanks,

A.

[Alexander Wirt]

Post by Antoine Beaupré
Hi,
So I've been looking at Enigmail again, after a long journey helping
people in stable getting that stuff fixed. It's pretty obvious there's
no way to upload that without first doing a GnuPG 2.1 backport into
jessie.
That, it turns out, requires *four* more source package
backports. Fortunately for us, *all* of those are already in
jessie-backports. They would, unfortunately, probably need to be
uploaded straight into jessie-security, however, if only for
consistency's sake.

Not only for consistency, jessie-backports is closed and will (hopefully) get
archived soon.

Alex

[Ben Hutchings]

Post by Antoine Beaupré
Hi,
So I've been looking at Enigmail again, after a long journey helping
people in stable getting that stuff fixed. It's pretty obvious there's
no way to upload that without first doing a GnuPG 2.1 backport into
jessie.
That, it turns out, requires *four* more source package
backports. Fortunately for us, *all* of those are already in
jessie-backports. They would, unfortunately, probably need to be
uploaded straight into jessie-security, however, if only for
consistency's sake.
That would mean, however, a more or less forced update on the following
* libassuan (part of GPG, 2.1 -> 2.4)
* libgcrypt20 (part of GnuTLS, 1.6 -> 1.7)
* libgpg-error (GPG, 1.17 -> 1.26)
* npth (GPG, 1.0 -> 1.3)
How should we handle this? I haven't looked at each backport in detail
to see if ABI changes are significant, but the version numbers seem to
indicate they are not (for what that's worth of course).

[...]

Unless these are bug-fix-only updates, I don't think they are suitable
for jessie-security. Would it be possible to bundle the libraries with
gpg 2.1, and install them somewhere that doesn't conflict with the
existing versions?

Ben.

[Antoine Beaupré]

Post by Ben Hutchings

Post by Antoine Beaupré
Hi,
So I've been looking at Enigmail again, after a long journey helping
people in stable getting that stuff fixed. It's pretty obvious there's
no way to upload that without first doing a GnuPG 2.1 backport into
jessie.
That, it turns out, requires *four* more source package
backports. Fortunately for us, *all* of those are already in
jessie-backports. They would, unfortunately, probably need to be
uploaded straight into jessie-security, however, if only for
consistency's sake.
That would mean, however, a more or less forced update on the following
* libassuan (part of GPG, 2.1 -> 2.4)
* libgcrypt20 (part of GnuTLS, 1.6 -> 1.7)
* libgpg-error (GPG, 1.17 -> 1.26)
* npth (GPG, 1.0 -> 1.3)
How should we handle this? I haven't looked at each backport in detail
to see if ABI changes are significant, but the version numbers seem to
indicate they are not (for what that's worth of course).

[...]
Unless these are bug-fix-only updates, I don't think they are suitable
for jessie-security.

I doubt they are:

https://tracker.debian.org/media/packages/liba/libassuan/changelog-2.4.3-2~bpo8%2B1
https://tracker.debian.org/media/packages/libg/libgcrypt20/changelog-1.7.6-1~bpo8%2B1
https://tracker.debian.org/media/packages/libg/libgpg-error/changelog-1.26-2~bpo8%2B1
https://tracker.debian.org/media/packages/n/npth/changelog-1.3-1~bpo8%2B1

Lots of "new upstream release" in there which can basically mean
anything. Here are the respective changelogs:

https://sources.debian.org/src/libassuan/2.4.3-2%7Ebpo8+1/ChangeLog/
https://sources.debian.org/src/libgcrypt20/1.7.6-1%7Ebpo8+1/ChangeLog/
https://sources.debian.org/src/libgpg-error/1.26-2%7Ebpo8+1/ChangeLog/
https://sources.debian.org/src/npth/1.3-1%7Ebpo8+1/ChangeLog/

None of those are patch releases. In fact, in some cases, there *are* no
patch releases (e.g. libpth) and I doubt minor releases are really minor
anyways...

So yes, those are significant upgrades.

I take solace in the fact that those packages are on jessie-backports
already and that if they would have broken stuff, people would have
noticed already...

... right? :)

Post by Ben Hutchings
Would it be possible to bundle the libraries with gpg 2.1, and install
them somewhere that doesn't conflict with the existing versions?

That is a possibility. libassuan, for example, is basically this in
jessie right now:

/usr/lib/x86_64-linux-gnu/libassuan.so.0.4.2

jessie-backports ships:

/usr/lib/x86_64-linux-gnu/libassuan.so.0.7.3

both share the same major SONAME, unfortunately. So they is a clash on
the .so.0 symlink. I am not sure how the linker could handle duplicates
of those entries. And we'd have trouble in /usr/share/doc/libassuan0,
for example.

libgcrypt is similar:

/lib/x86_64-linux-gnu/libgcrypt.so.20.0.3
/lib/x86_64-linux-gnu/libgcrypt.so.20.1.6

libgpg-error:

/lib/x86_64-linux-gnu/libgpg-error.so.0.13.0
/lib/x86_64-linux-gnu/libgpg-error.so.0.21.0

libnpth0:

/usr/lib/x86_64-linux-gnu/libnpth.so.0.0.3
/usr/lib/x86_64-linux-gnu/libnpth.so.0.0.6

I am not sure how we could ship both versions of those libraries in
jessie - that's beyond my linker skill level, i'm afraid. ;)

A.

[Emilio Pozuelo Monfort]

Post by Antoine Beaupré

Post by Ben Hutchings

Post by Antoine Beaupré
Hi,
So I've been looking at Enigmail again, after a long journey helping
people in stable getting that stuff fixed. It's pretty obvious there's
no way to upload that without first doing a GnuPG 2.1 backport into
jessie.
That, it turns out, requires *four* more source package
backports. Fortunately for us, *all* of those are already in
jessie-backports. They would, unfortunately, probably need to be
uploaded straight into jessie-security, however, if only for
consistency's sake.
That would mean, however, a more or less forced update on the following
* libassuan (part of GPG, 2.1 -> 2.4)
* libgcrypt20 (part of GnuTLS, 1.6 -> 1.7)
* libgpg-error (GPG, 1.17 -> 1.26)
* npth (GPG, 1.0 -> 1.3)
How should we handle this? I haven't looked at each backport in detail
to see if ABI changes are significant, but the version numbers seem to
indicate they are not (for what that's worth of course).

[...]
Unless these are bug-fix-only updates, I don't think they are suitable
for jessie-security.

https://tracker.debian.org/media/packages/liba/libassuan/changelog-2.4.3-2~bpo8%2B1
https://tracker.debian.org/media/packages/libg/libgcrypt20/changelog-1.7.6-1~bpo8%2B1
https://tracker.debian.org/media/packages/libg/libgpg-error/changelog-1.26-2~bpo8%2B1
https://tracker.debian.org/media/packages/n/npth/changelog-1.3-1~bpo8%2B1
Lots of "new upstream release" in there which can basically mean
https://sources.debian.org/src/libassuan/2.4.3-2%7Ebpo8+1/ChangeLog/
https://sources.debian.org/src/libgcrypt20/1.7.6-1%7Ebpo8+1/ChangeLog/
https://sources.debian.org/src/libgpg-error/1.26-2%7Ebpo8+1/ChangeLog/
https://sources.debian.org/src/npth/1.3-1%7Ebpo8+1/ChangeLog/
None of those are patch releases. In fact, in some cases, there *are* no
patch releases (e.g. libpth) and I doubt minor releases are really minor
anyways...
So yes, those are significant upgrades.
I take solace in the fact that those packages are on jessie-backports
already and that if they would have broken stuff, people would have
noticed already...
... right? :)

Post by Ben Hutchings
Would it be possible to bundle the libraries with gpg 2.1, and install
them somewhere that doesn't conflict with the existing versions?

That is a possibility. libassuan, for example, is basically this in
/usr/lib/x86_64-linux-gnu/libassuan.so.0.4.2
/usr/lib/x86_64-linux-gnu/libassuan.so.0.7.3
both share the same major SONAME, unfortunately. So they is a clash on
the .so.0 symlink. I am not sure how the linker could handle duplicates
of those entries. And we'd have trouble in /usr/share/doc/libassuan0,
for example.
/lib/x86_64-linux-gnu/libgcrypt.so.20.0.3
/lib/x86_64-linux-gnu/libgcrypt.so.20.1.6
/lib/x86_64-linux-gnu/libgpg-error.so.0.13.0
/lib/x86_64-linux-gnu/libgpg-error.so.0.21.0
/usr/lib/x86_64-linux-gnu/libnpth.so.0.0.3
/usr/lib/x86_64-linux-gnu/libnpth.so.0.0.6
I am not sure how we could ship both versions of those libraries in
jessie - that's beyond my linker skill level, i'm afraid. ;)

I can think of two options:

1) Ship them in a private dir (e.g. /usr/lib/gnupg2/), and link them to those
libs. Then ld should add an RPATH, otherwise an LD_LIBRARY_PATH hack could be used.

2) Statically link the libraries into gpg2

Cheers,
Emilio

[Antoine Beaupré]

Post by Emilio Pozuelo Monfort
1) Ship them in a private dir (e.g. /usr/lib/gnupg2/), and link them to those
libs. Then ld should add an RPATH, otherwise an LD_LIBRARY_PATH hack could be used.
2) Statically link the libraries into gpg2

But then that means double the work to maintain those libraries in the
future, with duplicate code copies and all.

What are we actually worried about regarding those libs? They are only
used by gnupg, really - gnutls uses nettle now - so the one thing they
would break would be gnupg 1.4...

Maybe we could just test that and see where it brings us instead of
mangling those libraries? :)

A.

[Daniel Kahn Gillmor]

Post by Antoine Beaupré
* libgcrypt20 (part of GnuTLS, 1.6 -> 1.7)

libgcrypt is not a part of GnuTLS. GnuTLS has used nettle instead of
gcrypt for years. gcrypt is more properly "part of GnuPG" than anything
else.

basically, all of these libraries are gnupg libraries.

It's a little bit distressing that upstream's attempt to split them out
as distinct libraries (which i think was intended to make them more
useful to other consumers) might be a roadblock on the way to updating
GnuPG itself.

Ben's suggestion of shipping them in a non-default location ("vendor
bundling"?) sounds pretty dubious to me -- i wouldn't want to reason
about (let alone vouch for) the upgrade path from such a hybridized
variant of jessie to standard debian stretch myself.

--dkg

[Ben Hutchings]

Post by Daniel Kahn Gillmor

Post by Antoine Beaupré
* libgcrypt20 (part of GnuTLS, 1.6 -> 1.7)

libgcrypt is not a part of GnuTLS. GnuTLS has used nettle instead of
gcrypt for years. gcrypt is more properly "part of GnuPG" than anything
else.
basically, all of these libraries are gnupg libraries.
It's a little bit distressing that upstream's attempt to split them out
as distinct libraries (which i think was intended to make them more
useful to other consumers) might be a roadblock on the way to updating
GnuPG itself.
Ben's suggestion of shipping them in a non-default location ("vendor
bundling"?) sounds pretty dubious to me -- i wouldn't want to reason
about (let alone vouch for) the upgrade path from such a hybridized
variant of jessie to standard debian stretch myself.

I was thinking that those libraries would be included in the same
binary package as /usr/bin/gpg2 and other executables, which would all
have a run-path set. No-one should need to set LD_LIBRARY_PATH so no
other executables would use those libraries, and the libraries would be
removed when the executables that use them are removed or replaced.

Since gnupg2 actually spreads executables across multiple binary
packages, I realise the libraries would have to be an additional binary
package and that would remain after an upgrade. But it would be
harmless cruft that "apt autoremove" would deal with.

(I assume that GnuPG 2.1 would be packaged as "gnupg2", replacing GnuPG
2.0 since that is no longer supported upstream. If not then I do see a
problem of how to make, say, gnupg2.1 in jessie upgrade to gnupg2 in
stretch. But that's independent of the library issue.)

Ben.

[Antoine Beaupré]

Post by Ben Hutchings

Post by Daniel Kahn Gillmor

Post by Antoine Beaupré
* libgcrypt20 (part of GnuTLS, 1.6 -> 1.7)

libgcrypt is not a part of GnuTLS. GnuTLS has used nettle instead of
gcrypt for years. gcrypt is more properly "part of GnuPG" than anything
else.
basically, all of these libraries are gnupg libraries.
It's a little bit distressing that upstream's attempt to split them out
as distinct libraries (which i think was intended to make them more
useful to other consumers) might be a roadblock on the way to updating
GnuPG itself.
Ben's suggestion of shipping them in a non-default location ("vendor
bundling"?) sounds pretty dubious to me -- i wouldn't want to reason
about (let alone vouch for) the upgrade path from such a hybridized
variant of jessie to standard debian stretch myself.

I was thinking that those libraries would be included in the same
binary package as /usr/bin/gpg2 and other executables, which would all
have a run-path set. No-one should need to set LD_LIBRARY_PATH so no
other executables would use those libraries, and the libraries would be
removed when the executables that use them are removed or replaced.
Since gnupg2 actually spreads executables across multiple binary
packages, I realise the libraries would have to be an additional binary
package and that would remain after an upgrade. But it would be
harmless cruft that "apt autoremove" would deal with.
(I assume that GnuPG 2.1 would be packaged as "gnupg2", replacing GnuPG
2.0 since that is no longer supported upstream. If not then I do see a
problem of how to make, say, gnupg2.1 in jessie upgrade to gnupg2 in
stretch. But that's independent of the library issue.)

I think this is overengineered. I still haven't heard exactly what the
problem would be with upgrading those libraries. They are present in
jessie-backports and presumably well tested. They are rarely directly
consumed by third-parties and mostly encapsulated behind GPGME, at least
that's my understanding. The SONAMEs don't change, so they should be
backwards compatible anyways.

Right?

Doing otherwise would be a massive change and would mean we would be
maintaining multiple copies of those four libraries in jessie, and in an
obscure location as well. I don't know how we would proceed to do this
as source packages anyways - would they all get merged into the gnupg2
source package?

In any case, I don't feel confident starting down that path and I'm
running out of time for the month, so I'll let others figure that out
for the next two weeks.

A.

[Alexander Wirt]

Post by Antoine Beaupré

Post by Ben Hutchings

Post by Daniel Kahn Gillmor

Post by Antoine Beaupré
* libgcrypt20 (part of GnuTLS, 1.6 -> 1.7)

libgcrypt is not a part of GnuTLS. GnuTLS has used nettle instead of
gcrypt for years. gcrypt is more properly "part of GnuPG" than anything
else.
basically, all of these libraries are gnupg libraries.
It's a little bit distressing that upstream's attempt to split them out
as distinct libraries (which i think was intended to make them more
useful to other consumers) might be a roadblock on the way to updating
GnuPG itself.
Ben's suggestion of shipping them in a non-default location ("vendor
bundling"?) sounds pretty dubious to me -- i wouldn't want to reason
about (let alone vouch for) the upgrade path from such a hybridized
variant of jessie to standard debian stretch myself.

I was thinking that those libraries would be included in the same
binary package as /usr/bin/gpg2 and other executables, which would all
have a run-path set. No-one should need to set LD_LIBRARY_PATH so no
other executables would use those libraries, and the libraries would be
removed when the executables that use them are removed or replaced.
Since gnupg2 actually spreads executables across multiple binary
packages, I realise the libraries would have to be an additional binary
package and that would remain after an upgrade. But it would be
harmless cruft that "apt autoremove" would deal with.
(I assume that GnuPG 2.1 would be packaged as "gnupg2", replacing GnuPG
2.0 since that is no longer supported upstream. If not then I do see a
problem of how to make, say, gnupg2.1 in jessie upgrade to gnupg2 in
stretch. But that's independent of the library issue.)

I think this is overengineered. I still haven't heard exactly what the
problem would be with upgrading those libraries. They are present in
jessie-backports and presumably well tested. They are rarely directly
consumed by third-parties and mostly encapsulated behind GPGME, at least
that's my understanding. The SONAMEs don't change, so they should be
backwards compatible anyways.
Right?
Doing otherwise would be a massive change and would mean we would be
maintaining multiple copies of those four libraries in jessie, and in an
obscure location as well. I don't know how we would proceed to do this
as source packages anyways - would they all get merged into the gnupg2
source package?
In any case, I don't feel confident starting down that path and I'm
running out of time for the month, so I'll let others figure that out
for the next two weeks.

I can't stress thos often enough. Jessie-backports doesn't exist anymore.
They are unsupported for months and I do really hope that they get archived
soon.

Do NOT use it.

Alex - Debian Backports ftpmaster

[Antoine Beaupré]

Post by Alexander Wirt
I can't stress thos often enough. Jessie-backports doesn't exist anymore.
They are unsupported for months and I do really hope that they get archived
soon.

I'm sorry I implied we might use backports for this. I didn't mean to: I
mean we should take what has been backported in jessie-backports and
upload that to jessie-security.

A.

[Ben Hutchings]

Post by Antoine Beaupré

Post by Ben Hutchings

Post by Daniel Kahn Gillmor

Post by Antoine Beaupré
* libgcrypt20 (part of GnuTLS, 1.6 -> 1.7)

libgcrypt is not a part of GnuTLS. GnuTLS has used nettle instead of
gcrypt for years. gcrypt is more properly "part of GnuPG" than anything
else.
basically, all of these libraries are gnupg libraries.
It's a little bit distressing that upstream's attempt to split them out
as distinct libraries (which i think was intended to make them more
useful to other consumers) might be a roadblock on the way to updating
GnuPG itself.
Ben's suggestion of shipping them in a non-default location ("vendor
bundling"?) sounds pretty dubious to me -- i wouldn't want to reason
about (let alone vouch for) the upgrade path from such a hybridized
variant of jessie to standard debian stretch myself.

I was thinking that those libraries would be included in the same
binary package as /usr/bin/gpg2 and other executables, which would all
have a run-path set. No-one should need to set LD_LIBRARY_PATH so no
other executables would use those libraries, and the libraries would be
removed when the executables that use them are removed or replaced.
Since gnupg2 actually spreads executables across multiple binary
packages, I realise the libraries would have to be an additional binary
package and that would remain after an upgrade. But it would be
harmless cruft that "apt autoremove" would deal with.
(I assume that GnuPG 2.1 would be packaged as "gnupg2", replacing GnuPG
2.0 since that is no longer supported upstream. If not then I do see a
problem of how to make, say, gnupg2.1 in jessie upgrade to gnupg2 in
stretch. But that's independent of the library issue.)

I think this is overengineered. I still haven't heard exactly what the
problem would be with upgrading those libraries. They are present in
jessie-backports and presumably well tested.

[...]

Those updated library packages are installed and used by people that
specifically choose to use GnuPG 2.1 in jessie. I don't think we can
assume they are well-tested in conjunction with GnuPG 1.4.

Ben.

[Antoine Beaupré]

Post by Ben Hutchings

Post by Antoine Beaupré

Post by Ben Hutchings

Post by Daniel Kahn Gillmor

Post by Antoine Beaupré
* libgcrypt20 (part of GnuTLS, 1.6 -> 1.7)

libgcrypt is not a part of GnuTLS. GnuTLS has used nettle instead of
gcrypt for years. gcrypt is more properly "part of GnuPG" than anything
else.
basically, all of these libraries are gnupg libraries.
It's a little bit distressing that upstream's attempt to split them out
as distinct libraries (which i think was intended to make them more
useful to other consumers) might be a roadblock on the way to updating
GnuPG itself.
Ben's suggestion of shipping them in a non-default location ("vendor
bundling"?) sounds pretty dubious to me -- i wouldn't want to reason
about (let alone vouch for) the upgrade path from such a hybridized
variant of jessie to standard debian stretch myself.

I was thinking that those libraries would be included in the same
binary package as /usr/bin/gpg2 and other executables, which would all
have a run-path set. No-one should need to set LD_LIBRARY_PATH so no
other executables would use those libraries, and the libraries would be
removed when the executables that use them are removed or replaced.
Since gnupg2 actually spreads executables across multiple binary
packages, I realise the libraries would have to be an additional binary
package and that would remain after an upgrade. But it would be
harmless cruft that "apt autoremove" would deal with.
(I assume that GnuPG 2.1 would be packaged as "gnupg2", replacing GnuPG
2.0 since that is no longer supported upstream. If not then I do see a
problem of how to make, say, gnupg2.1 in jessie upgrade to gnupg2 in
stretch. But that's independent of the library issue.)

I think this is overengineered. I still haven't heard exactly what the
problem would be with upgrading those libraries. They are present in
jessie-backports and presumably well tested.

[...]
Those updated library packages are installed and used by people that
specifically choose to use GnuPG 2.1 in jessie. I don't think we can
assume they are well-tested in conjunction with GnuPG 1.4.

My understanding is that GnuPG 1.4 does not use those libraries at all,
and from what I can tell, gpg 1.4 does not link against them either.

A.

[Ben Hutchings]

[...]

Post by Antoine Beaupré

Post by Ben Hutchings

Post by Antoine Beaupré
I think this is overengineered. I still haven't heard exactly what the
problem would be with upgrading those libraries. They are present in
jessie-backports and presumably well tested.

[...]
Those updated library packages are installed and used by people that
specifically choose to use GnuPG 2.1 in jessie. I don't think we can
assume they are well-tested in conjunction with GnuPG 1.4.

My understanding is that GnuPG 1.4 does not use those libraries at all,
and from what I can tell, gpg 1.4 does not link against them either.

Oh! I don't know why I thought it did. Then this does seem like a
reasonable approach.

Ben.

[Daniel Kahn Gillmor]

Post by Ben Hutchings
[...]

Post by Antoine Beaupré

Post by Ben Hutchings

Post by Antoine Beaupré
I think this is overengineered. I still haven't heard exactly what the
problem would be with upgrading those libraries. They are present in
jessie-backports and presumably well tested.

[...]
Those updated library packages are installed and used by people that
specifically choose to use GnuPG 2.1 in jessie. I don't think we can
assume they are well-tested in conjunction with GnuPG 1.4.

My understanding is that GnuPG 1.4 does not use those libraries at all,
and from what I can tell, gpg 1.4 does not link against them either.

Oh! I don't know why I thought it did. Then this does seem like a
reasonable approach.

Just confirming Anarcat's comment here. GnuPG's classic branch (1.4.x)
is a monolithic build, and does not depend on any of the libraries in
question. Those libraries are used by GnuPG 2.0.x and later.

The main place where you'll find them used is:

* things that use gcrypt directly (e.g. cryptsetup)

* things that use gpgme (e.g. gmime)

As Anarcat suggests, i believe that upstream intends the lack of an
SONAME bump to mean that they should be cleanly upgradable.

I'm not super confident in upstream's ability to maintain a stable API,
sadly. For example, some of the libraries in question -- like gcrypt --
do a lot with string-passing between the main application and the
library, which means that they don't expose API changes via function
call entrypoints, which is how debian is best at doing simple API
tracking (e.g. .symbols files). There are also data structures in some
libraries (like gpgme) that are exposed directly, but that the user is
expected to receive pointers to from the library, but not to directly
instantiate (and yes, sometimes those data structures do grow over time,
though i don't think i've ever seen them actually change in a
backward-incompatible way across a release). The library documentation
is often sparse about which data structures the users are expected to
avoid instantiating directly, though upstream is usually pretty good
about providing feedback to developers who ask questions on the
gnupg-***@gnupg.org mailing list.

All that said, i don't think that upgrading jessie to the versions of
these libraries that are in debian stretch will break jessie. I do wish
we had more substantive autopkgtest-style coverage in jessie, so that we
could feel more confident about this, but i don't think we currently do.

--dkg

[Antoine Beaupré]

Post by Daniel Kahn Gillmor
All that said, i don't think that upgrading jessie to the versions of
these libraries that are in debian stretch will break jessie. I do wish
we had more substantive autopkgtest-style coverage in jessie, so that we
could feel more confident about this, but i don't think we currently do.

So this goes back to the question of whether we should test this
further, either ourselves or through this list's participants.

I was hoping publishing the test package would trigger some feedback; it
didn't. While I can do some tests of my own, the surface area of this is
so vast that it feels somewhat pointless to run discrete tests.

What's the best way to resolve this?

A.

[Holger Levsen]

Post by Antoine Beaupré

Post by Daniel Kahn Gillmor
All that said, i don't think that upgrading jessie to the versions of
these libraries that are in debian stretch will break jessie. I do wish
we had more substantive autopkgtest-style coverage in jessie, so that we
could feel more confident about this, but i don't think we currently do.

So this goes back to the question of whether we should test this
further, either ourselves or through this list's participants.

more tests are always good. sorry, i'm a bit lost here: are (source and binary)
packages available for testing?

Post by Antoine Beaupré
What's the best way to resolve this?

(by now) everybody participating in this thread has said that this is a
sensible approach forward. so I think another call for testing is the
next step, maybe on debian-user too?

[Antoine Beaupré]

Post by Holger Levsen

Post by Antoine Beaupré

Post by Daniel Kahn Gillmor
All that said, i don't think that upgrading jessie to the versions of
these libraries that are in debian stretch will break jessie. I do wish
we had more substantive autopkgtest-style coverage in jessie, so that we
could feel more confident about this, but i don't think we currently do.

So this goes back to the question of whether we should test this
further, either ourselves or through this list's participants.

more tests are always good. sorry, i'm a bit lost here: are (source and binary)
packages available for testing?

Yes, the head email on ***@curie.anarc.at links to the test
packages:

https://people.debian.org/~anarcat/debian/jessie-lts/gnupg2_2.1.18-8~deb8u3_amd64.changes

The dependencies are in backports.

A.

[Daniel Kahn Gillmor]

Anarcat, thanks for continuing to push on this, it's really appreciated!

Post by Antoine Beaupré
I was hoping publishing the test package would trigger some feedback; it
didn't. While I can do some tests of my own, the surface area of this is
so vast that it feels somewhat pointless to run discrete tests.

I think of it the other way -- if there's a vast surface area, then
running any tests you can seems reasonable. the trick is more about how
we decide which tests to prioritize, since we're not going to run every
test.

I'd start with the things that most obviously, directly use these
libraries. so that probably means running the build-time (and maybe
run-time, if they exist?) tests for:

* cryptsetup
* gpgme
* gmime
* libotr

Then if we want to go another step further afield, try running tests
from the more relevant (popcon-based if you want to be rigorous?)
packages. off the top of my head, i'd try:

* mutt
* claws
* mcabber

And of course, if we're moving modern enigmail packaging into jessie,
then we have the modern enigmail test suite that we can try to run as
well (debian packaging for enigmail prior to what's in buster didn't
have a good test suite at all).

sound plausible? I know it's a non-trivial amount of work, but i think
if these test suites pass, and no one else has raised any concerns, it
would seem reasonable to me to move forward.

--dkg

[Antoine Beaupré]

Hi,

As I'm running out of time to work on this problem for the month, I
figured I would at least try to wrap up the conversation we had on the
topic here so we can find a solution to move forward on.

The current situation is that I have a backport of GnuPG 2.1 available
for testing here:

https://people.debian.org/~anarcat/debian/jessie-lts/

It should work with the libraries from jessie-backports, and I haven't
heard any negative (or positive) feedback on the build, so I'm going
under the assertion that it doesn't cause too much trouble.

The blocker is it depends on those four jessie-backports libraries:

* libassuan (2.1 -> 2.4)
* libgcrypt20 (1.6 -> 1.7)
* libgpg-error (1.17 -> 1.26)
* npth (1.0 -> 1.3)

All four libraries are GnuPG-specific libraries that GnuPG 1.4 does
*not* currently use. They *are*, however, used by GPGME so that means
they are (transitively) linked into any package linking against libgpgme
(and there are quite a few of those). I do hope that GPGME would
insulate consumers from such changes however.

Updating gpg through backports is not possible: -backports is closed and
will be archived soon.

I have therefore proposed to simply ship the four libraries backports in
jessie directly. The concern is that those library updates are not
"bugfix-only" releases and might not be suitable fo sur updates.

An alternative approach would be to statically link gnupg2 against those
libraries or ship them as private copies, possibly as a separate binary
package, that would remain as cruft that a stretch upgrade would 'apt
autoremove'.

So that's the state of affairs. How do we move forward?

I've unassigned myself the Enigmail package to allow others to take a
shot at this in the next two weeks.

Have fun!

A.

[Moritz Muehlenhoff]

Post by Antoine Beaupré
and I haven't
heard any negative (or positive) feedback on the build, so I'm going
under the assertion that it doesn't cause too much trouble.

Realistically that means that noone tested them.

Cheers,
Moritz