Skip to content
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

51879 fix binary pillar return error #52334

Merged
merged 9 commits into from
Apr 12, 2019

Conversation

waynew
Copy link
Contributor

@waynew waynew commented Mar 27, 2019

What does this PR do?

Restores a previous behavior - allows binary GPG pillar data.

What issues does this PR fix or reference?

Fixes #51879

Previous Behavior

The original behavior on Python2 was that binary or text could be intermingled. When Python 3 support was introduced, we accidentally broke that backwards compatibility - say you had binary data stored in a GPG pillar (the simplest example is the byte '\x8b') this would blow up.

New Behavior

Now if we have a UnicodeDecodeError we assume that the data was meant to be binary data. Also, the file.managed state is in more in line with the module - it will restore Salt's original behavior and no longer fail if the file contents is binary data.

Tests written?

Yes

Commits signed with GPG?

Yes

waynew added 7 commits March 26, 2019 19:41
If we receive binary data, we should respond with binary data.
There's no real reason that pillars can't/shouldn't be able to
contain binary data. This gives us the ability to say that it's OK.
Try to encode as unicode, but if not, just fall back to binary.
That's probably what the data was in the first place.
@dwoz
Copy link
Contributor

dwoz commented Mar 27, 2019

@waynew Looks like the linter failed.

@dwoz dwoz requested a review from terminalmage March 29, 2019 01:03
@dwoz dwoz added the v2019.2.1 unsupported version label Apr 11, 2019
@dwoz dwoz merged commit 6eb2bce into saltstack:2019.2 Apr 12, 2019
@whytewolf
Copy link
Collaborator

looks like this somehow isn't in 2019.2.2 looking through the code for the changes in 2019.2.2.

but github is saying it should be. so I'm wondering if another commit overwrote the changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v2019.2.1 unsupported version
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants