this post was submitted on 24 Jan 2024
1 points (100.0% liked)
Open Source
31118 readers
288 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon from opensource.org, but we are not affiliated with them.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
Aha, I think we have arrived at the crux of the confusion.
As I said several times before, I'm extremely in favor of using API tokens that way, when they're being used from an automated workflow where the alternative is to store a password. That's an increase in security, yes.
What I'm irritated about is that my use of git as a command-line tool does not function to interact with github if I just give my github password. I do not have an automated workflow. I'm just using git from the command line, and would like to be able to type my password.
If this reduction in the security and convenience of my daily setup is because github believes, as you do apparently, that the only reason to use the command line is from an automated workflow, that may form a clue as to why they don't give a shit about my preferred workflow or my not wanting to introduce new attack vectors into it. Fair enough. But please don't lecture me on how not letting me just enter my password, and forcing me to store tokens for my interactive workflow, is better. Because for me, it isn't.
Glad we had this talk.
Yes, it looks like it was me who was confused. I did not know that github does not accept anymore the password when using git, and you're right that this is unnecessary. Sorry that I was rude, me implying that you were confused really wasn't a friendly thing.
If you use git often, and this is in the way for you, I think it's possible to save it in the gitconfig, tough, if that's fine. I think git should be able to use the credential manager of mac's too if you use that, but maybe it needs a separate package installed for that to work.
Hey it's all good. In seriousness I am glad we came to a point of understanding now.
And yeah, my API token I generated for the command line, I keep stored in my OSX keychain. It's all set at this point. I'm just irritated that I had to go through all that bollocks in the first place, and for no increase in security but actually a slight reduction, since my github password is not in the OSX keychain, but in a much-more-secure password manager and in my memory. And, that from time to time the whole issue rears its head again like it did yesterday.
Actually, holy shit - you just made me realize, as I was thinking on that "slight reduction in security" statement, that the pass"phrase" for my OSX keychain is one that I reused in other places on the internet, not one that I treat as "holy shit needs to be super-secure" like for my other password manager. Brb I am changing that right now.