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?
