Re: [RFC] Malicously tampering git metadata?
- From
Santiago Torres <santiago@nyu.edu>
- Date
- Jan 22, 2016, 18:00 UTC
- Message-ID
- <20160122180007.GB28871@LykOS>
- In-Reply-To
- <CAGZ79ka51e+-24RyMgUGAOUkBYXxnWZb8Pg7vrgjGHvvWU770Q@mail.gmail.com>
On Thu, Jan 14, 2016 at 09:21:28AM -0800, Stefan Beller wrote:
Show 25 quoted lines
> 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.
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.