Bug#835342: curl or git clone commands throws "gnutls_handshake() failed" on https targets

[marcel...@gmail.com]

Package: libgnutls30
Version: 3.5.3-2
Severity: important
Tags: upstream

Dear Maintainer,

Trying to git clone a github repo using libgnutls30 3.5.3-2 trhow the following
error:

fatal: unable to access 'https://github.com/xxx/yyy/': gnutls_handshake()
failed: Public key signature verification has failed.

Same happens for curl:

curl https://duckduckgo.com
curl: (35) gnutls_handshake() failed: Public key signature verification has
failed.

Downgrading to libgnutls30 3.5.2-2 solves the issue

PS.: For some reason I can't find this version on the debian repository
anymore, but I did on another machine previously and it worked as stated above:

dpkg -l | grep libgnutls
ii libgnutls30:amd64 3.5.2-2 amd64
GNU TLS library - main runtime library

PS2.: A (maybe) related bug can be found here https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=834724



-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libgnutls30 depends on:
ii libc6 2.23-5
ii libgmp10 2:6.1.1+dfsg-1
ii libhogweed4 3.2-1
ii libidn11 1.33-1
ii libnettle6 3.2-1
ii libp11-kit0 0.23.2-5
ii libtasn1-6 4.9-4
ii zlib1g 1:1.2.8.dfsg-2+b1

libgnutls30 recommends no packages.

Versions of packages libgnutls30 suggests:
pn gnutls-bin <none>

-- no debconf information

--
"Free Software is not the only way, but it's a correct way."
Marcelo Mendes
http://underlabs.org
mmendes @ IRC [OFTC-Freenode]
Gtalk: marcelomendes at gmail dot com


--
"Free Software is not the only way, but it's a correct way."
Marcelo Mendes
http://underlabs.org
mmendes @ IRC [OFTC-Freenode]
Gtalk: marcelomendes at gmail dot com

[Andreas Metzler]

On 2016-08-24 "marcel...@gmail.com" <marcel...@gmail.com> wrote:
> Package: libgnutls30
> Version: 3.5.3-2
> Severity: important
> Tags: upstream

> Dear Maintainer,

> Trying to git clone a github repo using libgnutls30 3.5.3-2 throw the

> following error:

> fatal: unable to access 'https://github.com/xxx/yyy/': gnutls_handshake()
> failed: Public key signature verification has failed.

> Same happens for curl:

> curl https://duckduckgo.com
> curl: (35) gnutls_handshake() failed: Public key signature verification has
> failed.

Hello,
Are you able to reproduce either of these errors with gnutls-cli?

> Downgrading to libgnutls30 3.5.2-2 solves the issue

> PS.: For some reason I can't find this version on the debian repository
> anymore, but I did on another machine previously and it worked as stated above:

The Debian mirrors only carry packages which are part of release
(stable, unstable, testing, etc.). 3.5.2-2 is not. Old versions can be
found on http://snapshot.debian.org/

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

[marcel...@gmail.com]

2016-08-25 13:25 GMT-04:00 Andreas Metzler <amet...@bebt.de>:
> On 2016-08-24 "marcel...@gmail.com" <marcel...@gmail.com> wrote:
>> Package: libgnutls30
>> Version: 3.5.3-2
>> Severity: important
>> Tags: upstream
>
>> Dear Maintainer,
>
>> Trying to git clone a github repo using libgnutls30 3.5.3-2 throw the
>> following error:
>
>> fatal: unable to access 'https://github.com/xxx/yyy/': gnutls_handshake()
>> failed: Public key signature verification has failed.
>
>> Same happens for curl:
>
>> curl https://duckduckgo.com
>> curl: (35) gnutls_handshake() failed: Public key signature verification has
>> failed.
>
> Hello,
> Are you able to reproduce either of these errors with gnutls-cli?

First, let me say I'm behind a proxy server.

Both versions of gnutls-bin (3.5.3-3 and the old 3.5.2-3) have the
same behavior:

gnutls-cli -V --port 443 duckduckgo.com
Processed 173 CA certificate(s).
Resolving 'duckduckgo.com:443'...
Connecting to '107.21.1.61:443'...
Connecting to '184.72.106.52:443'...
Connecting to '184.72.115.86:443'...

and stay there for some quit some time until I ctrl+c

But, with the old version of libgnutls30 (3.5.2-3) got from here:
http://snapshot.debian.org/package/gnutls28/3.5.2-3/#libgnutls30_3.5.2-3
commands like git clone/pull works and curl -I https://... works too.

I tried from my vps and this issue doesn't happen with either version,
thats a weird thing :)

Out of curiosity, the commands worked from inside a ubuntu-xenial
vagrant box (virtualbox vms) with older versions of libgnutls30
(3.4.x)

>> Downgrading to libgnutls30 3.5.2-2 solves the issue
>
>> PS.: For some reason I can't find this version on the debian repository
>> anymore, but I did on another machine previously and it worked as stated above:
>
> The Debian mirrors only carry packages which are part of release
> (stable, unstable, testing, etc.). 3.5.2-2 is not. Old versions can be
> found on http://snapshot.debian.org/
>
> cu Andreas
> --
> `What a good friend you are to him, Dr. Maturin. His other friends are
> so grateful to you.'
> `I sew his ears on from time to time, sure'

[Stefan Bühler]

Hi Marcelo,

On Fri, 26 Aug 2016 10:30:51 -0400 "marcel...@gmail.com"
<marcel...@gmail.com> wrote:
> 2016-08-25 13:25 GMT-04:00 Andreas Metzler <amet...@bebt.de>:
> > On 2016-08-24 "marcel...@gmail.com" <marcel...@gmail.com>
> > wrote:
> >> Package: libgnutls30
> >> Version: 3.5.3-2
> >> Severity: important
> >> Tags: upstream
> >
> >> Dear Maintainer,
> >
> >> Trying to git clone a github repo using libgnutls30 3.5.3-2 throw
> >> the following error:
> >
> >> fatal: unable to access 'https://github.com/xxx/yyy/':
> >> gnutls_handshake() failed: Public key signature verification has
> >> failed.
> >
> >> Same happens for curl:
> >
> >> curl https://duckduckgo.com
> >> curl: (35) gnutls_handshake() failed: Public key signature
> >> verification has failed.
> >
> > Hello,
> > Are you able to reproduce either of these errors with gnutls-cli?
>
> First, let me say I'm behind a proxy server.

Does the proxy happen to intercept TLS, i.e. is it a local CA and
creates certificates on demand, which might fail the verification?

Perhaps you could get a pcap with tcpdump of the connection(s) from
curl to the proxy?

tcpdump -i eno1 -w curl-to-proxy.pcap 'host <proxy-ip> and port <proxy-port>'

> Both versions of gnutls-bin (3.5.3-3 and the old 3.5.2-3) have the
> same behavior:
>
> gnutls-cli -V --port 443 duckduckgo.com
> Processed 173 CA certificate(s).
> Resolving 'duckduckgo.com:443'...
> Connecting to '107.21.1.61:443'...
> Connecting to '184.72.106.52:443'...
> Connecting to '184.72.115.86:443'...
>
> and stay there for some quit some time until I ctrl+c

I don't think gnutls-cli supports a proxy directly; you'd probably
have to use some LD_PRELOAD proxy wrapper (e.g. tsocks or similar).

[Andreas Metzler]

On 2016-08-26 "marcel...@gmail.com" <marcel...@gmail.com> wrote:
> 2016-08-25 13:25 GMT-04:00 Andreas Metzler <amet...@bebt.de>:
>> On 2016-08-24 "marcel...@gmail.com" <marcel...@gmail.com> wrote:
>>> Package: libgnutls30
>>> Version: 3.5.3-2

[...]

>>> Trying to git clone a github repo using libgnutls30 3.5.3-2 throw the
>>> following error:

>>> fatal: unable to access 'https://github.com/xxx/yyy/': gnutls_handshake()
>>> failed: Public key signature verification has failed.

>>> Same happens for curl:

>>> curl https://duckduckgo.com
>>> curl: (35) gnutls_handshake() failed: Public key signature verification has
>>> failed.

>> Are you able to reproduce either of these errors with gnutls-cli?

> First, let me say I'm behind a proxy server.

[ no. Looks like no access without proxy, which gnutls-cli does not
seem to support ]

Could use git bisect to find the offending commit?

[Andreas Metzler]

Control: tags -1 moreinfo

On 2016-08-28 Andreas Metzler <amet...@bebt.de> wrote:
> On 2016-08-26 "marcelo...@gmail.com" <marcel...@gmail.com> wrote:
[...]

> > First, let me say I'm behind a proxy server.
> [ no. Looks like no access without proxy, which gnutls-cli does not
> seem to support ]

> Could use git bisect to find the offending commit?

Any specific difficulties I could help you with there?

[marcel...@gmail.com]

---------- Forwarded message ----------
From: marcel...@gmail.com <marcel...@gmail.com>
Date: 2016-09-13 9:25 GMT-04:00
Subject: Re: Bug#835342: curl or git clone commands throws
"gnutls_handshake() failed" on https targets
To: Andreas Metzler <amet...@bebt.de>

2016-09-03 1:51 GMT-04:00 Andreas Metzler <amet...@bebt.de>:
> Control: tags -1 moreinfo
>
> On 2016-08-28 Andreas Metzler <amet...@bebt.de> wrote:
>> On 2016-08-26 "marcelo...@gmail.com" <marcel...@gmail.com> wrote:
> [...]
>> > First, let me say I'm behind a proxy server.
>> [ no. Looks like no access without proxy, which gnutls-cli does not
>> seem to support ]
>
>> Could use git bisect to find the offending commit?
>
> Any specific difficulties I could help you with there?

Never used git bisect before, so I don't know how much time until I
figure out how it works and give you proper feedback.

Today 13/09 I noticed a new version of gnutls-bin and libgnutls30 (3.5.4-2)

Tried to do a "vagrant box update" to update my boxes and got the same
little error, now from vagrant:

---------------------
There was an error while downloading the metadata for this box.
The error message is shown below:

gnutls_handshake() failed: Public key signature verification has failed.

---------------------

Then, I downgrade manually to the working version:

-------------------
sudo dpkg -i libgnutls30_3.5.2-3_amd64.deb gnutls-bin_3.5.2-3_amd64.deb
dpkg: warning: downgrading libgnutls30:amd64 from 3.5.4-2 to 3.5.2-3
(Reading database ... 365601 files and directories currently installed.)
Preparing to unpack libgnutls30_3.5.2-3_amd64.deb ...
Unpacking libgnutls30:amd64 (3.5.2-3) over (3.5.4-2) ...
dpkg: warning: downgrading gnutls-bin from 3.5.4-2 to 3.5.2-3
Preparing to unpack gnutls-bin_3.5.2-3_amd64.deb ...
Unpacking gnutls-bin (3.5.2-3) over (3.5.4-2) ...
Setting up libgnutls30:amd64 (3.5.2-3) ...
Setting up gnutls-bin (3.5.2-3) ...
Processing triggers for libc-bin (2.24-2) ...
Processing triggers for man-db (2.7.5-1) ...
--------------------

And everything works as expected with vagrant, git, curl, etc.

[Andreas Metzler]

On 2016-09-13 "marcel...@gmail.com" <marcel...@gmail.com> wrote:
> 2016-09-03 1:51 GMT-04:00 Andreas Metzler <amet...@bebt.de>:
{git bisect]

> > Any specific difficulties I could help you with there?

> Never used git bisect before, so I don't know how much time until I
> figure out how it works and give you proper feedback.

In essence you tell git that revision #50 worked and #100 didn't. Then
git checks out #75 for you to test. Depending on whether #75 was already
broken it then moves on to let you check either #62 or #87, continously
narrowing down the suspect subset and after ten tries or so you know
which commit broke.

> Today 13/09 I noticed a new version of gnutls-bin and libgnutls30 (3.5.4-2)

> Tried to do a "vagrant box update" to update my boxes and got the same
> little error, now from vagrant:

[...]

> sudo dpkg -i libgnutls30_3.5.2-3_amd64.deb gnutls-bin_3.5.2-3_amd64.deb

[...]

> And everything works as expected with vagrant, git, curl, etc.

In short you need this:

sudo apt-get install gperf build-essential
sudo apt-get build-dep gnutls28
ametzler@argenau:~$ mkdir /tmp/GNUTLS
ametzler@argenau:~$ cd /tmp/GNUTLS
ametzler@argenau:/tmp/GNUTLS$ git clone git://gitlab.com/gnutls/gnutls.git
ametzler@argenau:/tmp/GNUTLS$ cd gnutls
ametzler@argenau:/tmp/GNUTLS/gnutls$ git submodule update --init
[... wait ... ]
ametzler@argenau:/tmp/GNUTLS/gnutls$ git bisect start
ametzler@argenau:/tmp/GNUTLS/gnutls$ git bisect good gnutls_3_5_2
ametzler@argenau:/tmp/GNUTLS/gnutls$ git bisect bad gnutls_3_5_3
Bisecting: 75 revisions left to test after this (roughly 6 steps)
[72650a09530d5e62a6e6aa5aae4e74955ff1b384] doc: added section on reducing round-trips
ametzler@argenau:/tmp/GNUTLS/gnutls$ make bootstrap && ./configure && make -j4 ; echo build-exit $?
ametzler@argenau:/tmp/GNUTLS/gnutls$ git clean -f -x && git clean -d -x -f

Now you have got a freshly built gnutls library in
/tmp/GNUTLS/gnutls/lib/.libs and can run your test:

ametzler@argenau:/some/directory$ env LD_LIBRARY_PATH=/tmp/GNUTLS/gnutls/lib/.libs some-failing-command

Then you tell git about the test result:
success -> git bisect good
error -> git bisect bad
clean the repo
ametzler@argenau:/tmp/GNUTLS/gnutls$ git clean -f -x && git clean -d -x -f
and start the build again (at make bootstrap).

If the repository contains a broken commit that does not even compile
you can jump to the next one with "git bisect skip".

[marcel...@gmail.com]

2016-09-13 13:50 GMT-04:00 Andreas Metzler <amet...@bebt.de>:
> On 2016-09-13 "marcel...@gmail.com" <marcel...@gmail.com> wrote:
>> 2016-09-03 1:51 GMT-04:00 Andreas Metzler <amet...@bebt.de>:
> {git bisect]
>> > Any specific difficulties I could help you with there?
>
>> Never used git bisect before, so I don't know how much time until I
>> figure out how it works and give you proper feedback.
>
> In essence you tell git that revision #50 worked and #100 didn't. Then
> git checks out #75 for you to test. Depending on whether #75 was already
> broken it then moves on to let you check either #62 or #87, continously
> narrowing down the suspect subset and after ten tries or so you know
> which commit broke.
>
>> Today 13/09 I noticed a new version of gnutls-bin and libgnutls30 (3.5.4-2)
>
>> Tried to do a "vagrant box update" to update my boxes and got the same
>> little error, now from vagrant:
> [...]
>> sudo dpkg -i libgnutls30_3.5.2-3_amd64.deb gnutls-bin_3.5.2-3_amd64.deb
> [...]
>> And everything works as expected with vagrant, git, curl, etc.
>
> In short you need this:
>

...

> cu Andreas
> --
> `What a good friend you are to him, Dr. Maturin. His other friends are
> so grateful to you.'
> `I sew his ears on from time to time, sure'

Hey there,
After struggling a bit with the process of "bisecting", I think I got
something :).
You can view git bisect log here http://pastebin.com/sj1ZbbqA

c801a15bca9ea8f3f7abd4be48bebd36c54eeba2 is the first bad commit
commit c801a15bca9ea8f3f7abd4be48bebd36c54eeba2
Author: Nikos Mavrogiannopoulos <nm...@redhat.com>
Date: Mon Aug 1 10:48:46 2016 +0200

nettle: use rsa_*_key_prepare

Previously we calculated the size of the key directly, but
by using the rsa_*_key_prepare we benefit from any checks that
may be introduced in the future. Specifically any checks for invalid
public keys (e.g., keys that may crash the underlying gmp functions).

:040000 040000 29a2377df28240d7688082ac12318baacdd1bb7c
23aa890386085677a878268578e9a2c27d396c80 Mlib



It seems the commit "b0d560b" reverts "c801a15", and commit 186dc9c
breaks it again.

I hope that helps.

[Andreas Metzler]

On 2016-09-16 "marcel...@gmail.com" <marcel...@gmail.com> wrote:
[...]

> After struggling a bit with the process of "bisecting", I think I got
> something :).
> You can view git bisect log here http://pastebin.com/sj1ZbbqA

[...]

Thank you. Could you please alo provide a session capture?

How to:
| I'd run wireshark -i eth0 (replace eth0 with the ethernet interface
| name), and click start capture.
| Then on another terminal run the command that makes the TLS connection
| fail.
| Then click capture -> Stop, In "apply display filter", type ssl, then
| File -> Export specified packets and send the saved pcap file.

[marcel...@gmail.com]

2016-09-17 12:15 GMT-04:00 Andreas Metzler <amet...@bebt.de>:
> On 2016-09-16 "marcel...@gmail.com" <marcel...@gmail.com> wrote:
> [...]
>> After struggling a bit with the process of "bisecting", I think I got
>> something :).
>> You can view git bisect log here http://pastebin.com/sj1ZbbqA
> [...]
>
> Thank you. Could you please alo provide a session capture?
>
> How to:
> | I'd run wireshark -i eth0 (replace eth0 with the ethernet interface
> | name), and click start capture.
> | Then on another terminal run the command that makes the TLS connection
> | fail.
> | Then click capture -> Stop, In "apply display filter", type ssl, then
> | File -> Export specified packets and send the saved pcap file.

This link has two files:

pcap_gnutls.pcapng (Fail, libgnutls30:amd64 3.5.4-2)
pcap_gnutls_v352.pcapng (Working version, libgnutls30:amd64 3.5.2-3)

https://drive.google.com/drive/folders/0B3_AQUiHn1qMcEVjdVpNeHBJUHc

Cheers.

[Andreas Metzler]

On 2016-09-19 "marcel...@gmail.com" <marcel...@gmail.com> wrote:
> 2016-09-17 12:15 GMT-04:00 Andreas Metzler <amet...@bebt.de>:

[...]

> > | Then click capture -> Stop, In "apply display filter", type ssl, then
> > | File -> Export specified packets and send the saved pcap file.

> This link has two files:

> pcap_gnutls.pcapng (Fail, libgnutls30:amd64 3.5.4-2)
> pcap_gnutls_v352.pcapng (Working version, libgnutls30:amd64 3.5.2-3)

> https://drive.google.com/drive/folders/0B3_AQUiHn1qMcEVjdVpNeHBJUHc

Hello Marcelo,

this seems to be hard to debug/reproduce, Nikos (upstream) writes:

=======================================================================
I do not see anything wrong in the capture. I even created a small
program to replay the connection locally (I have a debian installation
on x86_64 with the same packages available), and the connection
continued past the failure point on that system.

I'm searching in the dark here, but the following info could help:
1. run gnutls-cli www.server-that-fails -d 9
2. run valgrind gnutls-cli www.server-that-fails
3. compile the attached program as "gcc -O2 -g sim.c -lgmp -lhogweed &&
./a.out", and also run valgrind ./a.out

[...]
One 4th item suggested by Niels Moeller:
4. run ldd /usr/bin/gnutls-cli # (that way we can see whether the
client is linked to the expected nettle library)
=======================================================================

[marcel...@gmail.com]

2016-09-20 12:48 GMT-04:00 Andreas Metzler <amet...@bebt.de>:
> On 2016-09-19 "marcel...@gmail.com" <marcel...@gmail.com> wrote:
>> 2016-09-17 12:15 GMT-04:00 Andreas Metzler <amet...@bebt.de>:
> [...]
>> > | Then click capture -> Stop, In "apply display filter", type ssl, then
>> > | File -> Export specified packets and send the saved pcap file.
>
>> This link has two files:
>
>> pcap_gnutls.pcapng (Fail, libgnutls30:amd64 3.5.4-2)
>> pcap_gnutls_v352.pcapng (Working version, libgnutls30:amd64 3.5.2-3)
>
>> https://drive.google.com/drive/folders/0B3_AQUiHn1qMcEVjdVpNeHBJUHc
>
> Hello Marcelo,
>
> this seems to be hard to debug/reproduce, Nikos (upstream) writes:

Yeah, I know, I'm following his replies.

I saw that he is making his tests using gnutls-cli, but as I stated
before, gnutls-cli doesn't work at all behind the proxy here.
Regardless of the version, either 3.5.2-x or 3.5.3+

The commands that I'm using to test are curl and git (and vagrant).
And these commands only work if I'm using libgnutls30:amd64 3.5.2-3.

>
> =======================================================================
> I do not see anything wrong in the capture. I even created a small
> program to replay the connection locally (I have a debian installation
> on x86_64 with the same packages available), and the connection
> continued past the failure point on that system.
>
> I'm searching in the dark here, but the following info could help:
> 1. run gnutls-cli www.server-that-fails -d 9

Same as shown in Message #15, except with the debug

> 2. run valgrind gnutls-cli www.server-that-fails
> 3. compile the attached program as "gcc -O2 -g sim.c -lgmp -lhogweed &&
> ./a.out", and also run valgrind ./a.out

I could try this, but where is the source code?

> [...]
> One 4th item suggested by Niels Moeller:
> 4. run ldd /usr/bin/gnutls-cli # (that way we can see whether the
> client is linked to the expected nettle library)
> =======================================================================

ldd /usr/lib/x86_64-linux-gnu/libgnutls.so.30.10.0

linux-vdso.so.1 (0x00007ffc34f7d000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f5cdb8a7000)
libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0
(0x00007f5cdb642000)
libidn.so.11 => /lib/x86_64-linux-gnu/libidn.so.11 (0x00007f5cdb40e000)
libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f5cdb1fb000)
libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x00007f5cdafc4000)
libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4
(0x00007f5cdad8d000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f5cdab0a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5cda76c000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f5cda563000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5cda35f000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5cda142000)
/lib64/ld-linux-x86-64.so.2 (0x0000561651905000)

ldd /usr/bin/gnutls-cli

linux-vdso.so.1 (0x00007ffd0c36b000)
libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30
(0x00007f57473f3000)
libopts.so.25 => /usr/lib/x86_64-linux-gnu/libopts.so.25 (0x00007f57471d2000)
libidn.so.11 => /lib/x86_64-linux-gnu/libidn.so.11 (0x00007f5746f9e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5746c00000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f57469e5000)
libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0
(0x00007f574677e000)
libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f574656b000)
libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x00007f5746334000)
libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4
(0x00007f57460ff000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f5745e7c000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5745b78000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5745972000)
/lib64/ld-linux-x86-64.so.2 (0x00005581363e8000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f5745769000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f574554c000)

dpkg -l | grep nettle
ii libnettle4:amd64 2.7.1-5+deb8u1
amd64 low level cryptographic library (symmetric and
one-way cryptos)
ii libnettle6:amd64 3.2-1
amd64 low level cryptographic library (symmetric and
one-way cryptos)
ii nettle-dev 3.2-1
amd64 low level cryptographic library (development files)

[Mariusz Gronczewski]

Hi,

I've hit same bug, Upgrading librtmp to latest (in testing, 2.4+20151223.gitfa8646d.1-1) fixed it for me. To be exact:

Unpacking librtmp1:amd64 (2.4+20151223.gitfa8646d.1-1) over (2.4+20150115.gita107cef-1)

--

Mariusz Gronczewski (XANi) <xan...@gmail.com>
GnuPG: 0xEA8ACE64

[marcel...@gmail.com]

Ok, this is very odd!
Long time ago I did some testing with some deb-multimedia packages.
After the tests I made a clean up and removed all the packages, and
the repo from my source lists, until the libgnutls30 upgrade
everything was fine. Now when Mariusz pointed out his experience with
similar issue I went to check the package and:

As you can see, this package (librtmp1) remained of the deb-multimedia
packages and has a old libgnutls dependency, my clean up wasn't so
clean after all. :(

---------------------------------------------
Package: librtmp1
Version: 1:2.4+20130918.git79459a2-dmo6
State: installed
Automatically installed: yes
Multi-Arch: same
Priority: extra
Section: libs
Maintainer: Christian Marillat <mari...@deb-multimedia.org>
Architecture: amd64
Uncompressed Size: 160 k
Depends: libc6 (>= 2.14), libgmp10, libgnutls-deb0-28 (>= 3.2.10-0),
libhogweed2, libnettle4, zlib1g (>= 1:1.1.4)
PreDepends: multiarch-support
Breaks: librtmp1:i386 (!= 1:2.4+20130918.git79459a2-dmo6)
Replaces: librtmp1:i386 (< 1:2.4+20130918.git79459a2-dmo6)
Description: Toolkit for RTMP streams (shared library).
A small dumper for media content streamed over the RTMP protocol
(like BBC's iPlayer high quality streams). Supplying an RTMP URL will
result in a dumped flv file, which can
be played/transcoded with standard tools.

This package contains the shared libraries, header files needed by
programs that want to use librtmp.
Homepage: http://rtmpdump.mplayerhq.hu/
Tags: role::shared-lib
---------------------------------------------


When I downgraded(!) to from multimedia package to debian package, as
suggested by Mariusz:

Unpacking librtmp1:amd64 (2.4+20151223.gitfa8646d.1-1) over

(1:2.4+20130918.git79459a2-dmo6) ...
Setting up librtmp1:amd64 (2.4+20151223.gitfa8646d.1-1) ...

Things are now working again.

I'm still curious to know why the package didn't upgrade since the
version of debian is from 20151223


That was a bit of a mess (my fault), but I'm glad things get to work again.

Thanks Mariusz for pointing out, and Thanks to Andreas and Nikos for
the pentience. :)

[Nikos Mavrogiannopoulos]

Thanks for the update, your case was really challenging my computing
knowledge :)
However, out of curiosity how does librtmp comes into play here? It
doesn't seem to be a dependency (direct at least) or either curl or
git.

[marcel...@gmail.com]

Both libcurl3-gnutls and libcurl3 depends on librtmp1
and git depends on libcurl3-gnutls

Thats the only relation I could find