Jeff King <peff@xxxxxxxx> writes: > I think (1) is actually not all that interesting. The server already has > credentials for each user via ssh or http. So it knows who each pusher > is already. It can't relay that information cryptographically to a > client who fetches later, of course, but we are just talking about > whether or not to accept the push at this moment. > > But if you really did want to do that, it seems like a pre-receive hook > would be sufficient. I see two flaws in that reasoning. The server's authentication may be found not trustworthy for some reason long after commits hit the tree, and GPG signature made by the _pusher_ would assert the integrity. Also this will open the door to accept push over an unauthenticated connection and allowing only signed pushes. > For (2), you don't want to trust the server, so the user's > authentication to the server isn't enough. You want a cryptographic > chain leading back to the original pusher. But the server doesn't > actually need to see or understand that cryptographic chain for this > purpose. Exactly. That is why the signed push certificate is stored without the server doing anything funky, only to annotate the pushed commits in the notes tree---the fetchers can peek the notes and verify the GPG signature. But not _forcing_ that the push certificate be placed in a notes tree on the client side allows different server hosting sites to additionally do different things using that data. > The only issue I foresee is one of atomicity. The very initial thinking was to create a notes tree commit on the client side and push that along with what is pushed, but that approach has an inherent flaw of causing unnecessary collisions between two people who are pushing to unrelated branches, and that is why I decided to let the server side handle it. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html