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, this is a possible solution to this issue. The solution I'm proposing here wouldn't require a side channel though. As long as users' keys are not compromised, the BSL could either expire (raise an alarm), or force an irreconcileable fork attack --- the user who submited the changes won't be able to push until this change makes it through. > > > > > Furthermore, upon fetching, users with write access also push an entry > > indicating that they fetched the BSL. This avoids cases in which a malicious > > attacker keeps older versions of the BSL and withhold changes to other users. > > This would make it a "be malicious to all or none" thing? So the > attacker cannot attack > a single target IIUC. Yes, this is true. The ides is that any attack to a single target is easy to identify. > > I have a bad feeling about repository modifications upon fetching as > software distribution is a highly asymmetric workflow (number of > fetches is many orders of magnitudes larger than pushes), which may > not scale well? Yes, we were worried about the same ourselves. The upside is that, push and fetch entries in our scheme are also orders of magnitude smaller; fetch entries do not need to be signed and they can be as little as four bytes (they might be gc-able also). > (How would you serialize parallel fetches into the BSL?) Yes, this would imply that locking needs to be performed on the server side. It is important to note that fetch entries are only relevant for users to have write access (as only they are beneffited by them). For read-only fetches, like an automated build, this feature could be disabled. > > Thanks, > Stefan Thanks again! -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