Update wildcard pattern behavior #301
Conversation
This commit adds explicit examples of targets that are not matched by a wildcard. It also adds a note warning users that incorrect assumptions about wildcard behavior can potentially lead to an untrusted role signing for a target. Signed-off-by: Aditya Sirish <aditya@saky.in>
tuf-spec.md
Outdated
| * a <a>PATHPATTERN</a> of `"foo/*"` matches `"foo/bar.tgz"` but not | ||
| `"foo/baz/bar.tgz"`, `"foo/bar/baz/bar.tgz"`, and so on. | ||
|
|
||
| Note: It is important to understand the functioning of path patterns to |
There was a problem hiding this comment.
I'd also list a note to the opposite effect first: remind the reader why this behaviour is there (not for arbitrary reasons).
There was a problem hiding this comment.
I tweaked the text a bit, does it help?
There was a problem hiding this comment.
No, sorry. First, please briefly explain why the current patterns work the way they do, and as such, they are optimised for those anticipated use cases. Your use cases here are outside of that, and should thus fall under a second paragraph.
There was a problem hiding this comment.
I'm not the best person to discuss why the current patterns work the way they do as I don't actually have that context. @mnm678 can you help with some text here? Thanks!
Signed-off-by: Aditya Sirish <aditya@saky.in>
Signed-off-by: Aditya Sirish <aditya@saky.in>
|
I bumped the patch version number. |
There was a problem hiding this comment.
This is great, thank you. Approved as is, but I wonder if we should move the coment on wildcards not apply recursively above the examples?
It is somewhat explicit because we state that we follow shell style globbing, but for many shell is synonymous with bash, which has globstar.
| security. For example, an assumption that `"foo/*"` applies recursively to | ||
| all files in subdirectories of `foo` in a terminating delegation could allow | ||
| a subsequent delegated role that should not be trusted to sign for a target | ||
| in a subdirectory of `foo`. |
There was a problem hiding this comment.
This is a great clarification to add, thanks! This point on wildcards not applying recursively feels important enough that I wonder whether we should raise it above the examples so that it's a little more prominent, WDYT?
This PR adds explicit examples of targets that are not matched by a wildcard. It also adds a note warning users that incorrect assumptions about wildcard behavior can potentially lead to an untrusted role signing for a target.
Related: theupdateframework/go-tuf#590