Related to #262907 (Django3 removal from nixpkgs).
This package already required an unreasonable amount of maintenance
regularly for a such small leaf-package. It has a few highly outdated
dependencies (e.g. flask 1, jinja2 2.11, sqlalchemy 1.3).
After at least each Python package-set update one had to fix up a lot of
dependencies to fix the package itself, so it was only useful on stable
branches. And having so much outdated software in a security-sensitive
piece of software seems questionable.
Finally, globin and I won't be available for maintaining this now that
Mayflower is migrating to another solution (and we'll do that as well)
and I'd expect this to bitrot extremely quick if we both bail out.
I don't really understand why this is only for a single version, so I
figured I'd just add this to the test matrix to also cover this
test-case for each major. Now, there's also one thing less to take care of
when removing old postgresql versions.
On current nixpkgs, no modifications to the server settings were
necessary to pass the audit. However, some of the client algorithms were
considered insecure. The client configuration lists all algorithms which
were listed as acceptable by `ssh-audit`.
This can be used as an example of a configuration currently considered
acceptable by `ssh-audit`, and verifies that such a configuration
results in a compatible client/server configuration.
Beware that this test will continue passing when future versions of
`ssh-audit` add support for new algorithms. In other words, the example
configuration represents a subset of what the current version of
`ssh-audit` would consider acceptable.
This flag allows the user to optionally exclude
switch-to-confguration.pl from toplevel.
This is interesting for appliance images where you don't want to re-build
the system. This flag is called `rebuildable` because the standard
interface to do this is `nixos-rebuild` which will not work anymore with
this change.
Kea may clean the runtime directory when starting (or maybe systemd does
it). I ran into this issue when restarting Kea after changing its
configuration, so I think the fact it normally doesn't clean it is a
race condition (it's cleaned on service start, and normally all Kea
services start at roughly the same time).
