On Fri, Jul 6, 2018 at 7:57 AM Davyd McColl <dav...@gmail.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
