That competition between gitlab and github is starting to give good results: 3 weeks in a row with news from both, each time with long-awaited features.
If this doesn't show that competition is good, I don't know what else could!
The lack of something is hard to notice, especially when the majority of people don't sign commits. Perhaps if people start widely signing commits and tags, Github could add an option to explicitly mark commits or tags as "unverified" if they fall after a specified date and don't have a signature.
I decided to start signing all my commits as a matter of policy, since the cost to break SHA1 is now estimated at $75k. There are certainly git repos that it would be worth $75k to compromise, and a single birthday attack collision in SHA1 can be reused to compromise multiple git repositories (requires some social engineering). So I think that is a good policy now.
Github could have a setting like "flag unsigned commits from me after $date" that allows this kind of policy to be communicated.
Apologies for being completely off-topic, but reading this comment gave me a flashback to whenever it was when I started reading Hacker News. Try to imagine that you know nothing about version control or cryptography and then read the above comment.
It's like someone is telling you that they always schnarkel their schnops with shaush, now that the cost of schnacking a schnill is a mere $75k.
After however many days, I pretty much understand all of what joeyh is saying, except maybe for how the social engineering part would work. Thanks Hacker News.
Note that signed commits only validate the commit file contents up to the SHA1 of the top level tree, it's not a GPG signature of the entire tree state.
This means that a SHA1 collision on the tree object, or any blob object, still results in a valid GPG signature.
So git GPG doesn't provide any additional security over SHA1; it only provides proof that a certain person signed a SHA1 and the commit message.
Git's use of SHA1 is explicitly not intended to provide any security (per Linus), so this argument really doesn't make sense. On github, right now, I can commit as you all I want, no exploits required, and that seems like a much more pressing reason to sign commits.
The other thing is that the SHA1 weaknesses are collisions. It's not likely to be possible in the foreseeable future to create a commit that matches an arbitrary hash - to generate colliding commits, the committer would need to generate the good and evil commit at the same time.
Is that $75k for a preimage attack? You would need to generate a collision that could be reasonably interpreted as a valid commit. It's my understanding that preimage attacks against SHA-1 are still considered to be impossible, even for a state actor.
The main thing stopping me from doing the same is that I do my work on three different machines: my personal laptop, my work laptop, and a build server in a lab. Those represent three different trust levels. So I'd need to make two more GPG keys than I currently have, and handle key management, which at the moment doesn't yet seem worth the trouble.
Apart from that, half the patches I prepare go out via git format-patch rather than a push and a pull request. So I'll need to confirm if the signature survives that workflow, and if it produces unwanted noise or other effects on development mailing lists.
I'm a huge fan of the concept, but unfortunately gpg is such a terrible program that I completely gave up using signed commits from basic testing. The agent that does exist I could not convince of working either at all or with git and entering a long passphrase on every commit is not my thing.
Are there any efforts in writing a minimal version of it with a modern and flexible UI?
I use a Yubikey 4 for this purpose, signing individual commits then becomes "physically touch the key to sign" (after you enter the pin one time) rather than entering a long passphrase.
Something more like openbsd's signify[1] tool seems like it would be a nice signing tool for git commits. Signatures and keys are small, due to use of ed25519[2].
What's up with the dead comment? I find GnuPG's command line interface to be on par with most other programs and don't have any particular troubles signing / encrypting / decrypting messages or files, symmetrically or otherwise.
Not that I know of. Everyone who's enthusiastic about modern crypto seems to want to throw out the proven cryptography baby with the horrible UX bathwater :(.
Honestly the agent is better than it was (not that that's saying much). Other than that, GPG relies on one part-time developer - I'm sure contributions would be very welcome.
I'm not so sure that contributions would be welcome. When I've come up against limitations, and go search through the mailing lists to see what's been done, I find that ideas and code have been rejected.
I have a key fob that performs cryptographic operations. Rather than use existing standards, GnuPG demands full control of the fob, making it impossible to use the same device for client certs on browsers, or for the VPN, etc. There are some barely maintained shims that get around some of these design flaws, but it's an extremely hassle to find the shims and to get them working.
GnuPG's agent also makes it quite difficult to use git remotely. Most of the code I write is on remote servers, setting up an agent to allow forwarded operations.
I think that it's time to move on from GPG, or fork it, or something. There's not much in GPG's implementation of PGP that I like.
I spent a considerable amount of time a few months ago trying to figure out GPG. I've used it for years but never really understood what it was doing. Part of the problem is that the documentation is really misleading in certain places (and conflates many different things attaching the label "key" to them).
Unfortunately after reading the source code and then reading the OpenPGP spec, I am convinced that most of the problem is actually OpenPGP. GPG is a bit of a hairball of a program, but it is faithfully doing what it is supposed to be doing.
Here is how I would describe the basics. Hopefully it will help you wrap your head around it. The bad part is that OpenPGP does not actually work this way. Consider this as "this is a way to view how it would work if OpenPGP wasn't completely insane":
- A key is composed of a private and public part. These are often referred to as "public key" and "private key"
- A key that one signs should actually be thought of as a certificate
- A certificate is just a bundle that includes a public key part, an "identity" (which is usually just a string, but can also include a picture), and a bunch of signatures. The signatures indicate that somebody believes that the identity is bound to the public key part (i.e. the string identifies the person who holds the private part of the public key).
- When you "sign" something, your signature is related to a piece of data (usually text). If someone has your public key part, they can verify only someone with the private part could have produced the signature. It is important to realise that you must sign something.
- When you "sign a key", what you are really doing is creating a signature for the identity string on a certificate and adding your signature to it.
- There are "master keys" and "sub keys". A "master key" should really be thought of as a certificate along with the private key part. A "sub key" is a public-private key pair with a particular ability (sign, certify, encrypt, or authenticate).
- You can create a certificate for your subkey that contains the public part of the subkey and is "certified" (basically signed) by the master key private part. This allows people to tell that your "sub key" certificate is associated with your "master key" certificate.
- Your sub key certificate has no identity information and is not signed by anyone other than the owner. To find out the identity of the person who owns the sub key, you have to have the master key in your possession and check the signature on the sub key.
- GPG makes a kind of "container" where it stores the master key certificate (which includes the public key part, the identity string (and possibly picture), and signatures of the identity by other people) along with the sub key certificates (which contains the public key part and a signature from they master key). In another place, GPG stores the private key parts that you may have for any master or sub keys.
Now go back to the GPG documentation and read it. That is how OpenPGP specifies that you must actually implement it. It would be nice to write an implementation that was simpler (possibly as I describe above), but it will always be a slightly leaky abstraction. And even my (much, much less confusing IMHO) description above is still ridiculously complicated.
Essentially you want 3 operations. Generate keypair, encrypt X with key, decrypt X with key.
You want this as a library that's impossible to misuse and a nice CLI on top.
The fact that it took you half an hour to understand the "basic usage" is ridiculous. The GPG developers have failed in the worst possible way when it comes to the design of their software. It's so bad I find it incomprehensible how that could have happened on accident.
If they would be working on something non-cryptographic, that would be one thing but for a cryptographic tool that's unacceptable. The design and ease of use is just as important as the cryptographic algorithms themselves for such a tool because any friction causes people to avoid cryptography.
I have little direct evidence, but I suspect the problem is a set of programmers that hate the command line and never learned to rely on man pages. When they try gpg, they try --help and see the giant list of options, and immediately panic.
This same attitude may also explain the tendency to reinvent things like rsync and other tools that have accumulated a large set of options over the years.
That is an order of magnitude more effort than most people are willing to put into it. Try teaching a not-computer-savvy relative to use it and exchange email with them.
If you're like me and gpg --export -a $KEY is 3000 lines of output due to lots of signatures on your key, try:
gpg --export-options export-minimal -a --export $KEY
I guess github wants to associate particular accounts with keys, but it seems they could save a lot of cut and paste bother if they supported importing keys from the keyservers.
I'm happy about this but I thought signing commits wasn't a good thing to do. Linus wrote a lengthy post[1] on this saying you should only care to sign tags.
(I'm not a security person)
Read svckr's comment below and link #1 - what I was saying here before my edit was wrong. :D
I'm not 100% sure what you're saying here, but in the post you linked, Linus seems to be referring to a hypothetical solution where you're not signing the SHA of a commit but some subset.
When you use Git to sign a commit or a tag, you vouch for the SHA of that commit or tag; i.e. the whole history of that branch up to that point, including author names and email addresses.
The point Linus is making is not exactly one of security. The problem you get when signing commits instead of tags is that the signatures become part of the branch's history and both (signature and history) become inseparable. You can't re-sign a commit without re-writing all the commits that follow. If for example your keys were compromised, you invalidated them, and want to re-sign your repo with your new keys, you'll have to change each and every commit.
With a tag, you'll just update the tags and the rest of the branch remains unchanged.
I hope, together with the thread you posted, this at least makes some sense.
Back to GitHub: I think this is a nice UI for displaying signatures in the history view. Assuming you can trust GitHub to really use your public key for validating (hat tip to fabulist) I don't see an issue with making that information accessible via the web. More importantly, they also display the "verified" badge on the "Releases" page where your tags appear.
I would add that you shouldn't trust GitHub not to lie to you, and verify signatures for yourself. One need not attribute malicious motives to GitHub in this scenario; they could get hacked, served with an NSL, successfully man-in-the-middled, or inadvertently hire a bad actor.
I was thinking it'd be nice if you could set a signing policy on GitHub - either all commits are signed or none are. A mixed situation just leads to harmful confusion. You would still need to verify sigs yourself, but if they're available for every commit this does still save you time before creating the signed tag.
I was amused, after discovering Monotone through the I2P project that you can sign your commits in git too (although in a SCM not written in C++, look around for that famous Linus rant). I was well on board with the idea, like signing my many emails, but even as a rank amateur I have nightmares of waking up like this guy.
So I would love tarballs and other things signed, and I do not want to be one of those whiny moochers, but imagine the backlash you get as thankless free software developer when you bork your tag sign or mess up one commit and people through you under the bus, because you cryptographically agreed to it? Haha.
I mean, my comment was partially in jest. I check gpg.asc probably more than the average, but not as much as a well-respected Debian maintainer. :-)
By the way, I am increasingly interested in trying to wrestle my VMs and various boxes into order. I am tired of failing to learn different DSLs for automation and love the pure Haskell of propellor, which is your tool for managing Debian boxes.
Part of its cleanliness a la Haskell (which I doubt I can ever learn, but applying it to a task like this makes it seem tangible), is you have signed configs and you encrypt your own config into the repo (with cute patches removing this folder will get my ire comments in the docs).
It is very refreshing and honest, like your other software. Hats off to you, sir.
I'm not asking this to be critical, I'm asking because I'm genuinely confused; how is this any more authenticated than just a password? Presumably anyone with your Github password can go add or change your GPG keys if they wanted, so how would it make you any more verified?
Anybody can push a commit to a git repo with Linus Torvalds name and e-mail on it. With GPG signing, they can verify that the claimed author signed off on the commit.
Except that's not how it actually works (you can push fake commits to your repos). If someone can log into your account (to be able to push fake commits to the account's repos) they can also add their GPG key. The point is that no additional security is added by this feature.
How would GitHub even authenticate against a password? Not everyone has an account (and some people have more than one account), and it's very common for one person to push someone else's commits. This gives them an interoperable way to verify commits, even if those commits were originally made on Bitbucket or somewhere else.
They do verify it against the email address on the key, so anyone who made it show up as verified had access to your github password and was able to read an email sent to you. But also, if you don't trust github, you have the option of checking the signature directly and verifying the key thorough any of the other OpenPGP mechanisms.
Am I the only one who thinks that, at this point, this has become and head on race between GitHub and GitLab?
I might be wrong, but it sounds like an incredible coincidence that two companies that haven't really made any noteworthy features on their platforms in a long time are starting to release noteworthy features on an almost weekly basis.
I'd argue GitLab had a late start and has been making significant progress since it started, and based on their Changelog they've been developing a lot of new features for the last year and a half at least (every .x update is released monthly on the 22nd): https://gitlab.com/gitlab-org/gitlab-ce/raw/master/CHANGELOG
Personally, I definitely have a fairly competitive attitude towards GitHub, and I'm motivated to push faster whenever they release a new feature :)
Readit News
If this doesn't show that competition is good, I don't know what else could!
https://help.riseup.net/en/security/message-security/openpgp...
Github could have a setting like "flag unsigned commits from me after $date" that allows this kind of policy to be communicated.
It's like someone is telling you that they always schnarkel their schnops with shaush, now that the cost of schnacking a schnill is a mere $75k.
After however many days, I pretty much understand all of what joeyh is saying, except maybe for how the social engineering part would work. Thanks Hacker News.
This means that a SHA1 collision on the tree object, or any blob object, still results in a valid GPG signature.
So git GPG doesn't provide any additional security over SHA1; it only provides proof that a certain person signed a SHA1 and the commit message.
Linus Torvalds http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...
The other thing is that the SHA1 weaknesses are collisions. It's not likely to be possible in the foreseeable future to create a commit that matches an arbitrary hash - to generate colliding commits, the committer would need to generate the good and evil commit at the same time.
Apart from that, half the patches I prepare go out via git format-patch rather than a push and a pull request. So I'll need to confirm if the signature survives that workflow, and if it produces unwanted noise or other effects on development mailing lists.
Are there any efforts in writing a minimal version of it with a modern and flexible UI?
[1]: http://www.openbsd.org/papers/bsdcan-signify.html
[2]: https://ed25519.cr.yp.to
I imagine alternate pinentry implementations exist for other OSes as well.
Honestly the agent is better than it was (not that that's saying much). Other than that, GPG relies on one part-time developer - I'm sure contributions would be very welcome.
I have a key fob that performs cryptographic operations. Rather than use existing standards, GnuPG demands full control of the fob, making it impossible to use the same device for client certs on browsers, or for the VPN, etc. There are some barely maintained shims that get around some of these design flaws, but it's an extremely hassle to find the shims and to get them working.
GnuPG's agent also makes it quite difficult to use git remotely. Most of the code I write is on remote servers, setting up an agent to allow forwarded operations.
I think that it's time to move on from GPG, or fork it, or something. There's not much in GPG's implementation of PGP that I like.
Unfortunately after reading the source code and then reading the OpenPGP spec, I am convinced that most of the problem is actually OpenPGP. GPG is a bit of a hairball of a program, but it is faithfully doing what it is supposed to be doing.
Here is how I would describe the basics. Hopefully it will help you wrap your head around it. The bad part is that OpenPGP does not actually work this way. Consider this as "this is a way to view how it would work if OpenPGP wasn't completely insane":
- A key is composed of a private and public part. These are often referred to as "public key" and "private key"
- A key that one signs should actually be thought of as a certificate
- A certificate is just a bundle that includes a public key part, an "identity" (which is usually just a string, but can also include a picture), and a bunch of signatures. The signatures indicate that somebody believes that the identity is bound to the public key part (i.e. the string identifies the person who holds the private part of the public key).
- When you "sign" something, your signature is related to a piece of data (usually text). If someone has your public key part, they can verify only someone with the private part could have produced the signature. It is important to realise that you must sign something.
- When you "sign a key", what you are really doing is creating a signature for the identity string on a certificate and adding your signature to it.
- There are "master keys" and "sub keys". A "master key" should really be thought of as a certificate along with the private key part. A "sub key" is a public-private key pair with a particular ability (sign, certify, encrypt, or authenticate).
- You can create a certificate for your subkey that contains the public part of the subkey and is "certified" (basically signed) by the master key private part. This allows people to tell that your "sub key" certificate is associated with your "master key" certificate.
- Your sub key certificate has no identity information and is not signed by anyone other than the owner. To find out the identity of the person who owns the sub key, you have to have the master key in your possession and check the signature on the sub key.
- GPG makes a kind of "container" where it stores the master key certificate (which includes the public key part, the identity string (and possibly picture), and signatures of the identity by other people) along with the sub key certificates (which contains the public key part and a signature from they master key). In another place, GPG stores the private key parts that you may have for any master or sub keys.
Now go back to the GPG documentation and read it. That is how OpenPGP specifies that you must actually implement it. It would be nice to write an implementation that was simpler (possibly as I describe above), but it will always be a slightly leaky abstraction. And even my (much, much less confusing IMHO) description above is still ridiculously complicated.
Anyway, I hope you found it interesting.
I can't understand what people find to be so bad in it. It took half an hour to learn the basic usage and the commands aren't hard to remember at all.
Can you please elaborate?
You want this as a library that's impossible to misuse and a nice CLI on top.
The fact that it took you half an hour to understand the "basic usage" is ridiculous. The GPG developers have failed in the worst possible way when it comes to the design of their software. It's so bad I find it incomprehensible how that could have happened on accident.
If they would be working on something non-cryptographic, that would be one thing but for a cryptographic tool that's unacceptable. The design and ease of use is just as important as the cryptographic algorithms themselves for such a tool because any friction causes people to avoid cryptography.
This same attitude may also explain the tendency to reinvent things like rsync and other tools that have accumulated a large set of options over the years.
gpg --export-options export-minimal -a --export $KEY
I guess github wants to associate particular accounts with keys, but it seems they could save a lot of cut and paste bother if they supported importing keys from the keyservers.
Was thinking exactly the same thing wrt keyservers.
(I'm not a security person)
Read svckr's comment below and link #1 - what I was saying here before my edit was wrong. :D
1: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t... (2nd post)
When you use Git to sign a commit or a tag, you vouch for the SHA of that commit or tag; i.e. the whole history of that branch up to that point, including author names and email addresses.
The point Linus is making is not exactly one of security. The problem you get when signing commits instead of tags is that the signatures become part of the branch's history and both (signature and history) become inseparable. You can't re-sign a commit without re-writing all the commits that follow. If for example your keys were compromised, you invalidated them, and want to re-sign your repo with your new keys, you'll have to change each and every commit. With a tag, you'll just update the tags and the rest of the branch remains unchanged.
I hope, together with the thread you posted, this at least makes some sense.
Back to GitHub: I think this is a nice UI for displaying signatures in the history view. Assuming you can trust GitHub to really use your public key for validating (hat tip to fabulist) I don't see an issue with making that information accessible via the web. More importantly, they also display the "verified" badge on the "Releases" page where your tags appear.
(thank you, kind expert)
I was thinking it'd be nice if you could set a signing policy on GitHub - either all commits are signed or none are. A mixed situation just leads to harmful confusion. You would still need to verify sigs yourself, but if they're available for every commit this does still save you time before creating the signed tag.
https://mikegerwitz.com/papers/git-horror-story
So I would love tarballs and other things signed, and I do not want to be one of those whiny moochers, but imagine the backlash you get as thankless free software developer when you bork your tag sign or mess up one commit and people through you under the bus, because you cryptographically agreed to it? Haha.
By the way, I am increasingly interested in trying to wrestle my VMs and various boxes into order. I am tired of failing to learn different DSLs for automation and love the pure Haskell of propellor, which is your tool for managing Debian boxes.
http://git.joeyh.name/propellor.git
Part of its cleanliness a la Haskell (which I doubt I can ever learn, but applying it to a task like this makes it seem tangible), is you have signed configs and you encrypt your own config into the repo (with cute patches removing this folder will get my ire comments in the docs).
It is very refreshing and honest, like your other software. Hats off to you, sir.
For folks who haven't seen the Torvalds "graffiti" on github, it's critical to distinguish here: "anybody can push a commit to /their/ git repo".
They do verify it against the email address on the key, so anyone who made it show up as verified had access to your github password and was able to read an email sent to you. But also, if you don't trust github, you have the option of checking the signature directly and verifying the key thorough any of the other OpenPGP mechanisms.
Deleted Comment
I might be wrong, but it sounds like an incredible coincidence that two companies that haven't really made any noteworthy features on their platforms in a long time are starting to release noteworthy features on an almost weekly basis.
I'd argue GitLab had a late start and has been making significant progress since it started, and based on their Changelog they've been developing a lot of new features for the last year and a half at least (every .x update is released monthly on the 22nd): https://gitlab.com/gitlab-org/gitlab-ce/raw/master/CHANGELOG
Personally, I definitely have a fairly competitive attitude towards GitHub, and I'm motivated to push faster whenever they release a new feature :)
So yeah, competition is awesome :D