Project

General

Profile

tickets #116638

checksum fails for downloaded ISO

Added by pjessen 2 months ago. Updated 2 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
Core services and infra
Target version:
-
Start date:
2022-09-15
Due date:
% Done:

0%

Estimated time:

Description

This issue has popped up every now and again, and also been the topic of a factory list thread, just this week.
The issue seems to be that mirrorcache issues redirects for certain (hardcoded) symlinks. I'm copying the most recent thread contribution by Andrei Borzenkov:

On 15.09.2022 20:34, Per Jessen wrote:
> Per Jessen wrote:
> 
>> Andrei Borzenkov wrote:
>>
>>> I am still unsure because the first redirection comes to the local
>>> file (not to a mirror), and I do not know whether this redirection is
>>> performed by mirrorbrain/MirrorCache or web server on download.o.o
>>> itself. But it does not really matter because the final name on
>>> mirrors will still include version.
>>
>> I've already checked the apache config pontifex, I'll do it again.
> 
> I have gone over the download.o.o apache config and I see nothing that
> does any redirection or rewriting based on symlinks.  I can only
> conclude it is being done by mirrorbrain/mirrorcache.  

For MirrorCache it apparently was added relatively recently:

commit 90e6bf65e20c49a96a974b1a504a2dcea750675f
Author: Andrii Nikitin <46994839+andrii-suse@users.noreply.github.com>
Date:   Thu Dec 9 07:09:53 2021 +0100

    Special handling unversioned media symlinks (#235)

    * Remove outdated variable MIRRORCACHE_COUNTRY_RESCAN_TIMEOUT
    * Improve test 04-remote-link
    * Try to use redirect for unversioned media symlinks
    * Track symlink with hashes for unversioned media files if in the
same folder
    * Do not calcuclate hashes for symlinks

I won't claim to understand what MirrorCache tries to do it for, but it
only does it for two files - -Media and -Current:

+sub _detect_ln {
+    my ($dir, $file) = @_;
+    return undef unless $file && $file =~
m/.*(Media|Current)\.iso(\.sha256)?/;
+

Tests added in the same commit expect that sha256 files are links

+echo now change the symlink and make sure redirect changes
+(
+    cd $ap9/dt/folder1
+    ln -sf file2.1-Media.iso file-Media.iso
+    ln -sf file2.1-Media.iso.sha256 file-Media.iso.sha256
+)
+$mc/backstage/job -e folder_sync -a '["/folder1"]'
+$mc/backstage/shoot
+$mc/curl -I /download/folder1/file-Media.iso        | grep -C 10 302 |
grep /download/folder1/file2.1-Media.iso
+$mc/curl -I /download/folder1/file-Media.iso.sha256 | grep -C 10 302 |
grep /download/folder1/file2.1-Media.iso.sha256
+$mc/curl -L /download/folder1/file-Media.iso.sha256 | grep -q
"2019dd7afaf5759c68cec4d0e7553227657f01c69da168489116a1c48e40270e  "

History

#1 Updated by pjessen 2 months ago

  • Category set to Core services and infra
  • Assignee set to andriinikitin
  • Private changed from Yes to No

#2 Updated by andriinikitin 2 months ago

  • Status changed from New to Feedback

Following scenarios were considered:
A. a user or script downloads openSUSE-Tumbleweed-DVD-x86_64-Current.iso and wants to check checksum of the file later at some point.
B. a script downloads openSUSE-Tumbleweed-DVD-x86_64-Current.iso and openSUSE-Tumbleweed-DVD-x86_64-Current.iso.sha256 .
C. a Download tool pauses download and then resumes.

Assuming that new .iso and .sha256 can be published any moment - consistent results are more likely to happen and troubleshooting will be easier when requests are get redirected to the particular version instead of delivering content under -Current label.
So MirrorCache has implemented behavior like that , e.g.:

# curl -I https://mirrorcache.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-DVD-x86_64-Current.iso.sha256
HTTP/2 302 
location: /tumbleweed/iso/openSUSE-Tumbleweed-DVD-x86_64-Snapshot20220914-Media.iso.sha256

Now (I must admit) that I didn't consider Apache on download.o.o would serve small files (i.e. .sha256 ) even before requesting MirrorCache, so current behavior of download.o.o is not as consistent as was planned.
I guess making an exception for .sha256 files in Apache config will solve the problem?
Or what logic can ensure consistent behavior in scenarios above?

#3 Updated by arvidjaar 2 months ago

andriinikitin wrote:

A. a user or script downloads openSUSE-Tumbleweed-DVD-x86_64-Current.iso and wants to check checksum of the file later at some point.
...

... requests are get redirected to the particular version instead of delivering content under -Current label.

Both

whet https://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-NET-x86_64-Current.iso

and

curl -LO https://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-NET-x86_64-Current.iso

store downloaded file under the original filename, even though they follow redirects for the file content. So in this case filename in the .iso.sha256 will be wrong.

bor@bor-Latitude-E5450:~/tmp/d.o.o$ LANG=C wget https://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-NET-x86_64-Current.iso.sha256
--2022-09-16 07:20:54--  https://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-NET-x86_64-Current.iso.sha256
Resolving download.opensuse.org (download.opensuse.org)... 2001:67c:2178:8::13, 195.135.221.134
Connecting to download.opensuse.org (download.opensuse.org)|2001:67c:2178:8::13|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-NET-x86_64-Snapshot20220914-Media.iso.sha256 [following]
--2022-09-16 07:20:55--  https://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-NET-x86_64-Snapshot20220914-Media.iso.sha256
Reusing existing connection to [download.opensuse.org]:443.
HTTP request sent, awaiting response... 200 OK
Length: 124 [application/x-download]
Saving to: 'openSUSE-Tumbleweed-NET-x86_64-Current.iso.sha256'

openSUSE-Tumbleweed-NET 100%[==============================>]     124  --.-KB/s    in 0s      

2022-09-16 07:20:55 (92.5 MB/s) - 'openSUSE-Tumbleweed-NET-x86_64-Current.iso.sha256' saved [124/124]

bor@bor-Latitude-E5450:~/tmp/d.o.o$ cat openSUSE-Tumbleweed-NET-x86_64-Current.iso.sha256 
35d5c061ebcd390d2296b4bb2db9ad74e805c9b91df57d9255d4890572785905  openSUSE-Tumbleweed-NET-x86_64-Snapshot20220914-Media.iso
bor@bor-Latitude-E5450:~/tmp/d.o.o$ 

ISO will be stored as openSUSE-Tumbleweed-NET-x86_64-Current.iso while checksum file has openSUSE-Tumbleweed-NET-x86_64-Snapshot20220914-Media.iso as file name.

This is chicken and egg problem - to store under the correct name you have know the correct name already at which point you just can download the correct name directly.

This will work correctly with current browsers which store downloaded file under the final redirected name. But not with scripts.

Now (I must admit) that I didn't consider Apache on download.o.o would serve small files (i.e. .sha256 ) even before requesting MirrorCache,

No, it is not the reason here. -Current.iso.sha256 is links for Tumbleweed, but for Leap 15.4 -Current.iso.sha256 and unversioned -Media.iso.sha256 are plain files and so are not redirected.

#4 Updated by robin_listas 2 months ago

I understand that the reason Apache on download.o.o serves the small .sha256 files, instead of the mirrors, is security. A rogue mirror could alter both the iso and the checksum.

Also available in: Atom PDF