1 |
On 170112-09:36+0000, Neil Bothwick wrote: |
2 |
> On Thu, 12 Jan 2017 19:19:11 +1100, Adam Carter wrote: |
3 |
> |
4 |
> > > > wget |
5 |
> > > > 'https://data.giss.nasa.gov/gistemp/tabledata_v3/GLB.Ts+dSST.txt' |
6 |
> > > > |
7 |
> > > > Resolving data.giss.nasa.gov... 128.183.4.33 |
8 |
> > > > Connecting to data.giss.nasa.gov|128.183.4.33|:443... connected. |
9 |
> > > > OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 |
10 |
> > > > alert handshake failure |
11 |
> > > > Unable to establish SSL connection. |
12 |
> > > |
13 |
> > |
14 |
> > Works ok here (~amd64) with the following versions/flags; |
15 |
> |
16 |
> Works here too. Could it be a certificate problem? Re-emerging |
17 |
> ca-certificates and removing any dead symlinks to old certificates might |
18 |
> help, but first I'd try cranking up the verbosity in wget. |
19 |
|
20 |
Sure that "-S": |
21 |
-S, --server-response print server response |
22 |
cranks up verbosity. |
23 |
|
24 |
But, maybe you're playing with the wrong sample that behaves well in |
25 |
three of us that posted, and bad in one machine only (Walter Dnes's). |
26 |
|
27 |
How about when you get with: |
28 |
|
29 |
wget -S \ |
30 |
https://www.redhat.com/archives/virt-tools-list/2017-January.txt.gz \ |
31 |
|& tee 2017-January.txt.gz.log |
32 |
|
33 |
consistently same good size, same hash: |
34 |
|
35 |
sha256sum 2017-January.txt.gz 2017-January.txt.gz.1 |
36 |
|
37 |
0ed31e4b55af11f341d7158741b3f1ab46c3b0eb07548063665fc038a50cc547 |
38 |
2017-January.txt.gz |
39 |
|
40 |
0ed31e4b55af11f341d7158741b3f1ab46c3b0eb07548063665fc038a50cc547 |
41 |
2017-January.txt.gz.1 |
42 |
|
43 |
( formatted for mail, but 3 lines only ) |
44 |
|
45 |
but alas, not gunzip'able file! |
46 |
|
47 |
(download it from |
48 |
http://www.croatiafidelis.hr/foss/cap/cap-170112_wget-ssl/ |
49 |
and also find the log, done with "wget -S", there now: |
50 |
2017-January.txt.gz.log |
51 |
) |
52 |
|
53 |
$ cat 2017-January.txt.gz | gunzip > 2017-January.txt |
54 |
|
55 |
gzip: stdin: not in gzip format |
56 |
$ |
57 |
|
58 |
And that's consistent, just rechecked. The hash is that same one as in |
59 |
the dir on my NGO's site, and as in this email. |
60 |
|
61 |
Is it because saves something from the attempt at using IPv6 first! |
62 |
Don't know... And it is here that the network traces play important |
63 |
role... But I get different results tracing with Tcpdump, then tracing |
64 |
with Dumpcap... And it may be that in neither case is the |
65 |
2017-January.txt.gz extractable correctly from traces. I only tried it |
66 |
with the other wget-downloding file that's in that dir on my NGO's site, |
67 |
and that other file, the wget-1.18.tar.xz, extract partly and |
68 |
differently with tcpdump and with dumpcap... |
69 |
|
70 |
However, I have more interfering issues. Interfering, because they're |
71 |
network, but they are different network issues, unrelated. And also not |
72 |
explainable in a sentence or two. Give me time, if you care, and check |
73 |
the right file this time around... ;-) |
74 |
|
75 |
And if the download shows like I described, then this is bug, and in |
76 |
that case, pls. if anybody has the time, try and just give the address |
77 |
of my samples to Giuseppe Scrivano, the Wget maintaner (a connational of |
78 |
Croatia, Hrvoje Nikšić, whom I don't know, is the original author of |
79 |
Wget), post the bug at the already given: |
80 |
|
81 |
http://lists.gnu.org/mailman/listinfo/bug-wget |
82 |
|
83 |
(of course, only if the download shows like I described above) |
84 |
|
85 |
Give me more time, and I'll try and tell about those interfering |
86 |
unrelated network issues. |
87 |
|
88 |
( |
89 |
And did anybody noticed that the network might be getting decryptable |
90 |
for us final users, it the Wget's trend to decrypt SSL-keys into the |
91 |
$SSLKEYLOGFILE catches up? Repasting the link from the first post: |
92 |
|
93 |
Write TLS session keys to $SSLKEYLOGFILE |
94 |
https://github.com/rg3/youtube-dl/issues/11614 |
95 |
|
96 |
Nobody understands how big thing that is, should the trend catch up? |
97 |
youtube-dl, and then imagine, decrypting your conversations that you do |
98 |
with git, just imagine, no more opaque conversations for the user!! |
99 |
|
100 |
And then all the other FOSS programs that interact with the network! SSL |
101 |
encrypted well for everybody else, noone can MiTM you, you passwords |
102 |
secure, but the conversations opens up like a flower to you, and tells |
103 |
you everything that happened on the network... |
104 |
|
105 |
Which is not the case today. Exampli gratia: Youtube, the stinking |
106 |
Schmoog's Youtube. It is as opaque as prison without light five storeys |
107 |
underground! The self proclamed "do-no-evil" liers and factual spies on |
108 |
almost the whole world! |
109 |
) |
110 |
|
111 |
Regards! |
112 |
-- |
113 |
Miroslav Rovis |
114 |
Zagreb, Croatia |
115 |
http://www.CroatiaFidelis.hr |