MySQL Bugs: #97346: mysql-connectors-community and mysql-tools-community defect repo

Bug #97346	mysql-connectors-community and mysql-tools-community defect repo
Submitted:	23 Oct 2019 16:53	Modified:	26 Oct 2019 11:17
Reporter:	Paul Pech	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Package Repos	Severity:	S3 (Non-critical)
Version:		OS:	SUSE (SLES 12)
Assigned to:	MySQL Verification Team	CPU Architecture:	x86

Description:
The file 

repomd.xml

in directory

https://repo.mysql.com/yum/mysql-connectors-community/sles/12/x86_64/repodata/

contains the following lines:

<data type="primary">
<checksum type="sha">1d280d2739850246594b47ae9c81bc6608f382ab</checksum>
<open-checksum type="sha">e7304f0f7a6392c348e1efc66bac7a31f58f61d6</open-checksum>
<location href="repodata/1d280d2739850246594b47ae9c81bc6608f382ab-primary.xml.gz"/>
<timestamp>1570866411</timestamp>
<size>12507</size>
<open-size>255621</open-size>
</data>

Yet a file named

1d280d2739850246594b47ae9c81bc6608f382ab-primary.xml.gz

cannot be found in (...)/sles/12/x86_64/repodata/

As such this repository is deemed invalid for zypper installations or updates.

How to repeat:
Add mentioned repository to your list of repositories (with signature verification!) and zypper and or Yast2 will consider it an invalid repository as file 
1d280d2739850246594b47ae9c81bc6608f382ab-primary.xml.gz
cannot be found in the repository.

Hi!

Thanks for your report!

Can you please post 20 first lines or so of:

 http://repo.mysql.com/yum/mysql-tools-community/sles/12/x86_64/repodata/repomd.xml

I get:

<repomd>
<revision>1570770296</revision>
<data type="filelists">
<checksum type="sha">e86efa1aa6ebee02b4dfa1365e092cd1940c2f34</checksum>
<open-checksum type="sha">e413e547137aafd3074b5bdfdbb23ae413161a42</open-checksum>
<location href="repodata/e86efa1aa6ebee02b4dfa1365e092cd1940c2f34-filelists.xml.gz"/>
<timestamp>1570770307</timestamp>
<size>15225</size>
<open-size>261807</open-size>
</data>
<data type="primary">
<checksum type="sha">0ef1ceba5e00b15ab47198fbcc067f415c627d21</checksum>
<open-checksum type="sha">8ef99912515a44c6c598978e09e964b7f73ea43e</open-checksum>
<location href="repodata/0ef1ceba5e00b15ab47198fbcc067f415c627d21-primary.xml.gz"/>
<timestamp>1570770307</timestamp>
<size>7820</size>
<open-size>129911</open-size>
</data>

Can you please verify you got similar outpt?

If not, please make sure you don't have stale data.

Thanks for getting back to me!

After reviewing your comment, I now believe that the issue is with http vs. https connections.

If I connect to the repos using a plain http connection I get a valid repository listing. If I connect using https, I get the previously mentioned invalid repositories.

The repomd.xml files are the same, for both http and https:


Tools:  <revision>1570770296</revision>
Primary: 0ef1ceba5e00b15ab47198fbcc067f415c627d21-primary.xml.gz

Connectors: <revision>1570866407</revision>
Primary: 1d280d2739850246594b47ae9c81bc6608f382ab-primary.xml.gz

But the directory contents differ:

Tools https: No file named 0ef1ceba5e00b15ab47198fbcc067f415c627d21-primary.xml.gz
Tools http: File is present

Connectors https: No file named 1d280d2739850246594b47ae9c81bc6608f382ab-primary.xml.gz
Connectors http: File is present

If key verification for the repositories is enabled, then connecting with plain http is of no concern.

Should connecting with https be avoided? 

The issue was first detected on October 14th (on our side). Before that date, using the repositories with https worked fine.

Thanks,

Paul

Hi again!

I am not able to reproduce, both https:// and http:// works for me.

You have a direct connection or behind proxy?

Hi Paul,

http and https is the same repo, it's a possibility you are fetching a cached invalid version. As my colleague asked, do you have any proxy / transparent proxy between you and the internet? Any "antispam" dns appliances (for e.g. https://pi-hole.net/ is known to create issues with akamai content delivery). 

all best

Hi,

we're on a direct internet connection from Germany, no proxies, no DNS appliances, nothing fancy at all :-)

We use wget to get a local copy of the repositories, so I believe no caching should be involved.

I've now used Chromium to access the online repositories (subdir "metadata") and the difference between http and https is still there:

https dir listing for community-connectors (no file 1d280... to be found)
https://pastebin.com/pYxzP07p

http dir listing for community-connectors (file 1d280... can be found)
https://pastebin.com/VvzPKhqs

At them moment, repo.mysql.com resolves to 2.22.90.225 or 104.101.101.42.

If you need further information, I'll gladly provide it.

Thanks,

Paul

I'm resolving it as 2.18.69.79

and I see the proper files on https and http 

can you please put 2.18.69.79 in hosts and try out if you see proper repo that way? maybe there's a problem with some akamai servers and you cached the bad one :(

thanks

If I put 2.18.69.79 in my hosts file, file 1d280... is there. Both with http and https.

This is certainly a good workaround for now.

As previously mentioned this started on or around October 14th. Maybe it will resolve itself in a couple of days... We've been using your repositories since February this year, and until October no issues showed up.

Thank you for your fast support.

Yours,

Paul

Hi,

definitely some issue with akamai, not much we can do about it :(

all best