Re: [RFC PATCH] t5551: delete auth-for-pack-but-not-refs test

> Jonathan Tan <jonathantanmy@google.com> writes:
> 
> > Because this configuration is not supported by all protocol versions,
> > and because this configuration seems to be of limited usefulness (only
> > useful for people who use manual credential entry and on servers that
> > are OK with exposing refs but not objects, and even in this case, helps
> > only in a no-op fetch), delete the test that verifies that this
> > configuration works.
> 
> A possible and different conclusion that naturally follow your first
> "because" could be "fix protocol versions whose support of this
> configuration is broken", and your second "because" is with "seems
> to be", that makes it quite weak.
> 
> Quite honestly, I hate to see a proposed log message that downplays
> its potential negative effects without sufficient justification.

> Isn't this feature primarily for those who want to poll from an
> automated job (and naturally you want to assign as little privilege
> as possible to such an automated job) with ls-remote and only run an
> authenticated fetch, perhaps manually, with or without cred helper,
> when the automated polling job finds there is something worthwhile
> to fetch?  What this test is checking seems to be a quite effective
> way to achieve that useful workflow, at least to me, and offhand I
> do not think of other ways to easily achieve the same.
> 
> The "ls-remote" communication may not even touch any outside network
> but may be happening all within a single organization, in which case
> "are OK with exposing refs" is making a security mountain out of a
> molehill.  If it were a truly problematic hole that makes it a
> security issue, wouldn't we deleting this test and at the same time
> plugging the hole for earlier protocol versions?

> Having said all that, I do not care too deeply.  Would a much better
> longer-term solution for those who want to poll and fetch only when
> there is something new be to allow clients to subscribe to a feed
> that hangs while there is nothing new, and lets the upstream side
> continuously feed incremental updates to the receiving client, as
> its refs are updated, or something?  As long as such a thing is in
> our vision (it is OK if nobody is currently working on it) to become
> replacement, I do not think it is a huge loss to lose the ability for
> unauthenticated ls-remote with authenticated fetch.