Using the .NET 4.0 version did not solve the issue.
wyUpdate downloads from S3 now failAnswered
The same update files (including the .wys file) that could be successfully downloaded by wyUpdate from S3 a week or 2 ago now fail. The same goes for our legacy versions of the application that have been there for years. I can successfully download the .wys from the same URL in my browser.
Error trying to save file: Error downloading [URL]: The remote server returned an error: (403) Forbidden.
Yes, they're still publicly accessible as mentioned above.
I assume using the .NET 4.0 (if I'm already not) version of wyUpdate might be a temporary fix, as mentioned in some other similar posts. If that's the case, is there any option where I can get things to work temporarily in order to get the right version of wyUpdate.exe to my existing users?
The downloads seem to work every once in a while. If I run wyUpdate over and over, it typically fails and then here and there the .wys will get checked successfully. I also had one instance where the update was also download successfully. It's not related to my internet, as other users are experiencing the same update failures.
I confirmed that the issue is, as expected from other posts, the use of TLS 1.0 and not using strong cryptography.
Setting the following registry keys (which is not a solution) allowed the download to happen, when using the .NET 2.0 version of wyUpdate:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.5072]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001It appears to me that updating wyUpdate is the proper fix here.
I am experiencing the same issue. I believe it is triggering now because Amazon is in the process of removing support for TLS 1.0 and 1.1 from all AWS endpoints. This is a gradual process rather than a big bang all at once and Amazon do not expect to be complete until end of year. So the intermittent nature of the fails will likely get progressively worse.
Answer
Here's a very comprehensive post on what your workaround options are for getting downloads from S3 to work.
Unfortunately, I saw another post in the forums here by the wyDay team that they will stop supporting S3 in wyBuild, considering it as using “non-standard” protocols. I suppose that's true in the sense that S3 has its own file API, but the API is using current protocols. The S3 uploads would work fine if using modern TLS. With S3 being so ubiquitous, I've got to wonder.
If they're going to drop support for S3 uploads in wyBuild, I'm curious if they intend to update HTTP file downloads in wyUpdate to fix the above issues. The response for these sorts of issues has been “No hard date. ASAP." for quite a while.
Reading this post from them gives a very clear view about their stance on the product. And paying attention to the tone of the responses there, plus the tone in other forum answers to questions, it leaves me very confused.
I probably would've stuck around for that “new direction” like many others, and would've paid them more money for better support of the current version of the product, like many others have said too.
So, if they're wanting to widen their target market, I don't understand why they interact with us like they do.
We support and will continue to support HTTP, HTTPS, and FTP for downloads from wyUpdate.
We support and will continue to support FTP, SFTP (aka SSH FTP) and FILE for uploads in wyBuild.
Azure, Amazon, and Google all have proprietary APIs that we don’t care to support.
These products & companies also support SSH to upload files. You might have to jump through hoops to enable it, but that’s a them-problem. So, because these companies support both a standard protocol (SSH FTP) and proprietary protocols, why would we waste our time, effort, and money supporting the proprietary protocols?
So, long story short: we’re dropping unstable (ever changing) proprietary APIs in favor of standards (like SSH).
Downloading from S3 and uploading to S3 will still work. You'll just have to use open standards.
Make sense?
@Wyatt O'Day Uploading to S3 is not the issue here, we can work around the S3 upload issues by using Cyberduck to upload as you mentioned in other posts (or in my case I was able to write code to do it using the AWSSDK). So uploads to S3 is fine as we have workarounds.
The problem now is that wyUpdate.exe downloads have since last week become flaky, intermittently throwing 403 errors even though my download site is specified with a HTTPS URL for the S3 bucket in the Download Sites screen. Why doesn't the HTTPS URL continue to work?
(I have also selected the “Use wyUpdate built for .Net 4.0” option).
It appears to be that wyUpdate.exe v2.6.18.4 is still defaulting to TLS 1.0 which Amazon have recently begun to retire support for. So should downloading from S3 still work? Or is there some config I am missing? Or do you know of a workaround?
Covered on our forum many times: https://wyday.com/forum/t/3882/error-downloading-could-not-create-ssltls-secure-channel/#post-22523
Next version will not be .NET, and thus will not have this problem (.NET is a disaster).
Same situation here. As above, have read around. Given breaking the chain of updates is an existential issue for updater software, I want to ensure I understand all the moving parts here.
1. The fix is to update the settings that produce the “built” `wyupdate.exe` that we bundle with our app.
But
2. This updated `wyupdate.exe` can only be included in new installers, not the updates. So this isn't a retrospective fix? i.e. the update chain will break for existing users?
i.e. Build wyUpdate & Updates > "You must to rebuild wyUpdate (the updater) for every new version of your software. You can include the generated wyUpdate.exe and client.wyc files with your installer, but you can only include the "client.wyc" file in your updates (not wyUpdate.exe)."
3. Also, if registry changes are required on the wyUpdate building machine, then that suggests it's a custom binary. But wyUpdate has an updater for itself, with a default presumably serving a single `wyupdate.exe` binary to all, from wyday servers?
i.e. File > Properties > wyUpdate > “Add a site (or sites) that will host the server file for wyUpdate. This server file will be downloaded by wyUpdate to check for updates to itself. Leave this list blank to use the default servers.”
@Wyatt O'Day Your answer is “I've answered this before” and you link to another post where you say you've answered before, giving the bare minimum amount of information to almost be helpful. That plus the tone in the response. Sure, after some digging, I did find some related conversations and actually, the helpful response is from one of your other users (Sonny B) that I linked above, not from your team.
The thing is, these TLS issues didn't just start happening; here's a post from 5 years ago (where you also said "This has been discussed multiple times on here"). TLS 1.0 has been deprecated for years. I get it that this product is not your focus and fixing it takes money, but we have no idea if we'll ever get a proper fix. And not being upfront that the workaround is entirely either customer-side or end-user side, causes obvious issues in smooth transition of software, and isn't even properly documented or communicated. And then responding to us with the attitude that we're not reading enough of the other forum posts asking for help: give full answers somewhere, instead of half answers everywhere.
Remember, all of your users are also software developers with software products. We also have to support users and communicate solutions.
Answer
Unfortunately .Net was sold as a technology that compile-once and run anywhere. But it has never lived up to that promise.
It’s a bust for anything but business/CRUD apps. For multi-purpose tools, like wyUpdate, it’s been a disaster.
The newer .net versions are worse versions of the original vision (now you include the whole damn framework with your app).
The solution to the TLS problem has been described in detail multiple times and linked to multiple times (searching the forum will take you to any of a dozen of the exact same discussion).
So, use the registry key to fix it. Yes, it fixes it system-wide. The customers don’t care.
This is a known problem with a known solution. No immediate action is needed by us.
The next version of wyUpdate doesn’t use .Net (it’s a native app that’s an order of magnitude faster, smaller, and doesn’t require bending over backwards to use — no external frameworks needed, no configuration fiddling needed).