Research: malicious content in an index without a server

[Maximilian-Nesslauer]

Closes #69

The page reports what CKAN, Thunderstore, Modrinth, CurseForge and Factorio do about malicious code, what a free automated check could reach, and what belongs to the client instead.
It concludes that the gap is a disclosure problem and not a tooling problem, and recommends a narrow RFC that states what a green check proves and what it does not, with no change to the merge rule.

Most of this was done using LLMs.

[LaurensDeV]

Automated mod screening for the KSA content index.pdf

I did some research with Claude into a possible way to do automated security screening (without any costs)

[Maximilian-Nesslauer]

@LaurensDeV thanks a lot for the proposal, I finally got to read it properly.

I think we are closer than the two documents look.
The research page mostly argues against a scanner that blocks or gives a verdict, and your design only blocks on withheld.

And we both end up at the same idea to show what changed between two releases.

The research wanted to do that in Borea, but you are right that the index is the better place, because then the information exists before the download and every client sees the same thing.

You also answer one of the research's main objections without saying so.
The tricks that hide code from a reference list (Assembly.Load(byte[]), GetDelegateForFunctionPointer, an obfuscator) are themselves in your table, so a hijacked update still shows up as something new in the diff.

A real example from my own mod is that AFC 0.8.0 added native libraries (clarabel_c.dll, scs.dll and the Linux .so files) for the new guidance solvers, plus Assembly.LoadFrom and Reflection.Emit.
With your rules that update gets review with new native-code and dynamic-load, which is correct, but it is a completely normal update.
So the wording will matter a lot: something like "This update adds a native library. If you did not expect that, ask the author in the forums thread" rather than an alarm.

but to be honest who would care if i added an native libarary to my mod? I think we should make it even less strict.

There are three things I would change:

• No automatic withheld for now. The VirusTotal public API terms forbid "business workflows that do not contribute new files", and it is unclear whether we count. Loaders are also classic false positives (BepInEx's winhttp.dll got flagged), and a withheld StarMap release would break every code mod at once. I would turn a ClamAV hit into review plus an urgent issue, and let a steward delist it.
• No clean verdict. You write yourself that we should never call a release safe, and clean sounds exactly like that. I would publish the facts and what is new since the last release, and no verdict at all.
• Keep the list small. Hardly anyone reads permission lists (one study found 17 percent look at them and 3 percent understand them). So on the mod page just "runs code in the game", on an update "This update adds: ...", and the full list folded away for people who want it.

I merged #70 as research and updated its numbers to today.

As a next step I would do your shadow run over all current listings first, so we know how often each rule actually fires, and then one RFC that combines the disclosure from #70 with your per-release facts and the diff, without withheld and without a verdict.

Would you like to write that RFC and do the test? :)