On Thu, Jan 14, 2016 at 09:21:28AM -0800, Stefan Beller wrote: > On Thu, Jan 14, 2016 at 9:16 AM, Santiago Torres <santiago@xxxxxxx> 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. 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. Thanks a lot! -Santiago. -- 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