Honestly I was expecting more. There are many languages that support Unicode in variable or function names and I expected it to be used there.

It sounds like Python only allows approved Unicode characters to start a variable name but if it allowed any you could do something like `nonprintable = lambda x: insert exploit code here`. If that was hidden in what looked like a blank line between other additions would you catch it?

I'm sure there's some other language out there that has similar syntax and lax Unicode rules this could be used in.

The solution is that this and many other Unicode formatting characters should be ignored and converted to a visible indicator in all code views when you expect plain text.

> The solution is that this and many other Unicode formatting characters

This isn't about formating characters, this is about private use characters.

You know that QR code is just text you can read right? It's just an otpauth:// URI you can copy and paste into most password managers.

We even have these amazing things that securely share passwords or other secret data between multiple authorized users.

Seriously just scan the QR code and put it in any password manager that supports TOTP and it will start outputing codes.

Yes, I am very familiar with zbarimg and qrencode. But, other people might not be, and that's why just scanning a QR code works. Not everyone has Bitwarden, 1Password, Pass, keepass, etc.... also these tools may not be approved by your security teams.

And we are talking about the root account for your production AWS account. No need to get fancy. Just print the QR code, and put it in a safe hoping you never need it.

That's precisely why you want it in a safe.

The latest release was June 2022 and the last non dependabot commit was March 2023, until new activity 4 days ago using AI. Why should anyone use this?

Part of how the USA got that way is hilariously enough, anti-corruption policies.

I'm currently in the endless email loop because someone named Raymond used one of my Gmail names to register with State Farm. One of their agents even emails me directly when he gets really behind on his payments but won't do anything when I tell them it's the wrong email.

In the past when this happens I usually reset the password and change the email to some anon throwaway but I can't do that without Raymonds DOB (don't quote me on that, been a while since I tried).

This exact thing happened to me with a State Farm agent.

After a few months, I told them I was concerned about the privacy ramifications and would have to report it to their state insurance regulator, and it was very quickly fixed.

Not just idiots, rich idiots that will make more from the hype and publicity than we normal people could make in a few years.

This would be perfect if it also was able to expose secrets as files scoped to the process ala /run/secrets/secret_name.

The problem isn't the .env file itself but using environment variables at all to pass secrets is insecure.

I strongly disagree.

Environment variables are -by far- the securest AND most practical way to provide configuration and secrets to apps.

Any other way is less secure: files on disk, (cli)arguments, a database, etc. Or about as secure but far more complex and convoluted. I've seen enterprise hosting with a (virtual) mount (nfs, etc) that provides config files - read only - tight permissions, served from a secure vault. A lot of indirection for getting secrets into an app that will still just read them plain text. More secure than env vars? how?

Or some encrypted database/vault that the app can read from using - a shared secret provided as env var or on-disk config file.

Disagree, the best way to pass secrets is by using mount namespaces (systemd and docker do this under /run/secrets/) so that the can program can access the secrets as needed but they don't exist in the environment. The process is not complicated, many system already implement it. By keeping them out of ENV variables you no longer have to worry about the entire ENV getting written out during a crash or debugging and exposing the secrets.

How does a mounted secret (vault) protect against dumping secrets on crash or debugging?

The app still has it. It can dump it. It will dump it. Django for example (not a security best practice in itself, btw) will indeed dump ENV vars but will also dump its settings.

The solution to this problem lies not in how you get the secrets into the app, but in prohibiting them getting out of it. E.g. builds removing/stubbing tracing, dumping entirely. Or with proper logging and tracing layers that filter stuff.

There really is no difference, security wise, between logger.debug(system.env) and logger.debug(app.conf)

While this is a good feature, I fear most people aren't aware of git archive. Of the more basic CI tools I have looked at, I didn't notice any of them using git archive. Capistrano is the first I now know of that does this. Are there any others?

There is also export-subst that is also used by git archive to create an output similar to git describe directly in a file.

I'm not very familiar with deploy tools other than Capistrano, but I would think you also do not want to have the .git directory with your entire repo inside the working directory on the production server, so I assume some kind of "git export" must happen at some stage on most deploy tools? (Or perhaps they just rm -rf the .git directory?)

tangential, but deploys/builds that involve worktrees happen to neatly sidestep this since then .git is just a pointer to the real one. i use this to avoid having to otherwise prevent docker from wasting time reading the git info into the build context (especially important for latency if feeding local files into a remote image build)

The author makes a very common mistake of not reading the very first line of the documentation for .gitignore.

  A gitignore file specifies intentionally untracked files that Git should ignore. Files already tracked by Git are not affected; see the NOTES below for details.

You should never be putting "!.gitignore" in .gitignore. Just do `echo "*" > .gitignore; git add -f .gitignore`. Once a file is tracked any changes to it will be tracked without needing to use --force with git add.

The point of that line is to robustly survive a rename of the directory which won't be automatically tracked without that line. You have to read between the lines to see this: they complain about this problem with .gitkeep files.

Yeah, this. Plus a mistake from the article:

  $ echo '*\n!.gitignore' > build/.gitignore

The \n won't be interpreted specially by echo unless it gets the -e option.

Personally if I need a build directory I just have it mkdir itself in my Makefile and rm -rf it in `make clean`. With the article's scheme this would cause `git status` noise that a `/build/` line in a root .gitignore wouldn't. I'm not really sure there's a good tradeoff there.

> The \n won't be interpreted specially by echo unless it gets the -e option.

Author's probably using Zsh, which interprets them by default.

If you want any kind of non-trivial formatting, use the printf command, not echo.

If you have a project template or a tool that otherwise sets up a project but leaves it in the user's hands to create a git repo for it or commit the project into an existing repo, then it would be better for it to create a self-excepting .gitignore file than to have to instruct the user on special git commands to use later.

I think I'd prefer to have all ignores and un-ignores explicitly in the file and not have some of them defined implicitly because a file was added to tracking at some point.

But ignore files are only for untracked files anyway. Maybe you want them to specify what can be in the repo and what not, but this is not how Git works.

This is functionally the same. What do you mean by “you should never”? According to who?

What an arrogant take. This is preference. Don’t mistake it for correctness.

Why is this approach better than the author's?