On Apr 05, 2020, Adrian Zaugg wrote: > Hi Dan > > On 05.04.20 13:12, Dan Purgert wrote: > > OK, so now you've "verified(tm)" that you successfully got > > "devuan_a1gn1ng_key" from https://devane.com/pgp.asc. Great that > > you were able to verify the server. But you still got a bogus key > > :) > > > > Which was pretty much my point -- TLS doesn't protect you from getting > > sent the wrong key, if you somehow got directed to the wrong site... > You will copy the link from the manual or the mail. Yes things can go > wrong everywhere, even there. Because so many things can go wrong, one > should reduce the risk that they do (and as well make it harder for > attackers to succeed). It's a none argument to say a technique doesn't > protects you from everything, so renounce on using it. In contrary, use > what you can as long as its somewhat reasonable in resource consumption > and effort it needs to set up. Writing https instead of http in a manual > for one package is not so much of a job and for that one package the > server will not go down because of increased load.
I'm not saying to throw away TLS in every case. I'm only saying that TLS offers nothing for the transfer of a public PGP key. Frankly, blindly trusting a public pgp key "just because you got it from "https://somewhere.com"; is actively detrimental in that now you're just giving yourself a false sense of security. -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
signature.asc
Description: PGP signature
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
