On Sun, Apr 15, 2007 at 11:01:03PM -0400, Theodore Tso wrote: > On Sun, Apr 15, 2007 at 07:17:29PM -0700, Robin H. Johnson wrote: > > Nobody has addressed the single problem that I have with adding it when > > it's leaving the environment, and that's still of paramount concern to > > me. Simply put, there is a conflict between being able to add revision > > information of stuff leaving the environment, and those additions > > breaking previous checksums (which may be digitally signed, and thus > > breaking the signatures). > > > > I'll reduce it further from my previous example. > > > > 1. Developer commits some change to file A. > > 2. The checksum file is updated because A changed (the checksum file > > explicitly does not contain keywords). > > 3. Developer signs the checksum file, and commits it. > > > > If during the export process (which is undertaken elsewhere, by a > > different person or script), file A now has an expansion applied to it, > > you break the checksum file, which you CANNOT redo, because you lose the > > developer's digital signature on the checksum file! > > Simple, the release engineer runs a script which exports the tree, > expanding any keywords and updating the checksum file as necessary, > and then the release engineer signs the checksum file! As has already > been stated, if this doesn't work, you probably don't have a well > defined and formal release process. The checksum file (named Manifest) we are talking about is for a single subdirectory, and is signed as proof that it was not modified between the developer and submission to the tree. As I wrote originally, this is the Gentoo distribution tree, it's NOT delineated by well-defined releases in the conventional sense. There are presently 11571 Manifest files in the tree. Our tools will not allow commits to each package of things that radically break the package (semantic correctness and some automatic validation, but thinkos can still get through the checks). The 'release' process for the tree runs automatically every 30 minutes, and consists of more validation checks, updating a cache directory, producing a signed master Manifest [1] and publishing everything to the rsync servers. > Just because a developer has signed a checksum doesn't mean that the > tree is suitable for release; that's the job of the release engineer > to confirm, probably after running a set of regression test suites. > And in fact, with git, it's pointless for the developer to sign a > checksum file and then commit it, since git is already maintaining > checksums as an integral part of how revisions are named. The entire point of the checksums is to allow end users to validate content that has been exported, with only minimal tools. [1] The master Manifest stage is only in production for the tree tarballs, and NOT in the rsync production at the moment, but will be within the next month. It exists solely to allow the detection of compromised mirrors. -- Robin Hugh Johnson Gentoo Linux Developer & Council Member E-Mail : robbat2@xxxxxxxxxx GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Attachment:
pgp4QNfRe3v0r.pgp
Description: PGP signature