wyUpdate can't/won't self-updateAnswered

We haven’t released a new version. So there’s nothing to self-update.

Regarding your own self-updates make sure your server supports the old TLS protocols supported by the old .NET version.

I am baffled why you have continued to make commits to wyUpdate (including commits that fix the very problem we are having, e.g. commit 60cccd3 on 14 April 2020) if you have no intention of releasing any updates to the 2012 version. If there is no new version it will be impossible to continue to use wyUpdate once TLS 1.0 and 1.1 are retired, which I have no control over. Eventually it will be impossible to find a server anywhere that allows TLS 1.0 and 1.1. We will not be leaving AWS (“make sure your server supports the old TLS protocols”) in favour of wyUpdate, compromised security, and delaying the inevitable.

We have no “self-updates”. According to your own documentation, wyUpdate performs self-updates (https://wyday.com/wybuild/help/faq.php “You should not include wyUpdate.exe in your updates — wyUpdate self-updates.”), which it can't do if no further updates are forthcoming. When functioning properly, it then updates our products.

Can you recommend an updater that will work in 2023 and beyond? And how do we migrate all existing installations from wyUpdate to a different updater? We will need to disable and remove wyUpdate once we have a replacement that works in a secure environment as it causes error in our applications when it fails.

Alternatively, can you suggest a path forward that will allow existing installations to continue to update with wyUpdate once TLS 1.0 and 1.1 are switched off? If you are not already aware, this article explains that AWS will disable TLS 1.0 and 1.1 by 28 June 2023: https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/ All old (and therefore current) versions of wyUpdate will cease to work on AWS at that point, leading to many upset customers. In order to prevent unexpected service disruptions, AWS recommends switching now which we are attempting to do.

It took us 4 days to build this workaround. Multiply your daily rate by 4 to work out how much it cost us, and how much it would cost you to work out an equivalent solution from scratch without wyDay's help.

If you are reading this after 28 June 2023 and your AWS hosted solution has suddenly stopped updating, know that Wyatt O'Day was aware of this issue 9 months before it happened and chose to not take it seriously. One day TLS 1.3 (the latest version at the time of writing) will be deprecated and unsupported. But Wyatt O'Day thinks TLS 1.0 will be supported forever which is why he doesn't see the need to release an update to wyUpdate to fix this issue.

Overview

Many wyUpdate deployments using Amazon S3 will fail on June 28, 2023 when Amazon enforces the TLS 1.2 minimum. 

From my investigation, using the .NET 4 version of wyUpdate is not enough. 

------------------------------------------------------

Known problematic workarounds

To get wyUpdate to use TLS 1.2, you also need to do one of the following (each of which has some downsides):

• Make registry changes (see wyBuild forum post)
  • 1) But in many cases it’s not practical to change a user’s system-wide registry settings given the user has other apps other than your own running on their device.
  • 2) the update will likely trigger UAC.
  • 3) potential IT complications (now or in the future, considering both enterprise and consumer environments)
  • Note that this is a somewhat recognized solution, at least on fully managed endpoints - see Microsoft Intune - How to enable TLS 1.2 on clients
• Target a newer version of .NET, e.g. commit 7774d60
  • But this requires deploying a custom version of wyUpdate
• Hardcode the TLS version change, e.g. commit 60cccd3
  • But this requires deploying a custom version of wyUpdate
  • Note that the user’s machine will still need the newer .NET runtime if wyUpdate was built targeting the older .NET 2 or .NET 4. (This may be a consideration on legacy environments.)
  • Note that hardcoding doesn’t follow Microsoft TLS best practices
• Use an app config file (see Appendix at end)
  • This seemed more promising than registry changes but there were some issues and downsides.

------------------------------------------------------

Tests

Here are some of my tests with wyUpdate + Amazon S3 bucket with TLS 1.2 enforced on an up-to-date Windows 11 device:

• .NET 4 (Aug 2012 - v2.6.18) commit b7b5a1d — fails as it defaults to TLS 1 connection
• .NET 2 (Aug 2012 - v2.6.18) commit b7b5a1d — fails as it defaults to TLS 1 connection
• .NET 2 (Dec 2020) commit 977ab4e - NotSupportedException due to hardcoding an unsupported TLS version (though perhaps the .NET 2 project is deprecated anyway)
• .NET 4.8 (Dec 2020) commit 977ab4e - Success, as expected with .NET 4.8

This is consistent with Amazon’s post on the TLS 1.2 change:

The most common use of TLS 1.0 or 1.1 are .NET Framework versions earlier than 4.6.2.

------------------------------------------------------

Possible solutions

The easiest solution for us would be if there was an official wyUpdate hotfix release that forks off of the Aug 2012 release to fix the issue... though it seems highly unlikely that wyUpdate will have a fix before the June 28 deadline, and it’s not clear to me what a “universal” fix is. Targeting a newer .NET and/or TLS version should be a quick and easy fix, but it could potentially affect wyUpdate customers in legacy environments.

Personally I’m leaning towards one of these solutions (or a combination of these solutions, given that being able to update is critical):

• Add Azure as an update server site because Azure still allows older TLS 1.0. The client.wyc file (with the list of server sites) is easier to update than wyUpdate.exe.
• Use Amazon CloudFront to allow older TLS connections
• (Long-term) consider moving to a different updater that is more actively maintained

For future readers, some links regarding .NET + TLS versions.

• https://stackoverflow.com/questions/34920429/is-tls-1-1-and-tls-1-2-enabled-by-default-for-net-4-5-and-net-4-5-1
• https://stackoverflow.com/questions/28286086/default-securityprotocol-in-net-4-5/28333370#28333370
• https://en.wikipedia.org/wiki/.NET_Framework_version_history#Overview

------------------------------------------------------

Appendix - wyUpdate.exe.config file

Another possible solution was using adding a config file, i.e. wyUpdate.exe.config file, but there were some issues:

• I had some test cases where it would have trouble establishing a connection with wyday.com for wyUpdate self-update .wyu patch files if there is a wyUpdate self-update available. (I was able to test this because I was testing with my own manual wyUpdate builds.) Thus, I think manually adding a config file like this has some downsides similar to “forking” your own custom version of wyUpdate. Note that if the self-update step fails, your app will not update either, so this seemed a bit risky.
• It’s a bit clunky to manually add a file like this to the project.
• You also need to be careful to target the appropriate .NET runtime, or the user will receive an error dialog prompt to install .NET.
• It's officially documented but it felt a bit brittle. Note that I didn't spend that much time testing it.

Some links regarding the config file:

• https://learn.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-configure-an-app-to-support-net-framework-4-or-4-5
• https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/startup/supportedruntime-element?redirectedfrom=MSDN#version
• https://kevinchalet.com/2019/04/11/forcing-an-old-net-application-to-support-tls-1-2-without-recompiling-it/
• https://www.koskila.net/how-to-force-an-outdated-net-project-to-use-tls-1-2/
• https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls#configuring-security-via-appcontext-switches-for-net-framework-46-or-later-versions

wyUpdate.exe.config example (to emphasize, this worked but I had some issues as noted above):

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <runtime>
   <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=false"/> 
   <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=false"/>
  </runtime>
    <startup>
     <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6"/>
    </startup>
</configuration>

Note:

• .NET 4 wyUpdate doesn’t require supportedRuntime for this to work. Only the .NET 2 wyUpdate requires this.
• Windows 10 ships with .NET 4.6, but you can also try a higher version of .NET if appropriate for your use case.
• .NET 4.6.2 or later is required for default TLS 1.2 connection if you don’t want to manually set AppContextSwitchOverrides.

------------------------------------------------------

Appendix - S3 Transfer Acceleration

S3 Transfer Acceleration should also work as it uses CloudFront. See this aws re:post question for details.

------------------------------------------------------

If anyone else is affected by the issue or has additional information, please share. Thanks.