kardan wrote 17 lines
On Sun, 3 Dec 2017 00:33:04 +0100
"Tomas Hajny" wrote:
> On Fri, December 1, 2017 00:55, kardan wrote:
> .
> .
> > In your case it would be probably enough to
> > sha256sum $FILES > SHA256SUMS.txt
> > gpg --sign SHA256SUMS.txt
>
> Sorry, but I'm afraid that you miss the point
In what way?
> adding checksums requires additional effort from release builders
Yes, to run a script. Like many others.
Then provide such a script that would cover all the cases. Simple, right?
> and they are not convinced about usefulness and/or necessity
FPC is a niche and if one intends to make it more widespread, best
practice should be followed. More users with slow connection will show
Let's say that I'm not convinced that being a niche or not depends on checksums...
up in the future. The best way to verify downloads after continuing a
download is a checksum. I am willing to learn other ways however, if
you teach me how to verify a download (not by just comparing file size).
At least .zip and .tar.gz files already contain checksums and the respective unpackers warn you in case of an incomplete file. Similarly, MS Windows would probably complain when trying to run an incomplete installer. I know next to nothing about .dmg files for Mac OS X, but I'm strongly convinced they would behave simmilarly. Ditto for .rpm packages. Have I forgotten something?
Show quoted text 10 lines
> this at the moment (especially if a secure download option is already
Secure download (HTTPS) does not provide verification. I use ansible
and travis a lot and when a download fails, the build fails. For
example composer silently accepts terminated connections as successfull
downloads. It uses the curl API internally which means the "modern"
curl won't tell you, if the load balancer terminates the connection
after 15 minutes. If your internet is fast enough, you are happy,
otherwise you end up with a file of 25mb instead of 40mb and notice that
tar and composer phar fail.
The FPC team isn't responsible for tools used by users. Regardless of the platform, most WWW browsers provide means for checking whether the download was successful / complete, or not. If somebody chooses to use broken tools, well, his or her choice.
> anybody may build the release on his own from the provided sources to
> make 100% sure about the consistency).
The source can't be downloaded with verification. Apart from that, do
It can - see above. Moreover, it's also possible to get the sources from the SVN repository (already HTTPS too).
you imply, that you intend to burden programmers with work the release
team should have done?
No, I say that people considering it important have ways for checking consistency. I would be very careful indeed if programming for a nuclear plant; most programmers are not in such a position.
> Nevertheless, if you consider this a priority, you can try to provide
> a complete solution
Is this a job offer? I can provide a cron script with no cost.
Yes, it's a job offer. You can get twice as much money for that job as I do for preparing the OS/2 releases and some other stuff - fair enough? ;-)
Show quoted text 6 lines
> While thinking about the solution, take the following into account:
>
> 1) Releases for all platforms are not created at the same time
It does not matter when and where files are created, just that they are
served along with valid checksums to verify downloads.
.
.
Alright, that approach assumes that the checksums are created at the build platforms. This implies that the tools used must be supported on all those platforms. I mentioned this point above because the other potential option would be collecting all release files first and running a script on all of them at once to reduce the dependencies and effort for release builders.
Show quoted text 5 lines
> 2) $FILES are scattered across a larger amount of subdirectories
It also does not matter how cross-mounted the server infrastructure is,
just that files are available and the checksum file is created from
actually present files by a cron job.
We can discuss this once the cron job exists. Obviously, a potential cron job needs to be sure that the file is already complete at the time this job runs. This is actually much more difficult than checking the consistency at the user side, btw (let's take the Windows installer as a nice example).
Show quoted text 5 lines
> 3) Release builds are being created by various people
See 1. The FTP master is on top of that and may ignore details about
creation of files as long as at the time of a download the provided
checksum is correct.
I talk about creation of the checksums, not the download time.
Show quoted text 5 lines
> 4) Releases are available from two groups of servers with different
> structure and different maintenance options. One group are SF.net
> mirrors, the other are FTP / HTTP mirrors of the FPC repository.
Is it really so hard to put a checksum file in the root folder?
Root of what? I guess that you already know by now that the 'root folder' wouldn't be very useful in the SF.net repository. ;-)
Tomas
