URL:
http://savannah.gnu.org/bugs/?42645
Summary: Use libgcrypt only if needed
Project: GNUstep
Submitted by: yavor
Submitted on: Sun 29 Jun 2014 09:36:19 PM EEST
Category: Base/Foundation
Severity: 3 - Normal
Item Group: Bug
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
___
Details:
Currently, +[GSTLSObject initialize] calls uncoditionally gcry_control, which
is superfluous with recent (~4 years old) GnuTLS releases.
As of version 2.11 GnuTLS does not depend on gcrypt initialization, as its
NEWS file indicates:
** libgnutls: Added gnutls_global_set_mutex() to allow setting
alternative locking procedures. By default the system available
locking is used. In *NIX pthreads are used and in windows the
critical section API. This follows a different approach than the
previous versions that depended on libgcrypt initialization. The
locks are now set by default in systems that support it. Programs
that used gcry_control() to set thread locks should insert it into a block of
#if GNUTLS_VERSION_NUMBER = 0x020b00
gcry_control(...)
#endif
Version 2.11.1 switched to nettle as the default crypto backend, and support
for libgcrypt was removed entirely in 2.99.2.
Proposed patch attached.
(P.S. The AC_MSG_WARN call if gcrypt is not found is redundant since there is
AC_MSG_ERROR a few lines below. As a side (minor) issue, it is considered
poor practice to nest AC_MSG_CHECKING/AC_MSG_RESULT because it leads to ugly
and/or confusing output like:
checking gnutls support... checking for gcry_control in -lgcrypt... yes
yes
checking for gnutls_transport_set_errno... yes
It is not immediately clear to the user what the lone yes is for. It is
even more confusing if there are mixed yes and no results.)
___
File Attachments:
---
Date: Sun 29 Jun 2014 09:36:19 PM EEST Name: use-gcrypt-if-needed.patch
Size: 2kB By: yavor
http://savannah.gnu.org/bugs/download.php?file_id=31636
___
Reply to this item at:
http://savannah.gnu.org/bugs/?42645
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep
