1 |
Rich Freeman <rich0@g.o> wrote: |
2 |
> |
3 |
> Biggest issue with git signature verification is that right now it |
4 |
> will still do a full pull/checkout before verifying |
5 |
|
6 |
Biggest issue is that git signature happens by the developer who |
7 |
last commited which means that in practice you need dozens/hundreds |
8 |
of keys. No package is available for this, and the only tool which |
9 |
I know which was originally developed to manage these (app-crypt/gkeys) |
10 |
is not ready for usage for verifaction (gkeys-gpg --verify was |
11 |
apparently never run by its developer since its python code breaks |
12 |
already for argument parsing), and its developmant has stalled. |
13 |
|
14 |
Moreover, although I have written a dirty substitute for gkeys-gpg, it |
15 |
is not clear how to use gkeys to update signatures and remove staled |
16 |
ones: It appears that for each usage you have to fetch all seeds and |
17 |
keys anew. (And I am not even sure whether the seeds it fetches are |
18 |
really still maintained). |
19 |
|
20 |
So currently, it is impossible to do *any* automatic tree verification, |
21 |
unless you manually fetch/update all of the developer keys. |
22 |
|
23 |
Safest bet if you are a git user is to verify manually whether the |
24 |
"Verify" field of the latest commit in github really belongs to a |
25 |
gentoo devloper and is not a fake account. (Though that may be hard |
26 |
to decide.) |
27 |
|
28 |
> until the patch makes its way into release (the patch will do a fetch |
29 |
> and verify before it does a checkout |
30 |
|
31 |
This helps nothing to get all the correct keys (and no fake keys!) |
32 |
you need to verify the signature. |
33 |
|
34 |
> unless you stick --force in your pull |
35 |
|
36 |
Unfortunately, it is not that simple: git pull --force only works if |
37 |
the checked out tree is old enough (in which case git pull without --force |
38 |
would have worked also, BTW). |
39 |
The correct thing to do if git pull failed is: |
40 |
|
41 |
git update-index --refresh -q --unmerged # -q is important here! |
42 |
git fetch |
43 |
git reset --hard $(git rev-parse --abbrev-ref \ |
44 |
--symbolic-full-name @{upstream}) |
45 |
|
46 |
(The first command is needed to get rid of problems caused by filesystems |
47 |
like overlayfs). |
48 |
|
49 |
(If you are a developer and do not want to risk that syncing overrides |
50 |
your uncommited changes, you might want to replace --hard by --merge). |
51 |
|
52 |
> not a great idea for scripts and portage doesn't do this). |
53 |
|
54 |
I think it is a very great idea. In fact, portage did do this previously |
55 |
*always* (with --merge instead of --hard) and the only reason this was |
56 |
removed is that the |
57 |
git update-index --refresh -q --unmerge |
58 |
takes quite some time which is not necessary for people who do not |
59 |
use a special filesystem like overlayfs for the portage tree. |
60 |
The right thing to do IMHO is that portage would use this anyway as |
61 |
a fallback if "git pull" fails. I usually patch portage to do this. |
62 |
|
63 |
> that was just dumb luck |
64 |
|
65 |
Exactly. That's why using "git pull" should not be considered as |
66 |
a security measurement. It is only a safety measurement if you are |
67 |
a developer and want to avoid loosing local changes at any price |
68 |
if you mistakenly sync before committing (although the mentioned |
69 |
--merge instead of --hard should be safe here, too). |
70 |
|
71 |
> Honestly, I think git is a good fit for a lot of Gentoo users. |
72 |
|
73 |
At least since the ChangeLogs have been removed. |
74 |
IMHO it was the wrong decision to not keep them in the rsync tree |
75 |
(The tool to regenerate them from git was/is available). |
76 |
|
77 |
> it is different, but all the history/etc is the sort of thing I think |
78 |
> would appeal to many here. |
79 |
|
80 |
Having the ChangeLogs would certainly be sufficient for the majority |
81 |
of users. It is very rare that a user really needs to access the |
82 |
older version of the file, and in that case it is simple enough |
83 |
to fetch it manually from e.g. github. |
84 |
|
85 |
> Also, git is something that is becoming increasingly unavoidable |
86 |
|
87 |
If you learn something about git from using it through portage, |
88 |
this only indicates a bug in portage. (Like e.g. using "git pull" is). |
89 |
|
90 |
> Security is obviously getting a renewed focus across the board |
91 |
|
92 |
Unfortunately, due to the mentioned keys problem, git is |
93 |
currently the *unsafest* method for syncing. The "git pull" bug |
94 |
of portage is not appealing for normal usage, either. |
95 |
(BTW, due to the number of committers the portage tree has a quite |
96 |
strict policy w.r.t. forced pushes. Overlays, especially of single |
97 |
users, might have different policies and thus can fail quite often |
98 |
due to the "git pull" bug.) |