(build) Appveyor reports that SSL/TLS secure channel couldn't be created

[AdmiringWorm]

I've noticed on most appveyor build runs that 1 or more packages fail to check for update with the following error message:
The request was aborted: Could not create SSL/TLS secure channel.
A few times it fails with a different error message which may or may not be related:
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
The packages that fail are rarely the same one, so although it won't matter in the long run it's quite annoying.

A few reports that mentions this error:
https://gist.github.com/gep13/bd2eaa76f2a9ab739ca0544c502dca6e/af0268e9e5f3047ae1a0add0bb140bacd6e12fb9#errors
https://gist.github.com/gep13/bd2eaa76f2a9ab739ca0544c502dca6e/3bcc07e3f8efbd0619210b30e5a400ef44cd8d69#errors
https://gist.github.com/gep13/bd2eaa76f2a9ab739ca0544c502dca6e/479233b8fe410d64adba09db9e33b2dd5de554d1#errors

[gep13]

@AdmiringWorm do we know what version of Chocolatey is running on AppVeyor?

[pascalberger]

@gep13 0.9.10.3 is reported here

[gep13]

In which case, I think that is the issue. Newer versions of Chocolatey now better handles the SSL/TLS handshake.

[gep13]

I think what we need is a choco upgrade chocolatey step.

[gep13]

chocolatey/choco#458

Shipped in 0.10.1.

[AdmiringWorm]

I don't think it's related to choco, it happens when we try to get the upstream version (usually), so it's pure powershell

[AdmiringWorm]

Of course, we could just try upgrading choco on appveyor first and see if it helps.
But in that case, I think we should download the nupkg separately and cache it, just so we don't have to hit chocolatey.org on each build run.

[gep13]

If I understand that issue correctly, then what you are describing is the same problem. i.e. the upstream web server is using a newer version of TLS, which Chocolatey/PowerShell doesn't understand. The newer version of Chocolatey 0.10.1, jumps through some hoops to make it work. That is my rudimentary understanding though. @ferventcoder would obviously know more.

[AdmiringWorm]

If I understand that issue correctly, then what you are describing is the same problem

I guess I'm bad at explaining then, so lets try again.

The problem isn't with chocolatey, as its functions isn't used unless the update script uses automatic checksums (which Ghostscript.app doesn't (see the first link)).
Also AU sets the same security protocols as choco v0.10.1 does:
https://github.com/majkinetor/au/blob/master/AU/Public/Update-Package.ps1#L307 .
Another thing, if the server used a version of TLS that powershell didn't understand, then the same packages would fail at every single build run, which they don't (it almost seem random which package(s) fail on each run)

[AdmiringWorm]

I've updated the appveyor.yml file to see if it helps updating chocolatey, if it doesn't fail for a few runs I'm satisfied it fixes the issue and this issue can be closed.

[majkinetor]

Nah, updating chocolatey wont help as it obviously isn't related to it.

This looks suspiciously similar to what happens here:
https://sartorialsolutions.wordpress.com/2015/02/04/intermittent-the-request-was-aborted-could-not-create-ssltls-secure-channel-solved/

[majkinetor]

Detailed eventlogs I added showed this under SChannel:

Source      : Schannel
TimeWritten : 5/9/2017 6:10:49 PM
Message     : A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 20.

According to table I found here this is:

20
bad_record_mac 
Received a record with an incorrect MAC. This message is always fatal.

I guess this represents random network error that is unfixable per se. Option may be Ignoring on all packages such error, maybe repeating update.ps1 on AU level or wraping iwr in try{} except {} which is probably too mucch work.

I will leave eventlogs for now to see if this is the only error reported for packages that fail.

[AdmiringWorm]

I guess this represents random network error that is unfixable per se. Option may be Ignoring on all packages such error, maybe repeating update.ps1 on AU level or wraping iwr in try{} except {} which is probably too mucch work.

I've been thinking about this, doing it per package would be to much work I believe. But having an a way to tell AU to ignore package with such an error would be nice (perhaps allowing AU to accept a regex option for failure messages to ignore?)

[majkinetor]

I will try to find a time to add error settings (majkinetor/au#76). Feedback on how it would look like would be welcome.

[majkinetor]

I guess this represents random network error that is unfixable per se.

I do wonder why it happens so often tho. Perhaps its something related to too-many background jobs.

[AdmiringWorm]

I do wonder why it happens so often tho. Perhaps its something related to too-many background jobs.

that would be my guess, or it could be some kind of memory allocation failure (like it was mentioned in the blog post you've linked to previously)

[majkinetor]

I think this will happen rarely now and certainly not cause any errors because it is also in the ignore list. Here is the one sample output:

Repeating inkscape (1): System.Management.Automation.RuntimeException: au_GetLatest failed
The request was aborted: Could not create SSL/TLS secure channel.
Sleeping 250 seconds before repeating
   inkscape has no updates

Notice that build time will now be at least 5 minutes when this happens because of this 250s sleep that I intentionally set this way in order for all other packages to finish. We could experiment with this value and repeat count, its probably that just repeating is enough without any sleep and with this seetings we will not exceed 10 minutes per run with repeats in foreseeable future.