unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Nikolaos Chatzikonstantinou <nchatz314@gmail.com>
To: Robert Pluim <rpluim@gmail.com>
Cc: 50507@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>,
	Eli Zaretskii <eliz@gnu.org>
Subject: bug#50507: New function in Emacs GnuTLS implementation
Date: Mon, 26 Sep 2022 17:39:09 -0400	[thread overview]
Message-ID: <CAAQmekfOSteHSRoQJOT8wEh7uBwGPTKOJcYwqsYzvX4Z4O3xCw@mail.gmail.com> (raw)
In-Reply-To: <878rm69hop.fsf@gmail.com>

On Mon, Sep 26, 2022 at 1:19 PM Robert Pluim <rpluim@gmail.com> wrote:
>
> >>>>> On Mon, 26 Sep 2022 11:43:41 -0400, Nikolaos Chatzikonstantinou <nchatz314@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")





  reply	other threads:[~2022-09-26 21:39 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-10 10:39 bug#50507: New function in Emacs GnuTLS implementation Nikolaos Chatzikonstantinou
2021-09-10 12:39 ` Eli Zaretskii
2021-09-11 15:28   ` Nikolaos Chatzikonstantinou
2021-09-11 15:34     ` Eli Zaretskii
2021-09-11 15:52       ` Eli Zaretskii
2022-08-25 15:07     ` Lars Ingebrigtsen
2022-09-14 15:51       ` Nikolaos Chatzikonstantinou
2022-09-15  7:09         ` Lars Ingebrigtsen
2022-09-26  9:56           ` Nikolaos Chatzikonstantinou
2022-09-26 11:03             ` Lars Ingebrigtsen
2022-09-26 15:43               ` Nikolaos Chatzikonstantinou
2022-09-26 17:19                 ` Robert Pluim
2022-09-26 21:39                   ` Nikolaos Chatzikonstantinou [this message]
2022-09-27  6:29                     ` Eli Zaretskii
2022-09-28 12:15                   ` Nikolaos Chatzikonstantinou
2022-09-28 13:11                     ` Robert Pluim
2022-09-29  3:09                       ` Nikolaos Chatzikonstantinou
2022-09-29  8:17                         ` Eli Zaretskii
2022-09-29 12:35                           ` Nikolaos Chatzikonstantinou
2022-09-29 13:08                             ` Eli Zaretskii
2022-09-29  9:02                         ` Robert Pluim
2022-09-29 13:44                           ` Nikolaos Chatzikonstantinou
2022-09-29 14:08                             ` Robert Pluim
2022-09-30 10:04                               ` Nikolaos Chatzikonstantinou
2022-09-30 10:47                                 ` Eli Zaretskii
2022-09-30 13:01                                   ` Nikolaos Chatzikonstantinou
2022-09-30 13:37                                     ` Eli Zaretskii
2022-09-30 13:49                                       ` Nikolaos Chatzikonstantinou
2022-09-30 14:32                                         ` Robert Pluim
2022-09-30 16:22                                           ` Nikolaos Chatzikonstantinou
2022-10-03  7:40                                             ` Robert Pluim
2022-10-03 13:00                                               ` Nikolaos Chatzikonstantinou
2022-10-03 13:19                                                 ` Robert Pluim
2022-10-05 14:20                                                   ` Nikolaos Chatzikonstantinou
2022-12-23 15:46                                                   ` Nikolaos Chatzikonstantinou
2022-12-29  9:01                                                     ` Eli Zaretskii
2022-12-29 17:03                                                       ` Robert Pluim
2022-12-29 17:18                                                         ` Eli Zaretskii
2022-12-30 16:41                                                           ` Robert Pluim
2022-12-31  7:33                                                             ` Eli Zaretskii
2023-01-02 10:24                                                               ` Robert Pluim
2022-12-30 20:45 ` Mattias Engdegård
2022-12-30 22:59   ` Nikolaos Chatzikonstantinou
2022-12-31  7:28     ` Eli Zaretskii
2022-12-31  7:25   ` Eli Zaretskii
2022-12-31  8:58     ` Colin Baxter
2022-12-31  9:44     ` Mattias Engdegård

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAQmekfOSteHSRoQJOT8wEh7uBwGPTKOJcYwqsYzvX4Z4O3xCw@mail.gmail.com \
    --to=nchatz314@gmail.com \
    --cc=50507@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=larsi@gnus.org \
    --cc=rpluim@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).