If it helps anyone, bom-squad.com is a very similar project and the whole site behind it is on github as well. Full disclosure I contributed to this project myself.
That is just tailwind CSS, one the most common CSS libs out there I would think. Your comment is actually a lot more telling of something as opposed to this AI written project though.
Envvars have much weaker access controls than files; basically anything in the same PID namespace can read your envvars. Poke around in /proc/*/environ to see for yourself. Files can use user permissions and MAC (AppArmor, SELinux, etc) to secure them against unauthorized processes.
If running in a containerized environment ENV is injected only to the container, at container runtime. If you’re running your containers with a single process, you are doing the exact access control you just outlined. At that point what is the difference between a file on disk with read permissions for the proc owner vs only the proc having the ENV injected to its shell at runtime? I’d maybe even say the ENV at runtime is more secure than the chown’d file on disk because the ENV injected variant is ephemeral and when that container/proc dies, so does the ENV sitting in its memory, whereas the other leaves a file on disk potentially depending on where it was written to, regardless of who can access it. Then there’s the fact that a lot more people than you think run containers as root so all file access control goes out the window.
From a security perspective it is always more secure to have something only in memory of the running process than it is to have a file on disk regardless of file permissions
Containers don't enforce that isolation. Another process can nsenter the container's PID namespace. You also have issues if your container's PID1 creates subprocesses.
File are not necessarily written to disk. e.g. the Secrets CSI Driver loads secrets directly from a secrets store as virtual files within ephemeral volumes.
> the Secrets CSI Driver loads secrets directly from a secrets store as virtual files within ephemeral volumes.
You could totally spin this as agreeing with 12factor… the virtual files are attached resources that are part of a deployment. The configuration, expressed as env vars, configures where to look for those secrets (ie. their filesystem path) and where they’re used (e.g. as a templatized database URL.)
12factor says config should be env vars, it doesn’t say secrets should be. It’s unfortunate that the site lists credentials as an example of configuration, but… it’d be great IMO if we could sidestep a lot of contention by just considering this to be errata of the example, and that secrets are left as an exercise to the user.
Struggling with this today, and numerous other days. It's so bad. Stop trying to build an operating system out of YAML. I'll always use and recommend Gitlab from now on.
And what the earth is an "actions" anyway? How on earth is simple bash functions not just as suitable here? Instead you have some weird YAML scripting language. It's so bad. Why. Somebody please tell me. I'm losing my mind. It is a good reflection of the rest of the world though and why the worlds infrastructure is crumbling in many places.
Executing bash statements/scripts/functions is the thing I struggle least with in GH actions personally, it's remarkably easy to execute shell steps. If you really want your entire build to be a shellscript the action executes, you can do just that with very little YAML.
Props to those of you still at the mercy of your OS publishers (Windows, Ubuntu, Mac) who dictate your software, updates, how your hardware is used and general freedom. Did a lot of that in my teens.
I boot my pc, login, press win+p, type in "fir" which autocompletes to firefox and it starts firefox. And I don't think this process will change much for the rest of my life.
The alternative is a constantly changing menu UI, intrusive popups/notifications, deprecations, and a "oh wait sorry Firefox now has to be Certified from the app store", random telemetry data being sent over, strange unknown but necessary "computation" happening and what else have I missed?
You've missed the part where you can press win+r to launch Firefox immediately (or open if it's already launched, but inactive, or hide if it's active without any autocompletion) on any of those systems ignoring all of the menu UI nonsense, which is also workflow that can remain stable for the rest of your life
(also, Firefox is also sending random telemetry data)
It's data is licensed under creative commons, and last I looked into it, you could easily download the entire stackoverflow dump. There was a torrent and it was about 50GB or something.
"Kubernetes manifests are an unnecessarily detailed abstraction for most software developers. Developers don't need as much control. Therefore, they need higher-level abstractions, which hide more detail."
Agreed... Though I think there is a different solution. Instead of coming up with all these hardcoded formats and standards (docker-compose, k8s, etc, helm, ansible) which essentially are just 'functions' that map X to Y.
Instead of defining 'docker-compose' files, just define the containers itself. And if required, map that to a docker-compose, or k8s manifest or whatever. Remove all these unnecessary layers that aren't really that helpful - because each standard or implementation has it's own parser, error handling etc - why bother with all this?
And just use something like Nix for this. Or just define it as a common python value. Otherwise we end up building all sorts of templating and ugly programming-in-yaml. You could take a look at https://docs.hercules-ci.com/arion/#_arion_compose_nix to see what this might look like - uses Nix to do something like docker-compose.
