Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
nixos/mailman: lots of big improvements #77444
Motivation for this change
Our current Mailman module is quite lacking in a number of ways, including security issues:
With these changes, all of these problems are resolved, and the Mailman module is much more useful. I’ve been using it pretty much like this for months, and it has worked perfectly.
Where necessary, I’ve explained the rationale for each change in more detail in the commit message. I strongly recommend reviewing commit by commit to understand why each change was made.
I’ve retained backwards compatibility as much as was practical, but some small changes will be required by users. The
jonringer left a comment
related commits should probably be squashed, not really sure where to draw the line on the module commits, but 17 commits seems excessive if this is likely to be backported
-1 to squashing any of it. Would make it much more difficult to see what had changed.
I think it’s probably not worth backporting. There are security implications, but this is a big, breaking change, and it’s been like this for months…
You might want to have a look at https://github.com/mayflower/nixexprs/blob/master/modules/mailman3.nix, which predates this module, to see if you want to steal something. I deemed it too hacky to try and push it upstream at the time but it might be interesting to compare if there's anything there missing here. When this PR is merged I'll probably just dump it anyway in favour of this.
I’ve dropped e6f970d because of https://gitlab.com/mailman/mailman/merge_requests/594. I could have applied the patch to the mailman package, but since it was an entirely cosmetic change I think it’s better to just wait for it to be fixed in upstream, and then we can unify the config file locations.
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.
It's likely that a user might want to set multiple values for relay_domains, transport_maps, and local_recipient_maps, and the order is significant. This means that there's no good way to set these across multiple NixOS modules, and they should probably all be set together in the user's Postfix configuration. So, rather than setting these in the Mailman module, just make the Mailman module check that the values it needs to occur somewhere, and advise the user on what to set if not.
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.