(owncloud-client) package not up-to-date, autoupdate seems broken

[marcquark]

Expected Behavior

owncloud-client should be on the most recent version (2.6.3) and the package should auto-update

Current Behavior

The last version of the package according to https://chocolatey.org/packages/owncloud-client is 2.6.1, but the sources here indicate that the last successful auto-update was 2.6.0 https://github.com/chocolatey-community/chocolatey-coreteampackages/blob/master/automatic/owncloud-client/owncloud-client.nuspec

Possible Solution

Fix the auto-updater, i believe it would have to be adjusted because ownCloud changed their website layout

Steps to Reproduce (for bugs)

irrelevant

Context

irrelevant

Your Environment

irrelevant

[AdmiringWorm]

Fix the auto-updater, i believe it would have to be adjusted because ownCloud changed their website layout

It isn't a problem with the updater (from the looks of it).
There seems to be indeed some kind of change on the software developers' server, but the updater is still able to correctly detect both the new version and the URL for the binary file.

Unfortunately, when the updater is trying to validate the MSI installer the updater found, the server refuses the download due to an SSL/TLS handshake failure: https://gist.github.com/choco-bot/a14b1e5bfaf70839b338eb1ab7f8226f#owncloud-client
This failure has been happening for a few days (I looked into it a couple of days ago), and unfortunately, it isn't much we can do about it AFAIK.

but the sources here indicate that the last successful auto-update was 2.6.0

That most likely happened because of an origin timeout error when pushing the package to chocolatey.org (In these cases, the source isn't updated in the repository). That doesn't matter much, though.

[RedBaron2]

@AdmiringWorm
Could this possibly be related to issue #366 that had plagued lightworks earlier?

The same fix could help this package too.

[AdmiringWorm]

@RedBaron2 not relevant, as that fix went directly into AU and not in the lightworks package.

[RedBaron2]

@AdmiringWorm
I would like to point out that the lightworks package has this line
This is NOT implemented into AU at all.

Second using the same site SSL test as that issue. Download.owncloud.com server supports TLS 1.3

I'm suggesting that you try adding the line of code into the verification or the chocolateyinstall.ps1 file and test. If it works then you have solved the problem. If not then you are back to the drawing board.

My local version of this package of owncloud-client has never missed an update, but it is Windows 10 Pro not the appveyor server build.

[marcquark]

@RedBaron2 as far as i can tell, the problem isn't within the au_GetLatest method. Looking at the bot's output we can tell that it fails one step further down the road. I.e. it can successfully parse the download link for the newest version, but then fails to download the actual installer. So applying a fix to update.ps1 won't do much. I misread that. Looking at it again, i agree that line should be added to chocolateyinstall.ps1, at least for a test.

Most likely AU, or at least the environment it runs in, needs to be fixed. Somebody has a very similar issue here majkinetor/au#213 This will become a general problem as more and more webservers will drop TLS1.0/1.1 support completely.

Comparing the TLS configuration of owncloud.org and download.owncloud.com explains why update.ps1 runs fine: The former still supports TLS 1.0/1.1, while the latter doesn't...

Apparently this would not be an issue with recent versions of PowerShell/.Net. I'm not sure whether i fully understand dependencies/responsibilities here. Is AU developed and maintained as an independent project, but used for chocolatey community repository automation? If so, who operates that specific installation of AU? I believe it would be up to them to either migrate to a more recent environment or reconfigure the existing one accordingly. In any case, at least TLS1.2, better yet TLS1.3, should be supported and enabled.

[RedBaron2]

@marcquark
It fails in the au_beforeupdate section in the called AU function get-remotefiles, but could be switch solved possibly.
The line of code needs to be put in this section.

FYI:
The AU is a powershell module and a chocolatey package maintained by @majkinetor.
AU has built in functions developed to make automating package updating quick and easy.

[AdmiringWorm]

@RedBaron2 it is in AU: https://github.com/majkinetor/au/blob/0264eef17f0f428eeed8fbfafe3a93a226c3e5d3/AU/Public/Update-Package.ps1#L384

If I remember correctly, that line in lightworks was used to test what was necessary before implementing it in au itself.

In any case, at least TLS1.2, better yet TLS1.3, should be supported and enabled.

TLS1.2 is supported, both by AU and by the environment, otherwise every single package in this repository that would download anything (or parse) from github would be failing as it requires TLS 1.2.
Not sure about TLS1.3, not even sure if .NET have implemented support for it.

[marcquark]

Thx for elaborating guys, the picture is becoming clearer now :)

So, if it should work, what could be done to debug why the download from choco-bot is failing? Could somebody point me in a direction here, i.e. could i create some minimalist example and run it on AppVeyor, possibly trying out different environments? Or was that already done behind the scenes and boils down to "can't fix it"?

Would it be an option to update the package manually until a fix for choco-bot is available?

[RedBaron2]

@AdmiringWorm @majkinetor
Just curious but doesn't the automated appveyor tests use the alias function updateall not update ?

[AdmiringWorm]

@RedBaron2 yes, however the updateall script then calls the package script, and the package script calls update.

So, if it should work, what could be done to debug why the download from choco-bot is failing?

Honestly, I have no idea how to debug it, I have already tried to debug it both locally and by doing RDP to the appveyor instance. Both of these returned a successful update.

Could somebody point me in a direction here, i.e. could i create some minimalist example and run it on AppVeyor, possibly trying out different environments?

Different environments have been tested in the past, originally the WMF5 image was used, but this caused problems in some rare cases and was changed to use the Visual Studio 2015 image. The Visual Studio 2017 image was also tried, but there was no difference between the VS2015 and VS2017 images, so the default one was used instead (Visual Studio 2015).

Would it be an option to update the package manually until a fix for choco-bot is available?

That is only an option if there is a user associated with the package (other than the chocolatey user), and it would be his/her responsibility to keep it up to date in that case.
None of the people normally working on this repository have any access to push on the behalf of the chocolatey user outside of the appveyor instance.

[RedBaron2]

@AdmiringWorm @marcquark
Confirmed and tested via Appveyor
The only change was to update the image to either Visual Studio 2017 or Visual Studio 2019 both seem to allow the update to progress correctly.
I would suspect that the older WMF5 and Visual Studio 2015 don't allow the newer ciphers required for owncloud.com

[AdmiringWorm]

@RedBaron2 thanks for checking that out.
I checked out which servers each image is now running on, and that seems to have changed since the last time I checked (last time I checked both VS2015 and VS2017 was running on Windows Server 2012 R2).
Using the VS2019 image is a nogo, as it does not have Windows PowerShell installed, only PowerShell Core.
I will give it a shot and change the image to VS2017 and see if it helps (I will only update the image on the updater, not the one that runs on pull requests as we want to test those on Windows Server 2012 R2 scratch that, I forgot the updater and the tester ran with the same appveyor file).

[AdmiringWorm]

Looks like updating the appveyor image used worked, thanks again @RedBaron2 for looking into it.

I will be closing this issue now as I noticed the updater mentioned that the latest version was pushed (it will take a few hours before it is available without a version argument).

[AdmiringWorm]

Re-Opening as the latest version is failing due to invalid mailing list/forum url