On Sun, 3 Dec 2017 00:33:04 +0100 "Tomas Hajny" <xhaj...@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 _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
