Re: [gentoo-user] Re: Re[4]: Re: Portage, git and shallow cloning

[Rich Freeman]

On Sat, Jul 7, 2018 at 1:34 AM Martin Vaeth <martin@×××××.de> wrote:
>
> Rich Freeman <rich0@g.o> wrote:
> >
> > Biggest issue with git signature verification is that right now it
> > will still do a full pull/checkout before verifying
>
> Biggest issue is that git signature happens by the developer who
> last commited which means that in practice you need dozens/hundreds
> of keys.

This is untrue.  The last git signature is made by infra or the
CI-bot, and this is the signature that portage checks.

Portage will NOT accept a developer key, or any other key in your
keychain, as being valid.

It will, of course, not work on the regular git repo used for
committing for this reason.  You need to use a repo that is signed by
infra (which typically includes metadata/etc as well).

I'll trim most of the rest of your email and only reply to significant
bits, because you seem to not understand the point above which
invalidates almost everything you wrote.  The concerns you raise would
be an issue if you were checking individual developer keys.

>
> So currently, it is impossible to do *any* automatic tree verification,
> unless you manually fetch/update all of the developer keys.
>

As noted, you don't need to fetch any developer keys, and if you do
fetch them, portage will ignore them.

>
> > unless you stick --force in your pull
>
> Unfortunately, it is not that simple: git pull --force only works if
> the checked out tree is old enough (in which case git pull without --force
> would have worked also, BTW).

You completely trimmed the context around my quote.  I was talking
about the malicious commits in the recent attack.  They were
force-pushed, so it doesn't matter how complete your repository is -
they simply would not be pulled without --force.

You seem to be providing advice for how to do a pull with a shallow
repository, which I'm not talking about.

> > Honestly, I think git is a good fit for a lot of Gentoo users.
>
> At least since the ChangeLogs have been removed.
> IMHO it was the wrong decision to not keep them in the rsync tree
> (The tool to regenerate them from git was/is available).

Changelogs are redundant with git, and they take a ton of space (which
of late everybody seems to be super-concerned about).  I don't get
that on one hand people get twitchy about /usr/portage taking more
than 1GB, and on the other hand they want a bazillion text files
dumped all over the place, and as a bonus they want them prepended to
instead of appended so that rsync resends the whole thing instead of
just the tail...

But, this was endlessly debated before the decision was made.  Trust
me, I read every post before voting to have them removed.

>
> > it is different, but all the history/etc is the sort of thing I think
> > would appeal to many here.
>
> Having the ChangeLogs would certainly be sufficient for the majority
> of users. It is very rare that a user really needs to access the
> older version of the file, and in that case it is simple enough
> to fetch it manually from e.g. github.

It is very rare that somebody would want to use Gentoo at all.  My
point is that the sorts of people who like Gentoo would probably tend
to like git.  But, to each their own...

>
> > Security is obviously getting a renewed focus across the board
>
> Unfortunately, due to the mentioned keys problem, git is
> currently the *unsafest* method for syncing.

The "keys problem" has nothing to do with the security of git
verification, because those keys are not used by git verification on
the end-user side.  An infra-controlled key is used for verification
whether you sync with git or rsync.  Either way you're relying on
infra checking the developer keys at time of commit.

Now, as I already mentioned git syncing is currently less safe due to
it doing the checkout before the verification, and they are in the
process of fixing this.

> (BTW, due to the number of committers the portage tree has a quite
> strict policy w.r.t. forced pushes. Overlays, especially of single
> users, might have different policies and thus can fail quite often
> due to the "git pull" bug.)

It probably should be a configurable option in repos.conf, but
honestly, forced pushes are not something that should be considered a
good practice.  There are times that it is the best option, but those
are rare, IMO.

-- 
Rich