Re: HEADS UP: upcoming change to libgcrypt and other gnupg libraries for Enigmail backport
On 2018-12-18 14:34:06, Emilio Pozuelo Monfort wrote:
> Looking at a jessie -> jessie-new diff, I see that several -dbg packages are
> gone in your backports.
Yes. That's because they were switched to dbgsym in stretch, but that
mecanism wasn't supported in jessie. I did a "fast" backport which meant
just dropping those, but I could possibly re-create the -dbg packages
for jessie-security, especially considering we might trigger bugs and
regressions which could really use dbg/gdb support.
> There are some mingw builds as well, which in some cases
> don't seemto be installed, but e.g. libgpg-error actually adds a mingw package.
> I would remove all that stuff.
Hmm... I *thought* I explicitely removed all that stuff, but i'll make
sure to remove that one as well, thanks for the catch!
> The npth diff is pretty trivial, basically comes down to this:
> src/npth.c | 132 ++++
Neat, I'll explicitely review that one then.
> libassuan is a bit larger, but not too bad:
> $ diff libassuan-2.*/src/ | diffstat | tail -1
> 26 files changed, 1492 insertions(+), 510 deletions(-)
> (some of that is Makefile.in)
Probably worth reviewing as well...
> libgpg-error has some autogenerated stuff, ignoring that it's mostly this:
> estream.c | 1456 +++++++++++++------
... and same.
> libgcrypt is a bit more worrying, even after dropping most of the noise:
> $ diff libgcrypt20-1.*/ | filterdiff -x '*.pc/*' -x '*/debian/*' -x '*/tests/*'
> | diffstat | tail -1
> 263 files changed, 51927 insertions(+), 14888 deletions(-)
Yeah, that's my concern as well.
Daniel, what do you think of that diff? Is that something we can
reasonably review? How much can we expect stability in that upgrade?
I know you stated before general principles of gpg vs lib / API
stability, but I'd be curious to hear your thoughts on gcrypt, in this
> FWIW I see that Ubuntu added OpenPGP.js back, and is using gnupg 2.0.x in
> trusty. We ruled that out because supporting gnupg 2.0.x is unfeasible or
> because we are missing some dependencies for OpenGPG.js ? Can't we just use the
> bundled code inside enigmail? Sorry if these questions have already been
> answered. I have looked at the various long threads but wasn't sure.
Yeah, I went down that rabbit hole... three months ago now! I documented
my work in bug #787774. It's a complicated set of nesting dependencies,
and many packages would first need to cross NEW in unstable (let alone
stretch / jessie) before this lands in Debian. A summary of the
situation is here:
I made a wiki page, back then, detailing all those dependencies. I am
just re-running the script again to get an accurate picture:
That's all stuff in unstable, mind you. All that would need to trickle
down in jessie somehow, and that includes npm/nodejs, which I am not
sure are in good health in jessie in the first place.
During times of universal deceit, telling the truth becomes a
revolutionary act. - Georges Orwell