On Mon, 2014-09-15 at 23:42 -0400, Steve Dougherty wrote: > 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
I think it's the wrong-layer... You really need a new key-type to do revocation/multi-signature properly. It doesn't have to be over-engineered (programmable) but it has to be consistent... think about TOCTOU Moreover, I think that you should start by a threat model: who are the players/actors? What do you expect them to be able/unable to do? ... and clarify who holds which key in the above; I've re-read it several times but it's still confusing to me. For instance: who holds the insert-key of the USK? Is it okay for them to DoS the mechanism? What if they "fast-forward" (inserting enough editions) a revocation to ensure the client layer skips the edition they want to ban? NextGen$
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
