talkingpumpkin

I actually like Debian’s slow update cycle, as I don’t want to be bothered often with setting up my system again.

I've been there too!

Updating to a new version is such a chore: you have to follow the news, then wonder how long to wait before updating, then you have to set aside at least a few hours for the actual update (well, for fixing what may go wrong - not that stuff actually goes wrong, but you still set aside some time just in case).

The solution to this is in the exact opposite direction you'd imagine.

For a few years (since last time I got a new PC), I've been running a rolling distro (tumbleweed *) and... it's been great: no big updates, just incremental ones.

If anything breaks (and it never happened to me: there has been times where errors prevented the system to update, but never has it broken on me), you just boot the snapshot before the last update and try again in a few hours/days.

I want something as close as “set it and forget it” as possible.

That's nixos :) It takes a long time to "set" (and you never really finish doing it) but you can switch to a new PC at any time and have your exact system on it (bar what the few things you have to change to account for the different hardware, of course).

* I hear that with arch&co you actually have to follow the release notes as sometimes there are manual tasks to do - it's not so in tumbleweed (at least, as much as i know and as far as me experience goes) - IDK about other rolling distros (or debian testing/sid)

What does "powerful" distro mean? (no, I've not watched the video - just curious what it means)

Getting the router to actually assign an IP address to the server

You would typically want to use static ip addresses for servers (because if you use DHCP the IP is gonna change sooner or later, and it's gonna be a pain in the butt).

IIRC dnsmasq is configured to assign IPs from .100 upwards (unless you changed that), so you can use any of the IPs up to .99 without issue (you can also assign a DNS name to the IP, of course).

all requests’ IP addresses are set to the router’s IP address (192.168.3.1), so I am unable to use proper rate limiting and especially fail2ban.

Sounds like you are using masquerade and need DNAT instead. No idea how to configure that in openwrt - sorry.

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.

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

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

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

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

Some game engines are real, others are... unreal

Man you should use a chatbot to talk to the other chatbots. AI all the way down

forgot to mention: I'm reporting this ad

Why did people upvote this ad?

Actual technical articles about LLM/diffusion would be interesting to read (I think?)... maybe something like [vibecoding]?

Actually, let's make that generic and use [futurology], so that it may apply regardless of whether the incumbent revolution/menace is LLMs, low code tools, or stack overflow.