15 ms·

GPG signature verification

• mavam 11y ago
  It's great to see efforts towards integration of strong cryptographic verifications. But what I currently miss is something much simpler: SHA digests for release tarballs. I've already contacted github support, but apparently this concern never made it high up enough in their priority list.
  • zokier 11y ago
    If you are downloading the releases over HTTPS then do digests really add any value at all?
    • cuckcuckspruce 11y ago
      Yes, because they allow you to have mirror sites. Serve the digest from the main machine over HTTPS and distribute the tarballs from a CDN or mirror network.
    • deleted 11y ago
      [deleted]
  • lolidaisuki 11y ago
    What good is an SHA without a signature? Maybe you could just include the sums in your README or something.
• codemac 11y ago
  Anyone successfully get a workplace to have signed commits? I've struggled to describe the wins. The risks are risks a lot of companies have to take on anyways due to other parts of their infrastructure, and generally end up ameliorating with signed blobs/releases.
  • hackcasual 11y ago
    This probably isn't worth managing the PKI for a workplace, but this should be good for open source contributions
  • michaelt 11y ago
    At my workplace we tried signed hg commits for a little over a year. Perhaps it was the relative inexperience of our team, coming from our subversion background, or it might be that we didn't adopt the best tools out there, but it was a lot of work for largely hypothetical benefits. We had a system involving a third-party extension to hg, and an agent that was supposed to work on Windows, Mac and OS X - but it never seemed 100% reliable on any of those platforms. We were also inexperienced enough that if, say, someone committed something while their signing was set up wrong we weren't able to figure out how to retroactively sign the commits. We also used x509 certificates issued by a central corporate IT team that issued them manually, and expired the certificates annually without automatically issuing replacements. I'm sure some of these issues were with our team/organisation rather than the tools themselves, but when the opportunity arose to switch to gitlab with no commit signing required whatsoever, we switched immediately.
• cgtyoder 11y ago
  OR, you could use already well-established key servers, e.g. pgp.mit.edu. Why reinvent the wheel?
  • finnn 11y ago
    This is providing that information in the GitHub web UI, which previously did not mention that if particular commit was signed. It has always been available via well-established key servers using the git/gpg command line tools.
  • eggman 11y ago
    I would love this to become a list of the benefits of adopting a 'reinvent the wheel' approach to building things.
  • jlgaddis 11y ago
    I recall a discussion a while ago (on the cryptography list, I believe) where it was mentioned that pgp.mit.edu is often out-of-date, stops syncing, or is otherwise broken. The SKS keyserver pool was recommended instead.
  • AdmiralAsshat 11y ago
    https://pgp.mit.edu/faq.html https://pgp.mit.edu/faq.html >Can you delete my key from the key server? >No, we cannot remove your key from the key server. When you submit a key to our key server the key is also forwarded to other key servers around the world, and they in turn forward the key to still other servers. Deleting the key from our server would not cause it to be deleted from any of the other servers in the world and so this is not an effective way to ensure the discontinued use of your key. I discovered the above the hard way when I was testing an Android app called OpenKeyChain, which creates your PGP key and, without telling you, uploads it to several keyservers for "convenience". Since I was testing the thing, I used a private e-mail and my name. As a result, real name is now inextricably tied to that e-mail address through a keyserver that was ostensibly supposed to provide privacy... Neither here nor there, but I mention it because the experience somewhat soured me on the idea of non-deletable keys.
• 616c 11y ago
  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. https://mikegerwitz.com/papers/git-horror-story 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.
  • ikeboy 11y ago
    Ironically, that gives a "untrusted certificate" error on my phone.
    • ryan-c 11y ago
      The cert is valid, but the server is misconfigured (not sending the cert chain).
  • joeyh 11y ago
    If you're reading that as an argument against signing git commits, I suggest you re-read it.
    • 616c 11y ago
      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. http://git.joeyh.name/propellor.git 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.
• the_mitsuhiko 11y ago
  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?
  • lolidaisuki 11y ago
    > but unfortunately gpg is such a terrible program 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?
    • ryan-c 11y ago
      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.
      • leshow 11y ago
        we're talking about developers signing commits here, not sending emails to your grandma gpg encrypted
    • DasIch 11y ago
      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.
• joepie91_ 11y ago
  I'm quite unhappy about this change, as it misrepresents how GPG is supposed to work. The whole point of using signed commits/tags is to not have to trust the Git server... yet by relying on GitHub's "verified" badge, that's precisely what you're doing. This is security theater, and it's going to mislead a ton of people into thinking something has been verified more than it could possibly have been. Signature verification is necessarily something that the client must do, not the server. EDIT: Would the downvoters care to comment?
  • Kerrick 11y ago
    These days the GitHub.com UI is developing into a full-fledged git client. You can branch, commit, merge, move and add files, and more. I see this as another evolution towards GitHub.com as a git client.
    • lmm 11y ago
      A git client that's running on hardware you don't control though. One of the golden rules of using GPG is to never run it on any machine except your own.
    • joepie91_ 11y ago
      That really doesn't matter. It doesn't run on your own system under your own control, and thus, for security purposes, it can't be considered a client. EDIT: In this case, the 'client' would be your browser.
  • detaro 11y ago
    (I didn't downvote you, but) Just because it doesn't protect against one class of attacks you have decided to be care about it isn't "security theater" if it helps against others. If your threat model includes "I don't trust GitHub/their servers", then yes, you obviously have to verify offline. > it's going to mislead a ton of people into thinking something has been verified more than it could possibly have been What specifically do you think people are going to think has been verified?
    • 11y ago
• kmfrk 11y ago
  I guess keybase.io wouldn't work with this, since you need the e-mail address to resolve for verification?
  • Oompa 11y ago
    You can add emails to your GPG key. I added my normal committer email to my keybase key and added the key to GitHub as well and all is working well!
    • tylersmith 11y ago
      Weird. I have my primary GH email address on my key but still says it's unverified.
      • Oompa 11y ago
        Be sure the email you commit with is also on your key. May not be your primary GH email address.
        • tylersmith 11y ago
          Seems to have just taken awhile for GH to show it as verified. Working now!
    • cjbprime 11y ago
      Yep, works great. `gpg --edit-key` and "add a new uid", then reupload the key to Keybase.
    • kmfrk 11y ago
      Awesome. Does it need to be the primary e-mail address/UID? I take it that's required for GitHub to send a verification e-mail.
• 0X1A 11y ago
  Got an error: "There was an error parsing that key. Check that the key is valid and try again." Cool. Edit: It seems to like my key now...? I've been signing my commits for at least a year now so it's nice that they added this. I think it adds another layer of author verification other than maybe SoB.
• r3bl 11y ago
  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.
  • peterhadlaw 11y ago
    Welcome to competition! What would you like next? <3
  • unfunco 11y ago
    Dear GitHub...
  • connorshea 11y ago
    Disclosure: soon-to-be team member at GitLab 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 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
• JoshTriplett 11y ago
  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.
  • joeyh 11y ago
    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.
    • ryan-c 11y ago
      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.
      • joeyh 11y ago
        The existence of things that claim to have been committed as me, with no proof and not in the history of my master branch or a released tag, is irrelevant. My users use my release tags, and my master branch, they don't use random commits you make "as me" elsewhere. Before SHA1 is broken, you can't change things that I have committed, unless you have access to my account. If a SHA1 preimage attack becomes available, you can. If a SHA1 bithday attack becomes available (for the low low price of $75k, croudfund one today!), you can, by sending me some particularly evil forms of merge requests.
• robin__ 11y ago
  I'd rather see this integrated with some simple signing tool like openbsds signify.
• dorfsmay 11y ago
  This is huge! Not so much because of signing software, but because fairly soon most devs will have setup gpg and you'll be able to easily find their pub key and trust it!
  • nickik 11y ago
    Hopefully they will all start to use Keybase. Prove that their github key is the same as the one used on twitter and the same that signed their binary.
• emilecantin 11y ago
  Just tried this, and apparently Github doesn't recognize my key... I have a master key, and three subkeys (encryption, signing and authentication).
  • pietroalbini 11y ago
    If your commits aren't marked as verified in the repository, push a new signed commit to that repo. Then GitHub should start marking your commits (even the old ones) are verified. Apparently this needs to be done per-repo, it's not global to your account. I guess that's the way they check if you are the owner of that key. Edit: clarified
    • emilecantin 11y ago
      I mean I get an error message when adding my key on Github: > There was an error parsing that key. Check that the key is valid and try again.
      • pietroalbini 11y ago
        It accepted an ascii-armored export of my key (gpg --armor --export $GPGKEY), have you tried to add that?
        • bruth 11y ago
          I did and it failed to parse.
          • berdario 11y ago
            same here, I tried with both gpg2 and gpg PS: the problem was that I had multiple keys locally... but weirdly, now that I managed to upload my correct one, my commits are still seen as unsigned
            • emilecantin 11y ago
• jasonjei 11y ago
  It seems like it addresses Linus's complaint about author verification, especially needed with a mission-critical project like the Linux kernel. I wonder if GitHub will have out-of-the-box support for pull requests by email. That would be wonderful.
• mataug 11y ago
  Well finally ! I've been lamenting about signed commits for a while.
• joeyh 11y ago
  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.
  • dochtman 11y ago
    I actually tried to upload my 1800 lines out of output, and GitHub fails to parse it. Was thinking exactly the same thing wrt keyservers.
• sarnowski 11y ago
  That is great news! I hope they will also go the next tiny steps soon: 1) as another commenter already pointed out, I would really like to see an "unverified" badge instead of the "verified" to make GPG signing the default; everyone should really be aware that all commit metadata like author and committer are completely voluntary and you can lie as you want. 2) Please, add another merge restriction that only allows commit pushes/merges-to-master with GPG signatures. This allows me to fully verify future git repositories.
  • matt_wulfeck 11y ago
    That would require the --sign flag with every commit would it not? That sounds like a pain. I would like git to automatically sign my commits if that were the case.
    • sarnowski 11y ago
      You can set up the --sign flag in your local gitconfig. git config --global user.signingkey $GPGKEY git config --global commit.gpgsign true In general, since you definitely do not want to upload your key material to GitHub, you won't be able to use the pull request merge button and the new squash button. This means, your pull requests need to be fast-forwardable, else you cannot merge (as this merge would be unsigned). Also, instead of using the squash button, you would need to squash the commits on your local machine and push the newly signed squashed commit again. It comes as a cost but it also leverages the decentralized nature of git: you can do everything locally and sign locally so you do not need to trust someone else.
      • joeyh 11y ago
        git can sign merges.
        • sgarman 11y ago
          Right, but GitHub can't unless it has your private key which it probably should't(if it's password protected) but that's a discussion for another time. Many people use the feature on GitHub to manage their projects like the merge button.
• xgbi 11y ago
  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!
  • daheza 11y ago
    I sometimes wish my company had more competition so that we could improve the product.
    • WillAbides 11y ago
      What's your company? I'll see what I can do for you.
    • jjawssd 11y ago
      Pls respond
  • connorshea 11y ago
    <3 as a soon-to-be GitLab team member, glad to hear we're helping speed them up :)
  • sytse 11y ago
    For sure the competition is making us both better. Coincidentally we're working on the same feature in https://gitlab.com/gitlab-org/gitlab-ce/issues/4232 https://gitlab.com/gitlab-org/gitlab-ce/issues/4232 but congrats to GitHub for shipping it sooner.
    • ChristianBundy 11y ago
      Looks this this is Gitlab EE only though, is that right?
      • gpm 11y ago
        (I only know what I read on the issue tracker) The part that GitHub implemented (uploading keys to the site, displaying verified signed commits in the UI) looks like it is both. Configuring a project to only accept signed commits in various ways looks to be EE only.
• leshow 11y ago
  im getting an error adding the key, and it appears others in this thread are also. 'error parsing key'
• wilg 11y ago
  Looks like I have to do something special to get this working with GitHub Desktop (for Mac). Seems that gpg installed through brew isn't recognized by that client. Is it possible to use both?
  • mastahyeti 11y ago
    GitHub Desktop doesn't support commit/tag signing at this point. Sorry.
    • wilg 11y ago
      Drat!
    • mrsteveman1 11y ago
      Hopefully will at some point, it's one of the few reasons I use SourceTree at the moment. GPG in Github Desktop would be a fantastic addition :)
      • alain_gilbert 11y ago
        Do you use the "git flow" feature of SourceTree ? I have a hard time trying to sign my merge commit. (after a new release for example) I wonder if you were able to do it ?
        • mrsteveman1 11y ago
          Nope no git flow here sorry :) Is it failing to give you the option to sign (UI bug)?
          • alain_gilbert 11y ago
            There is no UI that allows you to specify that you want the merge commit to be signed. And if you configure git to sign all commits, you get this error: https://confluence.atlassian.com/sourcetreekb/sourcetree-commits-fail-when-using-git-signed-commits-794199810.html https://confluence.atlassian.com/sourcetreekb/sourcetree-com...
• wclax04 11y ago
  Did this release cause the current outage?
• mfincham 11y ago
  Here's a signed commit I pushed in January to see if they'd recognise it: https://github.com/fincham/test-signed-repo/commit/9d6e807d9e34c60e79659433280a8b25b144007a https://github.com/fincham/test-signed-repo/commit/9d6e807d9... Now shows a little "Verified" badge. Very nice!
• tombert 11y ago
  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?
  • MBlume 11y ago
    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.
    • wyldfire 11y ago
      > Anybody can push a commit to a git repo 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".
    • cyphar 11y ago
      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.
      • MBlume 11y ago
        Without this feature, I can push commits up to my repo and claim they were written by you; with this feature, people can tell whether you signed off on those commits.
        • cyphar 11y ago
          So what? That implies that someone should believe someone when they say "look, the email address on this commit says this person's name -- it must be that person!". This all comes down to repo ownership. In your fork of a repo, you have the ability to fake any history you want. Why should that bother me? GitHub should stop auto-associating emails to usernames -- that's the actual problem here.
• qwyxzy 11y ago
  When pushing signed commits, the GitHub web interface doesn't reliably update with the new commits. Anyone else experiencing this? Edit: Actually, it may just be commits in general. Usually the interface receives updates fairly quickly.
  • pietroalbini 11y ago
    https://twitter.com/githubstatus/status/717464295454470145 https://twitter.com/githubstatus/status/717464295454470145
    • qwyxzy 11y ago
      Thanks.
• jasonmp85 11y ago
  This would be even cooler if you could add signature files for release tarballs in GitHub Releases.
• jxy 11y ago
  Considering a long term project, signing using a private GPG key does not seem to be practical. What happens if the key expires? What happens if the key gets revoked? Or stolen? Are you going to sign every commit again?
  • minitech 11y ago
    Just sign new commits with the new key. Signing a commit also signs its history.
• coroutines 11y ago
  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 1: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t... (2nd post)
  • fabulist 11y ago
    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.
    • coroutines 11y ago
      I completely agree. 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.
  • svckr 11y ago
    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.
• seadog007 11y ago
  That's cool
• Perceptes 11y ago
  It's a nice feature to add signature verification to the UI, but it does leave out the trust aspect of PGP. Showing a green "verified" badge may be misinterpreted by users who are less familiar with PGP because they may think of it as meaning "you can trust the authenticity of this commit," which is not what it actually means. GitHub can verify that the signature matches the public key that the author uploaded to their account, but that's not actually useful unless the person viewing the commit trusts that public key. It would be great if it had three different badges to distinguish between different things: perhaps a red "unsigned" for commits with no signature at all and "invalid" for commits with a bad signature, a yellow "verified" for commits with signatures that match the author's uploaded public key, and a green "trusted" if the person viewing the commit has marked the author's public key as trusted.
• Gedrovits 11y ago
  It's all cool, but for example their own GitHub Desktop don't support this yet. RubyMine (don't start the holy war please) don't support this. So now it's not quite easy to sign the commits without using the console...