Re: [boost] What is http://downloads.sourceforge.net/boost/boost_1_63_0.tar.bz2 ?

Subject: Re: [boost] What is http://downloads.sourceforge.net/boost/boost_1_63_0.tar.bz2 ?
From: Jonathan Wakely (jwakely.boost_at_[hidden])
Date: 2017-02-09 11:53:30

On 7 February 2017 at 22:07, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:
> On Tue, Feb 7, 2017 at 11:12 PM, Jonathan Wakely
> <jwakely.boost_at_[hidden]> wrote:
>> On 28 January 2017 at 09:26, Olaf van der Spek wrote:
>>> On Sat, Jan 28, 2017 at 3:40 AM, Jonathan Wakely
>>> <jwakely.boost_at_[hidden]> wrote:
>>>> The Fedora RPM spec file was changed to use the redirecting URL years
>>>> ago, long before I took over maintenance of the package. It didn't
>>>> occur to me to verify it (since it was definitely a sourceforge.net
>>>> URL and for the boost project, and it seems  that until the CI
>>>> snapshots last summer it *was* getting the correct file).
>>>
>>> Doesn't the hash get verified, automatically, after downloading?
>>
>> No, because you don't download the file every time you build the RPM.
>> That would be a problem if the upstream went offline, for example.
>>
>> Instead the source tarball is downloaded once when updating the
>> package to a new version (which I did using the problematic URL in the
>> Subject) and then stored on Fedora's servers, and in future is pulled
>> from there when building an SRPM (at least using the standard
>> packaging workflow).
>
> Even if you trust Fedora infrastructure (and thus don't check the hash
> when the archive is downloaded from there), the hash should still have
> been verified when the archive was first downloaded from SourceForge.
> At that point updating the Fedora servers should have failed.

Checking the hash is a manual process that should be done by the
maintainer, it can't cause updating the Fedora servers to fail (the
infrastructure can't check the hash because it doesn't know what to
compare it to). I screwed that up for the first cycle of rebuilds I
did for Boost 1.63.0.

But this is not the main point. Having archives called
boost_1_63_0.tar.bz2 that are something completely different to boost
1.63.0 is just wrong. That should be self-evident. Putting "snapshot"
in the name would avoid any confusion (and would not require
generating a new name every day, which Rene has said would be
difficult).