Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming Security Communications Data Storage Privacy The Internet

Should GitHub Allow Username Reuse? (donatstudios.com) 84

Posted by BeauHD from the fundamentally-flawed dept.
Jesse Donat argues via Donut Studios why GitHub should never allow usernames to be valid again once they are deleted. He provides an example of a user who deleted his GitHub account and personal domain with a popular tool used for embedding data files into Go binaries. "While this is within his rights to do, this broke a dependency many people had within their projects," Donat writes. "To fix this, some users of the project recreated the account and the repository based on a fork of the project." Donat goes on to write: Allowing username reuse completely breaks any trust that what I pull is what it claims to be. What if this user had been malicious? It may have taken a while before someone actually noticed this wasn't the original user and the code was doing something more than it claimed to.

While Go's "go get" functionality is no doubt naive and just pulls the head of a repository, this is not exclusively Go's problem as this affects any package manager that runs on tags. Simply tag malicious changes beyond the current release and it would be deployed to many users likely with little actual review.
This discussion has been archived. No new comments can be posted.

Should GitHub Allow Username Reuse? More

Should GitHub Allow Username Reuse?

Comments Filter:
  • because it's not a problem with github; it's a problem with morons misusing github.

    • because it's not a problem with github; it's a problem with morons misusing github.

      Shrugging off a probblem and saying "Its misuse, its not us" was exactly the attitude microsoft took to security in the mid ninteys that gave windows the attrocious reputation for security it has.

      Username re-use is a LONG established security fail, especially in conjunction with githubs provision of security crtitical REST endpoints. Sure it requires a malicious human to exploit the vunerability, but thats true of all securit

  • No. No. No.

  • Irrelevant (Score:5, Insightful)

    by chrysalis ( 50680 ) on Friday February 09, 2018 @08:53PM (#56098337) Homepage

    A URL is not tied to an identity. The only way to verify who wrote the code is to use digital signatures.

    • Re: (Score:2)

      by tepples ( 727027 )

      How would the public key for each author be verified? TOFU? International travel to code signing parties?

      • You don't need it to be verified, you need it to be consistent. You are not verifying that the author of X is a specific individual, you are verifying that the author of X version 1.1 is the same as the author of X version 1.0. If both are signed with the same key, then you can be fairly confident of this (not completely, because the key may still have been compromised, but a lot more so than with two unsigned binaries).

        • Re: (Score:2)

          by tepples ( 727027 )

          How would the public key for each author be verified? TOFU?

          you are verifying that the author of X version 1.1 is the same as the author of X version 1.0.

          So TOFU (trust on first use), as I suspected. Use of TOFU raises two follow-up questions:

          1. If setting up a new machine, how would you already have the public key for the author of X version 1.0?
          2. For a brand-new project, how would the author of X version 1.0 gain reputation for the project's public key?

          • Re: (Score:1)

            by Gr8Apes ( 679165 )

            So TOFU (trust on first use), as I suspected. Use of TOFU raises two follow-up questions:

            I would hope you'd verify the codebase on first use. If not... well, there's some other word for what you are...

            • Re: (Score:2)

              by tepples ( 727027 )

              I would hope you'd verify the codebase on first use.

              How is that done on a new machine?

              • Re: (Score:1)

                by Gr8Apes ( 679165 )

                For the very very first initial verification, you use your buildable system and verify the codebase and build it. Compare to what you installed. Now reinstall with an alternate system from a different source, build your target system and compare the 2 builds. If you're really wanting to verify, do a third install (or LiveCD) and repeat. Then, after you're all done verifying and building your now validated source, you install your verified build and you have a trusted initial install. It's a lot of work, but

    • No need for signatures. Just always depend on a specific Git commit, identified by hash, for automatically retrieving dependencies. Also prevents changes from breaking stuff.

  • Problem with package manager, not repository (Score:5, Informative)

    by guruevi ( 827432 ) on Friday February 09, 2018 @08:53PM (#56098339)

    The package manager and dependency programmer should check either the hash or another cryptographic property of the code to authenticate the code.

    This is the same as someone re-registering an expired domain or simply poisoning the repository or even hacking the dns in your router. Unless you can check you have an authentic package, signed by a known author, you're purely depending on the goodwill of the Internet.

    I would think this is kind of mandatory but I guess Go/JavaScript developers don't need to think about security, the language/platform is secure.

    • Amusingly enough, Git already provides the solution to this problem cryptographically. Git revisions have a SHA1 hash. I just looked it up and the built-in Go package manager (invoked as `go get`) does not have any way to specify a revision hash or any other head marker of a Git repo. About a year ago, the language itself added some type of support for specific revisions (some dependency management they called "vendoring") but unless a specific hash is required for every dependency, you've still got the vul
  • Spelled my last name wrong the second time but not the first ;)

    • Re: (Score:1)

      by Anonymous Coward

      I bet everyone calls you donut

      • hey, you know who's the most popular guy at the nude beach? He's carrying two cups of coffee and a dozen donuts.

  • I'm not sure why there isn't a PKI system for this like with ssh or other open source projects. Once you've established the trust it would then warn you if it was signed with a different key. It's shocking that this most basic warning system doesn't exist.

    • It does. Check apt or yum for example. This is about code thrown together in Go and similar problems exist in lots of JavaScript code managers, I'm sure those languages are so secure they don't need to be checked.

    • Establishing the trust is another big issue, especially when bringing up a particular environment for the first time on a given machine. How many people make a point of verifying the server key fingerprint the first time they connect to a particular SSH server?

  • This doesn't solve anything. Just like various browser extensions for Chrome or whole Android Apps are sold and then made into adware or worse. There the whole account is basically bought, and the same can be done in github. If people continue to misuse github as a package repository, it will happen sooner or later.

    • One would hope that the PHBs who buy $Project$ will have learned to specify that buying $Project$ includes all private keys associated with $Project$. Put it in the contract.

      Does this conflict with concepts of code ownership and responsibility? Maybe. And, so?

  • Well, maybe they should do something like give everyone the equivalent of a date of birth at the end of the username, so that people can be distinguished even if they have the same core name.

    Otherwise, as time goes on, won't we start to run out of names if you can never reuse them?

    How do we deal with this problem for actual human beings who have similar names?

    • Re: (Score:2)

      by Misagon ( 1135 )

      Asking users to expose their birth dates is not a good idea.
      In some countries, birth dates are considered sensitive information.
      Either way, the data could be harvested by a third party and used for targeted advertising or more nefarious purposes.

    • everyone the equivalent of a date of birth

      Every user name, not every person. And in the world of crypto, I think you mean "a grain of salt", not a birth date.

      A perfectly reasonable use case is for "Joe" to have a Github account for the projects someone pays her to work on in the office, and a second account for his personal project tracking wombat breeding. And to extend that case, since I'm swapping Joe's gender-ish pronouns randomly, posit that "Joe" tries coding a FaceSpace-a-like that has gender fluidi

  • .... it should be based entirely on some unique identifier that people don't ordinarily use to identify the person, but can be easily discovered whenever necessary.

    A username should serve only as a human-readable identifier, it should not serve as an identifier that is used by itself for any security purposes at all. If a person changes their username, their previous name should be available for reuse, just as a disconnected phone number is, but in the case of usernames, you could still readily tell the

  • If this problem broke your build system (Score:2, Interesting)

    by Anonymous Coward

    Then you're a dangerous amateur and you should immediately stop developing software for the good of all humanity.

  • If this is a common problem for you, then you are choosing the wrong projects to depend on.
  • Go has a pretty stupid package manager if it's relying on a URL to deliver binaries to clients. Any code (binary or source) should be signed and signatures cross-checked in a distributed registry. If you think github name resuse is going to stop this you need to switch languages.

  • I think a source repository should be allowed to be deleted, and a username to not be reused. I think it's a huge mistake -- and I never have -- to use a repo as a dependency. Grab sources from a repo and if the head goes away stay with what you have. I have nuget packages that can't and should never be deleted.

  • That's why we have SSH and PGP keys on GitHub.

  • You sign a tag so that it's verifiable that no one else could have possibly created the tag, so if a malicious user gets your account name but not your private key, they can't create new tags.

  • User accounts are not something unique to GitHub, and I would expect any service that lets you pick usernames to allow reuse, otherwise eventually you are left with random letters and numbers as users move on.

    12 best practices for user account, authorization and password management
    https://cloudplatform.googlebl... [googleblog.com]

Slashdot Top Deals

"If it ain't broke, don't fix it." - Bert Lantz

Close