-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Remove BytesWarnings in client.py by putting u() around every hexlify, other BytesWarnings fixes #1661
Open
aggieNick02
wants to merge
3
commits into
paramiko:main
Choose a base branch
from
aggieNick02:master
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sorry, didn't realize there were whitespace checks. Do you want me to fix and supply a new PR? |
ploxiln
added a commit
to ploxiln/paramiko-ng
that referenced
this pull request
Apr 11, 2020
Transport._log() does not take msg list, it takes format string SFTPClient/SFTPServer _log() method does not take msg list SFTPBase gets new _loglist() method for the rare list case Transport and SFTP* use proper logging format strings and separate arguments SFTPClient no longer needs %% escaping of log messages, now that it logs correctly SSHClient and AuthHandler always log with single msg string, so pass to Transport._log() as "%s", msg get rid of util.tb_strings(), instead _log() with exc_info=True so that lines of traceback are not separate log messages (inspired by paramiko#406) binascii.hexlify() returns bytes, decode to string for logging (inspired by paramiko#1661)
ploxiln
added a commit
to ploxiln/paramiko-ng
that referenced
this pull request
Apr 11, 2020
Transport._log() does not take msg list, it takes format string SFTPClient/SFTPServer _log() method does not take msg list SFTPBase gets new _loglist() method for the rare list case Transport and SFTP* use proper logging format strings and separate arguments SFTPClient no longer needs %% escaping of log messages, now that it logs correctly SSHClient and AuthHandler always log with single msg string, so pass to Transport._log() as "%s", msg get rid of util.tb_strings(), instead _log() with exc_info=True so that lines of traceback are not separate log messages (inspired by paramiko#406) binascii.hexlify() returns bytes, decode to string for logging (inspired by paramiko#1661)
ploxiln
added a commit
to ploxiln/paramiko-ng
that referenced
this pull request
Apr 17, 2020
Transport._log() does not take msg list, it takes format string SFTPClient/SFTPServer _log() method does not take msg list SFTPBase gets new _loglist() method for the rare list case Transport and SFTP* use proper logging format strings and separate arguments SFTPClient no longer needs %% escaping of log messages, now that it logs correctly SSHClient and AuthHandler always log with single msg string, so pass to Transport._log() as "%s", msg get rid of util.tb_strings(), instead _log() with exc_info=True so that lines of traceback are not separate log messages (inspired by paramiko#406) binascii.hexlify() returns bytes, decode to string for logging (inspired by paramiko#1661)
ploxiln
added a commit
to ploxiln/paramiko-ng
that referenced
this pull request
Apr 20, 2020
Transport._log() does not take msg list, it takes format string SFTPClient/SFTPServer _log() method does not take msg list SFTPBase gets new _loglist() method for the rare list case Transport and SFTP* use proper logging format strings and separate arguments SFTPClient no longer needs %% escaping of log messages, now that it logs correctly SSHClient and AuthHandler always log with single msg string, so pass to Transport._log() as "%s", msg get rid of util.tb_strings(), instead _log() with exc_info=True so that lines of traceback are not separate log messages (inspired by paramiko#406) binascii.hexlify() returns bytes, decode to string for logging (inspired by paramiko#1661)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I run python in an environment where BytesWarnings are enabled and promoted to errors. This was really helpful during py2->3 transitioning, and still helps prevent misuse of bytes as strings.
I'd like to keep doing this while using Paramiko, but I hit BytesWarnings when doing so. I looked at related issues for paramiko, and they've previously been fixed by putting a u() around the offending bytes. This is appropriate for calls to hexlify that are then passed to format(), since hexlify returns the bytes for the ASCII-encoded hex rep of the input.
This is what was done for the same kind of issue previously: #1074
I also fixed the same kind of issue, in auth_client.py, reported at:
#1593
This should also close the issue 728 linked below. The issue requested a string-ish hex-digest, which would be more dramatic and risky for a wholesale transition, since there could be clients that still need the bytes-ish one. But the u() around the hexlifys going to format safely resolves being able to run with -bb.:
#726
I went ahead and found the rest of the uses of hexlify that were exclusively passed to format/print, and fixed similarly. I left other uses of hexllify alone, as there are definitely still places, e.g. tests, that fully expect bytes back.