> ... I run a simple scan ... against all the 74 real looking GitHub user tokens ... and discovered that 6 of them are actually valid.
> ... only 2 of them actually have bio and email, but one of them (a c/c++ developer) has a repo with 3.4k stars ...
> I obviously couldn’t verify all the secrets. From most of them I’ll probably be banned, so I stooped here.
As an alternative to manually testing the credentials (and risking bans), I wonder if any organisations would agree to test the credentials for you if you sent them a list of suspected leaks. If the organisation doesn't tell you which ones were valid (and takes responsibility for revoking/notifying), I don't see much room for abuse. Might be hard to convince the organisation of that though!
It is perfectly reasonable and consistent for one thread to set an environment variable while other threads are reading different environment variables.
Sure, some applications might require custom higher-level synchronisation, but it's still important for getenv/setenv to be thread-safe (i.e. not crash):
- The race might be irrelevant (e.g. simultaneous calls that access different variables are fine).
- The application author might not have complete control over all calls to getenv/setenv (e.g. if using a third-party library).
In Chrome you can inspect your closure (as you clarified in https://news.ycombinator.com/item?id=38226743#38231705) using the "Watch" pane, and then look at its "[[Scopes]]" pseudo-property. I don't think there is a way in Firefox.
