We *really* need to establish signing commits with a verified key as common practice in software development.
For some critical projects it should probably even be a strict requirement for collaboration 🤔
(for some it already is, but it's still the exception, not the rule)
@fribbledom I do this for every commit now. GitHub needs a setting that rejects non-verified commits.
I acknowledge the weaknesses of this stuff, but it's still better than nothing.
There is such a setting on a per-branch level. Go to `Project Settings` -> `Branches` -> `Branch protection rules`.
@fribbledom it would help if it wasn't kind of a pain in the ass to even establish pgp keys in a secure way, and then integrate them into that workflow
it is possible but, well, i personally have tried to do it and it isn't easy right now
@fribbledom need the ability to have a commit signing subkey that can just sign commits, as I surely don't want to tap my yubikey each time I commit.
@fribbledom there is no ability to specify which things a subkey can sign, so you could just sign uploads to Debian or Ubuntu with it as well.
I could use a second key and sign it with the primary key. Make it nice Ed25519, add a (Automatic code signing) comment.
Excellent idea with restricting signing subkeys!
I'd be cool to have two signing subkeys: one for signing important things that is rarely used (e.g. software releases) and one for signing other things frequently (like git commits). Or even have the ability to specify that “this subkey can be used only for git commits only for project X”.
@wiktor Tying subkeys to UIDs, and then tying permissions to UIDs instead of primary keys would work.
But arguably it's a lot of work and signing a separate key is easier.
Either way, need to get my primary key live to be able to sign keys or generate subkeys. Should really put it on redundant smart cards.
Yeah, agreed. Currently it’s not practical. I was just imagining what a “perfect solution” world would look like. Today having separate keys seems to be the way to go.
Redundant smartcards are definitely nice. I just broke one during testing and thanks to having another one I didn’t have much problems that day.
@fribbledom I like the sentiment (and I actually touch-yubikey-to-sign all my commits).
This gets a little messy when you mangle (e.g. rebase/squash) commits by others: they changed, so you have to re-sign them. I guess you only do that when also reviewing the code, so the signature means "I'm signing off on this code", not "I wrote this code". That should be explicit in the project rules, though.
(was this sparked by https://news-web.php.net/php.internals/113838 ?)
You're spot on with this short analysis! Rebase/squash via the web interface does become a bit messy, and it's the only reason I haven't started enforcing signed commits in my projects.
Also, yes, this was indeed sparked by the recent PHP news.
@fribbledom it would be neat if online git platforms (like GitHub) would use a per-account private key (e.g. 'raboof via GitHub') to sign commits made by that user through the UI!
@raboof @fribbledom Yeah, having tooling that can accommodate signing like that, or to step in via automation seems like it'd help a lot. My standard workflow is a squash/rebase on PR completion, so the most useful way to do this would be a server-stored key. PRs also offer interesting options for review signatures.
@fribbledom there is also a short summary at #mercurial about the problems of #signing in #git (and in general): https://www.mercurial-scm.org/wiki/CommitSigningPlan#Comparison_to_Other_VCS_Systems
@wago I had hoped Keybase might solve a lot of what was hard with the old PGP model (esp. the “web of trust” stuff in keyservers and key signing parties), but so far it doesn’t feel like it has made enough difference in practice.
Also, since Zoom bought Keybase I’ve felt more skeptical than before about using or promoting Keybase.
For the record in 2021 it’s https://keyoxide.org that’s solving the social proofs problem for OpenPGP.
Keybase had numerous small issues: centralized design with closed-source server and a feature creep that made it impractical to use in the wider open-source ecosystem.
@wiktor It’s a start, but it doesn’t actually solve most of the problems Keybase was trying to solve, including and most specifically the Ease of Use problems. Even assuming command line familiarity (as can be in the thread for developers you found my post in), you are entirely punting on key management issues/ease of use, which are the complaints in this thread. Yes, you have good reasons to punt because key management trust is HARD and dangerous, but it’s what people need.
@wiktor But the other problem is you’ve got the direction arrow on the proofs backward. The killer feature of Keybase proofs was not associating the key with the proof, but associating the proofed account with the key. Not just taking the keyserver’s word that it has keys for email/Twitter handle/Mastodon account, but that looking up email/Twitter/Mastodon in the keyserver returns A verified/proven key.
@wiktor Even Keybase has slightly more thought into a decentralized version of that than Keyoxide right now with their silly blockchain-based thing. Not that I’d recommend emulating that, as I would start by modernizing the keyserver and keyserver protocol designs myself. Decentralized directory services are something that have advanced quite a bit from 90s PGP state of the art.
@wiktor Anyway, my examination of your project stops at the documentation because I don’t use or contribute to AGPL products, but I hope you find the above criticism useful.
First, a disclaimer: not sure what do you mean by “your project” but even though I talked to the developer about the idea I didn’t write a single line of code for them.
The CLI familiarity is required now because it’s a young project, this is not the end result that they want to aim. Not having millions of dollars from VC makes implementation go a little bit slower than Keybase could manage.
As for associating the proofed account, that’s a nice property but it’s definitely easier to implement in centralized solution as Keybase. You have one database and that’s it. Where in truly decentralized setting this makes things more complicated (but for some providers it’s already possible today as they use predictable paths).
Not sure what’s decentralized in Keybase’s sigchain if they were the only party that run their “blockchain”. Do you mean the fact that they persisted the merkle tree root in Blockchain once in a while? If you could point me to these “decentralized directory services” I'd be very interested.
As for AGPL Keyoxide uses open protocol for social proofs that can be reimplemented in any language. Consider the page a mere frontend for displaying what’s in the keys.
@wiktor An example directly used your Mastodon handle so I assumed you were directly involved in the project.
The CLI problem is merely indicative of deeper problems, most especially key management. I understand the issues of bootstrapping from limited resources. That’s part of why I offered such criticism. “It’s not very useful in its current state.” and “Who is the target audience when it needs so much CLI familiarity?” even if the answer is on the TODO list.
@wiktor I’m not going to get into my software ethics concerns about the AGPL into depth here. I’m just making it clear under my professional code of ethics I do not engage with AGPL projects. I think it is a severely flawed license that violates my sense of ethics. I have no problem with any of the other GPL licenses, AGPL is just a line I personally do not cross for any reason.
@wiktor Again, it’s not a great system, but yes Keybase’s merklev tree is entirely open and the root is pinned over time in the Bitcoin chain. It’s theoretically possible to do distributed proof checks via that merkle tree without needing a Keybase server centrally. Merkle trees aren’t a data structure well suited for such searches so the “easiest” way would still be to painfully rebuild a central database by crawling it. It’s still technically A distributed system though.
@wiktor An OpenPGP keyserver is classic NNTP/FidoNet eventually consistent gossip chain. At the very least we have decades of knowledge in DHTs now as just one option. (ActivityPub-like federated pubsub is another in an entirely different direction.) On top of that most claims in an OpenPGP directory are entirely self-identified/self-assured. Anyone can post an email address and the OpenPGP response has always been “check the fingerprint and WoT”.
@wiktor If you are adding proofs to the system they should be at the directory level! Search for proofs directly in a DHT and get the proofed key and only the proofed key back. No fingerprint checks or additional WoT check steps maybe necessary.
Again, I understand trying to bootstrap from existing infrastructure, but at least from my viewpoint if there is infrastructure to Day 1 replace and throw out as bad UX garbage, I’d personally start with keyservers.
That’s definitely a bunch of interesting ideas! Have you thought about validating the idea by implementing DHT based key discovery and/or ActivityPub-like federated pubsub? Then you could publish it under a more permissive license and thus kill two birds with one stone.
Do you have an account on sr.ht, gitlab or any other service where I could follow?
@fribbledom These devices are expensive, and I am unsure their price would be worth the small gain of solely being able to sign my commits. And if I'd use it for 2FA too, I'd be too scared to loose them :/
You can get them from $15 upwards. I also use mine for password management, auth (2FA), email / communication encryption, document signing, and general purpose door-locks.
You can make encrypted copies of the key to protect yourself against losing it. 2FA typically gives you recovery keys, so you can still recover your accounts one way or another.
@shironeko Yeah this is precisely the kind of issues I don't want to deal with haha : keys, to store, to manage, to revoke, to sync accross devices, etc.
This is so much overhead, for so little gain, in my point of view
I have two Yubikeys, and I scan all OTP keys on both when I cannot use U2F, and I have an encrypted USB stick with the PGP vault backup, I have the keys on both my USB keys, and finally I printed a paperkey and paper revocation key in case USB key dies.
I did master key creation all offline with a debian live USB too. Although probably that's for the paranoid.
I think it's hassle, but totally doable for software engineers https://sammorrowdrums.com/using-pgp-encryption-in-2021
@fribbledom honestly if it wasn't PGP I'd be more bothered to keep it working
less long-lived keys would be nice, as well as automatic management, and no Web of Trust nonsense
I'm not really sure how you'd do it in a way that's not just specific to GitHub though
This idea looks good on the paper but if one scrutinizes it then the cracks begin to show. First of all what does it mean for the key to be “verified”? Do we get back to key signing parties? Or use weak social proofs of https://keyoxide.org ? Is it allowed to use the Web of Trust to verify keys?
How do we deal with key rotation and what’s the key source (keyservers that are prone to flooding  or Web Key Directory?).
Even if you get all of that right signed commits still leave room for exploitation for example repurposing your signed “test” commit on a master/main branch. We'd need to use git push --signed that is not supported on any git forges known to me. Details at: https://stackoverflow.com/a/27300197
Not to mention the practical trivia such as that some major projects (like kernel.org) work with git patches and signed commits cannot be sent that way.
@fribbledom I do sign my commits with my GPG key, but honestly the problem is GPG itself: it's tedious to use and very complicated.
I think we should have a very simple frontend (not necessarily a UI) on top of GPG that makes it actually easy to use and manage (like, notify the user when the key is close to expiring and managing renewal and derived keys)
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!