undefined | Better HN

0 pointsketch1y ago0 comments

The article has answers

> It seems that the original author

> - Briefly added the authorization token to their source code

> - Ran the source code (Python script), which got compiled into a .pyc binary with the auth token

> - Removed the authorization token from the source code, but didn’t clean the .pyc

> - Pushed both the clean source code and the unclean .pyc binary into the docker image

0 comments

10 comments · 4 top-level

bheadmaster1y ago· 4 in thread

> - Pushed both the clean source code and the unclean .pyc binary into the docker image

Oof.

Honestly, I can't blame the guy for a mistake like this, it's just so easy to make. But then again, deploying images built on a development laptop is generally an error-prone activity. This is why build and deployment servers exist.

sitkack1y ago

Why does one person have admin on all those repos?

Why is Python still running any classic access tokens?

Why is the access token EVER in the source code?

What other stuff is “running on their laptop”?

No pass!

People with access to the repos shouldn’t also have access to push bits to the world. It puts those people with that access in grave physical danger.

Edit, https://blog.pypi.org/posts/2024-07-08-incident-report-leake...

This token has been in the wild for 15 months! The JFrog post cannot say that disaster was averted because we do not know.

belter1y ago

> This token has been in the wild for 15 months! The JFrog post cannot say that disaster was averted because we do not know.

"Binary secret scanning helped us prevent (what might have been) the worst supply chain attack you can imagine"

The above comment from them sounds as weird, as the whole ecosystem security based out of a developer laptop...

andrewSC1y ago

This is the correct set of questions to be asking. I’m a little more than surprised there aren’t some defined processes and automation around high viz workflows/stuff like this. When are people going to take cybersec and opsec seriously? Esp. In big projects?

2 more replies

hirako20001y ago

Exactly. More than one bad practice in there. note the secret was never in the repo though. Only in the container image.

1 more reply

js21y ago· 2 in thread

It's probably a good idea for Python developers to disable pyc files in their development environments with PYTHONDONTWRITEBYTECODE=1 in their shell profile, dotenv file, or otherwise. In this case, perhaps it should also be set in the Dockerfile along with entries in .dockerignore to exclude pyc files and __pycache__ directories.

hirako20001y ago

Or just have a good `.dockerignore`

When I create a project now I automatically place a catch all ignore for both git and docker.

Binaries, .env files have a far lower chance to end up tracked in a repo or copied over to a container image.

zihotki1y ago

Or just use CI/CD on a build server to create release artifacts and a proper security setup (no PAT's, or use short living one)

playingalong1y ago

That's why I consider writing any secrets into code base a security malpractice. Just for a minute or I am sure I won't commit it, is not an excuse.

Use environment variables or better yet - store the secret on the disk outside of your repo and make the code read it. It's a one liner in plenty of languages.

sans_souse1y ago

Great reply thank you. This is totally relatable even to me, as a non-coder. He essentially crafted a shortcut to bypass redundancies, but with the foresight to go back and remove what he thought were all references to that shortcut. He was unaware or forgot there was one last reference and BOOM

j / k navigate · click thread line to collapse

0 comments

10 comments · 4 top-level

bheadmaster1y ago· 4 in thread

> - Pushed both the clean source code and the unclean .pyc binary into the docker image

Oof.

sitkack1y ago

Why does one person have admin on all those repos?

Why is Python still running any classic access tokens?

Why is the access token EVER in the source code?

What other stuff is “running on their laptop”?

No pass!

People with access to the repos shouldn’t also have access to push bits to the world. It puts those people with that access in grave physical danger.

Edit, https://blog.pypi.org/posts/2024-07-08-incident-report-leake...

This token has been in the wild for 15 months! The JFrog post cannot say that disaster was averted because we do not know.

belter1y ago

> This token has been in the wild for 15 months! The JFrog post cannot say that disaster was averted because we do not know.

"Binary secret scanning helped us prevent (what might have been) the worst supply chain attack you can imagine"

The above comment from them sounds as weird, as the whole ecosystem security based out of a developer laptop...

andrewSC1y ago

2 more replies

hirako20001y ago

Exactly. More than one bad practice in there. note the secret was never in the repo though. Only in the container image.

1 more reply

js21y ago· 2 in thread

hirako20001y ago

Or just have a good `.dockerignore`

When I create a project now I automatically place a catch all ignore for both git and docker.

Binaries, .env files have a far lower chance to end up tracked in a repo or copied over to a container image.

zihotki1y ago

Or just use CI/CD on a build server to create release artifacts and a proper security setup (no PAT's, or use short living one)

playingalong1y ago

That's why I consider writing any secrets into code base a security malpractice. Just for a minute or I am sure I won't commit it, is not an excuse.

Use environment variables or better yet - store the secret on the disk outside of your repo and make the code read it. It's a one liner in plenty of languages.

sans_souse1y ago

j / k navigate · click thread line to collapse