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

[Davyd McColl]

@Rich thanks for taking the time to formulate that in-depth response. 
Appreciated.

-d

------ Original Message ------
From: "Rich Freeman" <rich0@g.o>
To: gentoo-user@l.g.o
Sent: 2018-07-06 14:20:54
Subject: Re: Re[4]: [gentoo-user] Re: Portage, git and shallow cloning

>On Fri, Jul 6, 2018 at 7:57 AM Davyd McColl <davydm@×××××.com> wrote:
>>
>>@Rich: if I understand the process correctly, the same commits are
>>pushed to infra and GitHub by the CI bot?
>>
>
>I'm pretty sure the repos are identical (well, aside from whatever
>order they're updated in).
>
>>I ask because prior to the GitHub incident, I didn't have signature
>>verification enabled (I hadn't read about it and it didn't even occur
>>to
>>me). So my plan was to (whilst GitHub was being sorted out) switch to
>>the gentoo git repo and enable verification and, once I'd seen that
>>that
>>was working (because I'd also seen intermediate emails on this list
>>from
>>people having issues getting signing keys working), perhaps switch
>>back
>>to GitHub to put less strain on the Gentoo servers.
>
>I never had issues with the signing keys, but git syncing works
>differently from webrsync (which makes those threads a bit of a mess
>as you have people offering advice to people using a different sync
>method).  It is probably best to view them as completely different
>implementations, though I'm sure they have elements in common.
>
>Biggest issue with git signature verification is that right now it
>will still do a full pull/checkout before verifying, which means that
>if it fails you still have a bad /usr/portage (you get an error, but
>that's it, and subsequent emerge commands will act on the bad repo).
>For that reason alone it might be best to stick with infra's version
>until the patch makes its way into release (the patch will do a fetch
>and verify before it does a checkout, so while you might have bad git
>commits in the history the actual contents of /usr/portage will be
>known-good unless you go manually running git commands without doing
>your own verification).
>
>Now, in the recent attack a git sync would still have been safe
>because the attacker was dumb and did a force push, which will make
>git complain loudly if you try to pull (unless you stick --force in
>your pull, which probably isn't a great idea for scripts and portage
>doesn't do this).  But, that was just dumb luck because a smart
>attacker would have rebased the nefarious commits so that they'd
>seamlessly pull.  Really the attack was more of a defacement than
>anything as they made a bunch of mistakes that showed they weren't
>very serious, but any wakeup call is worth acting on.
>
>>So if the same commits are just pushed to two remotes (gentoo and
>>GitHub), then I should (in theory) be able to change my repo.conf
>>settings, fiddle the remote in /usr/portage, and switch seamlessly
>>from
>>gentoo to GitHub? Alternatively, I could start with a clean
>>/usr/portage
>>again, once I'm happy that I have signature verification working on my
>>machine.
>
>As far as I can tell if you edit the repo URL in repos.conf and
>probably also .git/config it should just seamlessly work, but I
>haven't tried it.  Since it only accepts fast-forward pulls it
>shouldn't do anything if the histories don't match.  If you do a sync
>immediately before/after the change maybe you'll find that one repo is
>behind the other and you just won't get any updates until the new repo
>catches up, but I don't think portage will revert anything (that is an
>advantage of git - it has a concept of directionality, though it looks
>like portage is looking to add support to prevent replay attacks with
>rsync as well).
>
>>I do sync frequently (I'm a bit of an update enthusiast) -- at least
>>once a week, though I prefer more often as I find that the longer I
>>leave between syncs and world-updates, the more effort I have to
>>overcome issues (few though they are). So git is a better fit for me,
>>I
>>think.
>
>Honestly, I think git is a good fit for a lot of Gentoo users.  Yes,
>it is different, but all the history/etc is the sort of thing I think
>would appeal to many here.  Also, git is something that is becoming
>increasingly unavoidable, and mostly for reasons that have universal
>appeal.  Once you grok it you'll be using it everywhere.
>
>Security is obviously getting a renewed focus across the board, so I
>think we'll see improvements no matter how you use Gentoo, ideally
>using defaults (for whatever reason git sig checking isn't a default
>today).  Besides improving verification on the end-user side there is
>also a lot of interest in improving security on the developer side,
>and with infra (hardware tokens, maybe E2E signature checking, etc).
>As usual this involves a certain amount of debate (authentication
>isn't actually all that easy of a problem).
>
>
>--
>Rich
>