GrapheneOS imposes a set of restrictions on how generative AI can be used in our project and community. It isn't forbidden but rather we imposed rules based on actual issues.
Posts made in our forum, chat rooms, issue tracker and the rest of our project must be written by humans. There's an exception from this rule for translation and accessibility features. That means commit messages, pull request messages, bug reports and feature requests are expected to be written by humans, not a machine.
Replying to @GrapheneOS@grapheneos.social
@GrapheneOS for an OS project that refused porting to non-PIxel h/w for so long b/c other platforms didn't meet security reqs, this pro-LLM stance is ludicrous.
~all bugs found by LLMs can likely be found by other methods using the same-or-less compute resources, especially w/ the human effort "babysitting" the LLMs to ensure they don't go off the rails.
there just aren't billionaire fascists subsidizing that compute, be honest about it.
stop covering + doing PR-by-action for LLM fascists
Replying to @elle@weathered-steel.social
@GrapheneOS to clarify the other methods I'm referring to are symbolic analysis, fuzzing, and static analysis tools.
I think this post from @david_chisnall puts it very well: https://infosec.exchange/@david_chisnall/117183568828323924
David Chisnall (*Now with 50% more sarcasm!*)@david_chisnall@infosec.exchangeRE: https://beige.party/@gildilinie/117182364841041560
This is really key for a lot of ‘AI’ success stories. The baseline is always not trying a thing. It’s never trying a different technique and allocating the same amount of compute power specialised for the task to it.
Vulnerability discovery is like this. We currently limit static analysers for C/C++ to a single compilation unit because the memory and CPU requirements for that work on a laptop or cheap cloud VM, whereas doing cross-compilation-unit analysis can require hundreds of GiBs of RAM and many hours of CPU time. Yet, when people are talking about the LLMs doing vulnerability discovery, they’re comparing against the run-on-a-cheap-laptop version, not the costs-as-much-to-run-as-LLM-inference model.
If you were willing to throw a huge amount of compute at static analysis, then generate coverage points for the paths in the predicted bug and use guided fuzzing techniques to create a reduced test case, I suspect you’d get higher success rates than LLM-based approaches. But VCs are willing to throw tens of thousands of dollars of compute per bug at the LLM approach because it makes the companies that they’ve invested in look good.