Slashdot Mirror
Should GitHub Allow Username Reuse? (donatstudios.com)
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.
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.
Maybe next time you'll actually check before blindly downloading code from the internet.
because it's not a problem with github; it's a problem with morons misusing github.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
No. No. No.
A URL is not tied to an identity. The only way to verify who wrote the code is to use digital signatures.
{{.sig}}
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.
Custom electronics and digital signage for your business: www.evcircuits.com
Spelled my last name wrong the second time but not the first ;)
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.
"[We'll be] really getting inside your head and making it an unpleasant place to be" -- Trent Reznor
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.
Reuse is fine, but there should be a period of inactivity. Many mail providers use 6 months to a year.
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?
The solution is simple. Give each user account a unique, (never may be reused number,) and allow the user to pick his/her name; then make sure users understand that only the number is the identifier, and the name is just a "nick". As for users permanently disabling their accounts, I'm not sure how this directly impacts other github users, (not being intimately familiar with github internals, but you just make it so that whenever an account is deactivated, shut off, locked out, etc., that all things belonging thereto default to someone above the original user, (i.e., the github user account that has been open longest, or the one perhaps in the relevant field whose account has been open/active longest, or the one open the longest that has been active fairly recently and routinely, and make that account the point of contact for anyone (or group) who work on that project.
User name reuse can be problematic when people don't know that the NEW user with that name may NOT be the same as the OLD user with that name, so that should never be allowed as such, without some mechanism. Perhaps include with usernames the date the account was established in parentheses after a user name, somewhat like how they do on /. but instead of user nickname (user number) have it be User ID (variable/user selected) and date established, followed by Unique User ID ACCOUNT Number
So it could be something like:
ReijnStrøm Project maintainer Slashdottier (20170125) UUAIDN: &h_000_000_000_001 posted this update to FAQ page on (date) ...
This would indicate the user name "Slashdottier" whose account was established January 25th, 2017, and whose unique hexadecimal user ID number is... 1.
Or however they do it on github. So then at least there is no ambiguity. Perhaps require each project to name a couple individuals who are designated to inherit a project if that account stops, deactivates, doesn't log in in a few years, etc.
Just a thought.
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 previous user from the current one because the unique identifier could be checked.
If a person doesn't think to check the unique ID, then that's their own bloody fault... about on par with a person not checking that a cashier has handed them back the right amount of change and not noticing any discrepancy until they got home.
File under 'M' for 'Manic ranting'
Right.
Related. Are republicans this stupid to believe the nonsense coming from the WH/stoogesOnHill, or do the just go along with it, knowing full well it is nonsense. I mean, it can't actually be 90% of republicans are morons... serially?
Then you're a dangerous amateur and you should immediately stop developing software for the good of all humanity.
gathers G.A.Y N1GGERS from all over America and abroad for one common goal - being G.A.Y N1GGERS.
Are you G.A.Y ?
Are you a N1GGER ?
Are you a G.A.Y N1GGER ?
If you answered "Yes" to any of the above questions, then G_N_A_A (G.A.Y N1GGER ASSOCIATION OF AMERICA) might be exactly what you've been looking for!
Join G_N_A_A (G.A.Y N1GGER ASSOCIATION OF AMERICA) today, and enjoy all the benefits of being a full-time G_N_A_A member.
G_N_A_A (G.A.Y N1GGER ASSOCIATION OF AMERICA) is the fastest-growing G.A.Y N1GGER community with THOUSANDS of members all over United States of America. You, too, can be a part of G_N_A_A if you join today!
Why not? It's quick and easy - only 3 simple steps!
First, you have to obtain a copy of G.A.Y N1GGERS FROM OUTER SPACE THE MOVIE and watch it.
You can watch G.A.Y N1GGERS FROM OUTER SPACE on Youtube.
Second, you need to succeed in posting a G_N_A_A "first post" on slashdot.org , a popular "news for trolls" website
Third, you need to join the official G_N_A_A irc channel #G_N_A_A on EFNet, and apply for membership.
Talk to one of the ops or any of the other members in the channel to sign up today!
If you are having trouble locating #G_N_A_A, the official G.A.Y N1GGER ASSOCIATION OF AMERICA irc channel, you might be on a wrong irc network. The correct network is EFNet, and you can connect to irc.secsup.org or irc.easynews.com as one of the EFNet servers.
If you do not have an IRC client handy, you are free to use the G_N_A_A Java IRC client by clicking here.
If you have mod points and would like to support G_N_A_A, please moderate this post up.
This post brought to you by Penisbird , a proud member of the G_N_A_A
G_____________________________________naann_______ ________G
N_____________________________nnnaa__nanaaa_______ ________A
A____________________aanana__nannaa_nna_an________ ________Y
A_____________annna_nnnnnan_aan_aa__na__aa________ ________*
G____________nnaana_nnn__nn_aa__nn__na_anaann_MERI CA______N
N___________ana__nn_an___an_aa_anaaannnanaa_______ ________I
A___________aa__ana_nn___nn_nnnnaa___ana__________ ________G
A__________nna__an__na___nn__nnn___SSOCIATION_of__ ________G
G__________ana_naa__an___nnn______________________ ________E
N__________ananan___nn___aan_IGGER________________ ________R
A__________nnna____naa____________________________ ________S
A________nnaa_____anan____________________________ ________*
G________anaannana________________________________ ________A
N________ananaannn_AY_____________________________ ________S
A________ana____nn_________IRC-EFNET-#G_N_A_A________ ________S
A_______nn_____na_________________________________ ________O
*_______aaaan_____________________________________ ________C
Gary Niger gary_niger@G_N_A_A.us G_N_A_A Corporate Headquarters 143 Rolloffle Avenue Tarzana, California 91356
Enid Al-Punjabi enid_al_punjabi@G_N_A_A.us G_N_A_A World Headquarters No.33 Kyutei Bld. 2F, Shinjuku 2-11-7, Shinjuku-ku, Tokyo, Japan ????????2??11-6
Copyright (c) 2003-2015 G.A.Y N1GGER Association of America
Ich Bindawalross (London) - G_N_A_A (NYSE:
If you publish something on github, why does deleteing your account make that stuff go away?
It kind of defeats the the idea of publishing s/w for other folks to incorporate into theirs.
If somebody else wishes to take over an abandoned project, the projects using it can still get the old stuff by asking for a specific version.
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.
Why are you trusting a random strangers GitHub git repo, one that can be updated at any time for any reason, including changing existing versions to be something other than they were before? And the USERNAME is the part that you're worried about? You use NPM too don't you?
If you're going to pull random libraries from random GitHub users, fork them into your own repo so they can't be modified in any way by any random person without your knowledge. If you want to have reliable builds, you should be pulling your dependencies from a local cache with static versions. By pulling your libraries directly from the source at build time, you may get the 'advantage' of always having the 'latest' version . . . but that advantage sucks when the latest version happens to be from some hack that owns your account during the build process.
Thats okay though right, because your builds are only run by a user which has nothing more than read only access to your repos anyway . . . right? So the fact that 'they' now have all your build configuration information can't be used to login to your GitHub account and hax0r your repo ... RIGHT?
The problem here is that its stupid to link directly to third party libraries. Download a copy that doesn't change until you tell it to change. Fork the repo, whatever. Put it somewhere that your build can access rather than downloading from source every time.
USE A THIRD PARTY REPOSITORY FOR YOUR LIBRARIES. Seriously. Decentralized is NOT ALWAYS THE BEST WAY TO DO THINGS, a central repo like yum, maven, apt-get and all the other real package managers use and you get at least a few people with eyes on whats happening to ensure its probably safe, and all the other end users who may find errors without you looking. When you pull from some random GitHub repo though ... thats just begging for trouble.
I don't care if Go makes its super easy to pull libraries from GitHub, is super stupid to pull in third party repos this way and you pretty much deserve what you get for doing so.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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?
If this is a common problem for you, then you are choosing the wrong projects to depend on.
"First they came for the slanderers and i said nothing."
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.
This should be obvious, standard infosec policy in 2018. It should be blatantly obvious for corporate networks, e-mail hosts, banking, social media, and other such outlets, but really it should be a blanket policy everywhere.
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.
How's life in the hypocrite lane?
That's why we have SSH and PGP keys on GitHub.
Kriston
Like a trademark
A user id is like a trademark that never expires. No one should be able to hijack another person's trademark, even if the original code is deleted. This applies to a repository bank like
Github.
A URL is a different story, because a URL may have a generic name, like recipes.com. A user id should never be generic, or inherited like a person's name, or be able to be sold like a URL or a commodity.
have no idea what github is, so who cares? Github users I guess.
This is not a problem with Go or any other github-using frameworks or languages. This is a *process* issue. Any project manager, 'DevOps' house or poor schmuck on the dev team who has to handle the CI system just needs to ensure no one (and no build server) blindly auto-updates third party libs from external sources.
Automate, but never *over* automate. Review update notifications manually, verify, stage and test them, before using in production.
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.
> Git hashes aren't intended to be cryptographic strength.
That wasn't the suggestion, but I can understand how you would choose to pessimistically misunderstand the sentiment.
> Git commit, identified by hash
Many people know that the git hashes aren't cryptographically secure, but the git documentation spells it out for you.
The suggestion was to create another hash for the intended purpose.
SMH
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...
2 extremes:
Is it like a phone number? When you abandon a phone number (can't or won't port it to a new provider), it goes back into the pool and gets reused at some point.
Is it like a Facebook account? Names do not get reused. When properly notified of death or the account gets deleted, Facebook archives them and prevents further updates. Lots of systems do something like this when an account or its owner goes away - things may remain online for some amount of time, but read-only, and future use of the account ID is prohibited.