Hans Jerry Illikainen <hji@xxxxxxxxxxxx> writes: >> It almost makes me suspect that what you are trying to do with the >> "verification upon cloning" may be much better done as a "verify the >> tree for trustworthyness before checking it out to the working tree" >> mechanism, where the trustworthyness of a tree-ish object may be >> defined (and possibly made customizable by the policy of the project >> the user is working on) like so: >> >> - A tree is trustworthy if it is the tree of a trustworthy commit. >> >> - A commit is trustworthy if >> >> . it carries a trusted signature, or >> . it is pointed by a tag that carries a trusted signature, or >> . it is reachable from a trustworthy commit. >> >> Now, it is prohibitively expensive to compute the trusttworthiness >> of a tree, defined like the above, when checking it out, UNLESS you >> force each and every commit to carry a trusted signature, which is >> not necessarily practical in the real world. > > Even though you mention that it's computationally expensive, I kind of > like this approach. It seems generalized enough that it doesn't need to > be tied to a single operation like 'clone'. Well, I don't ;-) But even if you are not signing each and every commit, it may be possible that the reachability information kept in the commit-graph may help reduce the cost of the computation. We'd probably need a way to memoise which tags and commits have already been verified earlier for trustworthiness for the scheme to work. > Wouldn't that still forgo signature verification when doing something > like: > > $ git fetch > $ git checkout -b foo origin/branch-with-previously-unseen-commits > > unless either fetch or checkout is equipped with signature verification? Yes, but I was assuming that "fetch", as an underlying mechanism for "pull" would be what you'd teach the verification. > Also, in case of a revoked key, this approach would require that tags > signed with that key be deleted on origin. I am not sure if I follow. An object that was signed back when a key was OK and then the key gets revoked later---what should happen to the trustworthiness of that object? Another object that was obtained from elsewhere was verified to be trustworthy, but later we found out that the key we thought was trusted was already revoked--- what should happen to the trustworthiness of that object? In either case, I think it is an unrelated matter if the tag object should be removed either here or at the origin. When spread *now*, the key that was used to sign that tag object is known to have been revoked, so while it is of no use to convey trustworthiness, if the upstream project chooses to keep the tag (perhaps while re-issuing a new version of the tag that points at the same object but signed with a different key), that is perfectly fine, I would say. > Maybe that's to be > considered best practice anyway, but distro maintainers might not > appreciate disappearing release tags. I think that is best left as a policy decision for each project, and we are not in the business of removing objects---we just should give them tools to determine what key was used to sign an object, GPG or whatever signing and key management infrastructure the projects chooses to use gives them tools to decide if the key is what the project trusts, and we give them tools to remove tags the project finds unwanted. Combining the tools according to the policy decision the project makes is outside the scope of what we do here.
