GNU bug report logs - #50507
New function in Emacs GnuTLS implementation

Previous Next

Full log

Message #45 received at 50507 <at> debbugs.gnu.org (full text, mbox):

From: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 50507 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#50507: New function in Emacs GnuTLS implementation
Date: Mon, 26 Sep 2022 17:39:09 -0400

On Mon, Sep 26, 2022 at 1:19 PM Robert Pluim <rpluim <at> gmail.com> wrote:
>
> >>>>> On Mon, 26 Sep 2022 11:43:41 -0400, Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> said:
>     Nikolaos> Date: Mon, 26 Sep 2022 11:08:18 -0400
>     Nikolaos> Subject: [PATCH] fix(gnutls): add possibility of password for key-file
>
>     Nikolaos> The GnuTLS function
>
>     Nikolaos>     gnutls_certificate_set_x509_key_file
>
>     Nikolaos> is replaced by its second version
>
>     Nikolaos>     gnutls_certificate_set_x509_key_file2
>
>     Nikolaos> and the definitions of gnutls-boot and gnutls-boot-parameters are
>     Nikolaos> modified to include the :pass and :flags keys, which are additional
>     Nikolaos> parameters in the second version.
>
>     Nikolaos> +PASS is a string, the password of the key.
>     Nikolaos> +
>     Nikolaos> +FLAGS is an ORed sequence of gnutls_pkcs_encrypt_flags_t values.
>     Nikolaos> +
>
> Youʼre at the lisp level here. Perhaps you could define a mapping from
> the C-level enum to lisp defconsts or similar? Or you could define it
> as taking a list of flags, and then the C-code can take care of ORing
> them.

Does Emacs code have a way to signal this C-to-lisp enum-to-defconst
map? Otherwise I will go with the keywords option.

>     Nikolaos> +  pass                  = plist_get (proplist, QCpass);
>     Nikolaos> +  flags                 = plist_get (proplist, QCflags);
>
> pass and flags will both be 'nil' here if theyʼre not specified, so
> that....
>
> <removed>
>
> ...this is likely to fail in that case. Or maybe not, I havenʼt tested
> it, but XUFIXNUM(nil) in a build with asserts enabled will trigger an
> assert and exit, I think.

Thanks, I will look into this.

> In any case, if youʼre going to replace _file with _file2, you should
> describe the new constraints on the arguments. e.g. Maybe having pass
> as nil is OK, but then you need to say that, or maybe you need to fall
> back to _file if :pass is not specified.

Okay, will do. The first version of the function exists since 0.4.0
but the second appeared "recently" in 3.2.0 (released on June
2013). Should I put some preprocessor #if checks? How would the
docstring be affected? Instead of duplicating the string (can't put
#if inside its body, it's already in a macro), perhaps I should write
that the feature is "only supported with GnuTLS 3.2.0 and above")

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.