I’m looking for a forgejo cli (something similar to gh for github or glab for gitlab - neither of which I’ve ever used).
I found one named forgejo-cli and another named fgj but, from a quick look at the source, both seem to save my API key in a plaintext file, which… I just find unacceptable (and, frankly, quite dumb).
Do you know of any others?
And how do you think other tools are keeping their tokens?
Plenty of tools are using the system keychain. There are good libraries that provide a generic interface to gnome-keyring or kwallet depending on what is running. When I was working with Node I used the keytar library for that purpose.
Edit: Oh, apparently there is a standard DBus API for keyrings. So you can use libsecret to interact with whatever keyring.
They should be keeping them in something like kwallet. But in practice they don’t because a) there isn’t really a single standard for that on Linux (yeay, I have to support gnome-keyring too!), b) it’s a lot more work than using a plain text file, c) the UX is considerably worse, and d) the security benefits are marginal at best (especially if you have full disk encryption).
Plain text is the most sensible option.
e) on Linux, the security benefits are mostly outweighed by the security drawbacks.
The d-bus interface used by those wallets/keyrings has no security at all. Secrets passed over it are in plain view of any spyware that decides to look, and since it’s a well-known interface, it’s a much easier target than secrets stored in separate files with application-specific locations.
Interesting how do you do that exactly?
I was thinking you can just start the app that has permission to read the wallet, attach a debugger and then inject code to dump the wallet. It’s definitely more complicated than reading a plain text file but not fundamentally less possible.
But really if you have that level of access it’s game over anyway and you just MitM sudo and get root access, or use one of the many local privilege escalation vulnerabilities and get root immediately.
I’m not sure I understand your question… is that a convoluted way to say they all do plaintext?
I’m curious what usage secnario you have in mind where that’s a serious concern?
But besides that, you could run it in a podman container and use the secrets feature. That will not only store the password slightly safer, it will sandbox the executable from the rest of your system.
Scenario? Not keeping your secrets in plain text is just good hygiene.
Do you need a usage scenario where not showering for a week would be a serious concern for you to shower more often than that? You wash because you dislike feeling dirty and because you know that proper hygiene makes you more resilient towards whatever health hazard you might be exposed to… it’s the same for securing your secrets :)
Cybersecurity works inherently with risk scenarios. Your comparison is flawed because you state that there is an absolute security hygiene standard.
That said: I highly appreciate your approach to the subject, i.e. looking at the code and raising a discussion about something that looks wrong. Thank you for that!
On the subject itself:
There are two common ways to implement token management. The most common one I am aware of is actually the text based one. Even a lot of cloud services save passwords as environment variables after a vault got unlocked via IAM. That’s because the risk assessment is: If a perpetrator has access to these files the whole system is already corrupted - any encryption that gets decrypted locally is therefore also compromised.
The second approach is to implement the OS level secret manager and what you’re implicitly asking for from my understanding.
While I agree that this would be the “cleaner” solution it’s also destroying cross platform compatibility or increasing maintenance load linear to the amount of platforms used, with a huge jump for the second one: I now need a test pipeline with an OS different than what I’m using.
Cybersecurity works inherently with risk scenarios. Your comparison is flawed because you state that there is an absolute security hygiene standard.
First of all it’s risk analysis :) On top of identifying threats (which I assume is what you mean by “scenarios”), one must assess the likelyhood of those threats and what potential impact they have.
Risk analysis, however is not the core of cybersecurity: that’s just the part security consultants are tasked with (and, consequently, the part pros talk more about, and newbies fill their mouths with).
The core of cybersecurity (and of security in general) is striking a balance between cost and benefit, which is an inherently an executive decision (you’ll hear “between usability and security” - that’s just what people say when they want to downplay “cost” to push others to move towards “security”).
That is exactly like managing your health.
YouI could get a comprehensive health checkup every couple months: that would possibly catch a cancer in its early stages (here’s your “risk scenario”) and wouldn’t have serious health repercussions, but I don’t because it’s not worth the money/time/hassle (cost-benefit analysis).Exactly like one does with health, there are security measures you adopt just because you are sure they have a benefit (just that it exists) their cost is very reasonable (ie. low in absolute terms and specifically compared to how much a full risk analysis would cost): did you do a full risk analysis before deciding your PC should have a password? Before setting up a screensaver that locks your screen?
There are two common ways to implement token management. The most common one I am aware of is actually the text based one.
Yeah, the two I’ve my OP seems to point
Even a lot of cloud services save passwords as environment variables after a vault got unlocked via IAM.
Environment variables have their attack surface, which is way smaller than that of a text file stored in your home directory.
That’s because the risk assessment is: If a perpetrator has access to these files the whole system is already corrupted - any encryption that gets decrypted locally is therefore also compromised.
I’m not sure what “the whole system” refers to in “If a perpetrator has access to these files the whole system is already corrupted”.
If the system is my PC, then the reasoning is backwards: the secrets get compromised if (they are not secured and) my PC is breached, not the other way round. On top of that, while basically a lot of breaches may expose the files in your home directory (say, a website gaining read access through your browser, or you accidentally starting a badly written/configured webserver, or you disposing of your old drive, or your PC being stolen, or… many others), a lot fewer compromise properly kept secrets (say, password-protected ssh keys).
If the system is my Codeberg account, then that’s the whole reason I should secure my secrets. (Admittedly, neither of these make much sense, but I don’t know what else the system could be).
Besides that, I must say “who cares? we’re fucked anyway” is quite the lazy threat assessment :D
The second approach is to implement the OS level secret manager and what you’re implicitly asking for from my understanding.
There are a lots of secrets management tools that have little to do with the OS (I’d even say most of them are): bitwarden and all other password managers, ssh keys and ssh-agent, sops, etc.
While I agree that this would be the “cleaner” solution it’s also destroying cross platform compatibility or increasing maintenance load linear to the amount of platforms used, with a huge jump for the second one: I now need a test pipeline with an OS different than what I’m using.
I don’t get the point… It would seem you are trying to tell me that secure tools are impossible to build (when you yourself have talked of “vaults that get unlocked via IAM”) or that I should just use insecure tools (which… is my own decision to make)?
If you took offense because I called those forjego CLIs “dumb” I do apologize (are you the dev of one of those?).
Sorry if I use the wrong English terms! I think you are right :) With system I refered to the literal computer system the file is saved on. I’m not a dev of one of those tools but I know several maintainers and developers that’s why I’m a bit sensitive there! Thats why I (baldy apparently, apologies!) tried to focus on the developer point of view and ignored the whole cost/benefit aspect which you described very well - thank you for that!
Back to my point re/ local security because I feel this is the only one where I see a fundamentally different assessment between us: (Fontext: access an unencrypted file on my machine): I’m not aware of a mechanism to read (unencrypted or not) files on a host without a preceding incident. How else could your files be acessed? I don’t understand how I might have this backwards.
You’re completely right if course that there are a lot of tools out there one could use - but it would be on the developer to implement support for those. If you support one you can be damn sure users shout for “I want to use Y”. And then you would still need a Fallback for anyone not willing to install a supported third party tools.
I’m not a dev of one of those tools but I know several maintainers and developers that’s why I’m a bit sensitive there!
I get it and I appreciate your sentiment.
I also understand that you are not accusing me of disrespect towards FOSS devs, but let me nonetheless stress that “dumb implementation decision” is not the same as “dumb developer”, and that open/frank discussion is as important for the FOSS ecosystem as the effort put in by devs (meaning both are essential, and that is without subtracting from the fact that developing things takes much more effort than talking about them).
I’m not aware of a mechanism to read (unencrypted or not) files on a host without a preceding incident. How else could your files be acessed? I don’t understand how I might have this backwards.
That’s not how you should approach security! :)
You should not think of security in the all-or-nothing terms of avoiding your system getting breached.
You should think of it in terms of reducing the probability of a breach happening in a given time frame, and minimizing the damage caused by such a breach.
The question to ask is “what measures will minimize the sum total of <cost of security> plus <damage from breaches>?” and the philosophy to adopt is defense in deep. (*).
Fortifying a perimeter and assuming everything is safe inside it is the kind of approach that leads to hyper-secured and virus-ridden corporate LANs (if applied to contrasting drug trafficking, would lead to a country where the only anti-drug measures were border checks).
(*) note that a breach doesn’t need to be an hacker breaking in your computer or a thug pointing a gun at your head, it can be just you losing a USB key where you backed up some of your files, or
youme leaving my PC unlocked because I have to hurry to the hospitalPS: this might be my anti-corporate bias speaking, but I’d say the reason the “safe perimeter” idea is so widespread is that tools that promise to magically make everything secure are much easier to sell than education and good practices.
Keeping tokens in plaintext on the client is really common. The alternative would require the user to enter a decryption password on every system start, like some wallets do, which is a bit of a hassle. If at least there was “one obvious way of doing this” across platforms, that’d make things better, but in reality, some tools can’t even put their configs and cache in a sensible location.
The alternative would require the user to enter a decryption password on every system start, like some wallets do, which is a bit of a hassle.
The downside is that you need to type a password - the upside is that you don’t need to type any extra password, since you are already unlocking whatever wallet you are using anyway (unless you don’t use one - which is a whole different problem on its own).
If at least there was “one obvious way of doing this” across platforms,
For wallets I found https://github.com/hrantzsch/keychain/, but TBH I don’t think OS password managers would be the way to go here (at least not if you want to support CI systems and building in containers). Something based on age would be far more flexible, and could leverage existing ssh keys (which I’m sure some people store with no password protection - which, again, is a whole different problem on its own).
