14 ms·

Linus Torvalds did not commit this

• seba_dos1 11y ago
  Kinda hard to not come up with it when setting up your credentials is the first thing git wants you to do before you can commit anything. BTW. You can also overwrite them by command line switches per commit instead of setting environment variables. I guess it's worth noting here that you can sign your commits with GPG: https://git-scm.com/book/tr/v2/Git-Tools-Signing-Your-Work https://git-scm.com/book/tr/v2/Git-Tools-Signing-Your-Work
  • nailer 11y ago
    I guess the real uptake is that commits should really be signed by default (eg, by encouraging signing in the tools & ecosystem).
    • ultramancool 11y ago
      Really, this only becomes a problem when services like GitHub link the name up, making it look more legitimate than it is. If they enforced authentication as that user before providing the linking it would be better (perhaps allowing approval of the linking if posted by a different user). Currently it's trivial to make it look like any GitHub user is an actual committer to some sort of egregious or controversial project and users unaware of how GitHub maps this may easily be confused. EDIT: This gets even more disturbing when you realize that GitHub is a site many people list on their resumes and if this association applies from their user page too this could get very bad.
      • icebraining 11y ago
        It doesn't seem to link in reverse to the user page; at least, I can't find anything on Linus' page related to this repo.
        • _delirium 11y ago
          There's a Github help page explaining when commits show up in your profile (though worded as an answer for people wondering why one didn't): https://help.github.com/articles/why-are-my-contributions-not-showing-up-on-my-profile/ https://help.github.com/articles/why-are-my-contributions-no... The criteria not fulfilled for this one are that you have to have interacted with the repository on Github in some way. Any one of these criteria would suffice: you're a "collaborator" on the repository, you're a "member" of the organization the owns the repository, you have forked or starred the repository, you have opened a pull request or issue in the repository.
      • Maken 11y ago
        Apparently Github doesn't list those faked commits in your profile. Which is anyway a problem because you could be "committing" to who knows what project project without being notified.
      • uxcn 11y ago
        The simple solution seems to be github just distinguishing between signed and non-signed commits.
      • rakoo 11y ago
        I disagree, the real problem here is people thinking that somehow any github repository can be a trusted source. If you work on Linux, you know that the one and only source of truth is the repo that comes from Linus himself, not anything coming from github.
        • icebraining 11y ago
          Linus doesn't distribute anything himself; you can either have the copy hosted by Github, or the one hosted by a Californian nonprofit called the Linux Kernel Organization, Inc.
  • SilasX 11y ago
    Similarly, nothing stops you altering the time claimed in the commit. Or -- for that matter -- from taking someone's diff and claiming credit for it. For that reason, I jokingly created `git-upstage`, which streamlines the process of abusing commit edits and plagiarizing code! It squashes a branch, backdates it 5 minutes, and claims you wrote it. https://github.com/SilasX/git-upstage https://github.com/SilasX/git-upstage Edit: Looks like my last commit left the important stuff commented out and can't fix it at the moment. Ah well, you're going to use the tool to rip it off anyway ;-)
    • uniformlyrandom 11y ago
      Oh, it appears that git 2.3.2 only allows to go back as far as Dec 2014. That is a pity. I have already prepared a README.md claiming that I have created the internet, but then I failed while trying to backdate it to 1969 (PDT). I was this close to becoming very rich and very evil. Oh well.
      • seba_dos1 11y ago
        Don't give up so easily - you have the source code! ;)
        • uniformlyrandom 11y ago
          I got to my linux workstation, cloned the git repo and dug into the code. Could not figure out how the limitation worked though. Turned out, it did not - the problem was specific to my mac's git. So yes, you can author files from 1970 - it is not a big deal. Thought it was kind of a weird limitation.
    • ultramancool 11y ago
      I love this. Had a project in college that was supposed to be time limited... based on repository times. Oops. Big mistake prof. We rolled back the times on our repo and laughed maniacally about our free 6 hour extension.
      • 11y ago
  • micampe 11y ago
    Signing my commits doesn’t prove that I didn’t do an unsigned one.
  • sytse 11y ago
    We would love support for signed commits in GitLab itself so you can check the signature from the web-interface http://feedback.gitlab.com/forums/176466-general/suggestions/4006354-check-pgp-signed-commits http://feedback.gitlab.com/forums/176466-general/suggestions...
• wcummings 11y ago
  I think this is pretty well known. You could always sign your commits if you're really worried about someone sticking your email address in their git config.
  • stephengillie 11y ago
    I feel as though a GIT demo somewhere has already shown me how to impersonate Linus or anyone else.
    • wcummings 11y ago
      Yeah, I've definitely seen something very similar, as well.
  • rabbyte 11y ago
    While it's probably well known from a command line perspective, I doubt it's well known from a web service (GitHub) perspective. I have a healthy distrust of git logs but trusting a photo and username on GitHub is a pattern reinforced by every other social app.
    • berdario 11y ago
      Not only it's not well known, but it breaks them: some years ago I reported this issue on gitorious, which yielded an HTTP500 when the repository contained a signed commit: https://issues.gitorious.org/issues/193 https://issues.gitorious.org/issues/193 (it's now down, but hopefully it'll reappear on archive.org) and it'll prevent Launchpad from automatically mirroring git repositories (which is paramount to be able to automatically update PPA with recipes) https://bugs.launchpad.net/bzr-git/+bug/1372149 https://bugs.launchpad.net/bzr-git/+bug/1372149
    • wcummings 11y ago
      I've seen this demonstrated on github before w/ defunkt's account/email
    • andrewstuart2 11y ago
• zeeshanm 11y ago
  So, this actually works: https://github.com/zixan/uberfareestimator/commit/b4c5a16408d906b06310c6b232bbd947aca1226f https://github.com/zixan/uberfareestimator/commit/b4c5a16408...
  • seba_dos1 11y ago
    Why wouldn't it? I'd say it's "supported by design".
    • zeeshanm 11y ago
      It was a test to test the design.
• mmcclure 11y ago
  TBH we "exploit" this when accepting PRs for an open source project I work on. It's not really feasible for us to expect / force each PR author to have a clean commit history, so we basically do some squashing, then commit the "single" change as the original author before merging.
  • johannes1234321 11y ago
    So, when submitting to your project it can happen that I'm afterwards blamed for things I didn't do? (Or praised)
    • mmcclure 11y ago
      I'm not sure I follow? All of your work is intact and committed as you, it's just done as a single (squashed) commit instead of N commits. The only difficulty that potentially arises (that we've encountered so far) is a lack of granularity for commit messages, which is why we try to keep PRs very small and focused.
      • jchung 11y ago
        I think what johannes1234321 is concerned about is that while you say the work is intact, he can't actually vouch for that because he didn't do it. You did. Which means that he could potentially be blamed (or praised) for something he didn't do in the event that you don't keep his work intact (intentionally or otherwise).
        • bluehawk 11y ago
          If someone is concerned about getting blamed or praised for his work, he can sign his commits.
          • deleted 11y ago
            [deleted]
        • mmcclure 11y ago
• ppierald 11y ago
  I can imagine a scenario where a malicious employee is intentionally injecting malicious code (backdoor, whatever) and wants that commit tied back to someone else (their enemy, boss).
  • ikeboy 11y ago
    If they have push access, would github log who actually pushed it (i.e. ssh key)?
    • rectang 11y ago
      Yes, Github's authenticated push logs will tell you that. However, Github won't make those public, because they consider user identification private info. (Or at least they won't provide those push logs to the Apache Software Foundation, which is how I know this.)
      • ikeboy 11y ago
        They won't even give it to the owner of the repo in question?
        • rectang 11y ago
          They will not. For instance, the ASF cannot get the push logs for all the repositories under <https://github.com/apache> https://github.com/apache>.
• _wmd 11y ago
  In other words, a lot of people haven't the slightest clue how Git works. Luckily Github record push history separately
  • icebraining 11y ago
    This is not just about Git, it's also that Github is implicitly trusting user data, by linking to the user profile. In Git, it's clear that there's no authentication, a user is just a tuple of strings, but on Github the same doesn't apply, a user is actually a well defined entity which is secured by one or even two factors of authentication, so the expectations are different.
• ppierald 11y ago
  Another good article on git-signing: http://mikegerwitz.com/papers/git-horror-story http://mikegerwitz.com/papers/git-horror-story
  • JoachimS 11y ago
    Yes one have to be careful when merging and signing. But otherwise it works really well.
• aikah 11y ago
  It's a github 'social' issue , not really a git issue. It might also be a legal issue (identity theft). And i'm a bit surprised github let people impersonate others through their 'social' features.
  • yxhuvud 11y ago
    It is really not possible for github to track the origin of commits. For example, consider a fork. If you pull some commits from the original and then push them to your fork then that would look just like this. The only thing I can think of is that it may be possible to track commits if everyone would sign them as they were created, but that would require all users to change, so I don't see how that can happen.
    • andrewstuart2 11y ago
      If a user could upload their public GPG key to their account (as they can their public SSH key), GitHub could easily verify signed commits, which git itself allows with `git commit --gpg-sign[=<keyid>] ...`. It would be trivial for them to shell out to `git verify-commit <commit>` in order to verify that the claimed originator has signed his commits with a key tracked by github (by email address, which can belong to only one github user).
    • jerf 11y ago
      A checkbox that requires push commits to be signed (you don't have to sign each one, but the top level of any push would have to be signed) would be nice. So would any indication that commits are signed in the GitHub UI. I've started signing my commits to GitHub, but verifying even that a signature is present (let alone correct) requires you to clone the repo and investigate it with commands you'd probably have to Google, as far as I know. No UI visibility whatsoever.
    • icebraining 11y ago
      An idea that doesn't require signing is tracking commits internally. If you push a commit made by you, Github can tag that as "trusted" (since you, the GH user, are vouching for your own commits). Then anyone who pulls them into their repo (even offline) and pushes it to their GH account would still have those commits tagged, since GH could match the hash with the ones it already knew about. For the most part, this would solve the problem, since people usually upload the commits to their own GH fork and then issue a PR.
• vruiz 11y ago
  Yeah this is known, and you can get yourself an awesome list of contributors if you want: https://github.com/zixan/uberfareestimator/graphs/contributors https://github.com/zixan/uberfareestimator/graphs/contributo... I think github should allow me as a user to confirm contributions made out of the system, at least the first time per repo.
  • smt88 11y ago
    That's a great solution. People should tweet it at Github and see if they implement it.
  • talles 11y ago
    I second that too.
• therealmarv 11y ago
  we even do not know if he REALLY did not commit this ;)
• andmarios 11y ago
  Also you may send email from any address you want if you put it in the “MAIL FROM” SMTP transaction. Thankfully the Linux kernel project accepts only signed commits.
  • teraflop 11y ago
    > Thankfully the Linux kernel project accepts only signed commits. This is false, FWIW.
    • jordigh 11y ago
      Well, the signoff line that Linux requires is a legal signature, not a cryptographic one. It is meaningless to us, but it's good enough for lawyers.
    • andmarios 11y ago
      Indeed. Thanks for the correction! It requires signed patches, alas not with a cryptographic signature.
• moron4hire 11y ago
  There is a huge UX problem with validating the legitimacy of anything online. I have to know that credentials are available, and I have to know that it's possible to validate them. How do I even know if a particular set of credentials are legit? I'd have to know where to find validation for them. That's a whole other ball of wax in itself. And we default to not requiring such authentication because the means we have are either completely useless (i.e. passwords) or so onerous (I always have to Google when I setup cryptographic credentials on anything, and we expect lay users to do this?) that they ruin adoption rates for software and services. State-of-the-art secure credentialing should be as easy as passwords. Easier, even. Yet they're currently as "easy" as configuring Apache.
  • XorNot 11y ago
    There's also the issue that securing these things is tricky. How do I secure and sync a gpg keg? Should I load a private meeting on my work PC? My phone?
  • cbd1984 11y ago
    Any information you can get online or over the phone can be forged. (Passwords can be discovered, as can private keys, fingerprints, and the results of genetic tests.) Certain kinds of physical evidence, such as dead skin cells with usable genetic material in them, are to my knowledge effectively impossible to forge, but they can be "accidentally" contaminated beyond usability. Doing things in-person face-to-face is only an improvement if you knew the person before anyone had any incentive to fool you on the person's identity, which is hard; even then, allegiances can be bought, sold, and changed for other reasons. My point is that fixing this issue is out-of-scope for a DVCS. It could, however, be improved a bit.
• thedoctor79 11y ago
  So it seems the author has identified a real issue here, but I will go meta on this and identify issues with his demonstration. In my organization this would count as a bug report, so I wondered why this issue was not communicated privately to the operators of Github so they can have a chance to fix it before some un-educated person does some damage. Then I realized this issue might affect other git content hosters, so going public might alert them as well as forcing Github to fix it. Regardless, would the best approach not be to communicate privately first and allow Github to fix it before going public? If this was raised privately and not acted upon, then why are Github's internal processes so slow? So many questions, so little time...
  • ultramancool 11y ago
    The problem is that "it's not a bug, it's a feature". Look at the Linux kernel mirror for example. All those commits come from different users around the internet, but when their emails show up, GitHub can link their usernames to their profiles. What to do about this though... that's a good question. Perhaps just not linking profiles when pushed in this way and/or labeling them "unverified" would be sufficient. GPG signing would be nice, but would likely annoy some users.
  • facetube 11y ago
    I reported this to Github privately about a year ago – specifically, I asked why there isn't some visual indication when Git's `user.email` fails to match any of the Github account's verified e-mail addresses. If you commit with a `user.email` that doesn't match _anyone_, you get a little question mark; it seemed like they could do a similar thing when you commit using a `user.email` that matches someone-who-isn't-you. Even just showing which Github user made the HTTP or SSH connection to push the changeset would be an improvement. The tech told me that the current behavior was by design, and then pretty much said I didn't know how git worked and didn't understand Github's team/sharing/trust philosophy. I was pretty disappointed by their response, all told.
• latortuga 11y ago
  One workaround would be to remove any public email address you commit under from your Github profile. Github uses these email addresses to tie back to your user profile so if you don't want commits pointing at your profile, don't tie email addresses to your profile. Perhaps some mechanism is called for here for approving tying back to your user on new repositories or making any repository not owned by you or your organizations require an explicit opt-in to tie back to your profile. Edit: This is kind of the equivalent of spoofing the From address in an email.
  • brianshaler 11y ago
    My github profile email is different from my git author email. The latter is even more accessible. Just run git-log on any repository an author has committed to.
    • latortuga 11y ago
      Yes but if you remove that git author email from your list of emails on Github, any commits done under that email will no longer link back to your profile.
• nathancahill 11y ago
  Interesting, there must be some level of validation because it does not show up in his public activity feed[0] [0] https://github.com/torvalds?tab=activity https://github.com/torvalds?tab=activity
  • kachnuv_ocasek 11y ago
    That's because there's a difference between a GitHub account (usually authenticated by a key) and a git commiter (only identified by the name and email). It would be pretty annoying if hundreds of commits popped up in his feed every time somebody forked Linux or git.
• brillenfux 11y ago
  Another example of why email addresses cannot serve as "identities" like so many people, somehow magically, assume. If you know it, everything about email and its protocols would make you assume the exact opposite. Now PGP signatures on the other hand … but hey, nobody wants those, right?! Far too complicated! /rant
  • nolok 11y ago
    This has nothing to do with emails serving as identities and everything to do with not believing user's input without verification. If github was linking to user's profile based on first/last name rather than email the issue would be the exact same.
• bnrubin 11y ago
  I found that github's automatic identity resolution is actually helpful in some cases. I migrated a bzr repo into github recently and was pleasantly surprised to see my contributors matched up to their github accounts. I understand that many people might not want this, but it is a feature that can be useful.
• sandGorgon 11y ago
  git should really make it possible to use openssh/openssl keys for signing - so that I have one key both to push to github and sign my commits. I know that they can be converted from one form to another ... but its really inconvenient, especially on Windows, etc. The GPG key is designed for a email based collaboration flow - that Linus uses. But most of us use Github or Bitbucket's UI to collaborate. Github/Bitbucket should use this key in their UI as well - to show verified users.
  • jleight 11y ago
    I bought a YubiKey[0] a while back and was able to get it to do exactly what you're talking about--even on Windows, which I use most often. It wasn't necessarily easy to set up, but it has been working pretty consistently. It would have probably been easier if I had known more than just the basics of GPG. I have since switched to using my YubiKey and GPG for SSH authentication on pretty much everything, as well as using it to sign my tags in my public git repositories. I don't think I would want to go back to moving keys between devices or setting up unique keys on each device now that I've got my YubiKey set up. Worth the investment, in my opinion. [0] https://www.yubico.com/products/yubikey-hardware/ https://www.yubico.com/products/yubikey-hardware/
• rectang 11y ago
  To guarantee the origin of the commits in a Git changeset, you need either PGP-signed commits or the authenticated push logs for a centralized server. http://www.sunstarsys.com/essays/git-and-non-repudiation http://www.sunstarsys.com/essays/git-and-non-repudiation
• vetrom 11y ago
  related: https://github.com/will https://github.com/will
  • mahouse 11y ago
    No, not related.
• arihant 11y ago
  So this is a Github feature, which might be useful in some cases, I get that. The good news here is that it only goes one level deep, i.e., it does not automagically show up on Linus' account in any way. This also has been an issue with Git for a long time. In any repository, you can see the email of the person who committed it, and it can be spoofed, because there are no checks. So while here we see it linked to Linus' account, the problem with plausible identity theft has always been a part of Git. There are ways to solve it. Git can just put "<unsigned>" next to non PGP commits. Github can also put "<unverified>" when commits are made outside of Github realm (not using their keys of https auth), or are unsigned. Just be careful while merging pull requests, which one has to anyway. And because one has to, these issues never seem to get a fix.
• JoachimS 11y ago
  We use signed commits in the Cryptech project and it works really nice. So much in fact that I now sign all commits for all git repos I work on. It would be nice if Github displayed the signature though.
• comrade1 11y ago
  This is more of a problem with GitHub than git. Remember, it's not that hard to host your own git repo. There's no need to use GitHub.
  • hk__2 11y ago
    This has nothing to do with GitHub. The commit author field in Git is like the “From” field of an email; you can put whatever you want in it.
    • andreasvc 11y ago
      I think it does. Github is an open system, whereas if you host your own Git server you can ensure that only trusted people have commit access to it.
    • simoncion 11y ago
      This has everything to do with GitHub. Git provides mechanisms to sign both commits and tags, and to verify those signatures. GitHub fails to make use of those mechanisms.
• Argorak 11y ago
  The issue at hand here is interesting: GIT _commit_ integrity is not guaranteed over all operations, even if you sign commits. The problem is that GIT often changes commit details. If you, for example, rebase or cherry-pick a commit, the identity changes - as the commit includes a reference to the parent commit(s). This means that once you do any of those (standard) operations, the signature becomes invalid. Signing only makes sense on a tag level or in repositories that keep all commits and never change them (e.g. by explicitly merging and adding merge commits). There are systems that preserve commit integrity during all of those operations, e.g. DARCS.
  • pornel 11y ago
    IMHO git does it right. If signature was only at the commit level you could do a variant of replay attack. For example you could cherry-pick all commits except security fixes and create a malicious version of the software that has all commits still signed by the original author.
    • Argorak 11y ago
      I was not saying that the signature is _just_ at a commit level ("patches" being the DARCS lingo). DARCS, just as git, has tags for that. A tag depends on all previous patches, so a signed tag guarantees just the same as a signed git tag does. In that regard, git is strictly less powerful.
• logicallee 11y ago
  I don't get it, I never really looked at github comments before. Why are these comments so low-quality? Aren't developers who commit to github the only readership?
  • wyldfire 11y ago
    I had a relatively sane comment (IMO) about whether github should instead consider allowing users to opt-in to "show unsigned commits which claim to be from this address as unknown." Oddly enough my comment itself was altered to be a mindless obnoxious comment! (does github use git commits to track the comments themselves?)
    • hk__2 11y ago
      Repository authors can edit anyone’s comment.
• jotux 11y ago
  You can just use this and not have to overwrite your name/email: git commit -m "message" --author=<author> You can even pass a different commit date with --date=<date>. It's actually a really useful feature when you're migrating a project from a different SCM system to git.
• techpeace 11y ago
  Yeah, this is one of those "feature not a bug" things that's been known for some time. As others have pointed out, sign your commits if this bothers you. It's even possible to get your fellow open source contributors to sign commits to your project, as we do with the Metasploit Framework: https://github.com/rapid7/metasploit-framework/wiki/Landing-Pull-Requests https://github.com/rapid7/metasploit-framework/wiki/Landing-...
• castratikron 11y ago
  Isn't github just a mirror? I doubt serious kernel development happens there. tl;dr who cares?
  • darkstar999 11y ago
    It isn't just about Linux. You can masquerade as anyone on any public project and cause confusion.
• 2bluesc 11y ago
  It's pretty much the same as forging email. Most won't notice. Both can be signed with pgp, but few check and it's clumsy for the mainstream.
• jrv 11y ago
  Linus actually commented on this lack of identity handling in 2012 in his famous explanation of why he doesn't use GitHub: https://github.com/torvalds/linux/pull/17 https://github.com/torvalds/linux/pull/17 "since github identities are random, I expect the pull request to be a signed tag, so that I can verify the identity of the person in question." And: "github throws away all the relevant information, like having even a valid email address for the person asking me to pull."
  • ultramancool 11y ago
    Yeah, the GPG signing support in Git would be the best solution to this, unfortunately GitHub doesn't offer integration for that.
    • deleted 11y ago
      [deleted]
    • akshatpradhan 11y ago
      Maybe this is where Keybase.io could come in?
  • undrcvr-lagggal 11y ago
    He called github "braindamaged". Isn't that against the CoC?
    • dragonwriter 11y ago
      > He called github "braindamaged". Isn't that against the CoC? So, you think he violated a Code of Conduct that did not exist at the time, in the course of explaining why he was not a user of the service (so that any Code of Conduct for that service would not apply to him even if it existed.)
      • undrcvr-lagggal 11y ago
        Making the violation before it's formalized does not necessarily excuse it. Perhaps proper action is to remove the full post or specific parts.
• darkstar999 11y ago
  Wow the comments there are on par with 4chan.
• Aardwolf 11y ago
  I don't like github's dependency on some git EMAIL variables and stuff. First of all already of course there is the problem that putting your email on the internet is asking for spam. But a bigger problem is, if I'm on a machine that doesn't happen to have those variables configered, and I push something to github, even if I use my github username and password then, it does not show me as author. Very annoying. EDIT: I don't like git itself's email dependency either. But at least github could have done something with the fact that you login with a username... :)
  • hk__2 11y ago
    That’s because GitHub is just some nice sugar on top of Git. Git needs your email, so does GitHub.
  • to3m 11y ago
    You can put anything you like in the email field. I use fake addresses such as tom@tmbp (me on my laptop), tom@tw7 (me on my Windows 7 PC), and so on. Add these addresses to your email addresses list on the settings page of your github account if you want your github avatar, etc., to be shown against commits using these addresses.
• hk__2 11y ago
  Related: http://mikegerwitz.com/papers/git-horror-story http://mikegerwitz.com/papers/git-horror-story
• jayhuang 11y ago
  This has been around for quite a while now; I made a post on my blog about it back in 2013: http://www.jayhuang.org/blog/pushing-code-to-github-as-linus-torvalds/ http://www.jayhuang.org/blog/pushing-code-to-github-as-linus... Of course this doesn't actually give you access to the person's account, but UX wise, it's incredibly misleading for someone to click a commit in my repository by "torvalds" and have it actually go to his profile. My issue is very much with the social implications of this as opposed to it being an actual security issue (see: signed commits). There should be some indication at the very least that a commit is not signed.
• haddr 11y ago
  Unfortunately so far the same is possible for gitlab too. Isn't it the general problem that each user is authenticated as the "git" user and the rest (all the git commands) is just "user.name" and "user.email" fields in prefs?
  • mordocai 11y ago
    They could identify users by their auth and store that data with the commits instead of relying on the user email. You either have to provide username/password, API token, or ssh key to push to a github repo. All of these identify you as you. Edit: It is important to note that this would not replace git authorship info as it is very possible that you pushed something that someone else committed. It would allow you to have a UI trail to who pushed it which could help if you theorize that someone is impersonating someone else.
• davorak 11y ago
  You can use github's api to identify out who pushed a commit: Currently the event in question is on page 3 so you can use: https://api.github.com/repos/amoffat/masquerade/events?page=3 https://api.github.com/repos/amoffat/masquerade/events?page=... It i will roll to further pages as new events come in. Github comment with formatted json event output: https://github.com/amoffat/masquerade/commit/9b0562595cc479ac8696110cb0a2d33f8f2b7d29#commitcomment-12528903 https://github.com/amoffat/masquerade/commit/9b0562595cc479a... The login of the push is identified of course as the owner of the repo 'amoffat'
• Karunamon 11y ago
  If i recall right, it's abuse of this that got the farcical/satirical "c plus equality" project drummed out of nearly every code hosting site. The name and email pulls in a Gravatar, the same one probably used on many other sites, with the result that it amounts to a really convincing forgery.
• zooko3 11y ago
  https://github.com/warner/git-lockup https://github.com/warner/git-lockup Makes it so that when you "git pull" it automatically checks a digital with a certain public key and refuses to apply the patch unless it has a valid signature.
• zooko3 11y ago
  https://github.com/warner/git-lockup https://github.com/warner/git-lockup Makes it so that when you "git pull" it automatically checks a digital with a certain public key and refuses to apply the patch unless it has a valid signature.
• beefsack 11y ago
  GitHub issues become ridiculous places full of mindless stupidity whenever an issue breeches a certain level of popularity. I'd love to see a mechanism to improve signal to noise ratios, it's not a place for Redditisms.