This page collects known issues when running Offen and tries to give advice on how to fix or work around these issues.
- Login stops working after migrating an instance to new hardware
- Offen does not work when running behind a Cloudflare proxy
- Docker based deployment stops working after upgrading to v0.4.0 or later
GitHub issue 506
Starting with Offen version
v0.1.1 a bug got introduced that inadvertently tied hashed passwords and derived keys to the number of CPUs available on the host system. This means you would be able to move your instance to a host with the same number of CPUs easily, but once the new host had less or more CPUs, operator login would stop working.
While we can fix this issue for future versions and installs easily, there is no way for us to simply fix this for existing installs. We have, however implemented a workaround that allows you to migrate your instance to any new host without losing your ability to log in.
Assuming you have installed an Offen version in between
v0.2.0, you can work around this issue by doing the following:
- Find out the number of CPUs available to your host system when you first installed Offen. If you are using a VPS to host Offen, you can look up this value in your server specs. Alternatively you can use commands like
lscpu, run from the host system.
- Upgrade to Offen
- In your setup, define an environment variable called
OFFEN_ARGONNUMCPUOVERRIDE(this has to be a proper environment variable and cannot go into an
offen.envfile or similar) and set its value to the number of CPUs you found out in step 1.
You can now move your instance between hosts of any size. The environment variable needs to be set as long as any logins that have been created before the upgrade are still in use.
This bug does not bring security implications of any kind. Your passwords are always stored securely, no matter which version you installed. Any possible impact of the change in password hashing is solely performance related, and is likely to be non-noticeable to end users.
GitHub issue 564
Offen serves scripts with an SRI hash value to protect from MITM attacks on the content served. Some Cloudflare proxy settings seem to alter the contents of the script’s content, in turn failing the client side integrity check with an error message like this:
Failed to find a valid digest in the 'integrity' attribute for resource 'https://offen.mysite.org/vault/vendor-cdc94dde8f.js' with computed SHA-256 integrity '7h+DJVtMpNr1FVMcCV2spIwSjnKvTKLBR8VCunEO6IE='. The resource has been blocked.
If you cannot get the Cloudflare proxy to serve content unaltered, turning off the proxy can be your solution. If you rely on Cloudflare for handling SSL certifcates, you can also have Offen handle this for you instead.
You can still use Cloudflare for DNS with Offen. This only affects setups where the Cloudflare proxy is used.
GitHub PR 575
Up until v0.3.x, the
offen/offen Docker images were running the application as
root. This would theoretically allow malicious third party code injected into Offen through supply chain attacks to attempt a container escape and gain priviledged access on the Docker host (this has not happened in any Offen version). To prevent this from potentially happening in the future, all images published as v0.4.0 and later run the application as a dedicated, non-priviledged
If you are using the
offen/offen Docker image using a SQLite database and want to migrate to v0.4.0 this requires changing ownership of the database file so that the
offen user can read and write to that file once updated. This migration likely requires some service downtime and we advise you to take a backup of your data before updating.
The steps required to perform are:
- Stop the running
- Using the same volume mount configuration as before (not part of the below command), you need to run the following command as
rootagainst the container:
chown -R offen:offen /var/opt/offen /etc/offen /var/www/.cache
When run using
dockerthis would look something like this:
docker run -v offen_db:/var/opt/offen \ -v offen_certs:/var/www/.cache \ --rm -it -u 0 \ --entrypoint chown offen/offen:v0.4.2 \ -R offen:offen /var/opt/offen /etc/offen /var/www/.cache
- Restart your service
If you run into problems doing this, roll back your service to use the previous image version which will still work. Open an issue on the GitHub repository or send us an email to firstname.lastname@example.org and we’ll try to help you getting this sorted out.
If you do not want to (or cannot) run the above migration steps, you can use the following workaround for now: for all v0.4.x releases we will publish
-root versions for each tag to Docker Hub. For example, migrating from
v0.4.0 is possible without any intervention by using the
We recommend applying the migration wherever possible. The
-root versions of the images are deprecated and will be dropped with