[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] Why no secure code retrieval
From: |
Achim Gratz |
Subject: |
Re: [O] Why no secure code retrieval |
Date: |
Sun, 03 Jul 2016 20:25:16 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) |
Konstantin Kliakhandler writes:
> For what it is worth, the current discussion is actually precisely what I
> was aiming at. I agree with your analysis of my Intended goals but
> completely disagree that SHA1 alone is any sort of guarantee.. To be
> precise, I don't just think that it doesn't provide much, but rather that
> alone it provides none at all. This is because I have no idea who produced
> a given SHA1 - whether it was Bastien, or a MITM attacker, or just someone
> who compromised the server.
Getting the same data via https doesn't give you that sort of guarantee
either, it only ensures that the data cannot be read and altered in
transport. If the server or repo gets compromised, then it is game over
until someone notices that the server suddenly doesn't match up the
local clone.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
- Re: [O] Why no secure code retrieval, Bastien Guerry, 2016/07/02
- Re: [O] Why no secure code retrieval, Ian Barton, 2016/07/02
- Re: [O] Why no secure code retrieval, Bastien Guerry, 2016/07/03
- Re: [O] Why no secure code retrieval, Robert Klein, 2016/07/03
- Re: [O] Why no secure code retrieval, Achim Gratz, 2016/07/03
- Re: [O] Why no secure code retrieval, Robert Horn, 2016/07/03
- Re: [O] Why no secure code retrieval, Konstantin Kliakhandler, 2016/07/03
- Re: [O] Why no secure code retrieval,
Achim Gratz <=
- Re: [O] Why no secure code retrieval, Robert Horn, 2016/07/03
- Re: [O] Why no secure code retrieval, Konstantin Kliakhandler, 2016/07/03
- Re: [O] Why no secure code retrieval, Robert Horn, 2016/07/03
- Re: [O] Why no secure code retrieval, Konstantin Kliakhandler, 2016/07/04