Providing specific commits to be included

[jayvdb]

I have quite a few pre-GitHub commits where they were sent as patches, and committed/merged by someone (i.e. commits_authoring does not help) either with:

• my GitHub email in the commit body (easy to automatically verify)
• my GitHub username / full name in the commit body (a bit harder to automatically verify, with limited ability to 'steal' other peoples commits)
• an old email/username in the commit body (no easy way to verify this was my identity at the time; proof would need to be mailing list / bugzilla / etc)
• no attribution at all (again, other online resources may help with proof)

It would be nice to have a way to provide a list of these commits to be included in the stats.

[lowlighter]

I guess the first three points could be implemented if we edit the indepths analyzers to search stuff within the commit body too.
For the last point, maybe users could provide a list of commit sha which to consider them as authors.

A proof checking seems a bit overkill because eventually this action code can be forked and changed easily.
Nonetheless, it's nice to have mentioned it, it's very instructive and if someone ever need to check how to know if a commit not attributed to an user is legimate they'd know how to do it 🙂

[jayvdb]

I think we'd also need to allow specifying the repos, because GitHub doesnt know the repos have my commits in them.
e.g. https://github.com/apache/httpd/search?q=jayvdb&type=commits and https://github.com/search?q=org%3Aapache+vandenberg&type=commits (but the spark contribs are Erik Vandenberg, not me - afaik it isnt possible to exclude "erik", which makes me worry about searching in repos vs the more reliable approach of specifying commits)

Regarding proof checking, IMO the reason I have always prominently linked to generated profiles is that I find user-authored profiles to be not-worth-reading/taking-seriously because they are misleading. Someone wanting to check can go the GitHub Actions definition & README and verify the stats are generated from the upstream code. But I would like to eventually link to https://metrics.lecoq.io/about/jayvdb (as soon as it is working) to allow easier verification.

[lowlighter]

Yeah we could eventually use the syntax user/repo@sha1 which should be enough to work with I think

It's possible to exclude stuff from github search using NOT (e.g. https://github.com/search?p=2&q=org%3Aapache+vandenberg+NOT+ericvandenbergfb&type=Commits) but I think it's still a bit unreliable to rely solely on usernames

Proof-checking could be implemented eventually (though it seems to be a lot of work, so it may not be in available in a close future) but it could actually be re-used for other stuff, like the notable plugin.

As for the last point, even though I'd like it to be a reference, the metrics.lecoq.io/about doesn't have indepth mode enabled on it (actually all "advanced features" are disabled for security reasons and to avoid denial of service). Languages displayed on it are using the "base algorithm" which just use the languages associated on repo you contributed

[spenserblack]

I think we'd also need to allow specifying the repos, because GitHub doesnt know the repos have my commits in them.

I think it's possible to work back from a commit hash to a repo this way: https://api.github.com/search/commits?q=sha:9d118b531801698da7867e979cd1bfa38e578302

IIRC from a git feature request, git hashes are currently extremely unlikely to have a duplicate, but it's possible. I think it's good enough, though.

[lowlighter]

It's a nice way to avoid fetching a whole repository for a single commit indeed 👍
The only limitation is that the rate limit is pretty low for this endpoint IIRC, but I assume that users won't put thousands of commits manually

[lowlighter]

Probably will be done in the same time as #857

[jayvdb]

For me, GitHub username is part of GitHub public email, so part of (2) overlaps with (1)

Not a great example of (1) because there is no official github mirror https://github.com/search?p=2&q=jayvdb%40gmail.com+quilt&type=Commits . I guess I would need to tell metrics which repo to index.

https://github.com/search?q=jayvdb%40gmail.com+apache&type=Commits is better for (1) as apache/httpd@f658e4a would be the commit which should count, and the rest ignored.

A good example of (2) is apache/apr@2b35ac4

(3) bugzilla/bugzilla@af7e8c5

(4) is hard because I dont have any way to search for them either. before github, etc, it was very common for maintainers to accept a patch via email, doctor it a bit (sometimes good sometimes not) and commit as their own work since the patch was obviously not acceptable as-is and needed revising. Occasionally I run into one of these commits from 20 years ago, and have not had anywhere useful to record them, and thought I will remember this if ever I need it, then promptly forgot.

[jayvdb]

A case that is borderline (3) or (4) that maybe I would "claim": amalysh/kannel@4d536e6 (upstream mentions John.Vandenberg@callista.com.au (hence (3)) , but the commit body imply any authorship, because it is an improvement of my patches, one of them at https://www.mail-archive.com/devel@kannel.org/msg00898.html , and there should be a mysql one somewhere. The commit rewrote large parts of my patch, so I would only include this if I also footnoted it somehow to explain this (the general problem of (4)).

[lowlighter]

Thanks a lot for these examples, it'll help greatly to implement this feature 👍

As for the ownership issues, it's not entirely decided yet, but it'll probably just be a footnote like this:

The above is just a mockup and not definitive (I haven't started development yet), but basically I'm thinking of grouping in these categories:

• verified by gpg key (the ones attached to github account) (if possible, haven't checked yet if it'd be easy to integrate)
• verified by commit header
• verified by commit body
• unverifiable

This way people will have a "direct information" about how trust-worthy these stats are
Maybe it'll also have a small color diff similar to the indepth followup plugin mode, unless if it makes it too cluttered

I know we talked in the past about some sort of distributed storage across different users but I think it'll be too hard to setup and maintain. That's why I'm leaning towards the solution above

[spenserblack]

This could quickly hit the rate limit, but the GitHub API provides GPG verification status of commits.

But, if you need to verify that the key belongs to the GH user, you can first get the public key with github.com/<user>.gpg (e.g. https://github.com/jayvdb.gpg).

I'm not 100% sure where to go from there, but I guess you'd have to verify a detached signature from the commit API response's .verification.signature.

It should be noted that the commit footer Signed-off-by: Name <email> is a (not the) standard for commit messages (it's added with git commit --signoff). There's also the Co-authored-by footer that GitHub uses. So there could potentially be a verified by commit footer group as well.

[lowlighter]

This could quickly hit the rate limit, but the GitHub API provides GPG verification status of commits.

Since it's exclusively for the indepth mode, where the whole git repository history and git command are available locally, I think it's better to use directly git verify-commit. It's probably more efficient and it avoids spamming GitHub's API.

git verify-commit 740947ba9f0f41ffb01be14b0187a8cfb029ee96
gpg: Signature faite le 02/15/22 23:52:22 Eastern Standard Time
gpg:                avec la clef RSA 9E4F1A072F57376BE89AF4CCB7C0F095CFC70776
gpg: Bonne signature de ®ÿSimon Lecoq <22963968+lowlighter@users.noreply.github.com>ÿ¯ [ultime]

But, if you need to verify that the key belongs to the GH user, you can first get the public key with github.com/<user>.gpg (e.g. https://github.com/jayvdb.gpg).

The GET /user/gpg_keys endpoint seems more suited, although it does required the read:gpg_key scope. The advantages being that all keys can be listed at once, and the key id is already pre-computed from what I've seen (I'm not sure the public key is that revelant in this context)

It should be noted that the commit footer Signed-off-by: Name <email> is a (not the) standard for commit messages (it's added with git commit --signoff). There's also the Co-authored-by footer that GitHub uses. So there could potentially be a verified by commit footer group as well.

That's a good remark, I'll keep it in mind 👍

[lowlighter]

Related #1258