This PR adds explicit validation to the size parameters so we ensure that we throw a meaningful error message instead of fail on some later step.
This also fixes an error in an exception message. Should the error scenario ever trigger, it would previously show incorrect data or cause out-of-bounds error instead of the intended error message.
This PR adds a check that prevents performing link lookups on drive roots as this is reported to fail on some Windows versions.
The PR also makes a link lookup failure a warning instead of failing the restore process.
The logic is now that the properties for each of the server settings are defined on the constant that triggers them, instead of splitting it across the API and internal database.
This makes it less error prone to introduce newsensitive server settings.
This PR adds support for generating a self-signed CA and then using that CA to generate TLS certificates.
A new tool `duplicati-configure` / `Duplicati.CommandLine.ConfigureTool.exe` is added to manage the certificates. The tool saves the configuration in the database and is meant to run with elevated privileges for the initial CA installation.
The option `--configure-https` can be added to server/trayicon, and if the process has permissions, this will automatically install the CA certificate.
If a CA is configured, the server will automatically issue, renew and use a TLS certificate.
With this setup, the TLS is opt-in, but once the flow is well tested, we can switch it to opt-out.
Add a synchronization point after recreating missing index files to
ensure all uploads are settled and committed to the database before
the backup process continues. This prevents a race condition where
the backup could start while index files are still being uploaded.
In this case, it would be possible for the backup to reference the file that is currently being deleted. This would be very rare in production as the delays have to align and the new data must be changed and processed very quickly to trigger the issue.
In unittests we have observed the issue for a while but only showing up very rarely.
Instead of requesting all scopes up front, each sub-section of the backup/restore will request the permissions that are relevant for the operation.
The effect is that it is not required to grant all permissions to get a backup running. If permissions are failing, that part of the backup will generate warnings for items that are excluded.
