Re: [RFC] Malicously tampering git metadata?

From: Stefan Beller <sbeller@google.com>
Date: Jan 22, 2016, 18:51 UTC
Message-ID: <CAGZ79kYOQ1sphdozTXGf+Q2n=kNpmGx1pvzLD5SHBqfhWDBA3Q@mail.gmail.com>
In-Reply-To: <20160122180007.GB28871@LykOS>

On Fri, Jan 22, 2016 at 10:00 AM, Santiago Torres <santiago@nyu.edu> wrote:

Show 29 quoted lines

> 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@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.