BAD sig on Devuan ISO
First the correspondence, in two places, because... Well the places first:
https://lists.dyne.org/lurker/message/20170423.152414.27ee0859.en.htmland:
https://www.CroatiaFidelis.hr/foss/devuan/lurker/message/20170423.150932.e9ab7478.en.html (but see the thread links below; that message had too large attachment by some standards, it was rejected)
And in two places I offer it, because in the official, there don't seem to be attachments available like in my frozen lurker demo archive (in which the search does not work, no CGI there).
But a "dead" lurker is fine to keep attachments and all, including raw email, which I will need to demonstrate the usefulness of PGP with email in proving what happened... (if I don't break down exhausted in the process).
If you peruse with some attention this same thread, in either of the two places:
https://lists.dyne.org/lurker/thread/20170423.152414.27ee0859.en.html#20170423.152414.27ee0859
(where it comes with some attachments missing, and not just the 83k trace, but where it is likely to be updated with new mails)
https://www.CroatiaFidelis.hr/foss/devuan/lurker/thread/20170423.150932.e9ab7478.en.html#i20170423.150932.e9ab7478
(where it comes with all the attachments in all mails, but is not very likely to be updated with new mails, well at least not very soon; it's not so very trivial to do it; it would be updated in case of unpredictable development though...)
If you peruse with some attention that thread, you are bound to understand the ISO file that I downloaded simply wouldn't verify with the Devuan leader's PGP-signature.
Other then guessing, I simply don't know why that happened (either a blunder on my side, or on the other side, or on the way, or an attack, or something else). And the fact that more than 4 (four) hours later, it still wasn't possible to PGP-verify the download, i.e. the downloaded hash and the downloaded signature did not verify, along with the fact that on the Devuan ML nobody had a reply that would shine some light into what may have happened, is the reason that I'm trying to prove, not why, nor for what reason or what cause, that happened, but I'm trying to show exactly and beyond any reasonable doubt (for advanced users/devs; but also, and to some detriment of the former --I will be verbose, bear with me--, for stubborn and hardworking newbies, as usual), exactly what happened on the network.
That's what my uncenz method and other usual scripts are for, after all.
But, it's very late, it's the dead of night, it's 2017-04-24 02:18+02:00 (that's CET, and that's past 2 a.m.)... First I will post the network traces and the accompanying screencasts, and try and post to the list informing them that I now offer complete information.
Which complete information is necessary to rule out the cause of unverifiability being at the Devuan repository side, in case it is not there.
---
With my uncenz program I obtained the two pairs of network traces and corresponding screencasts below. For the first, no SSL-keys were captured, because the entire conversation was in cleartext, for the second there are also SSL-keys.
If skimming through these, I recommend skip first, the second is cleaner presentation (or keep to the first if https://wiki.wireshark.org/SSL is too much learning for you).
---
---
---
The files necessary for this study are listed in:
dump_170423_1642_g0n.pcap Screen_170423_1642_g0n.webm dump_170423_2102_g0n.pcap Screen_170423_2102_g0n.webm dump_170423_2102_g0n_SSLKEYLOGFILE.txtand verify to: ls-1.sum signed by: ls-1.sum.asc
You might find dump_dLo.sh script from my uncenz program more useful then downloading each file separately.
