[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <n703p992-486o-rp29-p19n-70pn82n5803p@vanv.qr>
Date: Wed, 7 Aug 2024 07:49:18 +0200 (CEST)
From: Jan Engelhardt <jengelh@...i.de>
To: oss-security@...ts.openwall.com
Subject: Re: feedback requested regarding deprecation of TLS
1.0/1.1
On Tuesday 2024-08-06 11:02, Neil Horman wrote:
>
>3) If the deprecated protocols are re-enabled, what would constitute a
>reasonable warning mechanism to inform users that these protocols are going
>away at some point in the future to pressure users to update to a newer,
>more secure protocol?
I think the power of warnings is overestimated (which is to say users can be
incredibly ignorant :-p)
The ERR_ buffer API could be used to convey information.
Problem I see is that, when the return code of some openssl function indicates
"success", no program exercising the openssl API will think to evaluate err
buffers at that point.
stderr seems kind of a sensible target. It is redirected in graphical
environments to e.g. ~/.xsession-errors, and I remember a time close to the end
of the 90s when /usr/bin/xconsole was started as part of a desktop experience
so you actually get to see the issues. But then desktops just stopped doing
that without replacement, which, in retrospect, was a bad choice, as it could
have been replaced by desktop notifications.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
