{"thread":{"id":"49763","subject":"Wildcard URL config matching","startedAt":"2018-11-05T20:57:02Z","lastAt":"2018-11-07T13:03:10Z","messageCount":2,"participants":["brian m. carlson","Patrick Steinhardt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"362531","messageId":"20181105205652.GA890086@genre.crustytoothpaste.net","threadId":"49763","inReplyTo":null,"subject":"Wildcard URL config matching","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2018-11-05T20:56:52Z","receivedAt":"2018-11-05T20:57:02Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"In a272b9e70a (\"urlmatch: allow globbing for the URL host part\",\n2017-01-31), we added support for wildcard matching for URLs when\nreading from .git/config.  Now it's possible to specify an option like\nhttp.http://*.example.com/.cookieFile and have it match for the URL\nhttp://foo.example.com.  However, since this option also allows\nwildcards at any level, the following also matches:\nhttp.http://*.*.*/.cookieFile.\n\nI'm wondering if it was intentional to allow this behavior or if we\nintended to allow only the leftmost label (or labels) to be a wildcard.\nThe tests seem to test only the leftmost label, and that is the behavior\nthat one has for TLS certificates, for example.  I don't really see a\nsituation where one would want to match hostname labels in an arbitrary\nposition, but perhaps I'm simply not being imaginative enough in\nthinking through the use cases.\n\nRegardless of what we decide, I'll be sending a patch, either to add\nadditional tests, or correct the code (or both).\n\nI ask because we're implementing this behavior for Git LFS, where we\ndon't iterate over all configuration keys, instead looking up certain\nvalues in a hash.  We'll need to make some changes in order to have\nthings work correctly if we want to implement the current Git behavior\nto prevent combinatorial explosion.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"362653","messageId":"20181107125601.GA20965@ncase.pks.im","threadId":"49763","inReplyTo":"20181105205652.GA890086@genre.crustytoothpaste.net","subject":"Re: Wildcard URL config matching","fromName":"Patrick Steinhardt","fromEmail":"patrick.steinhardt@elego.de","sentAt":"2018-11-07T12:56:01Z","receivedAt":"2018-11-07T13:03:10Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Hi Brian,\n\nOn Mon, Nov 05, 2018 at 08:56:52PM +0000, brian m. carlson wrote:\n> In a272b9e70a (\"urlmatch: allow globbing for the URL host part\",\n> 2017-01-31), we added support for wildcard matching for URLs when\n> reading from .git/config.  Now it's possible to specify an option like\n> http.http://*.example.com/.cookieFile and have it match for the URL\n> http://foo.example.com.  However, since this option also allows\n> wildcards at any level, the following also matches:\n> http.http://*.*.*/.cookieFile.\n> \n> I'm wondering if it was intentional to allow this behavior or if we\n> intended to allow only the leftmost label (or labels) to be a wildcard.\n> The tests seem to test only the leftmost label, and that is the behavior\n> that one has for TLS certificates, for example.  I don't really see a\n> situation where one would want to match hostname labels in an arbitrary\n> position, but perhaps I'm simply not being imaginative enough in\n> thinking through the use cases.\n\nThe behavior is intentional. The above example of \"http://*.*.*/\"\nobviously doesn't make a lot of sense, but e.g. the pattern\n\"http://*.*.example.com\" should match all sub-sub domains of\n\"example.com\" like for example \"http://foo.bar.example.com\". The\nability to use multiple globs is necessary as they aren't \"true\"\nglobs, but will only match the current component of the subdomain\nseparated by dots. So they behave similar to globs in the shell,\nwhere they only match up to the next directory separator.\n\nIf we were to remove the ability to use globs for multiple\ncomponents, then one would have to again explicitly list patterns\nfor all possible combinations.\n\n> Regardless of what we decide, I'll be sending a patch, either to add\n> additional tests, or correct the code (or both).\n\nI agree that there should've been additional tests to also verify\nthat multiple globs work as expected. So thanks for doing that!\n\n> I ask because we're implementing this behavior for Git LFS, where we\n> don't iterate over all configuration keys, instead looking up certain\n> values in a hash.  We'll need to make some changes in order to have\n> things work correctly if we want to implement the current Git behavior\n> to prevent combinatorial explosion.\n\nRegards\nPatrick\n"}]}