Re: F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2 (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux