John Sullivan <jo...@fsf.org> writes: >> Nick <liberationt...@njw.me.uk> writes: >>>The wonderful F-Droid already does this, as pointed out in the >>>article. So it doesn't seem like a proposal so much as an >>>explanation of why it's important. >> >> F-Droid does a lot of this. I couldn't find a standard way to get the >> exact source snapshot a particular app's build comes, nor what the build >> parameters were, although via the web site the app pages do give release >> numbers. They're hard at work on deterministic builds now, apparently, >> and I would guess that some of these essentially UI fixes will happen >> along with that. > >That info is in the server metadata file for the app (for example the >git tag for the source that was used to build the app, and the build >parameters). Probably just needs to be exposed in the UI.
Thanks, John; agreed. I saw your mail just after I filed https://gitlab.com/fdroid/fdroiddata/issues/76 about this very question. By the way, I've also updated the post at https://openitp.org/circumvention-tech/app-stores-and-trustable-code.html to give F-Droid some more credit -- I think I relied too much on those UI routes existing, when that's not necessarily a reliable indicator of what F-Droid is doing on the back end. Had I talked to you or someone else at F-Droid first, though, I could have discovered just how much of the proposal was already implemented there! Sorry not to have done so. In a private conversation with Brian Behlendorf, he pointed out that there's a more general version proposal that should really be the goal. I'd like to do a second piece on his proposal, but as I'm not sure I'll get to it soon, I'm posting it here just so it has some circulation. Quoting him (inner text is his, outer text is my reaction): Karl Fogel wrote: > Brian Behlendorf wrote: >> >> If we're proposing ideas for phone OS and app store folks, we should >> start from first principles: >> >> * End users should be able to trust that the code installed on their >> system came as intended by the app author and as verified by the App >> Store against their policies. >> >> * End users should be able to modify and recompile Open Source apps, >> and if they redistribute those modified works (whether direct or >> though app stores again), downstream recipients should be able to use >> the same means to verify the modified works. >> >> This suggests to me the following process: >> >> * App developer builds install image, generates a checksum, optionally >> signs it with a private pubkey. >> >> * App developer sends install image, source code to app store, who >> perform their acceptance tests, build their own copy of the install >> image, then validate that both install images checksum to the same >> number. >> >> * App developer publishes image name, version number, checksum, and >> signature to a well-known location on their own SSL website (the same >> way they did for robots.txt - call it appchecksums.txt) so that their >> identity can be tied to a registered domain name and SSL cert. >> >> * App store publishes the install image, checksum, and URL to their >> repository, making it available to all downloaders. If it's an Open >> Source package they also provide a clear URL to the specific revision >> of the code that builds the install image, as well as the OSI-approved >> license used. >> >> * App store client on the phone is asked to install the app. First >> they download the package, as well as the corresponding >> appchecksums.txt file from the developer's own website. If they don't >> match, error out or prompt for exception handling. If they do, feel >> free to install. >> >> * App store client on the phone provides a means to download the >> source code if the app developer wishes to allow it - and it points to >> the same bundle of code that the app store used to verify the build. >> >> This gets the app store out of the business of generating their own >> builds from a public tree (they still build, but only what the app >> developer asks them to build). It also removes the historic >> dependency on a public tree, just in case the project is closed or the >> code hosting service disappears. >> >> Thoughts? > > My thought is: spot-on. > > I had meant that the app store should host a copy (e.g., a git or hg > clone) of every source tree it builds; in any case, many other people > will have copies. The app store just needs to publish the snapshot > checksum -- the content ID checksum -- and the distributed archive of > the Internet can take it from there. So yes, the store should host a > copy of the tree, and in the case of open source apps, that copy happens > to match one or more other copies found out on the Net anyway. The > commit ID is the main thing. > > But your overall idea: that the app store can still usefully prove to > the *author* as well as to the public that what's being shipped matches > the intended code, seems really good to me, and is a generalization that > applies to more than just open source trees. Best, -K -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
