Bug#885127: vlc: Cast Chromecast unusable due to gnutls error

[floris]

Package: src:vlc
Version: 3.0.0~rc2-2
Severity: normal

Dear Maintainer,

I'm unable to cast a video with vlc to the chromecast due to a gnutls error:

From command line or via Video -> Renderer -> Scan -> Chromecast

vlc -vv --sout="#chromecast{ip=192.168.1.14}" test.mp4

...
[00007ff9a0003020] gnutls tls client debug: using GnuTLS version 3.5.16
[0000558879fa27c0] qt interface debug: IM: Setting an input
[00007ff9a0003020] gnutls tls client debug: loaded 149 trusted CAs from system
[00007ff9a0003020] main tls client debug: using tls client module "gnutls"
[00007ff9a0003020] main tls client debug: resolving 192.168.1.14 ...
[00007ff9a0003020] gnutls tls client debug: TLS handshake: Resource temporarily
unavailable, try again.
[00007ff9a0003020] gnutls tls client debug: TLS handshake: Success.
[00007ff9a0003020] gnutls tls client debug: - safe renegotiation (RFC5746)
enabled
[00007ff9a0003020] gnutls tls client debug: - extended master secret (RFC7627)
enabled
[00007ff9a0003020] gnutls tls client debug: - false start (RFC7918) enabled
[00007ff9a0003020] gnutls tls client error: Certificate verification failure:
The certificate is NOT trusted. The certificate issuer is unknown. The
certificate chain uses insecure algorithm. The name in the certificate does not
match the expected.
[00007ff9a0003020] main tls client error: TLS session handshake error
[00007ff9a0003020] main tls client error: connection error: Resource
temporarily unavailable
[00007ff9a0000ec0] stream_out_chromecast stream out error: cannot load the
Chromecast controller (Failed to create client session)
[00007ff9a0000ec0] main stream out debug: no sout stream modules matched
[00007ff9a0000ec0] main stream out debug: destroying chain... (name=(null))
[00007ff9a0000ec0] main stream out debug: destroying chain done
[00007ff9a0000ba0] main stream output error: stream chain failed for
`chromecast{ip=192.168.1.14}'
[00007ff9a80009e0] main input error: cannot start stream output instance,
aborting
[0000558879f5d250] main playlist debug: dead input
...

Apparently, on a windows machine you get a "trust this certificate" pop-up
window and you are able to import the chromecast certificate. In Debian
there isn't such window. How to accept the chromecast certificate?

Other programs (mkchromecast and google-chrome) are able to use the chromecast
without errors.



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

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

Versions of packages vlc depends on:
ii vlc-bin 3.0.0~rc2-2
ii vlc-l10n 3.0.0~rc2-2
ii vlc-plugin-base 3.0.0~rc2-2
ii vlc-plugin-qt 3.0.0~rc2-2
ii vlc-plugin-video-output 3.0.0~rc2-2

Versions of packages vlc recommends:
ii vlc-plugin-notify 3.0.0~rc2-2
ii vlc-plugin-samba 3.0.0~rc2-2
ii vlc-plugin-skins2 3.0.0~rc2-2
ii vlc-plugin-video-splitter 3.0.0~rc2-2
ii vlc-plugin-visualization 3.0.0~rc2-2

vlc suggests no packages.

Versions of packages libvlc-bin depends on:
ii libc6 2.25-5
ii libvlc5 3.0.0~rc2-2

Versions of packages libvlc5 depends on:
ii libc6 2.25-5
ii libvlccore9 3.0.0~rc2-2

Versions of packages libvlc5 recommends:
ii libvlc-bin 3.0.0~rc2-2

Versions of packages vlc-bin depends on:
ii libc6 2.25-5
ii libvlc-bin 3.0.0~rc2-2
ii libvlc5 3.0.0~rc2-2

Versions of packages vlc-plugin-base depends on:
ii liba52-0.7.4 0.7.4-19
ii libarchive13 3.2.2-3.1
ii libaribb24-0 1.0.3-1
ii libasound2 1.1.3-5
ii libass9 2:0.14.0-dmo1
ii libavahi-client3 0.7-3
ii libavahi-common3 0.7-3
ii libavc1394-0 0.5.4-4+b1
ii libavcodec57 10:3.4.1-dmo2
ii libavformat57 10:3.4.1-dmo2
ii libavutil55 10:3.4.1-dmo2
ii libbasicusageenvironment1 2017.10.28-2
ii libbluray2 2:1.0.2-dmo2
ii libc6 2.25-5
ii libcairo2 1.15.8-3
ii libcddb2 1.3.2-5
ii libchromaprint1 1:1.4.2-dmo1
ii libcrystalhd3 1:0.0~git20110715.fdd2f19-12
ii libdbus-1-3 1.12.2-1
ii libdc1394-22 2.2.5-1
ii libdca0 0.0.5-dmo3
ii libdvbpsi10 1.3.1-2
ii libdvdnav4 5.0.3-3
ii libdvdread4 5.0.3-2
ii libebml4v5 1:1.3.5-dmo1
ii libfaad2 2.8.8-1
ii libflac8 1.3.2-1
ii libfontconfig1 2.12.6-0.1
ii libfreetype6 2.8.1-0.1
ii libfribidi0 0.19.7-2
ii libgcc1 1:7.2.0-18
ii libgcrypt20 1.8.1-4
ii libglib2.0-0 2.54.2-4
ii libgnutls30 3.5.16-1
ii libgpg-error0 1.27-5
ii libgroupsock8 2017.10.28-2
ii libharfbuzz0b 1.7.2-1
ii libjpeg62-turbo 1:1.5.2-2+b1
ii libkate1 0.4.1-7+b1
ii liblirc-client0 0.10.0-2+b1
ii liblivemedia61 2017.10.28-2
ii liblua5.2-0 5.2.4-1.1+b2
ii libmad0 0.15.1b-8.1
ii libmatroska6v5 1:1.4.8-dmo1
ii libmicrodns0 0.0.8-1
ii libmpcdec6 2:0.1~r495-1+b1
ii libmpeg2-4 0.5.1-8
ii libmpg123-0 1.25.8-1
ii libmtp9 1.1.13-1
ii libncursesw5 6.0+20171125-1
ii libnfs8 1.11.0-2
ii libogg0 1.3.2-1+b1
ii libopenmpt-modplug1 0.3.4-1
ii libopus0 1.2.1-1
ii libpng16-16 1.6.34-1
ii libpostproc54 10:3.4.1-dmo2
ii libprotobuf-lite10 3.0.0-9.1
ii libpulse0 11.1-4
ii libraw1394-11 2.1.2-1+b1
ii libresid-builder0c2a 2.1.1-15
ii librsvg2-2 2.40.20-1
ii libsamplerate0 0.1.9-1
ii libsdl-image1.2 1.2.12-7
ii libsdl1.2debian 1.2.15+dfsg2-0.1
ii libsecret-1-0 0.18.5-5
ii libshine3 3.1.1-1
ii libshout3 2.4.1-2
ii libsidplay2 2.1.1-15
ii libsndio6.1 1.1.0-3
ii libsoxr0 0.1.2-3
ii libspeex1 1.2~rc1.2-1+b2
ii libspeexdsp1 1.2~rc1.2-1+b2
ii libssh2-1 1.8.0-1
ii libstdc++6 7.2.0-18
ii libswscale4 10:3.4.1-dmo2
ii libsystemd0 236-1
ii libtag1v5 1.11.1+dfsg.1-0.2
ii libtheora0 1.1.1+dfsg.1-14+b1
ii libtinfo5 6.0+20171125-1
ii libtwolame0 1:0.3.13-dmo3
ii libudev1 236-1
ii libupnp6 1:1.6.24-4
ii libusageenvironment3 2017.10.28-2
ii libva-drm2 2.0.0-2
ii libva2 2.0.0-2
ii libvlccore9 [vlc-plugin-abi-3-0-0f] 3.0.0~rc2-2
ii libvorbis0a 1.3.5-4
ii libvorbisenc2 1.3.5-4
ii libx264-148 2:0.148.2795+gitaaa9aa8-1
ii libx265-146 1:2.6-dmo1
ii libxcb-keysyms1 0.4.0-1+b2
ii libxcb1 1.12-1
ii libxml2 2.9.4+dfsg1-5.2
ii libzvbi0 0.2.35-13
ii vlc-data 3.0.0~rc2-2
ii zlib1g 1:1.2.8.dfsg-5

Versions of packages vlc-plugin-base recommends:
ii xdg-utils 1.1.2-1

Versions of packages vlc-plugin-base suggests:
ii libdvdcss2 1.4.0-dmo2

Versions of packages vlc-plugin-notify depends on:
ii libc6 2.25-5
ii libgdk-pixbuf2.0-0 2.36.11-1
ii libglib2.0-0 2.54.2-4
ii libgtk-3-0 3.22.26-2
ii libnotify4 0.7.7-3
ii libvlccore9 [vlc-plugin-abi-3-0-0f] 3.0.0~rc2-2

Versions of packages vlc-plugin-qt depends on:
ii libc6 2.25-5
ii libgcc1 1:7.2.0-18
ii libqt5core5a 5.9.2+dfsg-6
ii libqt5gui5 5.9.2+dfsg-6
ii libqt5svg5 5.9.2-3
ii libqt5widgets5 5.9.2+dfsg-6
ii libqt5x11extras5 5.9.2-1
ii libstdc++6 7.2.0-18
ii libvlccore9 [vlc-plugin-abi-3-0-0f] 3.0.0~rc2-2
ii libwayland-client0 1.14.0-1+b1
ii libx11-6 2:1.6.4-3

Versions of packages vlc-plugin-qt recommends:
ii vlc-bin 3.0.0~rc2-2

Versions of packages vlc-plugin-skins2 depends on:
ii fonts-freefont-ttf 20120503-7
ii libc6 2.25-5
ii libfreetype6 2.8.1-0.1
ii libfribidi0 0.19.7-2
ii libgcc1 1:7.2.0-18
ii libstdc++6 7.2.0-18
ii libvlccore9 [vlc-plugin-abi-3-0-0f] 3.0.0~rc2-2
ii libx11-6 2:1.6.4-3
ii libxext6 2:1.3.3-1+b2
ii libxinerama1 2:1.1.3-1+b3
ii libxpm4 1:3.5.12-1
ii vlc-plugin-qt 3.0.0~rc2-2

Versions of packages vlc-plugin-skins2 recommends:
ii vlc-bin 3.0.0~rc2-2

Versions of packages vlc-plugin-video-output depends on:
ii libaa1 1.4p5-44+b1
ii libavcodec57 10:3.4.1-dmo2
ii libavutil55 10:3.4.1-dmo2
ii libc6 2.25-5
ii libcaca0 0.99.beta19-2+b2
ii libegl1 1.0.0-1
ii libgl1 1.0.0-1
ii libgles2 1.0.0-1
ii libva-drm2 2.0.0-2
ii libva-wayland2 2.0.0-2
ii libva-x11-2 2.0.0-2
ii libva2 2.0.0-2
ii libvlccore9 [vlc-plugin-abi-3-0-0f] 3.0.0~rc2-2
ii libwayland-client0 1.14.0-1+b1
ii libwayland-egl1-mesa [libwayland-egl1] 17.3.1-1
ii libx11-6 2:1.6.4-3
ii libxcb-keysyms1 0.4.0-1+b2
ii libxcb-shm0 1.12-1
ii libxcb-xv0 1.12-1
ii libxcb1 1.12-1

Versions of packages vlc-plugin-video-splitter depends on:
ii libc6 2.25-5
ii libvlccore9 [vlc-plugin-abi-3-0-0f] 3.0.0~rc2-2
ii libxcb-randr0 1.12-1
ii libxcb1 1.12-1

Versions of packages vlc-plugin-visualization depends on:
ii libc6 2.25-5
ii libgl1 1.0.0-1
ii libvlccore9 [vlc-plugin-abi-3-0-0f] 3.0.0~rc2-2

-- no debconf information

[Rémi Denis-Courmont]

That popup also exists in Linux. But it is not adequate to handle insecure
algorithms, only unknown or mismatched certificates.

> In Debian
> there isn't such window. How to accept the chromecast certificate?

The TLS support within VLC is identical for Windows and Linux. The difference
is the Windows version ships an older version of GnuTLS, than that in Debian.
Presumably, the server is using SHA-1 certificate signatures - which are being
phased out industry-wide, and no longer accepted by newer GnuTLS version.

I don't see how this is a VLC bug. It's actually working as intended. If you
think the diagnostic is wrong, then it's a problem with GnuTLS.

--
Rémi Denis-Courmont

[Floris]

>>
>> Apparently, on a windows machine you get a "trust this certificate"
>> pop-up
>> window and you are able to import the chromecast certificate.
>
> That popup also exists in Linux. But it is not adequate to handle
> insecure
> algorithms, only unknown or mismatched certificates.
>
>> In Debian
>> there isn't such window. How to accept the chromecast certificate?
>
> The TLS support within VLC is identical for Windows and Linux. The
> difference
> is the Windows version ships an older version of GnuTLS, than that in
> Debian.
> Presumably, the server is using SHA-1 certificate signatures - which are
> being
> phased out industry-wide, and no longer accepted by newer GnuTLS version.
>
> I don't see how this is a VLC bug. It's actually working as intended. If
> you
> think the diagnostic is wrong, then it's a problem with GnuTLS.
>

I'm not sure this is a VLC bug, although I think it is odd that VLC 3 has
a Chromecast feature, but it isn't working. Maybe build vlc without
Chromecast support in Debian until Google and/ or GnuTLS has a decent fix
for this issue. Or make a workaround.

[Floris]

To accept the Chromecast certificate:
1. Get the certificate with gnutls-cli
$ gnutls-cli --save-cert=chromecast.pem 192.168.1.14:8009

2. Start VLC with the --gnutls-dir-trust option
$ vlc -vv --gnutls-dir-trust=/home/floris
--sout="#chromecast{ip=192.168.1.14}" <video file>

3. A pop-up window appears with a "Insecure site" warning. Here you can
accept the certificate.

[Rémi Denis-Courmont]

reassign 885127 libgnutls30
found 885127 3.5.16-1
affects 885127 vlc
tags 885127 + upstream confirmed
thanks

Hello,

The version of GnuTLS in Debian incorrectly flags self-signed certificates as
insecure certificate chain algorithm. This makes no sense; the flag is for
certificate chains using insecure algorithms such as MD2, MD5 and SHA-1.

This is reproducible also with gnutls-bin (both with Debian and upstream
GnuTLS):

# gnutls-cli self-signed.badssl.com
Processed 148 CA certificate(s).
Resolving 'self-signed.badssl.com:443'...
Connecting to '104.154.89.105:443'...
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
- subject `CN=*.badssl.com,O=BadSSL,L=San Francisco,ST=California,C=US',
issuer `CN=*.badssl.com,O=BadSSL,L=San Francisco,ST=California,C=US', serial
0x0086fb4dc8e5dd0f18, RSA key 2048 bits, signed using RSA-SHA256, activated
`2016-08-08 21:17:05 UTC', expires `2018-08-08 21:17:05 UTC', pin-
sha256="9SLklscvzMYj8f+52lp5ze/hY0CFHyLSPQzSpYYIBm8="
Public Key ID:
sha1:7965dfc93c6ae6fe8381ec482216ec44ef47282a
sha256:f522e496c72fccc623f1ffb9da5a79cdefe16340851f22d23d0cd2a58608066f
Public Key PIN:
pin-sha256:9SLklscvzMYj8f+52lp5ze/hY0CFHyLSPQzSpYYIBm8=
Public key's random art:
+--[ RSA 2048]----+
| |
| . |
| o . . o |
| = o o o .o..|
| + + S o . .=.|
| E . + o + o .. .|
| . . . + o +o |
| . .+. . |
| .o...|
+-----------------+

- Status: The certificate is NOT trusted. The certificate issuer is unknown.

The certificate chain uses insecure algorithm.

*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
*** handshake has failed: Error in the certificate.

--
Rémi Denis-Courmont

[Andreas Metzler]

Control: forwarded -1 https://gitlab.com/gnutls/gnutls/issues/347

On 2017-12-29 Rémi Denis-Courmont <re...@remlab.net> wrote:
> The version of GnuTLS in Debian incorrectly flags self-signed certificates as
> insecure certificate chain algorithm. This makes no sense; the flag is for
> certificate chains using insecure algorithms such as MD2, MD5 and SHA-1.

> This is reproducible also with gnutls-bin (both with Debian and upstream
> GnuTLS):

Hello,

I have forward the issue upstream.

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'

[Daniel Kahn Gillmor]

Control: tags 885127 + moreinfo unreproducible

On Fri 2017-12-29 14:38:14 +0200, Rémi Denis-Courmont wrote:
> The version of GnuTLS in Debian incorrectly flags self-signed certificates as
> insecure certificate chain algorithm. This makes no sense; the flag is for
> certificate chains using insecure algorithms such as MD2, MD5 and SHA-1.

sorry, i'm having a hard time seeing this. In the example you give below:

the error says "The certificate issuer is unknown", which is surely the
*correct* response for a self-signed certificate when you haven't added
that certificate to your list of X.509 root authorities.

In the forwarded bug report
(https://gitlab.com/gnutls/gnutls/issues/347), Andreas says:

>>> a) gnutls-cli self-signed.badssl.com
>>> b) Generate a test-cert with "certtool --generate-self-signed " with
>>> default algoritms and use gnutls-serv/gnutls-cli

(though presumably not in that order)

well, i tried that, and things still worked for me.

in particular, to generate the self-signed certificate, i did:

certtool --generate-privkey --outfile key.pem
certtool --generate-self-signed --load-privkey key.pem --outfile cert.pem

when answering the questions in the second invocation, i just hit enter
on everything except:


Common name: bad.example
The certificate will expire in (days): 30
Is this a TLS web server certificate? (y/N): y
Will the certificate be used for encryption (RSA ciphersuites)? (Y/n): n

Once that was done, i pointed bad.example to 127.0.0.1 in /etc/hosts,
launched the server with:

gnutls-serv --x509keyfile key.pem --x509certfile cert.pem

and then connected with the client like so:

gnutls-cli --x509cafile cert.pem bad.example:5556


everything worked successfully.

Can you give a clearer example of the problem you're seeing? I don't
see anything broken in my tests.

--dkg

[Daniel Kahn Gillmor]

On Tue 2017-12-26 22:24:59 +0100, Floris wrote:
> I'm not sure this is a VLC bug, although I think it is odd that VLC 3 has
> a Chromecast feature, but it isn't working. Maybe build vlc without
> Chromecast support in Debian until Google and/ or GnuTLS has a decent fix
> for this issue. Or make a workaround.

Dropping chromecast support in debian doesn't seem like great option to
me if it's available upstream. And GnuTLS has at least two different
fixes available.

One approach (as noted in my earlier post on this bug report) is to
explicitly grant that self-signed cert root CA status. But that's
generally unpleasant, because it means that cert can MITM any of your
other connections.

A better approach to connecting to a persistently-named, self-signed
chromecast stream would be for VLC to take advantage of GnuTLS's "TOFU"
(trust on first use) functionality:

https://gnutls.org/manual/gnutls.html#Certificate-verification

or, if we already know that chromecast is never a strongly-secured
connection, we could just disable authentication on chromecast
connections (i do not have a chromecast, and i do not know what security
posture chromecast users expect from their connections).

hth,

--dkg

[Floris]

Op Fri, 29 Dec 2017 22:48:30 +0100 schreef Daniel Kahn Gillmor
<d...@debian.org>:

I think a lot of end users expect the "it just works" method. When you
cast something from Chrome/ Chromium to the Chromecast there isn't a
warning about a certificate. In addition, the certificate issued by the
chromecast is only valid for 2 days. Does it mean that you get a new
warning every two days? So I tend more to the last option.

gnutls-cli 192.168.1.14:8009
Processed 149 CA certificate(s).
Resolving '192.168.1.14:8009'...
Connecting to '192.168.1.14:8009'...

- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:

- subject `CN=c036e8e6-dce8-c593-4624-e743f8eb7f04', issuer
`CN=c036e8e6-dce8-c593-4624-e743f8eb7f04', serial 0x07b58554, RSA key 2048
bits, signed using RSA-SHA256, activated `2017-12-29 09:57:32 UTC',
expires `2017-12-31 09:57:32 UTC',
pin-sha256="lqW7HJ396wf5w02vBO0Oyu3Os05S7OKUunht17mBwQE="
Public Key ID:
sha1:6b30af9317dcec5b8f16671aff24ccfa8af38bd4
sha256:96a5bb1c9dfdeb07f9c34daf04ed0ecaedceb34e52ece294ba786dd7b981c101
Public Key PIN:
pin-sha256:lqW7HJ396wf5w02vBO0Oyu3Os05S7OKUunht17mBwQE=

Public key's random art:
+--[ RSA 2048]----+
| |
| |
| |
| |

| o.So |
| +o.o.ooo |
| .+o. EB+ .|
| oo..o+o+.o |
| .o +=*+o..|
+-----------------+

- Status: The certificate is NOT trusted. The certificate issuer is

unknown. The certificate chain uses insecure algorithm. The name in the
certificate does not match the expected.

[Andreas Metzler]

On 2017-12-29 Daniel Kahn Gillmor <d...@debian.org> wrote:
> On Fri 2017-12-29 14:38:14 +0200, Rémi Denis-Courmont wrote:
>> The version of GnuTLS in Debian incorrectly flags self-signed
>> certificates as insecure certificate chain algorithm. This makes no
>> sense; the flag is for certificate chains using insecure algorithms
>> such as MD2, MD5 and SHA-1.

> sorry, i'm having a hard time seeing this. In the example you give below:

>> This is reproducible also with gnutls-bin (both with Debian and upstream
>> GnuTLS):

[...]

>> - Status: The certificate is NOT trusted. The certificate issuer is unknown.
>> The certificate chain uses insecure algorithm.
>> *** PKI verification of server certificate failed...
>> *** Fatal error: Error in the certificate.
>> *** handshake has failed: Error in the certificate.


> the error says "The certificate issuer is unknown", which is surely the
> *correct* response for a self-signed certificate when you haven't added
> that certificate to your list of X.509 root authorities.

[...]

Daniel, I agree that ""The certificate issuer is unknown" would be the
correct error message. However gnutls *additionally* throws an "The
certificate chain uses insecure algorithm." And the latter is afaict
wrong. There is no insecure algorim involved, the self-signature uses
"RSA-SHA256". (I had tried to make this clear with Actual
results/Expected results in the upstream report.)

cu Andresas

[Rémi Denis-Courmont]

tags 885127 - moireinfo unreproducible
thanks

On vendredi 29 décembre 2017 16:48:30 EET Daniel Kahn Gillmor wrote:
> On Tue 2017-12-26 22:24:59 +0100, Floris wrote:
> > I'm not sure this is a VLC bug, although I think it is odd that VLC 3 has
> > a Chromecast feature, but it isn't working. Maybe build vlc without
> > Chromecast support in Debian until Google and/ or GnuTLS has a decent fix
> > for this issue. Or make a workaround.
>
> Dropping chromecast support in debian doesn't seem like great option to
> me if it's available upstream. And GnuTLS has at least two different
> fixes available.
>
> One approach (as noted in my earlier post on this bug report) is to
> explicitly grant that self-signed cert root CA status. But that's
> generally unpleasant, because it means that cert can MITM any of your
> other connections.
>
> A better approach to connecting to a persistently-named, self-signed
> chromecast stream would be for VLC to take advantage of GnuTLS's "TOFU"
> (trust on first use) functionality:
>
> https://gnutls.org/manual/gnutls.html#Certificate-verification

VLC already supports that feature - if the root CA is unknown and/or the
hostname does not match the certificate common name, but everything else is
fine.

The whole point of this bug report is that some GnuTLS update broke this
feature by adding the insecure algorithm error flag on self-signed
certificates. VLC should not accept MD2 or MD5 certificate chains ever, so it
fails hard if that flag is set (ditto expired certificate).

And this is trivially reproducible; we already provided multiple ways to do
that. with either gnutls-bin or VLC.

--
Rémi Denis-Courmont