I'm not sure if we should hardcode 'utf-8' in, but PR #1489 doesn't fully fix #1486/#1482 because there's still an instance of md5_constructor running around without a utf-8 encode. @tkopecek ?

:thumbsup:

Yes, you're right, I've missed it. utf-8 seems to me ok. Theoretically 'ascii' should be enough, but utf-8 seems to be ok for me.

This looks like it could fail under python2.

• user comes from environ. Looks like this will be a plain str under py2
• we're converting tstamp to a plain str, though that should always be ascii
• it looks like environ['koji.options']['Secret'].value will also be a plain str under py2

Either the user value or the secret value could contain non-ascii characters. Calling .encode() on such a string in python2 will raise an error.

>>> s = 'həllo'
>>> s.encode('utf8')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc9 in position 1: ordinal not in range(128)

The above also likely applies to #1489.

If it is passed this way, it means, that it is already converted to utf-8.

s1 = 'həllo'
s2 = u'həllo'
s1 == s2.encode('utf-8')
True

I think it should never happen, but anyway, I've added a commit to encode just under PY3 - it doesn't hurt: https://pagure.io/fork/tkopecek/koji/commits/pr1498-fix

Thanks tkopecek! I'll try to cherry-pick your commit over. Having some issues cloning over SSH right now (even though I added my ssh-keys in, and I can't push when I clone via HTTPS). Worst-case I'll add you as a contributor to my fork, or you can just submit a PR with your branch instead.

:thumbsup:

Commit bdfac5b1 fixes this pull-request

(merged with manual rebase)