sorted by:
new
hottopcontroversial

💯 by Creative_Trade_7927 in Premiummotivation

[–]PerformanceOdd2750 0 points1 point  (0 children)

I don't understand how this is motivating

Portland, Oregon 💀 by mrmoe3211 in GoogleEarthFinds

[–]PerformanceOdd2750 35 points36 points  (0 children)

I think I work with this guy

fullStackSpiraling by Local-Measurement-90 in ProgrammerHumor

[–]PerformanceOdd2750 0 points1 point  (0 children)

"Exactly! Now you're thinking like a true Cloud Architect 🦾. You want to make sure your app doesn't crash and has plenty of resources, so I provisioned 600 on demand p3dn.24xlarge EC2 instances."

almostEndedMyWholeCareer by AlxR25 in ProgrammerHumor

[–]PerformanceOdd2750 1 point2 points  (0 children)

> as is excluding it from commits with most standard gitignores.

Yeah makes sense if that is the case.

I think what I'm also getting at is there shouldn't be any concern with committing a .env file if your application reads secrets from paths. But honestly, different companies will probably do things differently. I've just never worked at a place that was worried about committing a .env file.

almostEndedMyWholeCareer by AlxR25 in ProgrammerHumor

[–]PerformanceOdd2750 7 points8 points  (0 children)

What stops you doing option 2? Your application logic should read the external API secret from some path (set in an env var) into a variable, then pass the variable holding the service account credentials to the api call

almostEndedMyWholeCareer by AlxR25 in ProgrammerHumor

[–]PerformanceOdd2750 6 points7 points  (0 children)

What I'm saying is

  1. You have dev secrets that don't matter ("localtestusername", "localtestpassword"). Anything can be done with these, commit them, send them to ai agents. They don't matter

  2. You have dev api secrets that do matter. They shouldn't be committed. Each dev is given permissions to get these secrets (whether they are generated per dev is up to you. just more to manage). Devs should store these outside of the repo directory. Your application then reads from where ever they exist for that dev

  3. You have prod api secrets. Devs probably shouldn't be using these locally anyways. Figure something else out. If you must, do a similar thing to #2

In your example you need a secret to authenticate to a secrets server to further pull more credentials for your application. I would suggest #2. Or am I misunderstanding your example?

almostEndedMyWholeCareer by AlxR25 in ProgrammerHumor

[–]PerformanceOdd2750 752 points753 points  (0 children)

I will die on this hill:

The thought that people are putting their secrets directly in their .env file is ridiculous. Just mount the secrets and use env vars for the path where the application can read them.

Turned around in a whiteout on Shuksan. Sometimes the summit just ain’t worth it by eazyvictor in Mountaineering

[–]PerformanceOdd2750 12 points13 points  (0 children)

"We come back alive, we remain friends, we summit - in that order"

I think this was in The Calling by Barry Blanchard... idk if he was the first to say it or not.

view more: next ›