-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add exceptions to TAR extended attribute constructors to disallow '=' and '\n' characters in keys and values. #82812
Add exceptions to TAR extended attribute constructors to disallow '=' and '\n' characters in keys and values. #82812
Conversation
I compared the extraction behavior of the gnu The tool is quite permissive: As long as the reported size of the data section is correct, once an error happens when reading an extended attribute due to finding those characters where they shouldn't be, it simply skips the whole extended attributes section and continues reading the next file. This behavior aligns to what we already do: we abort the runtime/src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarHeader.Read.cs Line 624 in 68e8cd9
Also, the |
src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarHeader.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Formats.Tar/tests/TarEntry/PaxTarEntry.Tests.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarHeader.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarHeader.cs
Outdated
Show resolved
Hide resolved
…s containing '\n'.
…tesTarEntry constructors that take an extended attributes dictionary, throw when a disallowed character is found.
…ert them to the lazily created dictionary if they pass the validations.
5a58ef6
to
a6ca6ae
Compare
{ | ||
throw new ArgumentException(SR.Format(SR.TarExtAttrDisallowedKeyChar, kvp.Key, kvp.Key[index] == '\n' ? "\\n" : kvp.Key[index])); | ||
} | ||
if (kvp.Value.IndexOf('\n') != -1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
readability:
if (kvp.Value.IndexOf('\n') != -1) | |
if (kvp.Value.Contains('\n')) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree it's more readable, but I am unsure if Contains is more or less performant compared to IndexOf. Let me find out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Contains is strictly better in this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We actually have an analyzer for this:
runtime/eng/CodeAnalysis.src.globalconfig
Lines 622 to 623 in 9c02b25
# CA2249: Consider using 'string.Contains' instead of 'string.IndexOf' | |
dotnet_diagnostic.CA2249.severity = warning |
Do we know why it's not firing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No idea. @carlossanlop can you please check?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The analyzer has a bug: it only runs when using ==
or >=
. My code is using !=
.
I opened an issue: dotnet/roslyn-analyzers#6587
I would like to backport this to 7.0, @ViktorHofer @ericstj. The exception would protect users from improper use of extended attributes, which could cause data loss. Do you have any concerns or objections? |
Tactics will generally not approve speculative ports. They'll ask for evidence this is being hit. |
Follow up of #82810
Related to #81699
This change adds exceptions that prevent creating a PAX entry with extended attributes that contain:
The TAR spec indicates that the '=' character is used to divide a key from a value, and the '\n' character is used to divide a key-value-pair from another.
Since the keys and values are strings, the user could easily pass one of these characters where they shouldn't, and without proper internal detection, we end up writing them in the extended attributes. This prevents a roundtrip to properly read the extended attribute entries, and we either fail silently (the extended attributes show up as empty) or show corrupt data.