Markus Lude <markus.l...@gmx.de> writes: > On Tue, Nov 03, 2015 at 10:32:36PM +0000, Stuart Henderson wrote: >> On 2015/11/03 22:13, Markus Lude wrote: >> > On Mon, Nov 02, 2015 at 08:53:41PM +0000, Stuart Henderson wrote: >> > > On 2015/11/02 19:45, Markus Lude wrote: >> > > > On Sat, Oct 24, 2015 at 09:05:27PM +0200, Markus Lude wrote: >> > > > > Hello Paul, >> > > > >> > > > Hello again, >> > > > >> > > > > make fetch fails for recent youtube-dl: >> > > > > >> > > > > ===> Checking files for youtube-dl-2015.10.24 >> > > > > >> Fetch >> > > > > >> https://yt-dl.org/downloads/2015.10.24/youtube-dl-2015.10.24.tar.gz >> > > > > ftp: SSL read error: read failed: error:140940E5:SSL >> > > > > routines:SSL3_READ_BYTES:ssl handshake failure >> > > > >> > > > recent update to youtube-dl-2015.11.01 fails too at the dowenload >> > > > stage: >> > > > >> > > > ===> Checking files for youtube-dl-2015.11.01 >> > > > >> Fetch >> > > > >> https://yt-dl.org/downloads/2015.11.01/youtube-dl-2015.11.01.tar.gz >> > > > ftp: SSL read error: read failed: error:140940E5:SSL >> > > > routines:SSL3_READ_BYTES:ssl handshake failure >> > > > >> > > > >> > > > quick workaround: use http instead? >> > > > >> > > > Regards, >> > > > Markus >> > > > >> > > >> > > The https server for yt-dl.org requires SNI, is there anything unusual >> > > about the way you're connecting to it (weird proxy or something)? >> > >> > I'm not aware of any proxy (yet). >> > >> > > It would be interesting to see what 'nc -vvc yt-dl.org 443' says. >> > >> > $ nc -vvc yt-dl.org 443 >> > Connection to yt-dl.org 443 port [tcp/https] succeeded! >> > TLS handshake negotiated TLSv1.2/DHE-RSA-AES256-GCM-SHA384 with host >> > yt-dl.org >> > Peer name yt-dl.org >> > Subject: /OU=Domain Control Validated/OU=PositiveSSL/CN=yt-dl.org >> > Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA >> > Limited/CN=COMODO RSA Domain Validation Secure Server CA >> > Cert Hash: >> > SHA256:a396c2fb2644a50328b208e335e897a7639a7a2f2a22ae7f04d6908322a9429c >> > >> >> That's exactly what I'd expect from nc - that's odd though... if nc can >> connect, I don't think there's any reason why ftp shouldn't be able to >> (since jca added SNI support in 2014). >> >> Not really sure what to suggest... > > Unfortunately I forgot to mention that the problem occurs on 2 sparc64 > machines running snapshot from 3rd october. > It works on my notebook running i386 -current. > > on sparc64: > > $ /usr/bin/ftp -4 -d -o youtube-dl-2015.11.01.part > https://yt-dl.org/downloads/2015.11.01/ > host yt-dl.org, port (null), path downloads/2015.11.01/, save as > youtube-dl-2015.11.01.part, auth (null). > Trying 95.143.172.170... > Requesting https://yt-dl.org/downloads/2015.11.01/GET /downloads/2015.11.01/ > HTTP/1.0 > Host: yt-dl.org > User-Agent: OpenBSD ftp > > > ftp: SSL read error: read failed: error:140940E5:SSL > routines:SSL3_READ_BYTES:ssl handshake failure > > > on i386: > > $ /usr/bin/ftp -4 -d -o youtube-dl-2015.11.01.part > https://yt-dl.org/downloads/2015.11.01/ > host yt-dl.org, port (null), path downloads/2015.11.01/, save as > youtube-dl-2015.11.01.part, auth (null). > Trying 95.143.172.170... > Requesting https://yt-dl.org/downloads/2015.11.01/GET /downloads/2015.11.01/ > HTTP/1.0 > Host: yt-dl.org > User-Agent: OpenBSD ftp > > > received 'HTTP/1.1 200 OK' > [...] > > > on amd64 same as i386
Smells like a LibreSSL issue to me; Markus, could you report a bug about it? (on bugs@, preferably with sendbug(1)) -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
