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
