On Tue, Dec 17, 2019 at 09:43:23AM -0800, Junio C Hamano wrote: > Emily Shaffer <emilyshaffer@xxxxxxxxxx> writes: > > >> But that is too simple-minded. If we wanted to safelist foo.*.bar, > >> where '*' can be anything, walking on the list of safe variables > >> would not work. We must have a hash table that knows "foo.*.bar" is > >> allowed, and while walking all the configuration keys, when we see > >> foo.a.bar, we consult "foo.*.bar" as well as "foo.a.bar" to see if > >> it is whitelisted, or something like that. > > > > ...unless we want to use wildcards like you suggest. > > > > But I'm not sure it's a good idea. I envision someone writing another > > Git add-on, which offers someone to specify "user.password" ... > > Wildcarding the leaf level of two (or for that matter three) level > names like "user.*" in your example is of course a nonsense way to > use the safelist. But think about three-level names where the > second level is designed to be used for user-supplied token to give > things of similar nature a name the user can use to distinguish > things. If remote.origin.url is worth reporting, wouldn't > remote.upstream.url also be? Shouldn't remote.*.url be the way to > say "the URL field for each and every remote is a safe thing to > report" in the safelist? Bah, somehow this mail slipped through the cracks for me. When you put it that way, I see how it can be useful. Although I admit to fatigue on this patchset and now I'm hesitant about feature creep. :) I'm going to send the reroll for v5 as I have it, not having seen this mail, and think more about how I'd approach wildcarding in the middle like this. I want to take a look at the other configs which use a middle level as a user token and try to reason about whether we ought to be collecting them. I'll hope to report back sooner (or later). - Emily
