Subject: Re: [RFC] Malicously tampering git metadata?

From: Santiago Torres <[email-masked]>
Date: Fri, 22 Jan 2016 13:00:08 -0500

On Thu, Jan 14, 2016 at 09:21:28AM -0800, Stefan Beller wrote:
> On Thu, Jan 14, 2016 at 9:16 AM, Santiago Torres <[email-masked]> 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.