Re: Why no secure code retrieval

[Robert Horn <rjhorn@alum.mit.edu>]

Konstantin Kliakhandler writes:

> Hello Robert,
>
> I am the OP.
>
> 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.

The SHA1's are created by the git processes at the git server that you
connect to.  Or, in the case of a malicious source, by the malicious
source appearing to be the git server.  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.

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.

As Achim Gratz says:
>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.

The most common and appropriate next step (assuming git is used for
distribution) is to make use of PGP signing of tagged versions in git.  This is a
strong signature traceable to some release person or process.  It
provides strong verification and authentication for the contents of a
specific tagged release.  This protects against distribution server and repo
compromises, but not against development process compromises.

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

Signed tags do not provide much extra protection for developers.  The
usual git process of using SSH keys to authenticate developers is much
easier to manage than individually signed changes.  It's vulnerable to
all the usual attacks.  Overall integrity depends upon the release
testing and verification process.  Signed commits can reduce these
risks.

Signed commits are a lot more work than the SSH key methods.  I doubt
that the committers have the appetite to deal with all the issues
involved.

R Horn