Pulp

Hi,

I'm not sure this is the right project to open the bug for but I'm trying anyway.

Context¶

Operating System : CentOS 7.3

At our site, we're currently using those version of Pulp :

$ rpm -qa '*pulp*'
pulp-admin-client-2.13.1-1.el7.noarch
python-pulp-common-2.13.1-1.el7.noarch
pulp-rpm-admin-extensions-2.13.1-1.el7.noarch
python-pulp-client-lib-2.13.1-1.el7.noarch
python-pulp-rpm-common-2.13.1-1.el7.noarch
python-pulp-bindings-2.13.1-1.el7.noarch

The pulp server version or authentication mechanism is not relevant (I think) for this bug.

The bug is still present in the master branch of the github repository.

Bug description¶

My current combination of username and password has revealed a bug in the way pulp-admin is base64 encoding the data used for basic-auth.

In the code that handles the basic authentication headers creation, you're currently using the function base64.encodestring.

As stated in the documentation,

base64.encodestring = encodestring(s)
    Encode a string into multiple lines of base-64 data.

The problem can be exposed by the following python code :

Python 2.7.10 (default, Oct 14 2015, 16:09:02) 
[GCC 5.2.1 20151010] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import base64
>>> base64.encodestring('abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234')[:-1]
'YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXpBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWjAxMjM0'

>>> base64.encodestring('abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ012345')[:-1]
'YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXpBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWjAxMjM0\nNQ=='

The problematic part is the new line that is added by the base64.encodestring when the data len we want to encode exceed 57 characters.

My current password and username combination is triggering this bug and this makes me impossible to use the pulp-admin client to login using my current credentials. Other users at our site is having the same issue. This is why I've set the Severity of this issue to High.

Fix Proposal¶

I've tested that simply using the base64.b64encode function instead of base64.encodestring solves the problem and shouldn't introduce backward incompatibility.