di
commented
2 years ago Thanks for the issue!
Given that we wrap our Gravatar URL's in a Camo URL, I think the risks mentioned (MD5 reversal, user tracking) are mitigated. It also seems that Libravatar also does an MD5 hash of the user's email, so I'm not sure there's an advantage w.r.t. that risk.
Part of the reason we use Gravatar is that a) it's lightweight & maintenance-free for us, and b) many users have Gravatar avatars. Unless we have a solution that is comparable, that also allows us to fall back on Gravatar to maintain existing avatars, I think we're unlikely to migrate.
Given that, I'm going to close this issue for now, but I'm open to revisiting it in the future if things change.
What's the problem this feature will solve?
Gravatar is not an open source project. There are some talks about Gravatar having privacy issues. This will essentially replace Gravatar with a privacy focused alternative.
Describe the solution you'd like
Proposal 1:
My proposition is to replace Gravatar with Libravatar. Ivatar ( the software the powers Libravatar ) being a open source project, maintained by a Red Hat Systems Engineer and is backed by the Fedora project seems a really good, customizable, feature rich, actively developed candidate. Since Libravatar and Gravatar are API compatible it will just be a URL change in this line. Also we may not need to use warehouse-camo proxy ( because Ivatar does the proxying ) and save proxy bandwidth.
Proposal 2:
If we dont trust the Libravatar project or if we want more control over avatar management we can fork the Ivatar project ( to not reinvent the wheel ) and self host Ivatar as a avatar backend for PyPi. Which will also remove the need for warehouse-camo proxy. Also it would solve both #782 #8211. The code is mostly Python ( Django ), But it will increase bandwidth on our server / Require us to host a instance of Ivatar.
Additional context