Allow configuring Gitea to act as a proxy for libravatar requests #10446

New Issue

GiteaMirror · 2025-11-02T09:07:40-06:00

GiteaMirror commented

2025-11-02 09:07:40 -06:00

Originally created by @strk on GitHub (Mar 16, 2023).

Feature Description

Right now enabling Libravatar allows registered users (RU) to receive requests from the browsers of the forge's users (FU) when those users (FU) visit pages with the registered user (RU) avatar for the first time.

This is because Gitea delegates to users's browsers (FU) the operation of fetching those avatars.

By implementing a proxy in the forge itself we'd instead "masquerade" the forge users (FU) so that their information is not leaked. This would be at the expense of more load on the forge, so should be a server configuration.

Screenshots

No response

Originally created by @strk on GitHub (Mar 16, 2023). ### Feature Description Right now enabling Libravatar allows registered users (RU) to receive requests from the browsers of the forge's users (FU) when those users (FU) visit pages with the registered user (RU) avatar for the first time. This is because Gitea delegates to users's browsers (FU) the operation of fetching those avatars. By implementing a proxy in the forge itself we'd instead "masquerade" the forge users (FU) so that their information is not leaked. This would be at the expense of more load on the forge, so should be a server configuration. ### Screenshots _No response_

GiteaMirror added the type/proposal type/feature issue/needs-feedback labels 2025-11-02 09:07:40 -06:00

GiteaMirror closed this issue

2025-11-02 09:07:40 -06:00

GiteaMirror commented

2025-11-02 09:07:41 -06:00

@strk commented on GitHub (Jan 4, 2024):

The rationale for this would be to make it less of a privacy concern for system administrators to enable the federated avatar service, see https://codeberg.org/Codeberg/Community/issues/48

@strk commented on GitHub (Jan 4, 2024): The rationale for this would be to make it less of a privacy concern for system administrators to enable the federated avatar service, see https://codeberg.org/Codeberg/Community/issues/48

GiteaMirror commented

2025-11-02 09:07:41 -06:00

@strk commented on GitHub (Jan 4, 2024):

The alternative at the moment is to install a separate service: https://wiki.libravatar.org/running_your_own/

@strk commented on GitHub (Jan 4, 2024): The alternative at the moment is to install a separate service: https://wiki.libravatar.org/running_your_own/

GiteaMirror commented

2025-11-02 09:07:41 -06:00

@wxiaoguang commented on GitHub (Jan 4, 2024):

I do not think it's worth to make Gitea act as a proxy for libravatar requests. The reasons are:

Setting up a libravatar is quite complex, it also needs DNS setup (according to https://wiki.libravatar.org/running_your_own/).
Most end users do not really use libravatar. Large instances like Codeberg could have their own infrastructure to complete the complex libravatar proxy setup.
The Codeberg owner has stated that they are quite happy with their own-maintained Gitea forks, so they could implement it to fully satisfy their requirement.

And there is already an option for the customization: GRAVATAR_SOURCE, so, I think there is no need to bloat Gitea's codebase.

@wxiaoguang commented on GitHub (Jan 4, 2024): I do not think it's worth to make Gitea act as a proxy for libravatar requests. The reasons are: 1. Setting up a libravatar is quite complex, it also needs DNS setup (according to https://wiki.libravatar.org/running_your_own/). 2. Most end users do not really use libravatar. Large instances like Codeberg could have their own infrastructure to complete the complex libravatar proxy setup. 3. The Codeberg owner has stated that they are quite happy with their own-maintained Gitea forks, so they could implement it to fully satisfy their requirement. And there is already an option for the customization: GRAVATAR_SOURCE, so, I think there is no need to bloat Gitea's codebase.

GiteaMirror commented

2025-11-02 09:07:41 -06:00

@wxiaoguang commented on GitHub (Jan 21, 2024):

Inactive for 2 weeks. Feel free to reopen if there is a feasible plan.

@wxiaoguang commented on GitHub (Jan 21, 2024): Inactive for 2 weeks. Feel free to reopen if there is a feasible plan.

GiteaMirror commented

2025-11-02 09:07:41 -06:00

@github-actions[bot] commented on GitHub (Feb 29, 2024):

Automatically locked because of our CONTRIBUTING guidelines

@github-actions[bot] commented on GitHub (Feb 29, 2024): Automatically locked because of our [CONTRIBUTING guidelines](https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md#issue-locking)

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#10446