Re: [O] Why no secure code retrieval

[Konstantin Kliakhandler]

Hello,

On 3 July 2016 at 23:12, Robert Horn <address@hidden> wrote:

The SHA1's are reference elements used throughout git, and are primarily for integrity protection against accidents, not against attackers.  Hence it's sufficient that
they be maintained by the git processes.

Sufficient for what? I believe we were discussing security (that was my intention at least, and so did your previous email seem to indicate). And if this is the case, you have just contradicted yourself. I apologize for pointing it out so directly, and also if I misunderstood you.

 

The plain vanilla git process does not include distribution of SHA1
values by an independent path, so it's not easy to verify against a
trusted source for the correct values.

Which trusted source? This is the whole point of said discussion. If I haven't a secure connection to the server and none of the commits are signed, what exactly are you proposing to compare to? My proposal was comparison to the gpg signatures in git itself, at least for tagged revisions. This would provide a canonical source to compare to, and can be done automatically by git itself (the comparison).

I certainly can live off just tagged versions. Even when you want to fix a bug/add a feature, most likely you need to just work against files that haven't changed since last tag.

 

With your permission I'll quote the entire message of Achim Gratz:

 

> 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. 

No, it does not give me a guarantee. But very few things do. Signatures come closer to that, although https://xkcd.com/538/ should convince you that it isn't a guarantee either. But who said that there will ever be a point when the server doesn't match the local clone? https://mikegerwitz.com/papers/git-horror-story

But just because there are other ways to enter your house does not mean you should not put a lock on your front door.

This would be a reasonable step for org-mode releases.  The release
process only involves a few people, and key management would not be too
hard.  It doesn't solve the problem for non-git distribution methods.
My guess is that the ELPA users are the most exposed.  Fixing that
really belongs to ELPA, but if I were putting together the cyber
security plan for org-mode I would call out this gap and make clear that
it is a gap that can't be easily solved by org-mode.  (Maybe tweaking
someone more familier with ELPA to tell me how to solve it for ELPA.)

I believe that these days elpa is accessed by default via https and that archives are signed, though please correct me here. Assuming it is the case, there isn't much one can do beyond the currently suggested steps, I think.

Have a nice week,

Kosta