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
