| Commit message (Collapse) | Author | Age | Files |
|
|
|
|
|
|
| |
This silences the following deprecation warning:
Use 'ansible.utils.ipaddr' module instead. This feature will be removed from ansible.netcommon in a release after 2024-01-01.
Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
|
| |
|
|
|
|
| |
See https://salsa.debian.org/roundcube-team/roundcube/-/commit/f1e89494e8b777d69564e67f2d8b47ac84eb02f4 .
|
|
|
|
| |
Per https://salsa.debian.org/roundcube-team/roundcube/commit/7df02624eec4857053432d8ebe9b4e2b36f22bc5 .
|
| |
|
| |
|
|
|
|
| |
use_fallback_verifier/trusted_mtas.
|
|
|
|
| |
This was forgotten after a092bfd947773281a23419ee0ab62358371b7166.
|
| |
|
|
|
|
|
|
|
| |
This adds the following two ciphers:
ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We leave dynamic pages (those passed to PHP-FPM) alone for now:
compressing them would make us vulnerable to BREACH attacks. This will
be revisited once Roundcube 1.5 is released: 1.5 adds support for the
same-site cookie attribute which once set to 'Strict' makes it immune to
BREACH attacks:
https://github.com/roundcube/roundcubemail/pull/6772
https://www.sjoerdlangkemper.nl/2016/11/07/current-state-of-breach-attack/#same-site-cookies
|
|
|
|
|
| |
$ find -L /usr/share/roundcube/{plugins,program/js,program/resources,skins} -xtype f -printf "%f\\n" \
| sed -r "s/^([^.]+)(.*)/\1\2\t\2/" | sort -k2 | uniq -c -f1
|
| |
|
|
|
|
| |
They don't appear to be supported anymore.
|
|
|
|
|
| |
It doesn't integrate too well with the new elastic theme at the moment.
https://github.com/corbosman/keyboard_shortcuts
|
|
|
|
|
| |
We use the version from buster-backports (currently 1.4.4+dfsg.1-1~bpo10+1)
for the elastic theme.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We only serve whitelisted extensions (css, js, png, etc.), and only for
some selected sub-directories. Access to everything else (incl. log
files and config files) is denied with a 404. This is unlike upstream's
.htaccess file, which blacklists restricted locations and happily serves
the rest:
https://github.com/roundcube/roundcubemail/blob/master/.htaccess#L8
To find out which extensions exist on the file system, run
find -L /var/lib/roundcube/{plugins,program/js,program/resources,skins} -type f \
| sed -n 's/.*\.//p' | sort | uniq -c
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following policy is now implemented:
* users can use their SASL login name as sender address;
* alias and/or list owners can use the address as envelope sender;
* domain postmasters can use arbitrary sender addresses under their
domains;
* domain owners can use arbitrary sender addresses under their domains,
unless it is also an existing account name;
* for known domains without owner or postmasters, other sender addresses
are not allowed; and
* arbitrary sender addresses under unknown domains are allowed.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Instead, lookup the pubkeys and compute the digests on the fly. But
never modify the actual header snippet to avoid locking our users out.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Clients now have to use the NAMESPACE extension [RFC 2342] to discover
mailboxes under the “virtual/” namespace. (Plus an extra LIST command,
causing an overhead two roundtrips.) Of course the downside is that non
namespace-aware clients lose access to the “virtual/{all,flagged,…}”
mailboxes, but on second thought it's probably better this way rather
than having such clients treat these mailboxes as regular mailboxes.
|
|
|
|
| |
To avoid new commits upon cert renewal.
|
|
|
|
|
| |
We should use IPSec instead, but doing so would force us to weaken
slapd.conf's ‘security’ setting.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
locally.
And use this to fetch all X.509 leaf certificates.
|
| |
|
| |
|
|
|
|
| |
'block-all-mixed-content'.
|
|
|
|
| |
Per user request: https://wiki.fripost.org/tracker/CSP_too_strict/
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
See https://securityheaders.io .
|
| |
|
| |
|
| |
|
| |
|