[fpc-pascal] FPC 3.0.4 released!

[kardan]

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
> available).

Yes please, every mirror should provide a signed checksum file.

Thanks!
kardan