On Mon, 2022-05-02 at 19:33 +0200, Clemens Lang wrote:
This is the reason why the proposal contains extensive methods to
test
whether things are going to break by modifying the crypto-policy or using
bpftrace. Unfortunately there are hundreds of packages that depend on
cryptographic libraries, and millions of different configurations out there.
We can’t know ahead of time which ones of them are going to break, but the
proposal provides tools and a long transition period to identify and fix
them.
When changes like this broke things for users in the past, we talked
about a way to present the "insufficient crypto/digest/protocol" as
just another failure like server certificate validation failures, so
the application/user can *choose* to accept and proceed, in real time.
I'd like to see that as a *condition* of acceptance of further
restrictions in the policy.
I really don't want us continuing to break things for Fedora users and
driving them back to the proprietary VPN clients.
I am pleased to see some progress on this front with
https://fedoraproject.org/wiki/Changes/GnutlsAllowlisting but it isn't
clear to me that this gives us what we need. We *want* to warn users
that their VPN server doesn't meet modern crypto standards. We don't
want to just blindly re-enable ancient crap and have it silently work.
But we also do *need* it to work, after we've warned the user about it.
Which is why handling it like a certificate validation failure seems to
be the right answer, but I'm happy to explore other solutions... but
preferably *not* solutions like "manually set
GNUTLS_SYSTEM_PRIORTY_FILE=/dev/null in your Fedora package to
explicitly override all the Fedora crypto policies". That suggestion
made me sad... :)