From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-15?Q?P=E1draig_Brady?= Newsgroups: gmane.comp.lib.gnulib.bugs,gmane.emacs.devel Subject: Re: SHA, MD, and openssl Date: Wed, 11 Dec 2013 20:15:55 +0000 Message-ID: <52A8C7FB.30206@draigBrady.com> References: <83mwkbyw6v.fsf@gnu.org> <52A4DE34.7060407@cs.ucla.edu> <874n6h3238.fsf@uwakimon.sk.tsukuba.ac.jp> <52A762D6.5020908@cs.ucla.edu> <52A8B4F6.4080009@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1386792973 31340 80.91.229.3 (11 Dec 2013 20:16:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Dec 2013 20:16:13 +0000 (UTC) Cc: Paul Eggert , Bug-gnulib , emacs-devel@gnu.org To: rms@gnu.org Original-X-From: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Wed Dec 11 21:16:19 2013 Return-path: Envelope-to: gnu-bug-gnulib@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VqqCd-0002ZI-2T for gnu-bug-gnulib@m.gmane.org; Wed, 11 Dec 2013 21:16:15 +0100 Original-Received: from localhost ([::1]:60066 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqqCc-0000T3-JR for gnu-bug-gnulib@m.gmane.org; Wed, 11 Dec 2013 15:16:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59230) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqqCU-0000QS-RS for bug-gnulib@gnu.org; Wed, 11 Dec 2013 15:16:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VqqCQ-0001NL-Ky for bug-gnulib@gnu.org; Wed, 11 Dec 2013 15:16:06 -0500 Original-Received: from mail1.vodafone.ie ([213.233.128.43]:47468) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqqCM-0001MM-0j; Wed, 11 Dec 2013 15:15:58 -0500 Original-Received: from unknown (HELO [192.168.1.79]) ([93.107.189.219]) by mail1.vodafone.ie with ESMTP; 11 Dec 2013 20:15:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 In-Reply-To: <52A8B4F6.4080009@cs.ucla.edu> X-Enigmail-Version: 1.6 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 213.233.128.43 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Original-Sender: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Xref: news.gmane.org gmane.comp.lib.gnulib.bugs:33500 gmane.emacs.devel:166310 Archived-At: On 12/11/2013 06:54 PM, Paul Eggert wrote: > [Adding bug-gnulib to CC. This discussion no longer directly affects > Emacs, since I removed the libcrypto support from Emacs yesterday > . Gnulib > still has support for linking to libcrypto, though, so it's still > relevant for gnulib. This email thread starts at > .] coreutils still enables use of openssl libcrypto where available. I suspect this is more of an advantage to coreutils than to emacs, due to the provision of bulk data processing functionality through md5sum and sha1sum etc. > On 12/11/2013 07:13 AM, Richard Stallman wrote: > >> I don't think OpenSSL is included in the normal form of >> packaging Linux > > I'm afraid you've lost me. Did you mean that Linux is the "Major > Component" as described in the GPL? If so, that doesn't sound right, > as the code we're talking about is crypto hash code, which doesn't > need to interface to the Linux kernel at all. It's written in pure > C and/or assembly code, with no Linux system calls. > > The Major Component here is not the Linux kernel; it's cryptographic > services, which these days are a major essential component of many > operating systems, including common GNU/Linux distributions. > Obviously one can build a GNU/Linux system without crypto, just as one > can build one without a windowing system, but nevertheless crypto is a > major essential component for many systems, just as windowing is. > >> I don't think it satisfies (b) either. > > I don't see why not, for the crypto hash functions we're talking > about. MD5, SHA256, etc. are all interfaces that are official > standards defined by recognized standards bodies, and implementations > for them are available to the public in source code form. So practically I see the openssl crypto libs as ubiquitous and the chosen interface used to expose _system_ specific checksum functionality, down to specific sha instructions or coprocessing units etc. I don't see using these interfaces as detrimental to the essential freedoms, but instead _significantly_ improving the performance and thus the utility of these core GNU tools. If we don't use these system interfaces we'll just be sidelined for something that does. Now we could clean room implement equivalent operations for the many disparate systems out there, however it's worth noting there is significant advantage in hardware vendors consolidating around a single implementation, and openssl is where that's at currently. I'm not discounting that a GPL equivalent might arise, but until that happens we should use the current system interfaces. BTW openssl.org says it's OK to use these interfaces from GPL software due to the system lib exception: http://www.openssl.org/support/faq.html#LEGAL2 thanks, Pádraig.