-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Secret encryption fails with 128+ characters under Python 2 #2473
Comments
…community#2473) The encoding of the secret length indicator has likely been broken since commit b21833f which introduced Py3 support for secrets: the indicator was switched to using UTF-8 byte strings and this caused the length indicator to consume 3 bytes instead of just 2 under certain circumstances. For example when the plaintext secret length is between 128 and 256 bytes long. This is because contrary to latin-1 encoding, UTF-8 byte sting encoding consumes 2 bytes for code points > 80. See the table at https://en.wikipedia.org/wiki/UTF-8#Description The fix is to explicitely use 'latin-1' encoding for the length indicator. This makes the code behave exactly as it did with the original Python2 implemenation while remaining compatible w/ Py3. A test case which uses a 171 byte long plaintext string has also been added. This test triggers the bug when the fix is not present. This fixes netbox-community#2473
…y2 or py3 for the plaintext length indicator field. Py2.7 cannot encode code points > 128 so fall back to chr(code_point) without the "encode()" attribute when Python 2.x is detected. This does not change the existing decrypt/unpad code paths. So whatever is currently broken in the DB due to bug netbox-community#2473 will remain broken.
Wow, this is all over the place. I can confirm that NetBox generates an exception when attempting to create a secret larger than 127 bytes under Python 2, but beyond that much of what you're saying doesn't make sense.
I receive the same exception no matter how the secret is created. The exception originates from within the
Again, this is consistently reproducible.
I'm not sure what this is in reference too. NetBox doesn't care what you do with the stored data.
This has nothing to do with SSH key types; it is solely an issue regarding the encoding of data size. The same thing happens with any string of 128+ characters. |
I can't succeed to store ssh keypair within netbox secrets resource.
I can import the content successfully but I can't retrieve it.
When I try to read/unlock the content, I receive a 500 error code with the following exception:
Environment
Prerequisites
Steps to Reproduce
generate a ssh keypair
import content (using web UI)
Assuming the following:
for the private key, copy/paste the following:
for the public key, copy/paste the following:
Expected Behavior
Observed Behavior
On server side, nginx logs return the following HTTP error code:
Additional comments
The text was updated successfully, but these errors were encountered: