bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random num


From: Andy Moreton
Subject: bug#22202: 24.5; SECURITY ISSUE -- Emacs Server vulnerable to random number generator attack on Windows systems
Date: Tue, 19 Jan 2016 21:48:58 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (windows-nt)

On Tue 19 Jan 2016, John Wiegley wrote:

>>>>>> Eli Zaretskii <address@hidden> writes:
>
>> We have what we need; calling gnutls_rnd changes nothing in this regard.
>> It's just a more complex way of issuing the same system calls. It buys us
>> nothing in terms of security and performance, while we sustain the price of
>> having core functionality that must run at startup crucially depending on a
>> 3rd party library we don't control.
>
>> John, I feel this decision is wrong and the changes that prefer gnutls_rnd
>> should be reverted. Maybe I'm the only one who cares, but then Paul is the
>> only one who felt the need to make that change. I'd like to hear your take
>> on this, please.
>
> From what I've read, I agree with you Eli. If we can open /dev/urandom, why do
> we need a dependency on GnuTLS to effectively do the same thing?
>
> What critical feature is GnuTLS buying for us that would make this worthwhile,
> Paul?

As far as I can see, this set of patches attempted to fix a minor
problem, but in doing so:
 - added unnecessary dependencies on gnutls libraries
 - broke the Windows builds (which use runtime linking for gnutls)
 - broke all builds configured with "--without-gnutls"

I am happy for the original issue to be addressed, but only if all of
the issues listed above are addressed.

In particular, it must remain possible to build on a system that does
not have gnutls headers and libraries installed, or to disable gnutls
support even if the headers and libraries are present.

    AndyM






reply via email to

[Prev in Thread] Current Thread [Next in Thread]