This updates to the latest version. According to the changelog 0.5.12
was skipped. The changes in this release are required to be compatible
with the latest dovecot release.
Changes:
- duplicate: The test was handled badly in a multiscript (sieve_before,
sieve_after) scenario in which an earlier script in the sequence with
a duplicate test succeeded, while a later script caused a runtime
failure. In that case, the message is recorded for duplicate tracking,
while the message may not actually have been delivered in the end.
- editheader: Sieve interpreter entered infinite loop at startup when
the "editheader" configuration listed an invalid header name. This
problem can only be triggered by the administrator.
- relational: The Sieve relational extension can cause a segfault at
compile time. This is triggered by invalid script syntax. The segfault
happens when this match type is the last argument of the test command.
This situation is not possible in a valid script; positional arguments
are normally present after that, which would prevent the segfault.
- sieve: For some Sieve commands the provided mailbox name is not
properly checked for UTF-8 validity, which can cause assert crashes at
runtime when an invalid mailbox name is encountered. This can be
caused by the user by writing a bad Sieve script involving the
affected commands ("mailboxexists", "specialuse_exists").
This can be triggered by the remote sender only when the user has
written a Sieve script that passes message content to one of the
affected commands.
- sieve: Large sequences of 8-bit octets passed to certain Sieve
commands that create or modify message headers that allow UTF-8 text
(vacation, notify and addheader) can cause the delivery or IMAP
process (when IMAPSieve is used) to enter a memory-consuming
semi-infinite loop that ends when the process exceeds its memory
limits. Logged in users can cause these hangs only for their own
processes.
While we already had some test we might as well add the test for that
exact package to the tests attribute set. After all that should be what
(primarily) tests dovecot.
This fixes CVE_2020-24386, CVE-2020-25725 and a bunch of regular bugs
[1].
* CVE-2020-24386: Specially crafted command can cause IMAP hibernate to
allow logged in user to access other people's emails and filesystem
information.
* CVE-2020-25275: Mail delivery / parsing crashed when the 10 000th MIME part was
message/rfc822 (or if parent was multipart/digest). This happened
due to earlier MIME parsing changes for CVE-2020-12100.
[1] https://raw.githubusercontent.com/dovecot/core/2.3.13/NEWS
LuaJIT is built in rspamd only on x86_64-linux, and LuaJIT support
became enabled by default in 2.6, breaking builds without it. This
commit explicitly disables LuaJIT support on non-x86_64 architectures.
this software has not received any update since 2014, the website
is stating that it is unmaintained:
http://freepops.sourceforge.net/
It is also marked broken since 6 years
This makes packages use lapack and blas, which can wrap different
BLAS/LAPACK implementations.
treewide: cleanup from blas/lapack changes
A few issues in the original treewide:
- can’t assume blas64 is a bool
- unused commented code
Previously, some files were copied into the Nixpkgs tree, which meant
we wouldn't easily be able to update them, and was also just messy.
The reason it was done that way before was so that a few NixOS
options could be substituted in. Some problems with doing it this way
were that the _package_ changed depending on the values of the
settings, which is pretty strange, and also that it only allowed those
few settings to be set.
In the new model, mailman-web is a usable package without needing to
override, and I've implemented the NixOS options in a much more
flexible way. NixOS' mailman-web config file first reads the
mailman-web settings to use as defaults, but then it loads another
configuration file generated from the new services.mailman.webSettings
option, so _any_ mailman-web Django setting can be customised by the
user, rather than just the three that were supported before. I've
kept the old options, but there might not really be any good reason to
keep them.
We already had python3Packages.mailman, but that's only really usable
as a library. The only other option was to create a whole Python
environment, which was undesirable to install as a system-wide
package.
This replaces all Mailman secrets with ones that are generated the
first time the service is run. This replaces the hyperkittyApiKey
option, which would lead to a secret in the world-readable store.
Even worse were the secrets hard-coded into mailman-web, which are not
just world-readable, but identical for all users!
services.mailman.hyperkittyApiKey has been removed, and so can no
longer be used to determine whether to enable Hyperkitty. In its
place, there is a new option, services.mailman.hyperkitty.enable. For
consistency, services.mailman.hyperkittyBaseUrl has been renamed to
services.mailman.hyperkitty.baseUrl.
Using a custom path in the Nix store meant that users of the module
couldn't add their own config files, which is a desirable feature. I
don't think avoiding /etc buys us anything.
The previously propagated build inputs are optional, and so are
included in checkInputs so the tests can run, but not propagated so
they aren't included if unneeded.
This fixes some two-digit year rounding bugs that started triggering
because 2020 is closer to 2070 than 1970. Apparently two digits years
are still a thing.
