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