From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Robert Pluim Newsgroups: gmane.emacs.bugs Subject: bug#50507: New function in Emacs GnuTLS implementation Date: Thu, 29 Sep 2022 16:08:35 +0200 Message-ID: <875yh6cly4.fsf@gmail.com> References: <83ee9wiozc.fsf@gnu.org> <87sflkgy49.fsf@gnus.org> <87edwd15ck.fsf@gnus.org> <87tu4u8kjv.fsf@gnus.org> <878rm69hop.fsf@gmail.com> <87v8p7d4oq.fsf@gmail.com> <87a66id03q.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21355"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 50507@debbugs.gnu.org, Lars Ingebrigtsen , Eli Zaretskii To: Nikolaos Chatzikonstantinou Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 29 17:29:25 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1odvTY-0005M1-Eh for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 29 Sep 2022 17:29:24 +0200 Original-Received: from localhost ([::1]:52938 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1odvTX-0007Jw-GG for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 29 Sep 2022 11:29:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55848) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oduDm-0006Zk-Rb for bug-gnu-emacs@gnu.org; Thu, 29 Sep 2022 10:09:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40087) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oduDm-00020d-GL for bug-gnu-emacs@gnu.org; Thu, 29 Sep 2022 10:09:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oduDm-0006We-Bo for bug-gnu-emacs@gnu.org; Thu, 29 Sep 2022 10:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 29 Sep 2022 14:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50507 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 50507-submit@debbugs.gnu.org id=B50507.166446052625062 (code B ref 50507); Thu, 29 Sep 2022 14:09:02 +0000 Original-Received: (at 50507) by debbugs.gnu.org; 29 Sep 2022 14:08:46 +0000 Original-Received: from localhost ([127.0.0.1]:39165 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oduDW-0006WA-2m for submit@debbugs.gnu.org; Thu, 29 Sep 2022 10:08:46 -0400 Original-Received: from mail-wr1-f51.google.com ([209.85.221.51]:42528) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oduDT-0006Vn-M0 for 50507@debbugs.gnu.org; Thu, 29 Sep 2022 10:08:44 -0400 Original-Received: by mail-wr1-f51.google.com with SMTP id l18so2376503wrw.9 for <50507@debbugs.gnu.org>; Thu, 29 Sep 2022 07:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=3/J1pOh2bVAaaz84KMSMYMTKKPHTI7iiv1bcCRZExhE=; b=SyasdLpBETnhIUgTUDTah0FSZ0IiBDUvsrash3olqS9oI5TCurLojWHCaINj9mU/gw 94D/5J2fE2pIETO+iBRjlBT5ean187ZSKmXKHiSzsVD+dhUG5puu0GI77Z7wV+RtMgWj JEiUfYMgvxwo3EykEainOj1xhQvO9YCW14cipIo7Lejw2bnsBzKh9rJuxWYkx6j4jxZz BwQoi/9ZEeQ5TvIGTYPXMc9C1OTYMsyacEmPxUO27pdc23yqHp/jF83RE0QNoiCxlY6f V1VL/kbSyFRor/GypmroNTQnPbjuMBdr5K8eVmkuCPnlKMiBZJWwRZR5nEkGfySLHs2h eDQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date; bh=3/J1pOh2bVAaaz84KMSMYMTKKPHTI7iiv1bcCRZExhE=; b=rOFxAvceXVEK9V3W1k5Ngm/ZSXq2DlQj11HbP0O9AduG/CQFT/ONnHIr69w4guyldR 4QKoqtR28Kb0g85pMSIDt7GnkEJ2bpM0XFL/kKmEeXkIDCEP7PyG6RKzQamn0yXC8/5Y Rq7GFS33mXtyWoW55bjAXU+ijgzRMcbWNOIIoCJXXKJ9jzW25AZtbtlZ3ZPS3Eok6f1r mKDr3Xe+S9/p+MA37pgfBIL/kpULanKaVnV6d7Fp93S0+1FHvgnM9l7GK+jBcoBl7Zlc LcWTBPMjizUR+peJNdAcK3JT2JhKCCRpN76jCX6y72HJBDVyOhcXjJinx7vjue4jL4nw NQug== X-Gm-Message-State: ACrzQf23dZ9BLnX4Id+8pZUxaGhg4mQ+AIBhlOZjoMKCR23It+flVGjw UwTW3vzNO47we9YQTX/gHKo= X-Google-Smtp-Source: AMsMyM5obn2Xg04UEMIOvSasrplbOCyGemR15GaxwAvv9rBOH/udlJWW98zrs/3FF8MrWERd5SRJng== X-Received: by 2002:a05:6000:154e:b0:22a:3177:1985 with SMTP id 14-20020a056000154e00b0022a31771985mr2541755wry.117.1664460516693; Thu, 29 Sep 2022 07:08:36 -0700 (PDT) Original-Received: from rltb ([2a01:e0a:3f3:fb50:8359:d07c:62db:a1ca]) by smtp.gmail.com with ESMTPSA id q17-20020a05600c46d100b003b56be51138sm4374084wmo.31.2022.09.29.07.08.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Sep 2022 07:08:35 -0700 (PDT) In-Reply-To: (Nikolaos Chatzikonstantinou's message of "Thu, 29 Sep 2022 09:44:09 -0400") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:243909 Archived-At: >>>>> On Thu, 29 Sep 2022 09:44:09 -0400, Nikolaos Chatzikonstantinou said: >>=20 >> We have some convenience macros in lisp.h for traversing lists, one = of >> which is FOR_EACH_TAIL. The reason to prefer it is that it will dete= ct >> circular lists, which is good practice since this list will come from >> the user level, so it could be anything :-) Nikolaos> Good point. I opted for FOR_EACH_TAIL_SAFE, which seems even = better Nikolaos> for this case. As documented in ChangeLog.3, it's the right o= ne when Nikolaos> the operation is idempotent, which an OR of flags is. (repeat= ed flags Nikolaos> do not alter the result.) OK Nikolaos> +The :pass and :flags keys are ignored with old versions of G= nuTLS, and Nikolaos> +:flags is ignored if :pass is not specified. Nikolaos> + >>=20 >> Maybe mention that not specifying :flags or passing :flags nil means >> passing '0' to the GnuTLS function? Nikolaos> Yes, and on that note, I discovered two things. One, the valu= e 0 is Nikolaos> special; it has meaning but it is not an enumeration constant= . I Nikolaos> documented this appropriately. Two, the password may be NULL = instead Nikolaos> of a string. OK. I guess you=CA=BCre mapping ':pass nil' to that? Nikolaos> How can I differentiate between `:pass nil` and not specifying Nikolaos> `:pass`? I would like to do this because in the former case I= 'm Nikolaos> calling ...key_file2() and in the latter I'm calling the orig= inal Nikolaos> ...key_file(). You=CA=BCd do `plist-member' to check if there=CA=BCs a `:pass' in the plis= t at all, and then `plist-get' to extract the value. Nikolaos> + DEFSYM (Qgnutls_pkcs_plain, "GNUTLS_PKCS_PLAIN"); Nikolaos> Nikolaos> + DEFSYM (Qgnutls_pkcs_pbes2_gost_cpd, "GNUTLS_PKCS_PBES2_GO= ST_CPD"); >>=20 >> All this is kind of awkward, but apart from doing DEFVAR_LISP I=CA= =BCm not >> aware of how to define a lisp level symbol with a value (it would >> allow you to simplify `key_file2_aux', since you could just extract >> the values directly from the symbols). Nikolaos> I am now comparing against intern("GNUTLS_PKCS_PLAIN") and so= on. I guess that=CA=BCs another option, but it=CA=BCs not the preferred solution. Anyway, let=CA=BCs not let the perfect be the enemy of the good. Thanks Robert --=20