Rich Freeman <ri...@gentoo.org> wrote:
>
> Biggest issue with git signature verification is that right now it
> will still do a full pull/checkout before verifying
Biggest issue is that git signature happens by the developer who
last commited which means that in practice you need dozens/hundreds
of keys. No package is available for this, and the only tool which
I know which was originally developed to manage these (app-crypt/gkeys)
is not ready for usage for verifaction (gkeys-gpg --verify was
apparently never run by its developer since its python code breaks
already for argument parsing), and its developmant has stalled.
Moreover, although I have written a dirty substitute for gkeys-gpg, it
is not clear how to use gkeys to update signatures and remove staled
ones: It appears that for each usage you have to fetch all seeds and
keys anew. (And I am not even sure whether the seeds it fetches are
really still maintained).
So currently, it is impossible to do *any* automatic tree verification,
unless you manually fetch/update all of the developer keys.
Safest bet if you are a git user is to verify manually whether the
"Verify" field of the latest commit in github really belongs to a
gentoo devloper and is not a fake account. (Though that may be hard
to decide.)
> until the patch makes its way into release (the patch will do a fetch
> and verify before it does a checkout
This helps nothing to get all the correct keys (and no fake keys!)
you need to verify the signature.
> unless you stick --force in your pull
Unfortunately, it is not that simple: git pull --force only works if
the checked out tree is old enough (in which case git pull without --force
would have worked also, BTW).
The correct thing to do if git pull failed is:
git update-index --refresh -q --unmerged # -q is important here!
git fetch
git reset --hard $(git rev-parse --abbrev-ref \
--symbolic-full-name @{upstream})
(The first command is needed to get rid of problems caused by filesystems
like overlayfs).
(If you are a developer and do not want to risk that syncing overrides
your uncommited changes, you might want to replace --hard by --merge).
> not a great idea for scripts and portage doesn't do this).
I think it is a very great idea. In fact, portage did do this previously
*always* (with --merge instead of --hard) and the only reason this was
removed is that the
git update-index --refresh -q --unmerge
takes quite some time which is not necessary for people who do not
use a special filesystem like overlayfs for the portage tree.
The right thing to do IMHO is that portage would use this anyway as
a fallback if "git pull" fails. I usually patch portage to do this.
> that was just dumb luck
Exactly. That's why using "git pull" should not be considered as
a security measurement. It is only a safety measurement if you are
a developer and want to avoid loosing local changes at any price
if you mistakenly sync before committing (although the mentioned
--merge instead of --hard should be safe here, too).
> Honestly, I think git is a good fit for a lot of Gentoo users.
At least since the ChangeLogs have been removed.
IMHO it was the wrong decision to not keep them in the rsync tree
(The tool to regenerate them from git was/is available).
> it is different, but all the history/etc is the sort of thing I think
> would appeal to many here.
Having the ChangeLogs would certainly be sufficient for the majority
of users. It is very rare that a user really needs to access the
older version of the file, and in that case it is simple enough
to fetch it manually from e.g. github.
> Also, git is something that is becoming increasingly unavoidable
If you learn something about git from using it through portage,
this only indicates a bug in portage. (Like e.g. using "git pull" is).
> Security is obviously getting a renewed focus across the board
Unfortunately, due to the mentioned keys problem, git is
currently the *unsafest* method for syncing. The "git pull" bug
of portage is not appealing for normal usage, either.
(BTW, due to the number of committers the portage tree has a quite
strict policy w.r.t. forced pushes. Overlays, especially of single
users, might have different policies and thus can fail quite often
due to the "git pull" bug.)
