This meme was brought to you by the PyPI Director of Infrastructure who accidentally hardcoded credentials - which could have resulted in compromissing the entire core Python ecosystem.

you are viewing a single comment's thread
view the rest of the comments

[–] dan@upvote.au 52 points 1 month ago* (last edited 1 month ago) (12 children)

At my workplace, we use the string @nocommit to designate code that shouldn't be checked in. Usually in a comment:

// @nocommit temporary for testing
apiKey = 'blah';
// apiKey = getKeyFromKeychain();

but it can be anywhere in the file.

There's a lint rule that looks for @nocommit in all modified files. It shows a lint error in dev and in our code review / build system, and commits that contain @nocommit anywhere are completely blocked from being merged.

(the code in the lint rule does something like "@no"+"commit" to avoid triggering itself)

[–] cypherpunks@lemmy.ml 9 points 1 month ago (2 children)

At my workplace, we use the string @nocommit to designate code that shouldn’t be checked in

That approach seems useful but it wouldn't have prevented the PyPI incident OP links to: the access token was temporarily entered in a .py python source file, but it was not committed to git. The leak was via .pyc compiled python files which made it into a published docker build.

[–] OhNoMoreLemmy@lemmy.ml 1 points 1 month ago (1 children)

Yeah, but a combination of this approach, and adding all compiled file types including .pyc to .gitignore would fix it.

[–] cypherpunks@lemmy.ml 6 points 1 month ago

adding all compiled file types including .pyc to .gitignore would fix it

But in this case they didn't accidentally put the token in git; the place where they forgot to put *.pyc was .dockerignore.

load more comments (9 replies)