Repository navigation
platforms: reject "." and ".." in platform specifiers - #38
Conversation
Reject "." and ".." as architecture or variant components when parsing platform specifiers. These values were previously accepted, but are treated as path components by path.Join, which is used by Format and FormatAll. This could cause platforms to be silently changed when formatting them, making parsing and formatting inconsistent. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
There was a problem hiding this comment.
🟢 Approval recommended
No active review issues are recorded for the change rejecting dot components in platform architecture and variant fields.
No open issues 🎉
What changed in this PR
This PR prevents platform specifiers from silently changing during formatting by rejecting "." and ".." as architecture or variant components, which path.Join would otherwise clean.
Changes:
- Adds component validation that rejects dot components while preserving existing pattern checks.
- Adds invalid-input tests for both values in architecture and variant positions.
| File | Description |
|---|---|
platforms.go |
Adds and integrates validation to reject dot components during parsing. |
platforms_test.go |
Adds four regression cases covering dot architectures and variants. |
Review effort: Balanced
| // validateSpecifierComponent checks that s is a valid platform specifier | ||
| // component, excluding "." and ".." which would be cleaned by path.Join. | ||
| func validateSpecifierComponent(s string) error { | ||
| if s == "." || s == ".." { |
There was a problem hiding this comment.
Anything that starts with . should be rejected?
There was a problem hiding this comment.
Why reject then explicitly instead of just letting them not match? (More code to maintain for very little benefit, right?)
These two special cases make sense because they actually break the parsing in various ways.
There was a problem hiding this comment.
yeah, I think for some of these, we didn't have the presence of mind to use the same conventions as we did for image references (where we used a definition of alpha numeric characters with ., - as separators, but (if I'm not mistaken) not as leading/trailing characters (also to avoid --my-image ambiguity on the command-line)).
This one was indeed for a more targeted fix; it clearly wasn't able to roundtrip the string-format, and not something I expect anyone to depend on.
|
@austinvazquez @dmcgowan ptal |
Reject "." and ".." as architecture or variant components when parsing platform specifiers.
These values were previously accepted, but are treated as path components by path.Join, which is used by Format and FormatAll. This could cause platforms to be silently changed when formatting them, making parsing and formatting inconsistent.