GitLab

Enabled trust-dns and some updates.

- Enabled trust-dns feature which seems to help a bit when DNS is
causing long timeouts. Though in the blocking version it is less visible
then on the async branch.
- Updated crates
- Removed some redundant code
- Updated javascript/css libraries

Resolves #2118
Resolves #2119

Macro recursion decrease and other optimizations

- Decreased `recursion_limit` from 512 to 87
  Mainly done by optimizing the config macro's.
  This fixes an issue with the rust-analyzer which doesn't go beyond 128
- Removed Regex for masking sensitive values and replaced it with a map()
  This is much faster then using a Regex.
- Refactored the get_support_json macro's
- All items above also lowered the binary size and possibly compile-time
- Removed `_conn: DbConn` from several functions, these caused unnecessary database connections for functions who didn't used that at all
- Decreased json response for `/plans`
- Updated libraries and where needed some code changes
  This also fixes some rare issues with SMTP https://github.com/lettre/lettre/issues/678
- Using Rust 2021 instead of 2018
- Updated rust nightly

Fix PostgreSQL migration

Fix missing encrypted key after emergency access reject

Fix conflict resolution logic for `read_only` and `hide_passwords` flags

The PostgreSQL migration should have used `TIMESTAMP` rather than `DATETIME`.

Rejecting an emergency access request should transition the grantor/grantee
relationship back into the `Confirmed` state, and the grantor's encrypted key
should remain in escrow rather than being cleared, or else future emergency
access requsts from that grantee will fail.

For one of these flags to be in effect for a cipher, upstream requires all of
(rather than any of) the collections the cipher is in to have that flag set.

Also, some of the logic for loading access restrictions was wrong. I think
that only malicious clients that also had knowledge of the UUIDs of ciphers
they didn't have access to would have been able to take advantage of that.

Add email notifications for incomplete 2FA logins

An incomplete 2FA login is one where the correct master password was provided,
but the 2FA token or action required to complete the login was not provided
within the configured time limit. This potentially indicates that the user's
master password has been compromised, but the login was blocked by 2FA.

Be aware that the 2FA step can usually still be completed after the email
notification has already been sent out, which could be confusing. Therefore,
the incomplete 2FA time limit should be long enough that this situation would
be unlikely. This feature can also be disabled entirely if desired.

Emergency Access cleanup

This commit contains mostly superficial user-facing cleanup, to be followed up
with more extensive cleanup and fixes in the API implementation.

Merge branch 'domdomegg/2fa-check-accepted' of https://github.com/domdomegg/vaultwarden into domdomegg-domdomegg/2fa-check-accepted

During a small discusson on Matrix it seems logical to have the /alive
endpoint also check if the database connection still works.

The reason for this was regarding a certificate which failed/expired
while vaultwarden and the database were still up-and-running, but
suddenly vaultwarden couldn't connect anymore.

With this `DbConn` added to `/alive`, it will be more accurate, because
of vaultwarden can't reach the database, it isn't alive.

Merge branch 'update-openssl-amd64-alpine' of https://github.com/BlackDex/vaultwarden into BlackDex-update-openssl-amd64-alpine

Recently the LetsEncrypt DST certificate has expired.
Older versions of OpenSSL like v1.0.x have issues using this certificate.

Recently clux has updated his image to support OpenSSL v1.1.1[a-z].
This solves issues with those certificates.

This issues was disscused on Matrix.

- Fixed a bug in JavaScript which caused no messages to be shown to the
user in-case of an error send by the server.
- Changed mail error handling for better error messages
- Changed user/org actions from a to buttons, this should prevent
strange issues in-case of javascript issues and the page does re-load.
- Added Alpine and Debian info for the running docker image

During the mail error testing i encountered a bug which caused lettre to
panic. This panic only happens on debug builds and not release builds,
so no need to update anything on that part. This bug is also already
fixed. See https://github.com/lettre/lettre/issues/678 and https://github.com/lettre/lettre/pull/679

Resolves #2021
Could also fix the issue reported here #2022, or at least no hash `#` in
the url.

This adds back-end support for the [single organization policy](https://bitwarden.com/help/article/policies/#single-organization).

Revert Debian images back to Buster.

This fixes #1998 where with some checking it seems Bullseye has some
issues with the glibc sleep call. It returns a SIGILL.

The glibc on Buster doesn't seem to have this issue, so revert back for
now until a fix has been released.

Merge branch 'domdomegg/support-no-data-org-policies' of https://github.com/domdomegg/vaultwarden into domdomegg-domdomegg/support-no-data-org-policies