Re: [Bug] Re3gression in setup handling of SHA512 checksum failures

[Brian Inglis]

On 2018-03-22 08:41, Ken Brown wrote:
> On 3/21/2018 8:35 PM, Brian Inglis wrote:
>> On 2018-03-21 12:14, Ken Brown wrote:
>>> On 3/20/2018 4:11 PM, Achim Gratz wrote:
 Ken Brown writes:
> I'll look into both of these issues, unless Jon beats me to it.

 Thanks.

> By the way, this only affects local installs.  For network installs,
> the hash gets checked at an earlier stage.

 That's correct.  I forgot to mention that, but all my installs are from
 a local mirror (necessary due to the way network access is restricted at
 my workplace)
>>>
>>> I haven't been able to come up with a safe way to recover from a checksum 
>>> error
>>> at this point, at least not without a lot of work.  I propose that we just 
>>> bail
>>> out with an appropriate error message in this situation.
>>>
>>> Patch attached.
>>
>> Skipping a single package install is likely to be /relatively/ safe, but if 
>> this
>> patch causes setup to exit sometime after upgrading a bunch of packages but
>> before upgrading another bunch of packages, it could leave Cygwin unusable,
>> especially if there are upgrade dependencies between the packages installed
>> prior and not installed after the problematic download.
>>
>> It would be better in such cases to check all the hashes before proceeding 
>> with
>> any of the installs
> 
> We already do that.  My patch deals with the situation where we find a corrupt
> file during this process.

Sorry, it sounded like the check was happening during the install action,
instead of before. The process has changed now the solver is being used.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

Re: [Bug] Re3gression in setup handling of SHA512 checksum failures

[Jon Turney]

On 21/03/2018 18:14, Ken Brown wrote:

On 3/20/2018 4:11 PM, Achim Gratz wrote:

Ken Brown writes:

I'll look into both of these issues, unless Jon beats me to it.


Thanks.


By the way, this only affects local installs.  For network installs,
the hash gets checked at an earlier stage.


That's correct.  I forgot to mention that, but all my installs are from
a local mirror (necessary due to the way network access is restricted at
my workplace)


I haven't been able to come up with a safe way to recover from a 
checksum error at this point, at least not without a lot of work.  I 
propose that we just bail out with an appropriate error message in this 
situation.


Patch attached.


Thanks.

Yeah, this seems entirely reasonable.

Even the previous behaviour is wrong in unattended mode, i.e. 'setup -q 
-P foo -L' should definitely stop with an error if the package for foo 
is corrupt, rather than silently doing our best.

Re: [PATCH setup] Link with -lws2_32 again

[Jon Turney]

On 20/03/2018 21:42, Yaakov Selkowitz wrote:

libgpg-error 1.28 includes new APIs which use socket functions, which
on Win32 are provided by WinSock2.

https://cygwin.com/ml/cygwin/2018-03/msg00306.html

Signed-off-by: Yaakov Selkowitz 



Thanks.  Applied.

Re: [Bug] Re3gression in setup handling of SHA512 checksum failures

[Ken Brown]

On 3/21/2018 8:35 PM, Brian Inglis wrote:

On 2018-03-21 12:14, Ken Brown wrote:

On 3/20/2018 4:11 PM, Achim Gratz wrote:

Ken Brown writes:

I'll look into both of these issues, unless Jon beats me to it.


Thanks.


By the way, this only affects local installs.  For network installs,
the hash gets checked at an earlier stage.


That's correct.  I forgot to mention that, but all my installs are from
a local mirror (necessary due to the way network access is restricted at
my workplace)


I haven't been able to come up with a safe way to recover from a checksum error
at this point, at least not without a lot of work.  I propose that we just bail
out with an appropriate error message in this situation.

Patch attached.


Skipping a single package install is likely to be /relatively/ safe, but if this
patch causes setup to exit sometime after upgrading a bunch of packages but
before upgrading another bunch of packages, it could leave Cygwin unusable,
especially if there are upgrade dependencies between the packages installed
prior and not installed after the problematic download.

It would be better in such cases to check all the hashes before proceeding with
any of the installs


We already do that.  My patch deals with the situation where we find a 
corrupt file during this process.


Ken