-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Fix PAX extended attribute reading logic to treat '=' character as valid in the value strings. #82810
Conversation
…. It is not handling any filesystem entries.
…e contains an '=' character.,
…ribute roundtripping when the value contains an '=' character. Also add a null check for a subsequent GetNextEntry.
While working on this, I realized we should disallow adding key-value-pairs in which the key contains '=', or in which either the key or the value contain a '\n'. Both cases will cause the extended attribute reading logic to fail. I'll add the fixes to this PR unless anyone indicates a preference to have the two issues fixed separately. |
Separate sounds good to me. Would those other changes potentially be breaking? |
I don't think adding the exception would be breaking because we would be shielding the user from unexpected behavior and corrupted data due to improper use of reserved characters in the key or values. |
/backport to release/7.0 |
Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/4370450091 |
Fixes #81699
We had logic in TarHeader.Read.cs that was explicitly forbidding the '=' character as part of the body of the value string in an extended attribute key-value pair. It felt natural to have such restriction in place as it is one of the two separators that the spec indicates:
But the restriction is not needed: We only need to find the first '=' character to stop reading a key and start reading a value, and after that, we can keep reading any character, including any number of '=' characters, until we detect a '\n' character. Additionally, none of the specs indicated that the '=' is forbidden in values.
This issue was reported by a customer, so we would like to consider a backport to 7.0.