On Tue, Feb 5, 2013 at 5:29 PM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: > Hiderefs creates a "dark" corner of a remote git repo that can hold > arbitrary content that is impossible for anybody to discover but > nevertheless possible for anybody to download (if they know the name of > a hidden reference). In earlier versions of the patch series I believe > that it was possible to push to a hidden reference hierarchy, which made > it possible to upload dark content. The new version appears (from the > code) to prohibit adding references in a hidden hierarchy, which would > close the main loophole that I was worried about. But the documentation > and the unit tests only explicitly say that updates and deletes are > prohibited; nothing is said about adding references (unless "update" is > understood to include "add"). I think the true behavior should be > clarified and tested. > > I was worried that somehow this "dark" content could be used for > malicious purposes; for example, pushing compromised code then > convincing somebody to download it by SHA1 with the implicit argument > "it's safe since it comes directly from the project's official > repository". If it is indeed impossible to populate the dark namespace > remotely then I can't think of a way to exploit it. Or you can think hiderefs is the first step to addressing the initial ref advertisment problem. The series says hidden refs are to be fetched out of band, but that's not the only way. A new extension can be added to the protocol later to let the client explore this dark space. It's only truly dark for old clients. We could even shed some light to old clients by sending a dummy ref with some loud name like PLEASE_UPDATE_TO_LATEST_GIT_TO_FETCH_REMAINING_REFS (new clients silently drop this ref) -- Duy -- 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