Same for sops.

> The equivalent in vercel would be encrypted in the database (the encrypted '.env' file), with a decryption key in the backend

The encrypted .env file is actually committed to source code, and the decryption key is placed in Vercel's environment variables dashboard. The attacker only gained access to the latter here if using dotenvx so they can't get your secrets. Unless they also gained access to the codebase in which they have terabytes of data to go through and match up private keys from the database with encrypted .env files from the source code exfiltration - much more effort for attackers.

There is no silver bullet, but Dotenvx splits your secrets into two separate locations.

1. The private decryption key - which lives on Vercel in this example 2. The encrypted .env file which lives in your source code pushed to Vercel

Attackers only got access to the first (as far as I know was reported). So your secrets would be safe in this attack if using Dotenvx. (A private key is useless without its corresponding encrypted .env file. Attackers need both.)

The whitepaper goes into the problem and solution in more detail: https://dotenvx.com/whitepaper.pdf

I searched for solutions but wasn't happy with any so I created Vestauth.

Here's how it works:

It manages both the agent and the provider side. The agent with one command can set up a cryptographic identity avoiding human designed handshake mechanisms like OAuth. And on the provider side there is no management of API keys, no username and passwords, no users table even. Authentication works with a single line of code verifying this cryptographically.

Comments URL: https://news.ycombinator.com/item?id=47052501

Points: 11

# Comments: 1

to prevent this, use:

$ dotenvx ext precommit --install

Comments URL: https://news.ycombinator.com/item?id=40849922

Points: 11

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=40789353

Points: 354

# Comments: 206

* run anywhere (cross-platform) * multi-environment * encrypted envs

What do you think?

Comments URL: https://news.ycombinator.com/item?id=39347295

Points: 8

# Comments: 2

Inertia. This is everything. It takes effort to be around people unlike those currently around you.

We all have personal biases against the strata economically above us and below us. I think most of the individuals that move up economically are able to get beyond these biases for one reason or another. Otherwise, even the most hardworking individuals tend to self-sabotage when they start to feel out of place.

Anyone have one and like it? Or recommend a different dumb phone?

2. Start building. It will attract people. Don't go out and find them.

I was personally interested in HCQ before Trump ever tweeted it - turning it political. It was looking promising and still does.

After further personal study, I would like the conversation to continue.

[1] https://energycommerce.house.gov/sites/democrats.energycomme...

Comments URL: https://news.ycombinator.com/item?id=22553907

Points: 2

# Comments: 0

I'm willing to pay a 3rd party to streamline the process. My main priority is speed of acquisition.

My partner and I already hold US passports and are US citizens. Our children are also US citizens.

Comments URL: https://news.ycombinator.com/item?id=22522162

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=22324058

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=22197892

Points: 3

# Comments: 0

Email would only be allowed into my inbox if it was signed. Then, layer 2, it would only allow signed emails from senders whom I've accepted their public key.

A separate tab would show me all incoming request to accepts public keys (request to send email)

Now to opt-in to a marketing email I first accept their public key. To opt-out I delete their public key. Their email now goes to /dev/null.

Senders wouldn't have to re-implement unsub/subscribe, spammers would be /dev/nulled, and we could later add encryption on top of signing as a requirement.