From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: libnettle/libhogweed WIP Date: Tue, 18 Apr 2017 22:08:50 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87r30prvwt.fsf@lifelogs.com> References: <83a89gq3us.fsf@gnu.org> <87bmtjiv0w.fsf_-_@lifelogs.com> <83o9xjn06c.fsf@gnu.org> <87shmeb5ln.fsf_-_@lifelogs.com> <83y3w5z1ez.fsf@gnu.org> <87lgr6yakj.fsf@lifelogs.com> <87wpamww9k.fsf@lifelogs.com> <8337daggnj.fsf@gnu.org> <87d1cdwxt6.fsf@lifelogs.com> <83tw5pg1q3.fsf@gnu.org> <87zifhulc2.fsf@lifelogs.com> <83h91og80k.fsf@gnu.org> <87pogbuhoe.fsf@lifelogs.com> <834lxndmd9.fsf@gnu.org> <87efwrug6z.fsf@lifelogs.com> <87r30qu5av.fsf@lifelogs.com> <874lxmtxyy.fsf@lifelogs.com> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1492567785 30519 195.159.176.226 (19 Apr 2017 02:09:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Apr 2017 02:09:45 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 19 04:09:40 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d0f3s-0007pQ-4e for ged-emacs-devel@m.gmane.org; Wed, 19 Apr 2017 04:09:40 +0200 Original-Received: from localhost ([::1]:45334 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d0f3x-00075B-DF for ged-emacs-devel@m.gmane.org; Tue, 18 Apr 2017 22:09:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34152) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d0f3I-000755-R4 for emacs-devel@gnu.org; Tue, 18 Apr 2017 22:09:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d0f3F-0003Lx-ME for emacs-devel@gnu.org; Tue, 18 Apr 2017 22:09:04 -0400 Original-Received: from [195.159.176.226] (port=35362 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d0f3F-0003Lj-F7 for emacs-devel@gnu.org; Tue, 18 Apr 2017 22:09:01 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d0f37-00073s-7m for emacs-devel@gnu.org; Wed, 19 Apr 2017 04:08:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 57 Original-X-Complaints-To: usenet@blaine.gmane.org X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never Cancel-Lock: sha1:segCIC+L4toMcnBf6zTQNUDCHUU= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:214105 Archived-At: Update on the patch, summarizing the last few days and restating all my remaining questions. It's in the scratch/tzz/nettle branch of emacs.git or at https://gitlab.com/emacs-ci/emacs/merge_requests/2 I appreciate all your help and review. * all the ciphers, macs, and digests from the GnuTLS crypto API are available. I'll leave the PK crypto for later, this patch is huge already. * docs are up to date with current code * tests too * We don't want IVs to be reused for the same KEY, I'll work on that as recommended in https://tools.ietf.org/html/rfc5116#section-3.2 with an internal IV counter that can't be overridden and increments every time it's utilized, which is not too bad. * the KEY, if it's a string, is cleared by all the new functions that take it. I think it's best to only allow the key to come from a buffer or a file anyway, maybe even just a file. So this may not be needed later. In any case, I don't clear the INPUT or the rest of the parameters (thanks to Noam for noting that). * factored out extract_data_from_object() from secure_hash() which incidentally defines a data format for data extraction (BUFFER-OR-STRING INPUT-START INPUT-END CODING-SYSTEM NOERROR). This supports coding systems etc. so it's a good reuse of the secure_hash code for the GnuTLS crypto API glue. I'd like to allow files here, but I'd also like to avoid reading them into a buffer or a string just to use with extract_data_from_object(). There's no Lisp_Object AFAIK to represent a file. So for BUFFER-OR-STRING what do I use to indicate a file? "file:///the/path" ; a special string format: URL format? (file "/the/path") ; a nested list with a symbol? (insert-file-contents-literally "/the/path") ; a form, called in a temp buffer? * added `secure-hash-algorithms' so we know what algorithms are supported by `secure-hash'. At least for tests it's nice to have this. * I pin to GnuTLS 3.4.0 instead of AC_CHECK_FUNCS_ONCE because I couldn't get that autoconf macro to work! I would appreciate some help for how to use that macro for GnuTLS API functions. I think it needs to be told to include "gnutls/crypto.h" because the resulting C test doesn't. * the ERT tests look at the environment variable `GNUTLS_TEST_VERBOSE=1' to trigger verbose behavior. I'm not sure if there's a better way, and would like verbosity control and maybe even per-test-tag output settings (to make a specific type of test more verbose). It feels like something ERT should provide.