6:45 a.m.
Patch for https://fedorahosted.org/pki/ticket/1102
b64encode() and base64.encodestring() work slightly different.
encodestring() includes an extra newline at the end of the string. It
seems the server treats both representations equally.
I ran the KRA tests according to base/kra/functional/drmtest.readme.txt.
The tests are passing, too.
Christian
10:25 a.m.
On 6/29/2015 6:45 AM, Christian Heimes wrote:
Patch for https://fedorahosted.org/pki/ticket/1102
b64encode() and base64.encodestring() work slightly different.
encodestring() includes an extra newline at the end of the string. It
seems the server treats both representations equally.
I ran the KRA tests according to base/kra/functional/drmtest.readme.txt.
The tests are passing, too.
Christian
In drmclient_deprecated.py the extra '\n' is probably unnecessary:
print "retrieved data is " + base64.b64encode(response['data']) +
'\n'
Regardless, this file probably can be removed (check with alee).
ACK.
--
Endi S. Dewata
9:03 a.m.
New subject: PATCH 005] Replace legacy Python base64 invocations with Py3-safe code
On 2015-06-29 13:45, Christian Heimes wrote:
Patch for https://fedorahosted.org/pki/ticket/1102
b64encode() and base64.encodestring() work slightly different.
encodestring() includes an extra newline at the end of the string. It
seems the server treats both representations equally.
I ran the KRA tests according to base/kra/functional/drmtest.readme.txt.
The tests are passing, too.
Here is another take on my old patch. The new patch also fixes a
compatibility issue with Python 3.
1:13 p.m.
New subject: PATCH 005] Replace legacy Python base64 invocations with Py3-safe code
On 8/19/2015 9:03 AM, Christian Heimes wrote:
On 2015-06-29 13:45, Christian Heimes wrote:
> Patch for https://fedorahosted.org/pki/ticket/1102
>
> b64encode() and base64.encodestring() work slightly different.
> encodestring() includes an extra newline at the end of the string. It
> seems the server treats both representations equally.
>
> I ran the KRA tests according to base/kra/functional/drmtest.readme.txt.
> The tests are passing, too.
Here is another take on my old patch. The new patch also fixes a
compatibility issue with Python 3.
As discussed on IRC, in b64encode() there's a code that converts Unicode
string data into ASCII:
if isinstance(data, six.text_type):
data = data.encode('ascii')
This conversion will not work if the string contains non-ASCII
characters, which limits the usage of this method.
It's not that Python 3's base64.b64encode() doesn't support ASCII text
as noted in the method description, but it cannot encode Unicode string
because Unicode doesn't have a binary representation unless it's encoded
first.
I think in this case the proper encoding for Unicode is UTF-8. So the
line should be changed to:
if isinstance(data, six.text_type):
data = data.encode('utf-8')
In b64decode(), the incoming data is a Unicode string containing the
base-64 encoding characters which are all ASCII, so data.encode('ascii')
will work, but to be more consistent it can also use data.encode('utf-8').
--
Endi S. Dewata
8:14 a.m.
New subject: PATCH 005] Replace legacy Python base64 invocations with Py3-safe code
On 2015-08-26 20:13, Endi Sukma Dewata wrote:
As discussed on IRC, in b64encode() there's a code that converts
Unicode
string data into ASCII:
if isinstance(data, six.text_type):
data = data.encode('ascii')
This conversion will not work if the string contains non-ASCII
characters, which limits the usage of this method.
It's not that Python 3's base64.b64encode() doesn't support ASCII text
as noted in the method description, but it cannot encode Unicode string
because Unicode doesn't have a binary representation unless it's encoded
first.
I think in this case the proper encoding for Unicode is UTF-8. So the
line should be changed to:
if isinstance(data, six.text_type):
data = data.encode('utf-8')
In b64decode(), the incoming data is a Unicode string containing the
base-64 encoding characters which are all ASCII, so data.encode('ascii')
will work, but to be more consistent it can also use data.encode('utf-8').
We discussed the ticket a couple of weeks ago on IRC. The function is
deliberately limited to ASCII only text in order to avoid encoding hell.
Python 3 tries to avoid encoding bugs by removing implicit encoding of
text and decoding of bytes.
The special treatment is only required for encoding/decoding X.509 data
in JSON strings for Python 3. Since it's a special case I changed the
patch. The additional two functions are now called decode_cert() and
encode_cert(). The functions are only used for X.509 PEM <-> DER in JSON.
Christian
11:40 a.m.
New subject: PATCH 005] Replace legacy Python base64 invocations with Py3-safe code
On 9/21/2015 8:14 AM, Christian Heimes wrote:
On 2015-08-26 20:13, Endi Sukma Dewata wrote:
> As discussed on IRC, in b64encode() there's a code that converts Unicode
> string data into ASCII:
>
> if isinstance(data, six.text_type):
> data = data.encode('ascii')
>
> This conversion will not work if the string contains non-ASCII
> characters, which limits the usage of this method.
>
> It's not that Python 3's base64.b64encode() doesn't support ASCII text
> as noted in the method description, but it cannot encode Unicode string
> because Unicode doesn't have a binary representation unless it's encoded
> first.
>
> I think in this case the proper encoding for Unicode is UTF-8. So the
> line should be changed to:
>
> if isinstance(data, six.text_type):
> data = data.encode('utf-8')
>
> In b64decode(), the incoming data is a Unicode string containing the
> base-64 encoding characters which are all ASCII, so data.encode('ascii')
> will work, but to be more consistent it can also use data.encode('utf-8').
We discussed the ticket a couple of weeks ago on IRC. The function is
deliberately limited to ASCII only text in order to avoid encoding hell.
Python 3 tries to avoid encoding bugs by removing implicit encoding of
text and decoding of bytes.
The special treatment is only required for encoding/decoding X.509 data
in JSON strings for Python 3. Since it's a special case I changed the
patch. The additional two functions are now called decode_cert() and
encode_cert(). The functions are only used for X.509 PEM <-> DER in JSON.
Christian
ACK.
--
Endi S. Dewata
3376
days inactive
3463
days old
5 comments
2 participants
participants (2)
-
Christian Heimes -
Endi Sukma Dewata