Hi Stefan, thanks for the insight. > This is what push certificates ought to solve. > The server records all pushes and its signed certificates of pushes > and by the difference of the > refs (either in packed refs or as a loose ref) to the push certificate > this tampering of > the server can be detected. Is there any specification about push certificates? I would like to read about them, but I don't seem to find documentation anywhere. Are they a part of git's specification? > > The push certs can however not be obtained via Git itself (they are > just stored on the > server for now for later inspection or similar), because to be really > sure the client would > need to learn about these push certificates out of band. I was thinking that an in-band solution could be integrated as long as we assume a compromise would result in an complete (unreconcilable) fork attack; fork attacks aren't subtle and could be detected easily. > > The model there would be: > * A vulnerable piece of software exists. > * It get's fixed (and the fix is pushed with a signed push) > * the MITM server doesn't show the fix (show the code from before fix) nor > the push certificate thereof > * client still pulls vulnerable code Yes, this is a possible attack vector. However, a server could also present a branch pointer as different (e.g., point an experimental branch to an unsigned v1.1 tag). This has other implications, as the code is pushed/pulled from upstream, it just goes somewhere different. > > This model shows the distribution of push certs via the server itself may not be > optimal. Yes, it might not be optimal, but it could provide protection against the attack I just described, for more complex attacks might not be so subtle. Adding to this, developers likely coordinate their efforts through other means (sic), so the lack of a push certificate (withheld by a server) could raise some yellow flags. We've made a proof of concept of such tool (in-bandh push certificates), and would like to share the basic design of it here. However, it follows our threat model: a compromised server that can't introduce malicious code (thanks to commit signing), but can modify branch pointers and other unsigned metadata to alter the repository's state. > > Thanks for researching on Git, Thanks for working in such a great tool :) -Santiago > Stefan -- 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