git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: git@vger.kernel.org
Subject: Re: how to (integrity) verify a whole git repo
Date: Thu, 23 Apr 2020 20:12:28 +0200	[thread overview]
Message-ID: <6661ea6546fc02583959f00a99736cc110792ab9.camel@scientia.net> (raw)
In-Reply-To: <20200421161956.45slynbgkkom3qc3@chatter.i7.local>

On Tue, 2020-04-21 at 12:19 -0400, Konstantin Ryabitsev wrote:
> > So from my understanding, to use only commits that are authentic by
> > the
> > kernel upstream developers, I'd need verify all these tips.. and
> > throw
> > away everything which is not reachable by one of them.
> > 
> > Is that somehow possible?
> 
> You probably don't care about commits that arrive between releases, 

No, I guess not.


> so 
> effectively you are already doing that? Even if you have loose
> objects 
> that aren't reachable from your current tip (e.g. you only care
> about 
> objects in the stable branch linux-5.6.y), it's not like they are
> going 
> to "poison" your tree, so removing them is just a garbage collection 
> operation at best.

Well it's clear that any "loose" objects (in the sense of "not part of
the history by something that is signed and that I trust") don't poison
the tree before whatever I trust... but of course only if one never
accidentally uses anything of them.

For the Linus' kernel and Gerg's stable kernel repos this is probably
rather unlikely, since the do not contain much which is not signed by
one of the two.
But for other projects one might have many development branches or
other stuff which might not be signed at all.

When one then "works" on such a repo one doesn't always want to check
whether the current stuff one uses is signed and trusted or not.


> I would argue that your premise of "authenticity" is wrong. The best 
> that we are currently able to offer is a guarantee that, at the
> point 
> where the tag was signed, the tree is bit-for-bit exact to the tree
> the 
> way it exists on Linus Torvalds' (or Greg KH's) workstation.

And isn't that already something? :-D

It means to the least, that no simple MitM was possible in contrast to
when I just git clone git://whatever .


> However, both Linus and Greg merge code from tens of thousands of
> other 
> contributors and it's important to keep in mind that their tag 
> signatures do not offer any kind of attestation proof of the code's 
> actual authorship or origin.

Sure... but this is anyway the case... and nothing which one could
easily change or improve.

The best thing in terms of authenticity on can possibly get is being
able to have the repo exactly the same as it considered correct at it's
canonical upstream.

Everything better would require full trust paths and mutual signing
between all participating developers - which would surely be nice to
have, but is probably a completely other question.


Also, there are many much smaller projects, where things would be much
easier.



> 
> - Submaintainers don't put much trust into *who* wrote the code and 
>   review all submissions they receive as potentially containing
> security 
>   bugs (intentional or not); their job is to review the code and pass
> it 
>   up the chain to maintainers.
> - if maintainers receive pull requests from submaintainers, then
> they 
>   *may* check cryptographic signatures on the trees they pull. I am 
>   trying to encourage all maintainers to do this, and I've been
> working 
>   to introduce patch attestation so that maintainers preferring to
> work 
>   with patch series as opposed to pull requests can have similar 
>   functionality.
> - Linus checks all signatures on trees he pulls from non-kernel.org 
>   locations. Unfortunately, I've not been able to convince him that
> he 
>   should check them on stuff he pulls from kernel.org as well (and
> he 
>   has his own reasons for that).

But all this gives already quite some trust into the whole thing.


> So, all of this is to say that as the person cloning linux.git you
> are 
> merely the last link in the chain of "trusting the maintainer before 
> you." In your case that maintainer is Linus (or Greg KH), and you
> have 
> to agree that, in the end, "having a tree that is bit-for-bit
> identical 
> with what Linus has" is a pretty good assurance that it's as
> "authentic 
> Linux" as it gets.

Exactly... it's at least not much worse (if at all) than taking e.g. my
pre-compiled distro kernel, for which the sources are like not better
checked or more securely retrieved than when I clone Linus' git and
verify the tags.

My main concern was really to ideally "throw away" everything which
wasn't protected by a set of certain keys,... so that I wouldn't
accidentally use it.



Thanks,
Chris.


  reply	other threads:[~2020-04-23 18:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-21  4:45 how to (integrity) verify a whole git repo Christoph Anton Mitterer
2020-04-21  6:53 ` Jonathan Nieder
2020-04-21 14:42   ` Christoph Anton Mitterer
2020-04-21 16:19     ` Konstantin Ryabitsev
2020-04-23 18:12       ` Christoph Anton Mitterer [this message]
2020-04-21 19:14 ` Junio C Hamano
2020-04-23  4:02   ` Christoph Anton Mitterer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6661ea6546fc02583959f00a99736cc110792ab9.camel@scientia.net \
    --to=calestyo@scientia.net \
    --cc=git@vger.kernel.org \
    --cc=konstantin@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).