[fpc-pascal] FPC 3.0.4 released!

[Tomas Hajny]

On Sun, December 3, 2017 18:49, kardan wrote:
> 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.

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?


>> 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? ;-)


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


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


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


>> 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