[fpc-pascal] FPC 3.0.4 released!
kardan at riseup.net
Sun Dec 3 18:49:18 CET 2017
On Sun, 3 Dec 2017 00:33:04 +0100
"Tomas Hajny" <XHajT03 at hajny.biz> 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.
> 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
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).
> 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.
> 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
you imply, that you intend to burden programmers with work the release
team should have done?
> 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.
> 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.
> 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.
> 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.
> 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?
> would need to think where the potential SHA256SUMS.txt file should be
> stored on both of these groups (or how else it should be made
Yes please, every mirror should provide a signed checksum file.
More information about the fpc-pascal