Bug#927012: libravatar.cgi on bugs.debian.org fails with 500 error

[Laurence Parry]

Package: bugs.debian.org

My avatar (and indeed all avatars) are not showing up on bugs.debian.org.

When I tried to access the URL:
https://bugs.debian.org/cgi-bin/libravatar.cgi?email=greenreaper%40gmail.com
I got an 500 Internal Server Error:
---
Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator at ow...@bugs.debian.org to inform them of the time this error occurred, and the actions you performed just before this error.

More information about this error may be available in the server error log.
Apache Server at bugs.debian.org Port 443
---

I believe my own avatar would normally be obtained from Gravatar.

I checked in #libravatar on Freenode first to see if there was something up with the service on their end, but they said the cgi script was a caching mechanism and I should file a bug here.

While the avatar is a minor feature, it is useful for quickly identifying the participants.

Best regards,

--

Laurence "GreenReaper" Parry
https://www.greenreaper.co.uk/

[Oliver Falk]

Hi!

This bug has been reported a while ago and popped up again during some conversation in our IRC channel today.

As the maintainer of libravatar.org, I wonder if I can help somehow to solve this problem?

Please let me know if I can help in some way!

Kind regards,

 Oliver

[Paul Wise]

On Sat, 13 Apr 2019 15:51:12 +0100 Laurence Parry wrote:

> My avatar (and indeed all avatars) are not showing up on bugs.debian.org.
>
> When I tried to access the URL:
> https://bugs.debian.org/cgi-bin/libravatar.cgi?email=greenreaper%40gmail.com
> I got an 500 Internal Server Error:

FTR; this CGI script was disabled some years ago because it was
overloading the Debian bug servers. There was a plan to switch the
script from CGI to mod_perl but that never happened. As an example of
traffic, yesterday there were 21408 attempted executions of the script.
If anyone wants to work on the script, the source code for it is here:

https://salsa.debian.org/debbugs-team/debbugs/-/blob/master/cgi/libravatar.cgi

--
bye,
pabs

https://wiki.debian.org/PaulWise

[Oliver Falk]

Hi all!

I remember the CGI was disabled quite some time ago, but I have to admit, I never had the chance to engage with the right people to see how we can fix it.

I understand the script was added in order to provide additional caching, right?

What about if we change this to directly access libravatar.org and see if the performance is sufficient? (doesn't address federation...).

There is a very simple libravatar proxy python script:

https://git.linux-kernel.at/oliver/ivatar/-/blob/master/libravatarproxy.py

Note, this doesn't take into account any federation, but that could be added easily and it's on my todo list.

Since I do have some Perl experience as well, if you want to stick with Perl, I can also look into the existing CGI and depending on if you want or not, also add federation.

Point is: I'm very willing to help out to get this running again - for obvious reasons. :-)

Oliver

--

Oliver Falk, RHCE

He/Him/His

Manager Customer Success - Germany

Red Hat

fa...@redhat.com    

M: +436641665645     IM: ofalk

@RedHat   Red Hat   Red Hat

Red Hat Austria GmbH, Legal form: Limited company ("Gesellschaft mit beschränkter Haftung") Registered seat: Vienna
Commercial registry file: FN 479668w, Commercial Court ("Handelsgericht") Vienna

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, 
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Brian Klemm

[Paul Wise]

On Thu, 2022-04-07 at 11:01 +0200, Oliver Falk wrote:

> I remember the CGI was disabled quite some time ago, but I have to
> admit, I never had the chance to engage with the right people to see
> how we can fix it.

To be clear, I'm not the right person, just relaying some info that got
dug up on IRC today when other people noticed the script was broken.

> I understand the script was added in order to provide additional
> caching, right?

I think it was mainly for privacy; not sending the avatar image
requests to third-party domains such as libravatar.org.

> What about if we change this to directly access libravatar.org and
> see if the performance is sufficient? (doesn't address
> federation...).

That would presumably work, but there is the privacy issue.

> There is a very simple libravatar proxy python script:
> https://git.linux-kernel.at/oliver/ivatar/-/blob/master/libravatarproxy.py

Since the Debian BTS is written in Perl I assume the admins prefer it.

> Since I do have some Perl experience as well, if you want to stick
> with Perl, I can also look into the existing CGI and depending on if
> you want or not, also add federation.

That would be helpful I think.

I also note from looking at the Apache config today that the script
might have already been migrated to mod_perl, but I wasn't sure, so
I'll leave it up to the Debian BTS admins to check and respond and
maybe re-enable execution of the script again.

[Oliver Falk]

On Thu, Apr 7, 2022 at 11:52 AM Paul Wise <pa...@debian.org> wrote:

On Thu, 2022-04-07 at 11:01 +0200, Oliver Falk wrote:

> I remember the CGI was disabled quite some time ago, but I have to
> admit, I never had the chance to engage with the right people to see
> how we can fix it.

To be clear, I'm not the right person, just relaying some info that got
dug up on IRC today when other people noticed the script was broken.

Thanks for clarifying that - noted!

 

> I understand the script was added in order to provide additional
> caching, right?

I think it was mainly for privacy; not sending the avatar image
requests to third-party domains such as libravatar.org.

IMHO, the current solution doesn't really provide more security. Yes, Libravatar doesn't see the client IPs, but that's all. Currently, what happens is that the local CGI script is actually called with the mail address instead of the hash, which I'd see as a bigger issue.

Note that Libravatar has a privacy policy in place: https://www.libravatar.org/privacy/

Libravatar is a community driven project with a lot of eyes on it and we're fully committed to stay neutral; Read: We're not going to share or sell data.

 

> What about if we change this to directly access libravatar.org and
> see if the performance is sufficient? (doesn't address
> federation...).

That would presumably work, but there is the privacy issue.

I do understand people are concerned about privacy - I am too and that was one of the reasons why I stepped in as the core maintainer when fmarier decided to give up on the project and even added an option to proxy requests to Gravatar instead of redirecting.

 

> There is a very simple libravatar proxy python script:
> https://git.linux-kernel.at/oliver/ivatar/-/blob/master/libravatarproxy.py

Since the Debian BTS is written in Perl I assume the admins prefer it.

Fair point!

 

> Since I do have some Perl experience as well, if you want to stick
> with Perl, I can also look into the existing CGI and depending on if
> you want or not, also add federation.

That would be helpful I think.

Without digging much into it (esp. because I don't have the relevant modules + config in place), I'd say the script should work; No idea why it's currently throwing a server error.

 

I also note from looking at the Apache config today that the script
might have already been migrated to mod_perl, but I wasn't sure, so
I'll leave it up to the Debian BTS admins to check and respond and
maybe re-enable execution of the script again.

Thanks for checking! mod_perl should definitely help a bit to speed things up, but currently it looks like there is some error and not like someone disabled the script, but I have no insights of course.

Cheers,

 Oliver

[Paul Wise]

On Thu, 2022-04-07 at 12:39 +0200, Oliver Falk wrote:

> IMHO, the current solution doesn't really provide more security.

Its about not asking browsers to do third-party requests, which is the
policy for all Debian domains (where possible) and yes isn't a security
issue, but it is a privacy and trust issue.

> Currently, what happens is that the local CGI script is actually
> called with the mail address instead of the hash, which I'd see as a
> bigger issue.

That issue does need to be fixed yeah, please file a separate bug
report about that issue.

> Note that Libravatar has a privacy policy in
> place: https://www.libravatar.org/privacy/

This privacy policy and your practices are different to Debian's, for
example we don't log IP addresses by default, we don't use cookies or
JavaScript by default, we prefer to use static HTML by default, we have
Tor Onion sites, we delete old logs after a short period of time etc.

> Libravatar is a community driven project with a lot of eyes on it and
> we're fully committed to stay neutral; Read: We're not going to share
> or sell data.

I expect the Libravatar community is definitely trustworthy in general,
but visitors to Debian websites shouldn't have to review the privacy
policies and trustworthyness of third-parties when visiting our sites.

> I do understand people are concerned about privacy - I am too and
> that was one of the reasons why I stepped in as the core maintainer
> when fmarier decided to give up on the project and even added an
> option to proxy requests to Gravatar instead of redirecting.

Thanks for that work, I'm glad Libravatar got rescued!

> Without digging much into it (esp. because I don't have the relevant
> modules + config in place), I'd say the script should work; No idea
> why it's currently throwing a server error.

The script in the git repository has execute permissions, but the
script on the server does not and this is reflected in the server logs.
Other folks on the IRC channel said it has been disabled due to
overloading the server, referring me to previous discussions. 

> > so I'll leave it up to the Debian BTS admins to check and respond
> > and maybe re-enable execution of the script again.
> Thanks for checking!

The Debian BTS admin has confirmed that the script needs fixing:

<dondelelcaro> pabs: yeah, the design of libravatar.cgi needs to be readdressed before it gets renabled

[Don Armstrong]

The basic code is working, but we were having performance issues which
is why it was disabled on bugs.debian.org.

I haven't had a chance to dig into exactly why it was failing, though
now that everything is using md5sum of the e-mail addresses, I think the
privacy concerns that were mentioned previously have been addressed.

It's not super high on my priority list to fix, but I'll try to get to
it when I have some time.

--
Don Armstrong https://www.donarmstrong.com

"You know," said Arthur, "it's at times like this, when I'm trapped in
a Vogon airlock with a man from Betelgeuse, and about to die from
asphyxiation in deep space that I really wish I'd listened to what my
mother told me when I was young."
"Why, what did she tell you?"
"I don't know, I didn't listen."
–- Douglas Adams _The Hitchhikers Guide To The Galaxy_

[Oliver Falk]

On Fri, Apr 8, 2022 at 2:10 AM Paul Wise <pa...@debian.org> wrote:

On Thu, 2022-04-07 at 12:39 +0200, Oliver Falk wrote:

> IMHO, the current solution doesn't really provide more security.

Its about not asking browsers to do third-party requests, which is the
policy for all Debian domains (where possible) and yes isn't a security
issue, but it is a privacy and trust issue.

Fair point and if that's the policy, it's perfectly fine.

 

> Currently, what happens is that the local CGI script is actually
> called with the mail address instead of the hash, which I'd see as a
> bigger issue.

That issue does need to be fixed yeah, please file a separate bug
report about that issue.

I thought about this again and well, this would actually break the federation :-{

 

> Note that Libravatar has a privacy policy in
> place: https://www.libravatar.org/privacy/

This privacy policy and your practices are different to Debian's, for
example we don't log IP addresses by default, we don't use cookies or
JavaScript by default, we prefer to use static HTML by default, we have
Tor Onion sites, we delete old logs after a short period of time etc.

> Libravatar is a community driven project with a lot of eyes on it and
> we're fully committed to stay neutral; Read: We're not going to share
> or sell data.

I expect the Libravatar community is definitely trustworthy in general,
but visitors to Debian websites shouldn't have to review the privacy
policies and trustworthyness of third-parties when visiting our sites.

Again, fair point!

[ ... ]

 

> Without digging much into it (esp. because I don't have the relevant
> modules + config in place), I'd say the script should work; No idea
> why it's currently throwing a server error.

The script in the git repository has execute permissions, but the
script on the server does not and this is reflected in the server logs.
Other folks on the IRC channel said it has been disabled due to
overloading the server, referring me to previous discussions. 

OK, that explains the server error.

 

> > so I'll leave it up to the Debian BTS admins to check and respond
> > and maybe re-enable execution of the script again.
> Thanks for checking!

The Debian BTS admin has confirmed that the script needs fixing:

<dondelelcaro> pabs: yeah, the design of libravatar.cgi needs to be readdressed before it gets renabled

Again, if I know exactly what is requested, I'm happy to help out with my coding knowledge!

Oliver

[Oliver Falk]

On Fri, Apr 8, 2022 at 6:27 AM Don Armstrong <d...@debian.org> wrote:

The basic code is working, but we were having performance issues which
is why it was disabled on bugs.debian.org.

I haven't had a chance to dig into exactly why it was failing, though
now that everything is using md5sum of the e-mail addresses, I think the
privacy concerns that were mentioned previously have been addressed.

When I checked it yesterday, the script was still called with the mail address !?

 

It's not super high on my priority list to fix, but I'll try to get to
it when I have some time.

Let me know if I can help you in some way, I'm happy to do so if I know what exactly is required.

Oliver

[Don Armstrong]

On Fri, 08 Apr 2022, Oliver Falk wrote:
> When I checked it yesterday, the script was still called with the mail
> address !?

The script is, but libravatar and gravatar are no longer called with the
mail address; they're all using the md5 of the e-mail address now. [The
script caches responses from libravatar and gravatar and serves them
directly, so there's limited leakage of information on who is visiting a
specific page.]

> Let me know if I can help you in some way, I'm happy to do so if I
> know what exactly is required.

Thanks! To be honest, I haven't looked at the issue recently, so I'll
have to dig in to see what was failing. [It's probably time to just have
it use mod_perl directly instead of the CGI-based mod_perl.]

--
Don Armstrong https://www.donarmstrong.com

If you wish to strive for peace of soul, then believe; if you wish to
be a devotee of truth, then inquire.
-- Friedrich Nietzsche

[Oliver Falk]

Hi!

Yes, libravatar never had the option to query with the plaintext identity for good reasons.

Again, if there is anything I can do, please let me know!

Oliver

--
To unsubscribe, send mail to 927012-un...@bugs.debian.org.

[Andrea Pappacoda]

Hi, I discovered this issue after seeing https://bugs.debian.org/950052
- in that report it seems that lamby's avatar is shown. So
libravatar.cgi isn't really disabled?

--
OpenPGP key: 66DE F152 8299 0C21 99EF A801 A8A1 28A8 AB1C EE49