On Wed, May 4, 2022 at 12:52 PM Vít Ondruch <vondruch@xxxxxxxxxx> wrote: > > 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. I was talking error codes, not error messages, but oof. > > 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
