Yea, I'm thinking about cases similar to HTTP parameter pollution, and what the program expectations are. You'd be right to argue environment variables should not be user controlled. :)
Will need to double check some machines to make sure these two don't bite me:
On Unix systems the environment variables SSL_CERT_FILE and SSL_CERT_DIR can now be used to override the system default locations for the SSL certificate file and SSL certificate files directory, respectively.
The os/exec package now prevents child processes from being created with any duplicate environment variables. If Cmd.Env contains duplicate environment keys, only the last value in the slice for each duplicate key is used.
That could be a decent hack to get started. Ideally, I'd like for it to be a feature of hackerone et al, assuming security@ as a service providers become the point of interaction with the external security community.
I would love a Marauder's Map for bug bounty programs: Show me who is working on what, where they're finding bugs, and help me identify where I can most efficiently spend my time. Lots of 'feel bads' if I report a bug that's already been reported, and thus don't get a payout.
You've got a point there, but I'd ask why not remove the packages that aren't being used? Here's some of the raw data about which system libraries are lagging in security patches:
We'd love to be at the point where Patchwork notifications are ahead of public releases, and get you patched before the vulnerability is widely exploited. In fact, one of the crazy ideas we've been kicking around is how to detect 0days without installing an agent on production machines.
