Shouldn't we find all the places, where we are sending wrong input, than to make workarounds in constructors?
Btw, where you hit this problem? I'm not able to find place with incorrect input.

Shouldn't we find all the places, where we are sending wrong input, than to make workarounds in constructors?

inside koji:
- kojihub._generate_maven_metadata
- CG import
- add_rpm_sig
- get_verify_class
- _getUserCookie/_setUserCookie in kojiweb
- import_archive_internal

And I can find koji-tools also is using them as well
So I think making this changes directly in constructors is better, and it also keeps the same behavior as adler32_constructor

Btw, where you hit this problem? I'm not able to find place with incorrect input.

I got this problem from #koji. nickgresham is setting up kojiweb on F30 with python3. He met this problem in _setUserCookie

Ah, kojiweb - yes, this is at least one place, where input is not converted correctly.
I'm still little bit more for fixing our inputs, so users can expect, that these functions are behaving as expected from hashlib. Anyway, I've not strong opinion about that. @mikem?

Ah, kojiweb - yes, this is at least one place, where input is not converted correctly.
I'm still little bit more for fixing our inputs, so users can expect, that these functions are behaving as expected from hashlib. Anyway, I've not strong opinion about that. @mikem?

Maybe I would go one more step and drop md5_constructor/sha1_constructor from util completely (we don't support python <2.7 and hashlib is preset from 2.4).

@tkopecek I updated this PR to wrap those constructor by a mimicing class(to intercept update() as well)
Please review again

yes, agree.
Just not sure if any 3party tools is using md5 and sha1 construnctors...
Changing index.py should be easier and clearer anyway.

Ok, I'll create two separate issues for 1.19. Fixing index.py #1486 and deprecating these functions #1487.

I think it's better to fix the inputs, but I can see taking this approach as a temporary workaround.

Could we drop this one as preferring #1486 and #1498, and move those two in koji 1.18?

Could we drop this one as preferring #1486 and #1498, and move those two in koji 1.18?

Sure, let's go ahead and fix this the right way since it shouldn't take significantly more work.