[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
specific case.

> 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:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787774#49

I made a wiki page, back then, detailing all those dependencies. I am
just re-running the script again to get an accurate picture:

https://wiki.debian.org/Javascript/Nodejs/Tasks/openpgp

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.

A.

-- 
During times of universal deceit, telling the truth becomes a
revolutionary act.       - Georges Orwell


Reply to: