Use '.' instead of '=' in URLSafeBase64Encoder. #98

Closed
wants to merge 2 commits into
from

Projects

None yet

4 participants

@fletom

According to RFC 3986 section 2.3, the equal sign (=) is not an
unreserved character in URLs:

Characters that are allowed in a URI but do not have a reserved purpose are called unreserved. These include uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde.

Since the tilde is common used to represent home directories, I chose to use the period (.) for padding instead.

@fletom fletom Use '.' instead of '=' in URLSafeBase64Encoder.
According to RFC 3986 section 2.3, the equals sign (=) is not an
unreserved character in URLs.
90ceae2
@alex
Python Cryptographic Authority member

I'm concerned this might make this more confusing. To many Python folks, I imagine URLSafeBase64 means that function in the base64 module, whether or not that's correct or not.

@fletom

As long as an encoder is consistent (and this would be, since the code hasn't been released yet), it shouldn't cause problems for anyone. They might expect it to work exactly like base64 does, but I can't think of a scenario in which something could break because of it.

Either way, I'm more concerned (though still only slightly) that having a = in a string that is supposed to be URL-safe could result in a URL parameter injection vulnerability somehow.

@coveralls

Coverage Status

Coverage increased (+0.24%) when pulling 90ceae2 on fletom:master into 61cc9f2 on pyca:master.

@coveralls

Coverage Status

Coverage remained the same when pulling 41b78db on fletom:master into 61cc9f2 on pyca:master.

@dstufft dstufft referenced this pull request Mar 4, 2015
Closed

release v0.3.0 #73

@warner

I think consistency with stdlib is more important here.. it's unfortunate that base64 didn't replace the padding with a character that's actually reserved, but I expect that anyone who runs into that problem with pynacl's encoding function will have experienced it with stdlib first, and will be prepared to do whatever extra .replace("=",".") is necessary. Also, most implementations I've seen strip the padding anyways.

Closing as WONTFIX. Thanks!

@warner warner closed this Mar 4, 2015
@warner warner added the wontfix label Mar 4, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment