Martin-Éric RACINE
Martin-Éric RACINE
Does this one seem ready to merge too?
One good reason for switchign to blacklists includes this: if the hardening script creates files, they can remain there and not block newer algorithms on upgrade. Here, I've put hardening...
Just out of curiosity, where did that `update-crypto-policies` command come from, @Houlistonm ?
You mean [these](https://gitlab.com/redhat-crypto/fedora-crypto-policies/)? That apparently was ported to other distros as well, but is not actively maitnained outside of RHEL.
@jtesta I'd really like to see ssh-audit get around migrating its configs to disabling deprecated algorithms, rather than the current method of specify a whitelist, as proposed by @cjwatson above....
OpenSSH 10 has been back-ported to at least one older Debian release. Additionally, the non-@ssh variant of a kex was added to an earlier release. The key reason why policies...
@jtesta I really don't see why you make this a Debian-specific issue. The key point is not whether backports are available. It is to have upward-valid hardening configs. Blacklisting deprecated...
You've been asked to test the latest. 10.2.4 has been out for some time. Now we have 10.3.0 out. Why do you insist on testing against a heavily patched 10.2.2?
There's however tons of GitLab users who need to adjust their client config to weed out questionable algorithms and yet still have a few supported ones left.
Fair enough. Btw, I still don't get why curve25519-sha256 is makered with a warning.