On Fri, Jan 22, 2016 at 10:00 AM, Santiago Torres <santi...@nyu.edu> wrote: > On Thu, Jan 14, 2016 at 09:21:28AM -0800, Stefan Beller wrote: >> On Thu, Jan 14, 2016 at 9:16 AM, Santiago Torres <santi...@nyu.edu> wrote: >> > Hello Stefan, thanks for your feedback again. >> > >> >> This is what push certs ought to solve already? >> > >> > Yes, they aim to solve the same issue. Unfortunately, push certificates >> > don't solve all posible scenarios of metadata manipulation (e.g., a >> > malicious server changing branch pointers to trick a user into merging >> > unwanted changes). >> > >> >> AFAIU the main issue with untrustworthy servers is holding back the >> >> latest push. >> >> As Ted said, usually there is problem in the code and then the fix is >> >> pushed, >> >> but the malicious server would not advertise the update, but deliver the >> >> old >> >> unfixed version. >> >> >> >> This attack cannot be mitigated by having either a side channel (email >> >> announcements) >> >> or time outs (state is only good if push cert is newer than <amount of >> >> time>, but this may >> >> require empty pushes) >> >> >> > >> > I'm sorry, did you mean to say "can"? >> >> Yes, formulating that sentence took a while and I did not proofread it. > > Sorry, Stefan. I didn't mean to come off as rude; I just wanted to make > sure I understood correctly what you were proposing.
Not at all, I just made a typo. :) > > Do you have any further insight? I think that, besides the supporting > multiple workflows, maybe synchronizing concurrent fetches might be an > issue to our solution. I did not think further about any issues there. Thanks, Stefan > > Thanks a lot! > -Santiago. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
