assigner commit -S/--gpg-sign

[BehindTheBrain]

If one wants to both use gpg2-signed commits for protecting admin/grader files from student modification, and one is revising an existing assignment, then assigner commit needs to be able to sign those commits. @joshessman mentioned that python git modules can't sign yet, so this is not as trivial as would be desired. In the meantime alternatives include committing in a bash script, or enabling commit.gpgSign in git congfig.

After including such a feature, in the docs, we need to mention one needs to echo default-cache-ttl 10000 >>~/.gnupg/gpg-agent.conf if you want to cache your gpg passphrase for all these commits.

[joshessman]

Source: gitpython-developers/GitPython#580

[BehindTheBrain]

I think we may not need the gpg at all: The way it's implemented, in
assigner/backends/gitlab.py GitlabRep.list_authorized_users the
full_users only grabs maintainers or above, which should be sufficient given assigner's permission structure right?

Also we need to put in the docs that the Gitlab default email settings do not cut it, but that it also has to be selected in "public email" in the gitlab gui settings. I'm not sure if we can get the hidden private email at all in the api.

[joshessman]

A couple thoughts on this:

GL doesn't have first-class support for linking a user with a commit. Theoretically, a Maintainer could push commits authored by a student, or anyone really. There may be a way to check "push" events for each authorized user and attempt to cross-reference with the "suspicious" commits (i.e. those that modify grading files).

https://docs.gitlab.com/ee/api/events.html#get-user-contribution-events has some info that might be relevant.

[LinuxMercedes]

I am a little confused by these last two comments. Will everything be fixed if I modify assigner commit to gpg sign the commits?

I suppose we also need to note that assigner requires your git commit email to match the one on your gitlab account. I don't think gitlab has any API for querying special information about users, so public email is probably the best we can do. Do you have a link to some gitlab docs about the email settings that need to be set?

Git itself doesn't have any association between push events and commit authors, and I don't think it makes sense to try to tie commits and pushes together on gitlab if we can find a different way to validate them.

[BehindTheBrain]

Yes, optionally signing commits is the only thing needed, other that adding that line of documentation about the public email, keyids, signatures on commits, and emails all matching.

Using .gitconfig to force signing actually does not suffice. The git python API is lower level / earlier than that config operates for signing. So even when you sign all commits by default due to the config, assigner won't sign. I've just been doing this for mid-release edits:

for d in "$1"*/
do
    echo "$d"
    cd "$d"
    git add .
    git commit -m "updates" -S
    cd ../../../
done

Regarding confusion, I was not sure whether the full_user was actually only returned when all gpg signatures, keyids, and emails match, and forgot for a moment that the public email itself is not sufficient, given local repos have complete control.
full_user = self._gl_get("/users/{}".format(user["id"]))
But it is (just did a bunch of tests).

[joshessman]

After investigating this a little we should be able to just use repo.git.commit('-S -m "{}"'.format(message)), instead of

assigner/assigner/commands/commit.py

Line 85 in 1654298

index.commit(message)

though this won't pull up a prompt for the user to enter their GPG passphrase. I wonder if there's a way to preauthenticate without going through Python's git module.