Re: [PATCH 0/2] Hiding some refs in ls-remote

On 01/19/2013 01:37 AM, Junio C Hamano wrote:

Although I can understand the pain of slow network performance, somehow this proposal gives me the feeling of being expeditious rather than elegant.

Could the problem be solved in some other way? Maybe such references could be stored in a second repository or in a separate namespace (in the sense of gitnamespaces(7)) to prevent their creating overhead when they are unneeded?

And *if* reference hiding makes sense, it seems to me that the client, not the server, should be the one who decides which server references it is interested in (though I understand that would require a protocol change). Otherwise the git repository *relies* on out-of-band channels for its functionality. If I understand correctly, a user would have *no way* to discover, via git, what hidden references are contained in a remote repository, or indeed even that the repo contains a hidden namespace. For example this would make it impossible to clean up obsolete "hidden" references on a remote repository without the supplementary information stored elsewhere. And if anybody accidentally creates a reference in a hidden namespace by hand, it will just sit there undetectably, forever.

I assume (though I've never checked) that a server does not let a client ask for a SHA1 that is not currently reachable from a server-side reference, and I assume that that you are not proposing to change this policy. But allowing objects to be fetched from a hidden reference opens up some "interesting" possibilities:

* A pusher could upload arbitrary content to a public git server under a
cryptic hidden reference name.  Most people would be completely unable
to see this content, unless given the SHA1 or the reference name by the
pusher.  Thus this mechanism could be used as a dark channel to exchange
arbitrary data relatively secretly.

* Somebody could push a trojan version of code to a hidden reference in
a project, then pass the SHA1 to a victim.  The victim might trust the
code because it comes from a known project website, even though the code
would be invisible to other project developers and thus impossible for
them to audit.  And even if they learned about the trojan's SHA1 they
would be unable to remove it from their repository because they have no
way to find out the name of the hidden reference!

Obviously these hacks would only be possible for a bad guy with push privileges to a repository that has turned on hidden references, but I think they are sobering nevertheless.

These worries would go away if reference hiding were configured on the client rather than on the server.

A second point: currently, the output of "git show-ref -d" and "git
ls-remote ." are almost identical.  Under your proposal, I believe that
the hiderefs would only be omitted from the latter.  Would it be useful
to add an option to "git show-ref" to make it omit the "hiderefs" refs?
 And maybe another option to make it display *only* the hideref refs?

And in the bikeshedding department, I wonder if "hiderefs" is the best name for the config setting. "hiderefs", implies to me that the refs are actively hidden and not available to the client in any way. But in fact they are just not advertised; they can be fetched normally. Maybe another name would be more suggestive of its true effect, for example "quietrefs" or "noadvertiserefs".

Michael