Re: Weird shallow-tree conversion state, and branches of shallow trees

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:

quoted

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@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85