Can this particular URL be exempted from the User-Agent policy?

I don't think this has anything to do with the UA. Is the command correct? Maybe try downloading via curl/wget and then piping to gpg --import '. curl https://www.mediawiki.org/keys/keys.txt | gpg --import - works for me for example.

El T405165#11225510, @ssingh escribió:

I don't think this has anything to do with the UA. Is the command correct? Maybe try downloading via curl/wget and then piping to gpg --import '. curl https://www.mediawiki.org/keys/keys.txt | gpg --import - works for me for example.

I used tcpdump to inspect the traffic (using http instead of https URL) on both Debian and OpenSuSE, and no User-Agent was sent on Debian (see description).
I later confirmed the user-agent issue using curl to request the same URL, with the default user agent and also explicitly removing the user agent, with consistent results (failure when no user-agent was present)

How easy/difficult is to whitelist a specific path or URL? It was working before your (WMF) changes, requesting a particular static txt file shouldn't cause any significant amount of pressure on the servers, and retrieving it from gpg directly is very common. Debugging such a cryptic error message can be time consuming.

In T405165#11226025, @Ciencia_Al_Poder wrote:

El T405165#11225510, @ssingh escribió:

I don't think this has anything to do with the UA. Is the command correct? Maybe try downloading via curl/wget and then piping to gpg --import '. curl https://www.mediawiki.org/keys/keys.txt | gpg --import - works for me for example.

I used tcpdump to inspect the traffic (using http instead of https URL) on both Debian and OpenSuSE, and no User-Agent was sent on Debian (see description).
I later confirmed the user-agent issue using curl to request the same URL, with the default user agent and also explicitly removing the user agent, with consistent results (failure when no user-agent was present)

How easy/difficult is to whitelist a specific path or URL? It was working before your (WMF) changes, requesting a particular static txt file shouldn't cause any significant amount of pressure on the servers, and retrieving it from gpg directly is very common. Debugging such a cryptic error message can be time consuming.

OK, I revisited this again. It does make sense on why one fails (the one without the UA present at all) but not the other (the one with a default, even the generic one), so at least that adds up. There is no confusion there.

We are hesitant to add exceptions based on path and do require a UA to be set but let me check with the team on what they think about this one.

Change #1192210 had a related patch set uploaded (by Ssingh; author: Ssingh):

[operations/puppet@production] P:cache::haproxy: exempt mediawiki.org and /keys from UA policy

https://gerrit.wikimedia.org/r/1192210

@Ciencia_Al_Poder When you actually download the MediaWiki tarballs, as opposed to the GPG keys, would I be right in assuming they come from https://releases.wikimedia.org/mediawiki/ ?

Just thinking out loud that in theory another approach could be to move the location of the GPG key to match with the location of the releases files and then exempt that subdomain of wikimedia.org instead.

Yes, tarballs and signatures are downloaded from releases.wikimedia.org

I guess I should be trusting individual fingerprints and not assuming keys.txt hasn't been tampered, since they'll now reside on the same server/domain than the tarballs and signatures.