38
CLI for codeberg/forgejo? (lemmy.world)
submitted 8 months ago by to c/programming@programming.dev
12 comments fedilink hide all child comments
 

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?

you are viewing a single comment's thread
view the rest of the comments
[–] [S] 2 points 8 months ago (6 children)

I'm not sure I understand your question... is that a convoluted way to say they all do plaintext?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 4 points 8 months ago (5 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] [S] 3 points 8 months ago* (last edited 8 months ago) (4 children)

    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 :)

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 7 points 8 months ago (3 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] [S] 1 point 8 months ago (2 children)

    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. You I 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?).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 8 months ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] [S] 2 points 8 months ago

    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 plus ?" 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 you me leaving my PC unlocked because I have to hurry to the hospital

    PS: 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.

  • permalink
  • fedilink
  • source
  • parent