Bad MD5 filename for non-default avatars

[astos-marcb]

Description

The avatar picture endpoint always returns the default picture.
See difference to actual profile picture for account

Path for the non-default picture resolves to the file content hash md5(<id>-<md5(content)>) (as saved in u.Avatar) instead of the standardized md5(email).

Gitea Version

1.18.4

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

2.36.5

Operating System

Alpine Linux

How are you running Gitea?

docker, verified on https://try.gitea.io/

Database

SQLite

[Zettat123]

Maybe you want to get your custom avatar by accessing /avatars/{hash} and the hash is md5(email)?
Actually the hash filename only indicates a file, not a user.

[astos-marcb]

Exactly, the current user avatar should always be available at /avatars/{md5(email)} (standardized endpoint for avatars).

The default avatar is saved to the correct file name, a custom avatar is not.
Instead, a user+content-derived hash is used as the filename (value in User.Avatar) instead of md5(email).

Setting the default avatar will actually change the value in User.Avatar to md5(email), which in turn does not conform to the expected value in other parts of the code (detecting re-upload of same picture for a user).

An easy fix in CustomAvatarRelativePath would be to just throw away what's saved in User.Avatar (the user/content-derived MD5 sum in case of custom avatar) and just always use the correct filename conforming to avatars.HashEmail(User.Email).

This will of course break references to existing custom avatars which are already saved to a misnamed files…

[Zettat123]

Gitea's avatar service is not de designed to be a service like Gravatar. The hash filename only used to distinguish between different files.
Sorry I couldn't help more because we have no plans to develop this feature in the short term. Please feel free to reopen this issue if you still need help.

[zeripath]

It's a fairly interesting idea for Gitea to implement/replicate Gravatar's funcitonality and I don't believe that it would be too difficult to do this - but yes I don't believe that it is a bug that Gitea does not implement this.

@astos-marcb you could open a feature request but you'd need to link to the specs for it.

[astos-marcb]

In a way Gitea does already implement/provide it (supply an avatar picture at URL /avatars/{md5(email)})
The problem is that default (generated) and custom (uploaded) avatars are not named and treated equally (endpoint always resolves to the default avatar file).

A quick-and-dirty and incomplete solution would be to forgo content checking and always save the avatar file as avatars/{md5(mail)}.
This would not solve the conflicting naming conventions for user avatar and repo avatar and has no chance of supporting multiple mail addresses for the same user.

Ideally, logic used for repository avatar filenames ({repo-id}-{upload-checksum}) should be used and a correct mapping from all email entries of a user should be done in the router layer.
The default (out of the box) behavior of creating the default file with a different name would not have any drawbacks (assuming the router part is working as described).

A possible middle ground (and easy to debug solution) would employ:

• use same naming convention as for repos for the avatar file ({user-id}-{upload-checksum})
• create symbolic md5(email) links for all mail entries for a user (guaranteed to be unique per instance).

For migrating user-supplied avatars the transformed name can be just {user-id}-<zeros> to indicate unknown/discarded content checksum (it currently gets rehashed with the user mail address).

[astos-marcb]

Hm, there are already done some changes to unify avatar naming for v1.20.
Will have a look how/if this affects current /avatars/{md5(email)} behavior (break/improve?).
UNAFFECTED: The filename for generated avatars (still) uses md5({email}) instead of new/unified sha256({user}-{data}).