[imrelaxed]

It would be awesome if there was a volunteer financed code review group to review popular open source projects. I think I’m not the only one who would happily donate money to such a group for code reviews for various OSS projects. Initial code reviews would require a lot of effort, unless somehow automated, but after that it would be fairly easy to monitor and verify updates and changes to the code.

[dhimes]

I wonder if EFF or somebody could issue a "verified" badge that apps could apply for, with a small fee to finance the devs doing the audits?

[pdkl95]

A prerequisite of that type of badge that I really wish existed is a standardized, interoperable protocol for curation. Instead of trying to solve the problem of malicious software with a walled garden app store, anyone should be able to publish their own curated list of software (or any type of project?). The core component is a crypto-signed statement like:

    { "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.

[Corrado]

Would this verification feature be similar to how keybase works? You post a "fingerprint" message to a host of public web sites (ie. Twitter, Facebook, GitHub Gist, etc.) that anyone use to verify your identity. The idea is that even if someone tried to impersonate you, they would have to take over all of your accounts in order to do so.

I like this idea and think it would be a great addition to the development world.

[voicedYoda]

I love this idea and could get behind contributing.

[sergeykish]

Maybe on top of existing practice? Debian packages some addons [1], I don't know do they perform audit [2] on them.

[1] https://packages.debian.org/search?suite=default&section=all...

[2] https://www.debian.org/security/audit/auditing

[raxxorrax]

Would be good training for apprentices too. Reading code is probably one of the best ways to learn. Granted, it could include a sophisticated and obfuscated backdoor, but I think it would still be caught.

[Klathmon]

I wouldn't be so sure that it's an inevitability that things would be caught.

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.

[1] http://underhanded-c.org/

[2] http://underhanded-c.org/_page_id_14.html

[raxxorrax]

Ok, those might indeed not be found. Only fair that they could take something from my wallet then.

That is an awesome site, thanks. Sadly the contest seems to have stopped in 2014.