Update channels are a way to provide easier testing of development versions, make it easier for unofficial builds to be distributed, and can also enhance build security by allowing for multiple signatures with offline keys.
## Channel definition A channel definition describes an update channel: both the user-facing information and where to fetch it. It also contains security measures like a revocation key, a list of trusted key IDs, and the number of valid signatures required to deploy. This number can be zero if trusting the insert key is deemed sufficient. It is a key-value list of: * name * user-facing description * USK * trusted key IDs * number of valid signatures from trusted keys required to deploy * channel revocation SSK Depending on whether the definition is distributed with a build, the name and description could either be literal or localization keys. Those distributed with builds are copied to an `update_channels` directory on the filesystem and used from there to allow for clearer operation and have it make more sense to drop additional channel definitions in the directory. Trusted keys are exciting because although the update insert key must exist on an online machine in some form in order to perform the insert, trusted keys could be kept on offline machines with signatures inserted separately. Provided this is implemented and used, compromising the insert key would no longer be sufficient to deploy a malicious update. The trusted key IDs are updated if the channel definition is signed with enough valid signatures under the existing definition. This means everything on a channel - not just the files like freenet.jar - require signatures. This file is /definition under the USK. ## Channel manifest A channel manifest describes the version offered by that edition of the channel. In order to be a channel an edition of the key must contain a manifest. This could allow inserting the manifest to be a deployment trigger once everything else is ready. A manifest could also contain a skip marker if an edition is found to be bad after its artifacts are inserted, or if artifacts are not offered because the USK in the definition is changing. It is a key-value list of: * build string * skip boolean This file is /manifest under the USK. ## Artifacts Update channels provide some number of artifacts to be used. Depending on how reliable archive manifests are - this [0] gives me reservations - it could just be the list of files in the container. These are be the filenames used to deploy; the update manager matches filenames and reacts intelligently. Things like this are already available: * freenet.jar * freenet_windows_installer.exe * freenet_unix_installer.jar * release_notes.txt * developer_details.txt This expands to: * freenet.jar_source * freenet_windows_installer.exe_source * freenet_unix_installer.jar_source The updater could warn that non-txt artifacts without _source counterparts might not be able to be audited. Signatures are provided in the form of _0xKeyID.sig. Plugins could also query the update channel's artifacts. A plugin could fetch an update channel's packages and expose them over a port on the local interface for use with package systems like apt. This could be bootstrapped like Google Chrome which (with opt-out) adds its repository when installed. ## Artifact requirements Java artifacts can have minimum Java version requirements. From what I've been able to find Java .class files do not have standardized "target version" information, so this would need to be in the jar MANIFEST. With the upcoming Java 7 requirement implementing enough to get to a minimum Java version in the freenet.jar manifest seems like a useful and practical start to realizing these update channels. Without update channels, changes like this require changes to the update key. Currently maintaining a non-breaking upgrade path requires doing it anyway, but after that it should remove the need to do so except to update the crypto the key uses. This is in the jar itself instead of the channel manifest because packaged versions can already express these requirements. The jar need only add minimum version information if it will be used to update standalone installations. Notably Windows does not (currently) have packages, so official channels will certainly continue to provide a freenet.jar, but this is still a design consideration. # Build infrastructure The goal is that publishing updates is easier - both for official project things and unofficial builds. The guiding philosophy is to automate as much as practical and only require human interaction for confirmation or sanity checks. This means doing things like fetching an updated Oracle Java installer as part of the Windows installer build, and checking a change's legitimacy with a human. This can be centered around progressing artifacts through stages: build, sign, upload and insert. This is where I'd like to avoid re-implementing existing dependency ordering and resolution. What existing tools would make this easier, or provide most or all of it? Vagrant could be applicable; is ant sufficient for dependencies? Make? Gradle? CMake? Code and jar signing are part of the products themselves, and unlike PGP signatures require special support to be done on a separate offline system. The Freenet jar must be built and code-signed before the installers (which contain the jar) can be built and code-signed, so either offline signing must be done with multiple transfers or the build must be done offline as well. Something like Vagrant to set up a development or build environment would make this easier. # Closing thoughts This is a large idea, and it's not complete, but I'm excited about its potential and I'm interested in implementing at least the minimum Java version manifest subset of it for build 1466. Thoughts? - Steve [0] https://github.com/freenet/fred/pull/282
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
