@jacob agreed, they aren't high value for community run open source. Well resourced commercial entities can justify it. The Googles, Apples, and Microsofts have TM bearing Brands and Contractual Obligations to maintain.

Anyone trying to collectively organize bounties for OSS projects (is this what hackerone was doing?) is already on shaky ground if they don't provide expertise based filtering of reports seeking a bounty as part of that so that only actually worthy ones make it through to the volunteers.

At the end of the day, a security bug bounty program is a way to underpay a tiny fraction of gig-workers competing for work. In direct financial competition with their alt-gig-reward system of zero day exploit markets and state sponsored equivalent employers.

@nedbat Soo much test flakiness due to lru_cache decorators being added to codebases over time. Much hunting down caches and plumbing clears into fixtures ensues. I think in hindsight offering functools.lru_cache as a decorator was a bit too magical of a code pattern. I'd like anything cached to require a _cached suffix on its name. But that only solves highlighting immediate use of APIs where the name is seen. Most code involves transitive calls.

Use of a cache is effectively a taint that'd be nice to propagate upwards - it sounds like `pytest-antilru` effectively attempts this?! nice! - so that any given API use could be introspected to understand what caches code touched and how to clear them.

Runtime tracking such as the above is neat and practical. But from a static analysis PoV. It's "just" metadata on the data flow graph. I wonder what other design mistakes could be prevented via analysis if that were readily available without running the code.