Kenneth Skovhede
a7ef8e42f2
This PR is a security hardning change and will break some setups. The hardning is done to ensure the datafolder is not compromised and particularly that it is not maliciously seeded. The changes now **requires** that the datafolder is locked down with exact permissions, or Duplicati will refuse to use it. This is a change to prior functionality where the folder would simply be locked down if it was not already locked. Previously, a file named `insecure-permissions.txt` could be placed in the folder to instruct Duplicati not to set permissions. With this change that file is no longer supported. The only way to opt-out of the permission check is to supply `--allow-insecure-datafolder` or the environment variable `DUPLICATI__ALLOW_INSECURE_DATAFOLDER`. Once either of those are set, Duplicati will no longer check permissions and accept folders with other permissions. The setting can be applied to `preload.json`, but the file needs to be in a trusted location, which is either the directory with the binaries or the file pointed to by `DUPLICATI_PRELOAD_SETTINGS`. The setting cannot be placed in a `preload.json` file that is in an insecure folder as the folder is not read if the permissions are not correct. The previous paths `/usr/local/share/Duplicati/preload.json` and `C:\ProgramData\Duplicati\preload.json` are no longer supported as they cannot be guaranteed to be locked down. A `preload.json` in the datafolder is still supported, provided the folder passes the permission check (or the `--allow-insecure-datafolder` is passed to the executable). For most users, this should not cause any problems as Duplicati has been locking down the folders, so they should be correctly locked down already. The configuretool has been updated with a `secure-datafolder` command that can be used to force the correct permissions on a folder, in case the folder did not have the correct permissions. For some Docker setups it may not be possible to set the permissions and the check will fail. These setup will need to apply `DUPLICATI__ALLOW_INSECURE_DATAFOLDER=true` in the image to run without the protections.
Release Builder tool
This folder contains the ReleaseBuilder tool which builds installers and packages for all supported operating systems.
The tool is tested and used only on MacOS, but can be configured for other operating systems, including WSL and to some extent Windows.
The setup is a mix of environment variables, settings files and commandline arguments.
Required environment
The environment variables used by the tool are:
UPDATER_KEYFILE: The file containing the key used to sign the manifest. Create one with thecreate-keycommand.GPG_KEYFILE: A file encrypted with AESCrypt and the general password. The file has two lines:GPGIDandGPGPassphrasewhich are given to theGPGcommand.AUTHENTICODE_PFXFILE: A PFX file containing a signing key for Authenticode signing of Windows executables (needs to be purchased at a certificate vendor).AUTHENTICODE_PASSWORD: A file encrypted with AESCrypt and the general password. The file contains a single line, which is the password used forosslsigncodeGITHUB_TOKEN_FILE: A personal access token for Github API used to create releases and upload packages to Github.DISCOURSE_TOKEN_FILE: A personal access token for Discourse, used to create release posts.CODESIGN_IDENTITY: The identity used for MacOScodesignwhen signing the binary packages.NOTARIZE_PROFILE: The name of the profile used for notarizing MacOS packages.AWS_UPLOAD_PROFILE: The name of the AWS profile (fromaws-cli) used to upload packages.AWS_UPLOAD_BUCKET: The name of the bucket where the package are uploaded to.RELOAD_UPDATES_API_KEY: A key used to refresh the manifest files being cached by the update servers.
Tools used
These tools are used by the build process, each tool can be changed by using the environment variable name:
DOTNET=dotnet: Mandatory. Used to build the binary contents that will be packaged.GPG=gpg: Optional. Used to created signed release files.SIGNTOOL=osslsigncode: Optional. Used to make Authenticode signing of Windows executables (usingSIGNTOOL=signtool.exeon Windows)CODESIGN=codesign: Optional. Used to sign MacOS binaries and packages.PRODUCTSIGN=productsign: Optional. Used to sign MacOS packages.WIX=wixl: Optional. Required to build the Windows MSI packages.DOCKER=docker: Optional. Required to build some Linux packages.
Invoking the tool
The tool has commandline documentation, which can be invoked with dotnet run help.
The two commands that are currently implemented are:
dotnet run create-keydotnet run build <channel>
The create-key command creates a RSA 1024 bit signing, and encrypts it with the given password.
The build command creates the packages. An example command that builds all packages would be:
dotnet run build debug --version 1.0.0.1
To build only a single platform relase, disable all the features and choose the architectures:
dotnet run build debug --version 1.0.0.1 \
--disable-docker-push true \
--keep-builds true \
--disable-authenticode true \
--disable-signcode true \
--disable-notarize-signing true \
--disable-gpg-signing true \
--disable-s3-upload true \
--disable-github-upload true \
--disable-update-server-reload true \
--disable-discourse-announce true \
--targets win-x86-gui.zip \
--targets win-x64-gui.zip \