Feature: Autoupdate on all platforms, here: WinSparkle

[purejava]

This is the first part to provide Autoupdate for Cryptomator.

This PR requires an extension to the integrations-api (thanks to @infeo and the other Cryptomator devs for their help on how to use the optional integrations-api interfaces): cryptomator/integrations-api#15

and a reflection of the change in integrations-win: cryptomator/integrations-win#16

Some notes on WinSparkle

WinSparkle is designed the way, that it brings up a pop-up (enable or disable the search for updates etc.) on the second start of an application / Cryptomator. So you have to start Cryptomator, end it and start it again to show the pop-up.

It might help to delete the according Registry entry Software\Skymatic GmbH\Cryptomator\WinSparkle for testing purposes as WinSparkle also knows, whether is has been started in the past and delays further pop-ups. WinSparkle stores all this in the Registry entries and deleting them brings up the pop-up on second start of Cryptomator. See: https://github.com/vslavik/winsparkle/wiki/Registry-Settings

WinSparkle expects a base64 encoded SHA1 hash of the installer binary copied to the appcast.xml, that contains information about updates. WinSparkle provides scripts to generate these hashes and the key pair needed as a starting point.

[purejava]

Part of #275.

[nrk-akjaer]

Using SHA1 hashes with DSA for signing doesn't exactly scream confidence in 2023. There are good reason why we're (finally) moving away from SHA1 and dumped DSA years ago.

If this is how seriously the author of WinSparkle takes security then I'm quite worried, and would at the very minimum evaluate the code before creating a dependency on it. The project also seems semi-dead and the author stated he hasn't had the time for it in years.

The fact that the PR to support better cryptography has been open since 2018, with the linked update issue being stale for a solid year now makes me worried if this is the right approach to doing auto updates.

If there's no progression on supporting non-deprecated cryptography, and WinSparkle get stuck with sub-par hashing (like SHA1) and asymmetric keys (like DSA) that is supported by Sparkle (from what I understand) - then maybe Auto-Updates should be implemented differently for Windows. Just because Sparkle is used a lot on MacOS, doesn't mean a similar library is the right one to use for Windows.

If you're gonna add features like these to an application meant to be a secure vault storage, it's kinda important that you don't create a weakness in update delivery that could potentially be exploited by an advanced actor to gain access if the target is high-profile.

Just my two cents.