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")
next prev parent 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).