{ "curator": {
name="Alice",
pubkey="...",
url="..."
},
"artifact": {
type="software",
name="Bob's App",
version="1.2.3",
published_file="bobapp-1.2.3.zip",
published_file_sha256="...",
published_file_url="..."
},
"statements": [
{ "type": "member_of_collection",
"name": "Recommended Apps" },
{ "type": "attestation",
"name": "Passed Audit FOO",
...audit info... }
]
}
Publish lists of these (maybe RSS-ish style?), with sort of browsable/searchable/app-store-ish UI.A key feature is verification. A user should be able to easily inspect the known "curator statements" for an app for the curators the subscribe to, and be able to run a "git fsck"-style validation that proves "this app really is the version that: passed the EFF's 'No Tracking' audit, is on reviewer Carol's 'Recommended' list, was rated "Teen" by the ESRB, and is on my friend Dave's 'Cool stuff you should try' list.
With such a system, anyone can perform an audit, and people can make their own decisions about what they want to trust.
I like this idea and think it would be a great addition to the development world.
[1] https://packages.debian.org/search?suite=default§ion=all...
The "underhanded C contest" [1] is a good example of this and something I like to point people to. From their about page:
>The Underhanded C Contest is an annual contest to write innocent-looking C code implementing malicious behavior. In this contest you must write C code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should perform some specific underhanded task that will not be detected by examining the source code.
If you go look around the hall of fame on that site, or just take a look at the contest winners, it's absolutely insane how subtle some of those exploits are. And shockingly (to me anyway) many of the exploits don't require C or use some quirk of C, they would work in many different languages, the first contest winner is a perfect example of that [2].
I can honestly say that for some of them, even if you told me there was an exploit in the code, I wouldn't be able to find them on my own.
And the scariest part is that almost all of the submissions to that contest have plausible deniability. They look like innocent bugs, typos, or small logic mistakes. Some even layer multiple small subtle changes which each on their own are completely fine but when all run together reveal big exploits.
That is an awesome site, thanks. Sadly the contest seems to have stopped in 2014.