Dne 04. 05. 22 v 9:32 Alexander Sosedkin napsal(a):
On Wed, May 4, 2022 at 12:43 AM David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: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.If the error returned from GnuTLS isn't enough to infer
While I don't know much about GnuTLS, I have yet to see single OpenSSL error message which would help user to understand the issue.
Vít
that you should make the user opt-in into a legacy algorithm and then counter the restriction on the next attempt with a priority string extension or gnutls_protocol_mark_enabled, please file a bug with GnuTLS and describe your case. Your continued input would be appreciated. Same with the other libraries if you meant other libraries. If you don't want to spend a connection on just probing, but instead prefer to connect no matter what and then query what has been negotiated to make the warn/abort decisions on the application layer that should also be possible.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... :)+1, this is not the way _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
