I don't understand why I'm not seeing a single comment here regarding the fact that web apps are mostly a piece of shit performance and usability wise.
The Twelve-Factor App (2025)
151–160 of 184 posts
Re: The Twelve-Factor App (2025)
#152Earlier quoted context omitted.
The parent poster is wrongly quoting me to say the original post doesn't mean “env var”. Yes, it does mean env var.
No, they are not stored permanently on disk according to 12f. They are only injected for the lifetime of the application and destroyed when stopped. It's not okay to store your secret on your own machine disk's .bashrc forever. It seems we're in agreement anyway.
> "The environment" is not "environment variables" and not ".env files"
Is there confusion because an extra “not” leaked in?
Re: The Twelve-Factor App (2025)
#153> I. Codebase (https://12factor.net/codebase)
> Multiple apps sharing the same code is a violation of twelve-factor.
I never understood why the 12 factor app is against monorepos. It seems completely orthogonal to the contract between an application and its execution platform, which if I understand correctly, is the main point of 12 factor.
Re: The Twelve-Factor App (2025)
#154Earlier quoted context omitted.
Secrets should go in a vault and retrieved with the help of a workload identity.
How does the running app instance get the workload identity? The ways I can think of are (1) it's baked into the source code (worst possible security), (2) it's provided on the command line (also bad since command lines are visible to ps unless you do various OS-specific hijinks), (3) it's provided in an environment variable (no better than before), or (4) it's read from some well-known path (it seems to me that anyt…
> (3) it's provided in an environment variable (no better than before)
Even if you take no measures beyond simply using a token that can be exchanged for secrets (and you can – invalidate it, authenticate it, etc.), you’re already doing better than before, because the token isn’t useful to an attacker without access to the secret store, whereas something like a JWT secret key is very useful.
Re: The Twelve-Factor App (2025)
#155Earlier quoted context omitted.
Adding a config setting should never be dangerous (if it is your system is deeply broken) and should be distinct from changing an existing config setting.
> Adding a config setting should never be dangerous (if it is your system is deeply broken) While I can't name anything specific offhand, I feel pretty strongly that I've seen documentation for various things stating that those things check for an environment variable and, if it isn't present, fall back to other candidate names for the same variable. This makes setting a new variable synonymous with changing an exist…
Never seen this problem in the wild. Seems like it would be a very rare issue limited to very large configs with conflicting names.
Re: The Twelve-Factor App (2025)
#156You have to enjoy this article from the perception of its time. For example #1, the idea of a central codebase + many deploys was not always the way folks did things lol. The (2025) date must not be correct…
It's not this came out in 2012 when Heroku was The Way to run SaaS apps
I was confused at first, thinking this was going to be an updated version of the original.
Re: The Twelve-Factor App (2025)
#157Earlier quoted context omitted.
> Adding a config setting should never be dangerous (if it is your system is deeply broken) While I can't name anything specific offhand, I feel pretty strongly that I've seen documentation for various things stating that those things check for an environment variable and, if it isn't present, fall back to other candidate names for the same variable. This makes setting a new variable synonymous with changing an exist…
Never seen this problem in the wild. Seems like it would be a very rare issue limited to very large configs with conflicting names.
You've never seen software that will use a default value, instead of refusing to operate, when a particular environment variable isn't present in the environment?
Re: The Twelve-Factor App (2025)
#158Earlier quoted context omitted.
Never seen this problem in the wild. Seems like it would be a very rare issue limited to very large configs with conflicting names.
You've never seen software that will use a default value, instead of refusing to operate, when a particular environment variable isn't present in the environment?
No I’ve never seen software that broke because someone added a config key.
Re: The Twelve-Factor App (2025)
#159Earlier quoted context omitted.
> this had the second-order effect of leading devs to believe they could put all their local env secrets in ~/.bashrc files Teach them to use dotenv. We are moving away from configuration in config files because it is a pain to modify, especially if part of that configuration is secrets. You have to throw everything into your secrets vault of preference, and editing it requires extracting and reuploading the whole th…
My issue with the env is it's not a secret store. Dotenv is a delivery mechanism. If you're using it to put APP_BASE_URL or APP_PORT into your env, it's a very convenient one. If you're using dotenv to put SECRET_SIGNING_KEY into your env, it's as poor a delivery mechanism as ~/.bashrc is. Processes and subprocesses inherit your environment. Too much can go wrong. Something as innocent as an error logging library add…
[flagged]
Re: The Twelve-Factor App (2025)
#160Earlier quoted context omitted.
How does the running app instance get the workload identity? The ways I can think of are (1) it's baked into the source code (worst possible security), (2) it's provided on the command line (also bad since command lines are visible to ps unless you do various OS-specific hijinks), (3) it's provided in an environment variable (no better than before), or (4) it's read from some well-known path (it seems to me that anyt…
> (3) it's provided in an environment variable (no better than before) Even if you take no measures beyond simply using a token that can be exchanged for secrets (and you can – invalidate it, authenticate it, etc.), you’re already doing better than before, because the token isn’t useful to an attacker without access to the secret store, whereas something like a JWT secret key is very useful.
Thanks, I can see how invalidating the token after first use, or after a short time period, reduces the exploit possibilities. (If all upstream service providers that you depend on were perfect, this could be arranged separately for each JWT that you need, but they aren't perfect.)
> authenticate it
> the token isn’t useful to an attacker without access to the secret store
If it's not a bearer token (that is, if you need to provide some additional credentials to authenticate it to the secret store) then any such additional authentication would need to be passed in somehow. Are you maybe assuming that in the environment where the app runs, some subsystem will have already installed a credential for some suitable IAM security principal? Because in that case, I certainly agree that it's better to anchor everything off that. That covers many cases (including every cloud) but not, e.g., rented plain VPSes or a couple of servers in your own basement.