This PR updates SharpAESCrypt to version 3.0.0.
With this change the written format for encrypted fields in the database and the remote encrypted files will be changed to Stream Format v3, which improves the key deriviation function and includes additional safeguards regarding content length.
The library still supports reading v2 files, but will write all new files as v3.
Environment variables, as well as module options, can toggle this behavior.
# Environment variable overview
- `DUPLICATI__AES_VERSION`: The file format version, either 3 (default) or 2
-`DUPLICATI__AES_V3_ITERATIONS`: The number of Pbkdf iterations to apply (default 300k)
- `DUPLICATI__AES_MINIMAL_HEADER`: Writes AES files with a minimal header (saves ~100 bytes per file)
- `DUPLICATI__AES_IGNORE_PADDING_BYTES`: Legacy setting for reading files written by the mainline AESCrypt tool
# A note on iterations
The iterations protect a weak key by adding additional computational overhead, but only adds overhead if the key is already providing at least 256 bits of high entropy.
For low-power devices, such as 32-bit RPI, this can be set as low as 10k, which will lower encryption and decryption time. Beware that setting a low iteration count reduces security if the key is not sufficiently strong.
This updates all projects to target .NET Framework 4.7.1. The
TencentCOS and Tardigrade backends depend on .NET Standard 2.0. When a
.NET Framework prior to 4.7.1 is targeted, the system cannot be sure
that all the dependencies exist, so it copies all dependent assemblies
to the output directory. This causes many assemblies from the System
namespace to become bundled in the release.
https://stackoverflow.com/a/48875007
We had previously attempted to make individual projects target 4.7.1
(see pull request #4242), but this can cause compatibility issues when
4.6.2 projects depend on 4.7.1. projects.
This will require Mono 5.10.0 or greater (previously, we required 5.0.0
or greater).
https://www.mono-project.com/docs/about-mono/releases/5.10.0/#class-libraries
This fixes issue #4234.
- no code changes except those noted below
- projects upgrade to 4.6.2
- wixinstaller project upgraded automatically by VisualStudio
- wixinstaller updated to require 4.6.2
- Library.Encryption changed to Standard2.0 so accommodate update to SharpAesCrypt
Using strong-named assemblies can cause difficulties with the GNU LGPL
license, which allows for one to recombine or relink their application
with modified versions of the code. While one solution is to share the
private key so that people can sign the assemblies themselves, this
would break the trust that is expected from signed assemblies. For now,
the easiest fix is to simply not sign the assemblies. Note that by
doing so, we prevent the code from being referenced from other signed
assemblies.
This also fixes an issue introduced in revision ba94d36a80 ("Added
auto-update for WindowsService and Service."), where the WindowsService
project (signed) referenced the AutoUpdater project (not signed).
We also removed instances of <SignAssembly>false</SignAssembly> to be
consistent with newly created .csproj files that do not contain the
SignAssembly element.
This was motivated by the discussion in issue #2814.
