Hey everyone, I felt like I should introduce myself since this is my first patch on the git mailing list (or any mailing list actually) :D I am Shikher[1], currently in my 4th year undergrad at IIT Kanpur. This summer I was lucky enough to intern at NYU Secure Systems Lab[2] mentored by Santiago. We looked into how signed pushes work and how we can use them to increase the security of git. We encountered a strange error in tests which resulted in a patch[3] and I wrote a python script to verify push certificates[4]. I was pretty surprised to not find any push certificate on the remote repo after I did a signed push, hence this RFC. Anyway this is my first time trying to contribute to a large OSS so forgive me if I make any noob mistakes. Thanks Shikher Verma [1]http://shikherverma.com/ [2]https://ssl.engineering.nyu.edu/ [3]https://public-inbox.org/git/20170707220159.12752-1-santiago@xxxxxxx/ [4]https://gist.github.com/ShikherVerma/9204060b545c00597e7ad9b694cfeb9c On Wed, Sep 06, 2017 at 03:09:11PM +0530, Shikher Verma wrote: > Currently, git only stores push certificates if there is a receive hook > present. This may violate the principle of least surprise (e.g., I > pushed with --signed, and I don't see anything in upstream). > Additionally, push certificates could be more versatile if they are not > tightly bound to git hooks. Finally, it would be useful to verify the > signed pushes at later points of time with ease. > > A named ref is added for ease of access/tooling around push > certificates. If the last push was signed, ref/PUSH_CERT stores the > ref of the latest push cert otherwise it is empty. > > Sending patches as RFC since the documentation would have to be > updated and git gc might have to be patched to not garbage collect > the latest push certificate. > > This patch applies on master (3ec7d702a) > > Shikher Verma (2): > Always write push cert to disk > Store latest push cert ref in PUSH_CERT > > builtin/receive-pack.c | 25 ++++++++++++++++++++----- > path.c | 1 + > path.h | 1 + > 3 files changed, 22 insertions(+), 5 deletions(-) > > -- > 2.14.1 >