First, they restricted code search without logging in so I’m using sourcegraph But now, I cant even view discussions or wiki without logging in.
It was a nice run
The only thing surprising is that it took Microsoft almost three years to turn on the shit-spigot.
You gotta embrace first
There’s nothing wrong with it honestly, and OP seems to be giving bad info… And trust me, I’m not a fan of Microsoft lol
i literally just tested Discussions and wiki in private browsing mode on a few repos and they work. Which just proves it’s not a big deal that needing a login isn’t an issue. Seems nobody actually upvoting doesn’t have a login
I heard other people complaining about what OP says, so I’m thinking maybe it’s A/B testing…
I moved all my open source projects to Gitlab the day Microsoft announced they were acquiring Github.
(I wish in retrospect I’d taken the time to research and decide on the right host. I likely would have gone to Codeberg instead of Gitlab had I done so. But Gitlab’s still better than Github. And I don’t really know for sure that Codeberg was even around back when Microsoft acquired Github.)
Honestly for selfhosters, I can’t recommend enough setting up an instance of Gitea. You’ll be very happy hosting your code and such there, then just replicate it to github or something if you want it on the big platforms.
Just so you’re aware, Gitea was taken over by a for-profit company. Which is why it was forked and Forgejo was formed. If you don’t use Github as a matter of principle, then you should switch to Forgejo instead.
did they get federation working?
Nothing usable yet unfortunately, but they seem to be making good progress: https://codeberg.org/forgejo/forgejo/issues/59
The writing was on the wall when they established a generative AI using everyone’s code and of course without asking anyone for permission.
It’s an interesting debate isn’t it? Does AI transform something free into something that’s not? Or does it simply study the code?
There’s no debate. LLMs are plagiarism with extra steps. They take data (usually illegally) wholesale and then launder it.
A lot of people have been doing research into the ethics of these systems and that’s more or less what they found. The reason why they’re black boxes is precisely the reason we all suspected; they were made that way because if they weren’t we’d all see them for what they are.
The reason they’re black boxes is because that’s how LLMs work. Nothing new here, neural networks have been basically black boxes for a long time.
I’m still stuck on why I have to create a password-equivalent API token, and then store it on my hard drive if I want an at-all-convenient workflow.
“We made it more secure!”
“How is storing it on my hard drive more secure”
“Just have it expire after a week!”
“How is it more secure now, seems like now there are two points of failure in the system, and anyway I keep hearing about security problems in github which this hasn’t been a solution to any of them”
“SHUT UP THAT’S HOW”
An API token is more secure than a password by virtue of it not needing to be typed in by a human. Phishing, writing down passwords, and the fact that API tokens can have restricted scopes all make them more secure.
Expiration on its own doesn’t make it more secure, but it can if it’s in the context of loading the token onto a system that you might lose track of/not have access to in the future.
Individual API tokens can also be revoked without revoking all of them, unlike a password where changing it means you have to re-login everywhere.
And that’s just the tip of the iceberg. Lmk if you have questions, though.
Oh, API tokens in general, I think are great. As an additional layer of security between “I need my program to be able to access this API” and “I type my password”, they are great. My issue is with the specific way that github has implemented them.
An API token is more secure than a password by virtue of it not needing to be typed in by a human.
Remind me. When I create my API token, how do I provide it to git?
Am I, more or less, forced to save my token to persistent storage in a way I wouldn’t be with a password? I realize that most people store either one in a password manager at this point. My point is, if you’re going to store your password-equivalent in a password manager, how have you achieved greater security as compared with storing a password in the same password manager? How is that not just adding another compromise vector?
Phishing
Remind me. Does making a system significantly more complex mean that phishing gets easier? Or harder?
As an example, if someone can phish my password from me to compromise my security, is that better or worse than if they can either phish my password or else compromise my tokens? I remember this compromise for example, but I can’t remember whether it involved passwords or tokens.
writing down passwords
Remind me. Help me understand. Can someone write down their github password if the API token system exists? If they have to use it sometimes to log in to the web site anyway?
and the fact that API tokens can have restricted scopes
Yes. API tokens are a good system, in general, and restricting the scope of what they can do and making them time-limited are good reasons why.
My argument is that, in general, (a) adding an additional point of access to a system without doing anything to disable the existing point of access, and (b) saving a password equivalent to someone’s system instead of having the “standard way” be for them to retype their password to authenticate each session but not have it saved anywhere, are both overall reductions in security.
I get the motivation that github sometimes protects really critical stuff, and so it needs to be more secure. I am saying that their particular implementation of API tokens led to an overall reduction in security as opposed to an increase.
Remind me. When I create my API token, how do I provide it to git?
By copy-pasting it somewhere it has access to it. It can be the config file, it has several ways to use the system’s secret storage, and you can also autotype it from your password manager every time if you want.
forced to save my token to persistent storage in a way I wouldn’t be with a password
So not really
My point is, if you’re going to store your password-equivalent in a password manager, how have you achieved greater security as compared with storing a password in the same password manager?
Passwords can be short and simple. API tokens are lengthy and random, and you can’t change that. Also, you never type in your API key, and that can help against shoulder- and camera-surfing.
without doing anything to disable the existing point of access
You can’t do that, because
- the API token is strictly for API access for outside programs
- the API token cannot be used to manage your account, like change password or emails, or to create additional tokens
API tokens are not a total replacement, just a more secure and restricted replacement for the everyday and not too risky tasks and for automated systems.
I think this comment pretty well summarizes my argument on it. The only parts not addressed:
Passwords can be short and simple. API tokens are lengthy and random, and you can’t change that.
You can, as most modern web services including github do, have a minimum length and complexity for the password. That’s a very important part of the process yes.
Plus, you seem to still not be grasping the core of my argument: github still authenticates with a password. You can still log in to the web site and change everything, if you compromise someone’s password, whether because it’s insufficiently complex or for any other reason.
Also, you never type in your API key, and that can help against shoulder- and camera-surfing.
I would like to see a quantitative comparison of how many github compromises there have been because of a stolen API token vs. compromises of some comparable service from a shoulder-surfed password.
You can, as most modern web services including github do, have a minimum length and complexity for the password. That’s a very important part of the process yes.
Sorry, I wasn’t clear. What I wanted to say is that passwords can be insecure, and in the case of lazy people that had consequences on security. I think the minimum is often not really secure, it’s just “fine if you really must” but allowed to not lose to many users.
And at the same time tokens are always secure. It’s not defined by the user, they cannot lazy it away, it’s made equally complicated for everyone. Fortunately they don’t have to type it either, it’s copy paste and done.However I have to admit that while writing this response, complexity is not really the point with github access tokens.
Plus, you seem to still not be grasping the core of my argument: github still authenticates with a password. You can still log in to the web site and change everything, if you compromise someone’s password, whether because it’s insufficiently complex or for any other reason.
That’s right, these tokens won’t protect the lazy from their account being taken over. But I think these are still more secure for their use case: storing them in mostly text files, because the programs to which you give these will probably do that, and as these are not really password-equivalent things (these have very limited access to your account), it’s less of a problem.
Your original question here was how will it be more secure that we are storing these tokens in our password managers besides our passwords. My answer is that even if you put it into your password manager, that’s not it’s final place: it will probably end up in text files and other such places, and if such a file gets into the wrong hands you’ll be in less of a trouble because of the limited permissions. If you would have stored your password there, you could be hoping that you’ll get your account back, and that the person did not do anything bad in your name.
I think much of the confusion is coming from you believing that api tokens are equivalent to passwords. That’s not the case. Even if you give all possible permissions to a token, it won’t be able to do everything that you can do with the password through the website. In short, the main point here is that you don’t have to use your password in places where that’s totally unnecessary, and fewer permissions are fine.
it will probably end up in text files and other such places, and if such a file gets into the wrong hands you’ll be in less of a trouble because of the limited permissions
I am abandoning this conversation. This is only true with API tokens. With passwords, it generally stays in the password manager. The fact that the damage from your stolen API token is then mitigated if you’ve reduced its scope still leaves you in a worse position than if it had never been stored in the text file and never been stolen in the first place. If you can’t or won’t grasp this central point (or the other I mentioned in my other message), I think we have nothing to discuss.
The fact that the damage from your stolen API token is then mitigated if you’ve reduced its scope still leaves you in a worse position than if it had never been stored in the text file and never been stolen in the first place.
First, it’s not a question if you have reduced it’s permissions. With an api token you simply can’t do a lot of things that you can with a password.
Second, you don’t use api tokens as a hobby. You use them because you want to use a tool that needs to have access to your account. Either you use an api token that has a limited set of permissions, or your password that can do anything. Independently of that, it will be stored in a plain text file, because where in the heaven would it store it so that it does not need to prompt you for it every single time? Yes, there are a dozen secret store programs that could be used instead, but a lot of programs will not have support for every one of them. I fail to see that in case how a token with fewer permissions is worse than a password with all the permissions.
