GNU bug report logs -
#50507
New function in Emacs GnuTLS implementation
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 50507 in the body.
You can then email your comments to 50507 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Fri, 10 Sep 2021 12:02:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 10 Sep 2021 12:02:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hello bug-gnu-emacs,
I am looking at the src/gnutls.c:gnutls-boot function for the purpose of
modifying it to use the function gnutls_certificate_set_x509_key_file2
instead of gnutls_certificate_set_x509_key_file. (Note the missing `2')
The reason for this addition would be to protect the key with a
password. Note that the pass parameter may be NULL.
Moreover, the Emacs functionality could do with more than just file
access; users could provide their certificates and keys that lie in
memory instead of a file. This may be useful.
I am sending this e-mail to gauge interest in this as a proposal. It
makes sense to me but I am not very experienced. How does one submit
a patch for Emacs? Is it via the mailing lists by attaching a diff
hunk?
Thank you for your attention.
Regards,
Nikolaos Chatzikonstantinou
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEHHHUCYKNdWl5h845DtNR6zceZEgFAmE7NYYACgkQDtNR6zce
ZEgSjg//SDJzOtoYZBeGZ5FbXeR52Tt11+ztXlwFpgk+aIW5PNu+XzWMci7kp0BL
vxYkXKaKINHC8FM393r2wFxWbBf+Jss1tqtATl56s3VWwowXU4X7II+qI5hkjJok
jC6lRhxkPkhCNijDXBXxMTwGEoKo6/qiRzFCb46C5lGkYahsvNMZQGagadGV3tde
JFKhBHIR6W6JGGqkKgXZ4CL1627elzUBooLA0QfY8jzM8JOErCRo5tgD/A6omE/K
Uot9EMAOIAOID2XQQ8fPATSUxAqrlV9HvLW0fo+xE4jCraEhmhHNyFyWAnb3uCB9
LD9OOmN6xC9QeN6B0DVbv1VVYhCn78APEEXuglUv57LSkCGJteUh7zphwbKwwdbk
81ifniPlwnzjGIiq5B6dCYRQD2wCdVOczF7Nu8Zjoo9DQxUC/TiY3r5HnlSSUZVv
Msqfd/kdCVv19+JhZe5CKcTTPjXgdeJLR442Q/WD101KPtvdIkoZjBzoSnbd7tcC
qfj3X88xnVPJWmPViFNHVSD0EhCha6jCdLz0NF9ttacaoxrg5ocyg2itBLKTy7V9
excqFwCkxjfDMIOmMTES/a2TZ3bisJRc6XrGPgYYy7eAaXmLaynrxpqO7vOCGYiW
kYtBR8dgPLU3UYivn0KKgbyDeZdSNNZ008/mmIwPHIEh6FOvFLk=
=kjif
-----END PGP SIGNATURE-----
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Fri, 10 Sep 2021 12:40:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 50507 <at> debbugs.gnu.org (full text, mbox):
> From: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
> Date: Fri, 10 Sep 2021 19:39:52 +0900
>
> I am looking at the src/gnutls.c:gnutls-boot function for the purpose of
> modifying it to use the function gnutls_certificate_set_x509_key_file2
> instead of gnutls_certificate_set_x509_key_file. (Note the missing `2')
>
> The reason for this addition would be to protect the key with a
> password. Note that the pass parameter may be NULL.
Do you intend to make the change unconditionally, or do you intend to
make it an optional feature?
And what is the minimal GnuTLS version which provided this function?
> I am sending this e-mail to gauge interest in this as a proposal. It
> makes sense to me but I am not very experienced. How does one submit
> a patch for Emacs? Is it via the mailing lists by attaching a diff
> hunk?
Yes, you provide a patch as an attachment, preferably in the "git
format-patch" format. See the file CONTRIBUTE in the Emacs Git
repository for more details.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Sat, 11 Sep 2021 15:35:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 50507 <at> debbugs.gnu.org (full text, mbox):
> From: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
> Date: Sun, 12 Sep 2021 00:28:33 +0900
> Cc: 50507 <at> debbugs.gnu.org
>
> > > The reason for this addition would be to protect the key with a
> > > password. Note that the pass parameter may be NULL.
> >
> > Do you intend to make the change unconditionally, or do you intend to
> > make it an optional feature?
> >
> > And what is the minimal GnuTLS version which provided this function?
>
> I intend to introduce new functions without changing any of the others.
> The following functions were added at 2013-04-08:
>
> gnutls_certificate_set_x509_key_file2
> gnutls_certificate_set_x509_key_mem2
>
> Versions after 3.2 and 3.1.11 include them. Although it appears
> straightforward to introduce them, my plan is to spend some time
> acclimating myself with GnuTLS and the Emacs implementation to ensure
> that I did it right, and then I'll submit a patch. Does it sound good?
Yes, SGTM. Thank you very much for working on this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Sat, 11 Sep 2021 15:53:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 50507 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 11 Sep 2021 18:34:31 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 50507 <at> debbugs.gnu.org
>
> > Versions after 3.2 and 3.1.11 include them. Although it appears
> > straightforward to introduce them, my plan is to spend some time
> > acclimating myself with GnuTLS and the Emacs implementation to ensure
> > that I did it right, and then I'll submit a patch. Does it sound good?
>
> Yes, SGTM. Thank you very much for working on this.
And, of course, don't hesitate to ask questions if something in the
existing implementation is unclear.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Sat, 11 Sep 2021 15:59:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 50507 <at> debbugs.gnu.org (full text, mbox):
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
> From: Eli Zaretskii <eliz <at> gnu.org>
> Date: Fri, 10 Sep 2021 15:39:35 +0300
> > From: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
> > Date: Fri, 10 Sep 2021 19:39:52 +0900
> >
> > I am looking at the src/gnutls.c:gnutls-boot function for the
> > purpose of modifying it to use the function
> > gnutls_certificate_set_x509_key_file2
> > instead of gnutls_certificate_set_x509_key_file. (Note the missing
> > `2')
> >
> > The reason for this addition would be to protect the key with a
> > password. Note that the pass parameter may be NULL.
>
> Do you intend to make the change unconditionally, or do you intend to
> make it an optional feature?
>
> And what is the minimal GnuTLS version which provided this function?
I intend to introduce new functions without changing any of the others.
The following functions were added at 2013-04-08:
gnutls_certificate_set_x509_key_file2
gnutls_certificate_set_x509_key_mem2
Versions after 3.2 and 3.1.11 include them. Although it appears
straightforward to introduce them, my plan is to spend some time
acclimating myself with GnuTLS and the Emacs implementation to ensure
that I did it right, and then I'll submit a patch. Does it sound good?
Regards,
Nikolaos Chatzikonstantinou
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEHHHUCYKNdWl5h845DtNR6zceZEgFAmE8yqkACgkQDtNR6zce
ZEjF9hAAyoLaoIbMEmzaJ/TrzTyucic4L78LTYyoMMAB7UgNgWFwhRZ+6POUc2N2
UiIjuz5JBGtpUIBgQS/DOyzZppZxGyJMa+VeIu1rEypk6NYw4XVVgXgOg2kEpM5R
WBgdFmafsyUmNWwr9xEs8QtfaXE0qVlQA4TIXNJSI7iZsgK6B/WZbez1TBbiOign
Wydgzvvb9NcRRvMUV5BHxFMfTt7dDWiN2jpCx7mYizcjWnSiAwB/75H82YAGCIa+
vHKwGGX3Fl+k6bkd9dNeaNXX//seKecgOzipodu2KeahgY3AXSxL+t9jPIwRU0gp
dfm/h6qc9189WZ1hvigFpEgvU44Uc2yUUyDFQ+Gp7dLAaLo1KHsD9jVnG7WFtMBw
Owcz7CwD4nYHGBwqucijrtAjurclvus7Yuqh1aayMkYySjJCN0IoQOMmbpVYUbaZ
lP83wooZ4C624x0hSMIQNtAoDSB5en05ny71DkPTTozDvkED5vxfZkoARaSnQFiO
NeirllWwz07ZQck1PvoJXgOUvytUEf5OS4pJNvLX11/qGUzfwBWA1ZWO3mHAPHAx
K3iMUxWtRF0VnpvS6X1dXj0MYIhhJ/aEpYh/IL4uPyQrfrWoMUEmDgw3LNPB01Er
tqGpeSiWbQ/YSE6AERoYf+gsuaHnsOMWwxyznwvkWWfn12I4/34=
=qL1/
-----END PGP SIGNATURE-----
Severity set to 'wishlist' from 'normal'
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org
.
(Sat, 25 Sep 2021 18:18:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Thu, 25 Aug 2022 15:09:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 50507 <at> debbugs.gnu.org (full text, mbox):
Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> writes:
> Versions after 3.2 and 3.1.11 include them. Although it appears
> straightforward to introduce them, my plan is to spend some time
> acclimating myself with GnuTLS and the Emacs implementation to ensure
> that I did it right, and then I'll submit a patch. Does it sound good?
Sounds good to me.
This was almost a year ago -- did you get any further with this?
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 25 Aug 2022 15:09:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Wed, 14 Sep 2022 15:52:02 GMT)
Full text and
rfc822 format available.
Message #27 received at 50507 <at> debbugs.gnu.org (full text, mbox):
On Thu, Aug 25, 2022 at 11:07 AM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
>
> Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> writes:
>
> > Versions after 3.2 and 3.1.11 include them. Although it appears
> > straightforward to introduce them, my plan is to spend some time
> > acclimating myself with GnuTLS and the Emacs implementation to ensure
> > that I did it right, and then I'll submit a patch. Does it sound good?
>
> Sounds good to me.
>
> This was almost a year ago -- did you get any further with this?
Thanks for reminding me of this.
I spent my time learning some cryptography and doing other
things, unrelated to Emacs. I feel better equipped now to tackle
this issue, but it will take some time, I expect a month or
less. Luckily I have a lot of free time right now.
My goal is to increase the completion of the Emacs wrapper of
GnuTLS. Originally I cared only to add enough to implement
encryption-at-rest for the circe IRC client.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Thu, 15 Sep 2022 07:10:01 GMT)
Full text and
rfc822 format available.
Message #30 received at 50507 <at> debbugs.gnu.org (full text, mbox):
Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> writes:
> I spent my time learning some cryptography and doing other
> things, unrelated to Emacs. I feel better equipped now to tackle
> this issue, but it will take some time, I expect a month or
> less. Luckily I have a lot of free time right now.
>
> My goal is to increase the completion of the Emacs wrapper of
> GnuTLS. Originally I cared only to add enough to implement
> encryption-at-rest for the circe IRC client.
Great; looking forward to it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Mon, 26 Sep 2022 09:57:01 GMT)
Full text and
rfc822 format available.
Message #33 received at 50507 <at> debbugs.gnu.org (full text, mbox):
On Thu, Sep 15, 2022 at 3:09 AM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
>
> Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> writes:
> >
> > My goal is to increase the completion of the Emacs wrapper of
> > GnuTLS. Originally I cared only to add enough to implement
> > encryption-at-rest for the circe IRC client.
>
> Great; looking forward to it.
I have a small update.
I looked into src/gnutls.c to see which functions are implemented. In
total, there's 19 functions defined with DEFUN,
gnutls-hash-digest
gnutls-format-certificate
gnutls-peer-status-warning-describe
gnutls-peer-status
gnutls-deinit
gnutls-hash-mac
gnutls-errorp
gnutls-error-fatalp
gnutls-error-string
gnutls-macs
gnutls-digests
gnutls-ciphers
gnutls-available-p
gnutls-boot
gnutls-bye
gnutls-asynchronous-parameters
gnutls-get-initstage
gnutls-symmetric-encrypt
gnutls-symmetric-decrypt
However, I suspect that this API is not used by most
packages. Instead, these functions are called from Emacs'
make-network-process and friends in src/process.c. If I just dump new
gnutls functions in src/gnutls.c, they might not be accessible for
use, or I might duplicate functionality.
Before I make sensible changes to src/gnutls.c, I would need to
understand better how the functions are used in
src/process.c. However, that file is lacking function
comments. Therefore, since I'll be studying it anyhow, I suggest that
my first patch will be C documentation for those functions in
src/process.c.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Mon, 26 Sep 2022 11:04:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 50507 <at> debbugs.gnu.org (full text, mbox):
Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> writes:
> However, I suspect that this API is not used by most
> packages. Instead, these functions are called from Emacs'
> make-network-process and friends in src/process.c. If I just dump new
> gnutls functions in src/gnutls.c, they might not be accessible for
> use, or I might duplicate functionality.
I'm not sure I understand what you mean here. The point was to use
gnutls_certificate_set_x509_key_file2 instead of
gnutls_certificate_set_x509_key_file in gnutls.c -- so that should be an
internal change in gnutls.c that nothing else should need to know about.
> Before I make sensible changes to src/gnutls.c, I would need to
> understand better how the functions are used in
> src/process.c. However, that file is lacking function
> comments. Therefore, since I'll be studying it anyhow, I suggest that
> my first patch will be C documentation for those functions in
> src/process.c.
process.c has an abundance of comments already, but if there's further
comments that would be helpful, that's welcome, of course.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Mon, 26 Sep 2022 15:45:03 GMT)
Full text and
rfc822 format available.
Message #39 received at 50507 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Sep 26, 2022 at 7:03 AM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
>
> Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> writes:
>
> > However, I suspect that this API is not used by most
> > packages. Instead, these functions are called from Emacs'
> > make-network-process and friends in src/process.c. If I just dump new
> > gnutls functions in src/gnutls.c, they might not be accessible for
> > use, or I might duplicate functionality.
>
> I'm not sure I understand what you mean here. The point was to use
> gnutls_certificate_set_x509_key_file2 instead of
> gnutls_certificate_set_x509_key_file in gnutls.c -- so that should be an
> internal change in gnutls.c that nothing else should need to know about.
Ah yes, thanks for setting me straight. I should start with
that. Actually, this is not too complicated, and I just prepared this
patch save for one thing: how should the ORed values be passed in the
last parameter?
In C, it is an 'unsigned int' of ORed values of type
'gnutls_pkcs_encrypt_flags_t', whose enumeration constants are
detailed here,
<https://gnutls.org/reference/gnutls-x509.html#gnutls-pkcs-encrypt-flags-t>
See the patch attached (do not merge yet?).
[0001-fix-gnutls-add-possibility-of-password-for-key-file.patch.sig (application/pgp-signature, attachment)]
[0001-fix-gnutls-add-possibility-of-password-for-key-file.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Mon, 26 Sep 2022 17:21:01 GMT)
Full text and
rfc822 format available.
Message #42 received at 50507 <at> debbugs.gnu.org (full text, mbox):
>>>>> 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> Signed-off-by: Nikolaos Chatzikonstantinou
Nikolaos> <nchatz314 <at> gmail.com>
We donʼt use Signed-off-by, and the commit message has some rules
which are described in CONTRIBUTE (start at "** Commit messages" and
read up to and including "** Committing your changes")
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.
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....
Nikolaos> if (!STRINGP (hostname))
Nikolaos> {
Nikolaos> @@ -2038,8 +2051,8 @@ DEFUN ("gnutls-boot", Fgnutls_boot, Sgnutls_boot, 3, 3, 0,
Nikolaos> keyfile = ansi_encode_filename (keyfile);
Nikolaos> certfile = ansi_encode_filename (certfile);
Nikolaos> # endif
Nikolaos> - ret = gnutls_certificate_set_x509_key_file
Nikolaos> - (x509_cred, SSDATA (certfile), SSDATA (keyfile), file_format);
Nikolaos> + ret = gnutls_certificate_set_x509_key_file2
Nikolaos> + (x509_cred, SSDATA (certfile), SSDATA (keyfile), file_format, SSDATA (pass), XUFIXNUM (flags));
...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.
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.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Mon, 26 Sep 2022 21:40:02 GMT)
Full text and
rfc822 format available.
Message #45 received at 50507 <at> debbugs.gnu.org (full text, mbox):
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")
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Tue, 27 Sep 2022 06:30:02 GMT)
Full text and
rfc822 format available.
Message #48 received at 50507 <at> debbugs.gnu.org (full text, mbox):
> From: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
> Date: Mon, 26 Sep 2022 17:39:09 -0400
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 50507 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
>
> > 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?
Yes, we already have those in gnutls.c. Example:
# if GNUTLS_VERSION_NUMBER >= 0x030014
# define HAVE_GNUTLS_X509_SYSTEM_TRUST
# endif
> 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")
You don't have to mention the GnuTLS version explicitly, you can say
something more vague, like "supported by recent enough GnuTLS".
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Wed, 28 Sep 2022 12:16:02 GMT)
Full text and
rfc822 format available.
Message #51 received at 50507 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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> Signed-off-by: Nikolaos Chatzikonstantinou
> Nikolaos> <nchatz314 <at> gmail.com>
>
> We donʼt use Signed-off-by, and the commit message has some rules
> which are described in CONTRIBUTE (start at "** Commit messages" and
> read up to and including "** Committing your changes")
Okay, I'm submitting this patch with corrections included, see attachment.
[0001-add-pass-and-flags-to-gnutls-boot-for-keylist.patch.sig (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Wed, 28 Sep 2022 13:12:02 GMT)
Full text and
rfc822 format available.
Message #54 received at 50507 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 28 Sep 2022 08:15:26 -0400, Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> said:
Nikolaos> Okay, I'm submitting this patch with corrections included, see attachment.
I see a .sig attachment, but no patch (we donʼt currently require
signing of commits at all, but I guess thereʼs nothing stopping people
from doing it).
Regards
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Thu, 29 Sep 2022 03:11:02 GMT)
Full text and
rfc822 format available.
Message #57 received at 50507 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Sep 28, 2022 at 9:11 AM Robert Pluim <rpluim <at> gmail.com> wrote:
>
> >>>>> On Wed, 28 Sep 2022 08:15:26 -0400, Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> said:
>
>
> Nikolaos> Okay, I'm submitting this patch with corrections included, see attachment.
>
> I see a .sig attachment, but no patch (we donʼt currently require
> signing of commits at all, but I guess thereʼs nothing stopping people
> from doing it).
My bad, here it is. I also added "Copyright-paperwork-exempt: yes" (or
will this require paperwork?) and gave the helper function static
linkage in src/gnutls.c.
[0001-add-pass-and-flags-to-gnutls-boot-for-keylist.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Thu, 29 Sep 2022 08:19:01 GMT)
Full text and
rfc822 format available.
Message #60 received at 50507 <at> debbugs.gnu.org (full text, mbox):
> From: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
> Date: Wed, 28 Sep 2022 23:09:46 -0400
> Cc: 50507 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
>
> I also added "Copyright-paperwork-exempt: yes" (or will this require
> paperwork?)
The patch is large enough to require it, yes.
Would you like me to send you the legal form to start the paperwork?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Thu, 29 Sep 2022 09:03:01 GMT)
Full text and
rfc822 format available.
Message #63 received at 50507 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 28 Sep 2022 23:09:46 -0400, Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> said:
Nikolaos> On Wed, Sep 28, 2022 at 9:11 AM Robert Pluim <rpluim <at> gmail.com> wrote:
>>
>> >>>>> On Wed, 28 Sep 2022 08:15:26 -0400, Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> said:
>>
>>
Nikolaos> Okay, I'm submitting this patch with corrections included, see attachment.
>>
>> I see a .sig attachment, but no patch (we donʼt currently require
>> signing of commits at all, but I guess thereʼs nothing stopping people
>> from doing it).
Nikolaos> My bad, here it is. I also added "Copyright-paperwork-exempt: yes" (or
Nikolaos> will this require paperwork?) and gave the helper function static
Nikolaos> linkage in src/gnutls.c.
Eli answered that. A few nits below
Nikolaos> From b11707c423773f6234746991222acd80ab3f708c Mon Sep 17 00:00:00 2001
Nikolaos> From: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
Nikolaos> Date: Mon, 26 Sep 2022 11:08:18 -0400
Nikolaos> Subject: [PATCH] add :pass and :flags to gnutls-boot for :keylist
Nikolaos> * lisp/net/gnutls.el (gnutls-boot-parameters): add the keys :pass and
Nikolaos> :flags, and update the documentation.
Nikolaos> * src/gnutls.c (gnutls-boot): add the keys :pass and :flags, and
Nikolaos> update the documentation.
Nikolaos> (syms_of_gnutls): add the symbols :pass, :flags, and the symbols that
Nikolaos> correspond to the enumeration constants of the GnuTLS enum
Nikolaos> `gnutls_pkcs_encrypt_flags_t`.
Nikolaos> ; (key_file2_aux): private helper function that translates a list of
Nikolaos> ; symbols to its corresponding `unsigned int` value of the GnuTLS C
Nikolaos> ; enum `gnutls_pkcs_encrypt_flags_t`.
Each description of a change is a sentence, and should start with a
capital letter. The lines starting with ';' should not start with ';'
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> +
This is now a list of symbols, so the docstring needs adjusting.
Nikolaos> +/* Helper function for gnutls-boot.
Nikolaos> +
Nikolaos> + The key :flags receives a lisp of symbols, each of which
s/lisp/list/
Nikolaos> + corresponds to a GnuTLS C flag, the ORed result is to be passed to
Nikolaos> + the function gnutls_certificate_set_x509_key_file2() as its last
Nikolaos> + argument.
Nikolaos> +*/
Nikolaos> +static unsigned int
Nikolaos> +key_file2_aux (Lisp_Object flags)
Nikolaos> +{
Nikolaos> + unsigned int rv = 0;
Nikolaos> + Lisp_Object tail;
Nikolaos> + for (tail = flags; CONSP (tail); tail = XCDR (tail))
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 detect
circular lists, which is good practice since this list will come from
the user level, so it could be anything :-)
Also, the function is only relevant if
HAVE_GNUTLS_CERTIFICATE_SET_X509_KEY_FILE2 is defined, so you could
wrap it in a #ifdef
Nikolaos> +The :pass and :flags keys are ignored with old versions of GnuTLS, and
Nikolaos> +:flags is ignored if :pass is not specified.
Nikolaos> +
Maybe mention that not specifying :flags or passing :flags nil means
passing '0' to the GnuTLS function?
Nikolaos> +# ifdef HAVE_GNUTLS_CERTIFICATE_SET_X509_KEY_FILE2
Nikolaos> + if (STRINGP (pass))
Nikolaos> + ret = gnutls_certificate_set_x509_key_file2
Nikolaos> + (x509_cred, SSDATA (certfile), SSDATA (keyfile), file_format, SSDATA (pass), key_file2_aux (flags));
I think you should re-wrap this line.
Nikolaos> + DEFSYM (Qgnutls_pkcs_plain, "GNUTLS_PKCS_PLAIN");
Nikolaos> + DEFSYM (Qgnutls_pkcs_pkcs12_3des, "GNUTLS_PKCS_PKCS12_3DES");
Nikolaos> + DEFSYM (Qgnutls_pkcs_pkcs12_arcfour, "GNUTLS_PKCS_PKCS12_ARCFOUR");
Nikolaos> + DEFSYM (Qgnutls_pkcs_pkcs12_rc2_40, "GNUTLS_PKCS_PKCS12_RC2_40");
Nikolaos> + DEFSYM (Qgnutls_pkcs_pbes2_3des, "GNUTLS_PKCS_PBES2_3DES");
Nikolaos> + DEFSYM (Qgnutls_pkcs_pbes2_aes_128, "GNUTLS_PKCS_PBES2_AES_128");
Nikolaos> + DEFSYM (Qgnutls_pkcs_pbes2_aes_192, "GNUTLS_PKCS_PBES2_AES_192");
Nikolaos> + DEFSYM (Qgnutls_pkcs_pbes2_aes_256, "GNUTLS_PKCS_PBES2_AES_256");
Nikolaos> + DEFSYM (Qgnutls_pkcs_null_password, "GNUTLS_PKCS_NULL_PASSWORD");
Nikolaos> + DEFSYM (Qgnutls_pkcs_pbes2_des, "GNUTLS_PKCS_PBES2_DES");
Nikolaos> + DEFSYM (Qgnutls_pkcs_pbes1_des_md5, "GNUTLS_PKCS_PBES1_DES_MD5");
Nikolaos> + DEFSYM (Qgnutls_pkcs_pbes2_gost_tc26z, "GNUTLS_PKCS_PBES2_GOST_TC26Z");
Nikolaos> + DEFSYM (Qgnutls_pkcs_pbes2_gost_cpa, "GNUTLS_PKCS_PBES2_GOST_CPA");
Nikolaos> + DEFSYM (Qgnutls_pkcs_pbes2_gost_cpb, "GNUTLS_PKCS_PBES2_GOST_CPB");
Nikolaos> + DEFSYM (Qgnutls_pkcs_pbes2_gost_cpc, "GNUTLS_PKCS_PBES2_GOST_CPC");
Nikolaos> + DEFSYM (Qgnutls_pkcs_pbes2_gost_cpd, "GNUTLS_PKCS_PBES2_GOST_CPD");
All this is kind of awkward, but apart from doing DEFVAR_LISP Iʼm 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).
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Thu, 29 Sep 2022 12:36:02 GMT)
Full text and
rfc822 format available.
Message #66 received at 50507 <at> debbugs.gnu.org (full text, mbox):
On Thu, Sep 29, 2022 at 4:17 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
> > Date: Wed, 28 Sep 2022 23:09:46 -0400
> > Cc: 50507 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
> >
> > I also added "Copyright-paperwork-exempt: yes" (or will this require
> > paperwork?)
>
> The patch is large enough to require it, yes.
>
> Would you like me to send you the legal form to start the paperwork?
>
> Thanks.
Yes, please send me the legal form.
Regards,
Nikolaos Chatzikonstantinou
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Thu, 29 Sep 2022 13:10:02 GMT)
Full text and
rfc822 format available.
Message #69 received at 50507 <at> debbugs.gnu.org (full text, mbox):
> From: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
> Date: Thu, 29 Sep 2022 08:35:40 -0400
> Cc: rpluim <at> gmail.com, 50507 <at> debbugs.gnu.org, larsi <at> gnus.org
>
> On Thu, Sep 29, 2022 at 4:17 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > From: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
> > > Date: Wed, 28 Sep 2022 23:09:46 -0400
> > > Cc: 50507 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
> > >
> > > I also added "Copyright-paperwork-exempt: yes" (or will this require
> > > paperwork?)
> >
> > The patch is large enough to require it, yes.
> >
> > Would you like me to send you the legal form to start the paperwork?
> >
> > Thanks.
>
> Yes, please send me the legal form.
Form sent off-list.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Thu, 29 Sep 2022 13:45:01 GMT)
Full text and
rfc822 format available.
Message #72 received at 50507 <at> debbugs.gnu.org (full text, mbox):
On Thu, Sep 29, 2022 at 5:02 AM Robert Pluim <rpluim <at> gmail.com> wrote:
>
> >>>>> On Wed, 28 Sep 2022 23:09:46 -0400, Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> said:
>
> Nikolaos> From b11707c423773f6234746991222acd80ab3f708c Mon Sep 17 00:00:00 2001
> Nikolaos> From: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
> Nikolaos> Date: Mon, 26 Sep 2022 11:08:18 -0400
> Nikolaos> Subject: [PATCH] add :pass and :flags to gnutls-boot for :keylist
>
> Nikolaos> + corresponds to a GnuTLS C flag, the ORed result is to be passed to
> Nikolaos> + the function gnutls_certificate_set_x509_key_file2() as its last
> Nikolaos> + argument.
> Nikolaos> +*/
> Nikolaos> +static unsigned int
> Nikolaos> +key_file2_aux (Lisp_Object flags)
> Nikolaos> +{
> Nikolaos> + unsigned int rv = 0;
> Nikolaos> + Lisp_Object tail;
> Nikolaos> + for (tail = flags; CONSP (tail); tail = XCDR (tail))
>
> 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 detect
> circular lists, which is good practice since this list will come from
> the user level, so it could be anything :-)
Good point. I opted for FOR_EACH_TAIL_SAFE, which seems even better
for this case. As documented in ChangeLog.3, it's the right one when
the operation is idempotent, which an OR of flags is. (repeated flags
do not alter the result.)
> Nikolaos> +The :pass and :flags keys are ignored with old versions of GnuTLS, and
> Nikolaos> +:flags is ignored if :pass is not specified.
> Nikolaos> +
>
> Maybe mention that not specifying :flags or passing :flags nil means
> passing '0' to the GnuTLS function?
Yes, and on that note, I discovered two things. One, the value 0 is
special; it has meaning but it is not an enumeration constant. I
documented this appropriately. Two, the password may be NULL instead
of a string.
How can I differentiate between `:pass nil` and not specifying
`:pass`? I would like to do this because in the former case I'm
calling ...key_file2() and in the latter I'm calling the original
...key_file().
> Nikolaos> + DEFSYM (Qgnutls_pkcs_plain, "GNUTLS_PKCS_PLAIN");
<removed a few more such lines>
> Nikolaos> + DEFSYM (Qgnutls_pkcs_pbes2_gost_cpd, "GNUTLS_PKCS_PBES2_GOST_CPD");
>
> All this is kind of awkward, but apart from doing DEFVAR_LISP Iʼm 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).
I am now comparing against intern("GNUTLS_PKCS_PLAIN") and so on.
I will hold off the submission of the final patch until I figure out
the :pass issue that I mentioned above.
Regards,
Nikolaos Chatzikonstantinou
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Thu, 29 Sep 2022 14:09:02 GMT)
Full text and
rfc822 format available.
Message #75 received at 50507 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 29 Sep 2022 09:44:09 -0400, Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> said:
>>
>> 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 detect
>> 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 one when
Nikolaos> the operation is idempotent, which an OR of flags is. (repeated flags
Nikolaos> do not alter the result.)
OK
Nikolaos> +The :pass and :flags keys are ignored with old versions of GnuTLS, and
Nikolaos> +:flags is ignored if :pass is not specified.
Nikolaos> +
>>
>> 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 value 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ʼre 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 original
Nikolaos> ...key_file().
Youʼd do `plist-member' to check if thereʼs a `:pass' in the plist at
all, and then `plist-get' to extract the value.
Nikolaos> + DEFSYM (Qgnutls_pkcs_plain, "GNUTLS_PKCS_PLAIN");
Nikolaos> <removed a few more such lines>
Nikolaos> + DEFSYM (Qgnutls_pkcs_pbes2_gost_cpd, "GNUTLS_PKCS_PBES2_GOST_CPD");
>>
>> All this is kind of awkward, but apart from doing DEFVAR_LISP Iʼm 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ʼs another option, but itʼs not the preferred
solution. Anyway, letʼs not let the perfect be the enemy of the good.
Thanks
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Fri, 30 Sep 2022 10:05:01 GMT)
Full text and
rfc822 format available.
Message #78 received at 50507 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Sep 29, 2022 at 10:08 AM Robert Pluim <rpluim <at> gmail.com> wrote:
>
> >>>>> On Thu, 29 Sep 2022 09:44:09 -0400, Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> said:
> Nikolaos> +The :pass and :flags keys are ignored with old versions of GnuTLS, and
> Nikolaos> +:flags is ignored if :pass is not specified.
> Nikolaos> +
> >>
> >> 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 value 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ʼre mapping ':pass nil' to that?
Yes.
> Nikolaos> + DEFSYM (Qgnutls_pkcs_plain, "GNUTLS_PKCS_PLAIN");
> Nikolaos> <removed a few more such lines>
> Nikolaos> + DEFSYM (Qgnutls_pkcs_pbes2_gost_cpd, "GNUTLS_PKCS_PBES2_GOST_CPD");
> >>
> >> All this is kind of awkward, but apart from doing DEFVAR_LISP Iʼm 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ʼs another option, but itʼs not the preferred
> solution. Anyway, letʼs not let the perfect be the enemy of the good.
I went with intern. There were some additional #if checks to avoid
dynamically loading the symbol on library Windows if it is not
available. I used plist_member() to differentiate between `:pass nil`
and not specifying `:pass`, and I documented this in the docstrings.
Regards,
Nikolaos Chatzikonstantinou
[0001-add-pass-and-flags-to-gnutls-boot-for-keylist.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Fri, 30 Sep 2022 10:48:01 GMT)
Full text and
rfc822 format available.
Message #81 received at 50507 <at> debbugs.gnu.org (full text, mbox):
> From: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
> Date: Fri, 30 Sep 2022 06:04:30 -0400
> Cc: 50507 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
>
>
> On Thu, Sep 29, 2022 at 10:08 AM Robert Pluim <rpluim <at> gmail.com> wrote:
> >
> > >>>>> On Thu, 29 Sep 2022 09:44:09 -0400, Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> said:
> > Nikolaos> +The :pass and :flags keys are ignored with old versions of GnuTLS, and
> > Nikolaos> +:flags is ignored if :pass is not specified.
> > Nikolaos> +
> > >>
> > >> 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 value 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ʼre mapping ':pass nil' to that?
>
> Yes.
>
> > Nikolaos> + DEFSYM (Qgnutls_pkcs_plain, "GNUTLS_PKCS_PLAIN");
> > Nikolaos> <removed a few more such lines>
> > Nikolaos> + DEFSYM (Qgnutls_pkcs_pbes2_gost_cpd, "GNUTLS_PKCS_PBES2_GOST_CPD");
> > >>
> > >> All this is kind of awkward, but apart from doing DEFVAR_LISP Iʼm 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ʼs another option, but itʼs not the preferred
> > solution. Anyway, letʼs not let the perfect be the enemy of the good.
>
> I went with intern.
Why not use DEFSYM and then compare against the static symbols? That
is more efficient, since the intern call is avoided at run time.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Fri, 30 Sep 2022 13:02:01 GMT)
Full text and
rfc822 format available.
Message #84 received at 50507 <at> debbugs.gnu.org (full text, mbox):
On Fri, Sep 30, 2022 at 6:47 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
> > Date: Fri, 30 Sep 2022 06:04:30 -0400
> > Cc: 50507 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>
> >
> >
> > On Thu, Sep 29, 2022 at 10:08 AM Robert Pluim <rpluim <at> gmail.com> wrote:
> > >
> > > >>>>> On Thu, 29 Sep 2022 09:44:09 -0400, Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> said:
> > > Nikolaos> +The :pass and :flags keys are ignored with old versions of GnuTLS, and
> > > Nikolaos> +:flags is ignored if :pass is not specified.
> > > Nikolaos> +
> > > >>
> > > >> 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 value 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ʼre mapping ':pass nil' to that?
> >
> > Yes.
> >
> > > Nikolaos> + DEFSYM (Qgnutls_pkcs_plain, "GNUTLS_PKCS_PLAIN");
> > > Nikolaos> <removed a few more such lines>
> > > Nikolaos> + DEFSYM (Qgnutls_pkcs_pbes2_gost_cpd, "GNUTLS_PKCS_PBES2_GOST_CPD");
> > > >>
> > > >> All this is kind of awkward, but apart from doing DEFVAR_LISP Iʼm 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ʼs another option, but itʼs not the preferred
> > > solution. Anyway, letʼs not let the perfect be the enemy of the good.
> >
> > I went with intern.
>
> Why not use DEFSYM and then compare against the static symbols? That
> is more efficient, since the intern call is avoided at run time.
I did not understand the differences between DEFSYM() and
intern(). Can DEFSYM() be used outside of syms_of_gnutls()? In
particular can I (and, should I?) call it inside the key_file2_aux()
function?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Fri, 30 Sep 2022 13:38:01 GMT)
Full text and
rfc822 format available.
Message #87 received at 50507 <at> debbugs.gnu.org (full text, mbox):
> From: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
> Date: Fri, 30 Sep 2022 09:01:06 -0400
> Cc: rpluim <at> gmail.com, 50507 <at> debbugs.gnu.org, larsi <at> gnus.org
>
> On Fri, Sep 30, 2022 at 6:47 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > I went with intern.
> >
> > Why not use DEFSYM and then compare against the static symbols? That
> > is more efficient, since the intern call is avoided at run time.
>
> I did not understand the differences between DEFSYM() and
> intern(). Can DEFSYM() be used outside of syms_of_gnutls()?
Why do you need to use DEFSYM outside of syms_of_gnutls?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Fri, 30 Sep 2022 13:50:01 GMT)
Full text and
rfc822 format available.
Message #90 received at 50507 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Sep 30, 2022 at 9:37 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
> > Date: Fri, 30 Sep 2022 09:01:06 -0400
> > Cc: rpluim <at> gmail.com, 50507 <at> debbugs.gnu.org, larsi <at> gnus.org
> >
> > On Fri, Sep 30, 2022 at 6:47 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > >
> > > > I went with intern.
> > >
> > > Why not use DEFSYM and then compare against the static symbols? That
> > > is more efficient, since the intern call is avoided at run time.
> >
> > I did not understand the differences between DEFSYM() and
> > intern(). Can DEFSYM() be used outside of syms_of_gnutls()?
>
> Why do you need to use DEFSYM outside of syms_of_gnutls?
Nevermind, I had general confusion on how the internals work. Here is
the update, using DEFSYM.
[0001-add-pass-and-flags-to-gnutls-boot-for-keylist.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Fri, 30 Sep 2022 14:33:02 GMT)
Full text and
rfc822 format available.
Message #93 received at 50507 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 30 Sep 2022 09:49:30 -0400, Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> said:
Nikolaos> +static unsigned int
Nikolaos> +key_file2_aux (Lisp_Object flags)
Nikolaos> +{
Nikolaos> + unsigned int rv = 0;
Nikolaos> + Lisp_Object tail = flags;
Nikolaos> + FOR_EACH_TAIL_SAFE (tail)
Nikolaos> + {
Nikolaos> + Lisp_Object flag = XCAR (tail);
Nikolaos> + if (EQ (flag, Qgnutls_pkcs_plain))
Nikolaos> + rv |= GNUTLS_PKCS_PLAIN;
Nikolaos> + else if(EQ (flag, Qgnutls_pkcs_pkcs12_3des))
Space after 'if' here and in the rest of the function
Nikolaos> +# ifdef HAVE_GNUTLS_CERTIFICATE_SET_X509_KEY_FILE2
Nikolaos> + if (STRINGP (pass))
Nikolaos> + ret = gnutls_certificate_set_x509_key_file2
Nikolaos> + (x509_cred, SSDATA (certfile), SSDATA (keyfile), file_format,
Nikolaos> + SSDATA (pass), key_file2_aux (flags));
Nikolaos> + else if (NILP (pass) && plist_member (proplist, QCpass))
Nikolaos> + ret = gnutls_certificate_set_x509_key_file2
Nikolaos> + (x509_cred, SSDATA (certfile), SSDATA (keyfile), file_format,
Nikolaos> + NULL, key_file2_aux (flags));
Nikolaos> + else
Nikolaos> + ret = gnutls_certificate_set_x509_key_file
Nikolaos> + (x509_cred, SSDATA (certfile), SSDATA (keyfile), file_format);
Nikolaos> +# else
Nikolaos> ret = gnutls_certificate_set_x509_key_file
Nikolaos> (x509_cred, SSDATA (certfile), SSDATA (keyfile), file_format);
Nikolaos> +# endif
2 minor points:
- If you use an intermediate variable for
the C version of pass, you can set it correctly based on `plist_member'
etc, and only have one call to _file2 (as it is itʼs kind of
difficult to quickly see the difference between the two calls)
- I think you can then rework the #else/#endif here to avoid repetition of
the call to the _file variant
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Fri, 30 Sep 2022 16:23:01 GMT)
Full text and
rfc822 format available.
Message #96 received at 50507 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Sep 30, 2022 at 10:32 AM Robert Pluim <rpluim <at> gmail.com> wrote:
>
> >>>>> On Fri, 30 Sep 2022 09:49:30 -0400, Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> said:
> Nikolaos> +static unsigned int
> Nikolaos> +key_file2_aux (Lisp_Object flags)
> Nikolaos> +{
> Nikolaos> + unsigned int rv = 0;
> Nikolaos> + Lisp_Object tail = flags;
> Nikolaos> + FOR_EACH_TAIL_SAFE (tail)
> Nikolaos> + {
> Nikolaos> + Lisp_Object flag = XCAR (tail);
> Nikolaos> + if (EQ (flag, Qgnutls_pkcs_plain))
> Nikolaos> + rv |= GNUTLS_PKCS_PLAIN;
> Nikolaos> + else if(EQ (flag, Qgnutls_pkcs_pkcs12_3des))
>
> Space after 'if' here and in the rest of the function
>
> Nikolaos> +# ifdef HAVE_GNUTLS_CERTIFICATE_SET_X509_KEY_FILE2
> Nikolaos> + if (STRINGP (pass))
> Nikolaos> + ret = gnutls_certificate_set_x509_key_file2
> Nikolaos> + (x509_cred, SSDATA (certfile), SSDATA (keyfile), file_format,
> Nikolaos> + SSDATA (pass), key_file2_aux (flags));
> Nikolaos> + else if (NILP (pass) && plist_member (proplist, QCpass))
> Nikolaos> + ret = gnutls_certificate_set_x509_key_file2
> Nikolaos> + (x509_cred, SSDATA (certfile), SSDATA (keyfile), file_format,
> Nikolaos> + NULL, key_file2_aux (flags));
> Nikolaos> + else
> Nikolaos> + ret = gnutls_certificate_set_x509_key_file
> Nikolaos> + (x509_cred, SSDATA (certfile), SSDATA (keyfile), file_format);
> Nikolaos> +# else
> Nikolaos> ret = gnutls_certificate_set_x509_key_file
> Nikolaos> (x509_cred, SSDATA (certfile), SSDATA (keyfile), file_format);
> Nikolaos> +# endif
>
> 2 minor points:
>
> - If you use an intermediate variable for
> the C version of pass, you can set it correctly based on `plist_member'
> etc, and only have one call to _file2 (as it is itʼs kind of
> difficult to quickly see the difference between the two calls)
> - I think you can then rework the #else/#endif here to avoid repetition of
> the call to the _file variant
Thanks, I worked those out too, save for the last point you made. Do
you mean this sort of thing:
#if COND
if (something)
foo();
else
bar();
#else
bar();
#endif
To be rewritten as
#if COND
if (something)
foo();
else
#endif
bar();
Because in this case, I don't trust that kind of code to survive the
test of time. Someone may come along and break it by modifying the
bar() line, and it might be a sneaky bug. It's not easy to tell.
[0001-add-pass-and-flags-to-gnutls-boot-for-keylist.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Mon, 03 Oct 2022 07:42:01 GMT)
Full text and
rfc822 format available.
Message #99 received at 50507 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 30 Sep 2022 12:22:16 -0400, Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> said:
Nikolaos> #if COND
Nikolaos> if (something)
Nikolaos> foo();
Nikolaos> else
Nikolaos> bar();
Nikolaos> #else
Nikolaos> bar();
Nikolaos> #endif
Nikolaos> To be rewritten as
Nikolaos> #if COND
Nikolaos> if (something)
Nikolaos> foo();
Nikolaos> else
Nikolaos> #endif
Nikolaos> bar();
Nikolaos> Because in this case, I don't trust that kind of code to survive the
Nikolaos> test of time. Someone may come along and break it by modifying the
Nikolaos> bar() line, and it might be a sneaky bug. It's not easy to tell.
In the first version thereʼs the risk that one of the calls to 'bar'
will be changed and the other missed.
In the second version thereʼs only one 'bar' to change. If someone
changes the 'bar' code so it doesnʼt compile under COND, thatʼs
immediately obvious.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Mon, 03 Oct 2022 13:01:02 GMT)
Full text and
rfc822 format available.
Message #102 received at 50507 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Oct 3, 2022 at 3:40 AM Robert Pluim <rpluim <at> gmail.com> wrote:
>
> >>>>> On Fri, 30 Sep 2022 12:22:16 -0400, Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> said:
> Nikolaos> #if COND
> Nikolaos> if (something)
> Nikolaos> foo();
> Nikolaos> else
> Nikolaos> bar();
> Nikolaos> #else
> Nikolaos> bar();
> Nikolaos> #endif
>
> Nikolaos> To be rewritten as
>
> Nikolaos> #if COND
> Nikolaos> if (something)
> Nikolaos> foo();
> Nikolaos> else
> Nikolaos> #endif
> Nikolaos> bar();
>
> Nikolaos> Because in this case, I don't trust that kind of code to survive the
> Nikolaos> test of time. Someone may come along and break it by modifying the
> Nikolaos> bar() line, and it might be a sneaky bug. It's not easy to tell.
>
> In the first version thereʼs the risk that one of the calls to 'bar'
> will be changed and the other missed.
>
> In the second version thereʼs only one 'bar' to change. If someone
> changes the 'bar' code so it doesnʼt compile under COND, thatʼs
> immediately obvious.
Okay then, I have the fixed patch here.
[0001-add-pass-and-flags-to-gnutls-boot-for-keylist.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Mon, 03 Oct 2022 13:20:02 GMT)
Full text and
rfc822 format available.
Message #105 received at 50507 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 3 Oct 2022 09:00:26 -0400, Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> said:
Nikolaos> Okay then, I have the fixed patch here.
Thanks, no further comment from me, I guess weʼre waiting on the
paperwork now.
Regards
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Wed, 05 Oct 2022 14:21:01 GMT)
Full text and
rfc822 format available.
Message #108 received at 50507 <at> debbugs.gnu.org (full text, mbox):
On Mon, Oct 3, 2022 at 9:19 AM Robert Pluim <rpluim <at> gmail.com> wrote:
>
> >>>>> On Mon, 3 Oct 2022 09:00:26 -0400, Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> said:
>
> Nikolaos> Okay then, I have the fixed patch here.
>
> Thanks, no further comment from me, I guess weʼre waiting on the
> paperwork now.
Alas I hit a snag with the paperwork, so it will have to wait a few months...
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Fri, 23 Dec 2022 15:47:01 GMT)
Full text and
rfc822 format available.
Message #111 received at 50507 <at> debbugs.gnu.org (full text, mbox):
On Mon, Oct 3, 2022 at 4:19 PM Robert Pluim <rpluim <at> gmail.com> wrote:
>
> >>>>> On Mon, 3 Oct 2022 09:00:26 -0400, Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> said:
>
> Nikolaos> Okay then, I have the fixed patch here.
>
> Thanks, no further comment from me, I guess weʼre waiting on the
> paperwork now.
The assignment was signed and accepted and now you can proceed with the patch.
Regards,
Nikolaos Chatzikonstantinou
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Thu, 29 Dec 2022 09:02:02 GMT)
Full text and
rfc822 format available.
Message #114 received at 50507 <at> debbugs.gnu.org (full text, mbox):
> From: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
> Date: Fri, 23 Dec 2022 17:46:15 +0200
> Cc: 50507 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org
>
> On Mon, Oct 3, 2022 at 4:19 PM Robert Pluim <rpluim <at> gmail.com> wrote:
> >
> > >>>>> On Mon, 3 Oct 2022 09:00:26 -0400, Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com> said:
> >
> > Nikolaos> Okay then, I have the fixed patch here.
> >
> > Thanks, no further comment from me, I guess weʼre waiting on the
> > paperwork now.
>
> The assignment was signed and accepted and now you can proceed with the patch.
Robert, are you going to take care of this, or should I do it?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Thu, 29 Dec 2022 17:04:01 GMT)
Full text and
rfc822 format available.
Message #117 received at 50507 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Dec 29, 2022, 10:00 Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
> > Date: Fri, 23 Dec 2022 17:46:15 +0200
> > Cc: 50507 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org
> >
> > On Mon, Oct 3, 2022 at 4:19 PM Robert Pluim <rpluim <at> gmail.com> wrote:
> > >
> > > >>>>> On Mon, 3 Oct 2022 09:00:26 -0400, Nikolaos Chatzikonstantinou <
> nchatz314 <at> gmail.com> said:
> > >
> > > Nikolaos> Okay then, I have the fixed patch here.
> > >
> > > Thanks, no further comment from me, I guess weʼre waiting on the
> > > paperwork now.
> >
> > The assignment was signed and accepted and now you can proceed with the
> patch.
>
> Robert, are you going to take care of this, or should I do it?
>
> Thanks.
>
Hi Eli,
I can get to it tomorrow. For master I presume?
Thanks
Robert
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Thu, 29 Dec 2022 17:18:02 GMT)
Full text and
rfc822 format available.
Message #120 received at 50507 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Date: Thu, 29 Dec 2022 18:03:25 +0100
> Cc: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>, 50507 <at> debbugs.gnu.org,
> Lars Magne Ingebrigtsen <larsi <at> gnus.org>
>
> I can get to it tomorrow.
Sure, there's no rush.
> For master I presume?
Yes, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Fri, 30 Dec 2022 16:43:02 GMT)
Full text and
rfc822 format available.
Message #123 received at 50507 <at> debbugs.gnu.org (full text, mbox):
tags 50507 fixed
close 50507 30.1
quit
Done (with a very minor change to the commit message: I added the bug
number).
I tested with and without GnuTLS builds on GNU/Linux. The MS-Windows
changes looked sane, but I didnʼt test those.
Thanks for this.
Closing.
Committed as e9983b1b635
Added tag(s) fixed.
Request was from
Robert Pluim <rpluim <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Fri, 30 Dec 2022 16:43:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 30.1, send any further explanations to
50507 <at> debbugs.gnu.org and Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
Request was from
Robert Pluim <rpluim <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Fri, 30 Dec 2022 16:43:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Fri, 30 Dec 2022 20:46:01 GMT)
Full text and
rfc822 format available.
Message #130 received at 50507 <at> debbugs.gnu.org (full text, mbox):
After e9983b1b63, the build of master fails on emba.gnu.org which perhaps uses a slightly older gnutls. Errors below.
CC gnutls.o
gnutls.c: In function 'key_file2_aux':
gnutls.c:1829:8: error: 'GNUTLS_PKCS_PBES2_GOST_TC26Z' undeclared (first use in this function)
rv |= GNUTLS_PKCS_PBES2_GOST_TC26Z;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
gnutls.c:1829:8: note: each undeclared identifier is reported only once for each function it appears in
gnutls.c:1831:8: error: 'GNUTLS_PKCS_PBES2_GOST_CPA' undeclared (first use in this function)
rv |= GNUTLS_PKCS_PBES2_GOST_CPA;
^~~~~~~~~~~~~~~~~~~~~~~~~~
gnutls.c:1833:8: error: 'GNUTLS_PKCS_PBES2_GOST_CPB' undeclared (first use in this function)
rv |= GNUTLS_PKCS_PBES2_GOST_CPB;
^~~~~~~~~~~~~~~~~~~~~~~~~~
gnutls.c:1835:8: error: 'GNUTLS_PKCS_PBES2_GOST_CPC' undeclared (first use in this function)
rv |= GNUTLS_PKCS_PBES2_GOST_CPC;
^~~~~~~~~~~~~~~~~~~~~~~~~~
gnutls.c:1837:8: error: 'GNUTLS_PKCS_PBES2_GOST_CPD' undeclared (first use in this function)
rv |= GNUTLS_PKCS_PBES2_GOST_CPD;
^~~~~~~~~~~~~~~~~~~~~~~~~~
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Fri, 30 Dec 2022 23:00:01 GMT)
Full text and
rfc822 format available.
Message #133 received at 50507 <at> debbugs.gnu.org (full text, mbox):
> On 30 Dec 2022, at 10:45 PM, Mattias Engdegård <mattias.engdegard <at> gmail.com> wrote:
>
> After e9983b1b63, the build of master fails on emba.gnu.org which perhaps uses a slightly older gnutls. Errors below.
>
> CC gnutls.o
> gnutls.c: In function 'key_file2_aux':
> gnutls.c:1829:8: error: 'GNUTLS_PKCS_PBES2_GOST_TC26Z' undeclared (first use in this function)
> rv |= GNUTLS_PKCS_PBES2_GOST_TC26Z;
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> gnutls.c:1829:8: note: each undeclared identifier is reported only once for each function it appears in
> gnutls.c:1831:8: error: 'GNUTLS_PKCS_PBES2_GOST_CPA' undeclared (first use in this function)
> rv |= GNUTLS_PKCS_PBES2_GOST_CPA;
> ^~~~~~~~~~~~~~~~~~~~~~~~~~
> gnutls.c:1833:8: error: 'GNUTLS_PKCS_PBES2_GOST_CPB' undeclared (first use in this function)
> rv |= GNUTLS_PKCS_PBES2_GOST_CPB;
> ^~~~~~~~~~~~~~~~~~~~~~~~~~
> gnutls.c:1835:8: error: 'GNUTLS_PKCS_PBES2_GOST_CPC' undeclared (first use in this function)
> rv |= GNUTLS_PKCS_PBES2_GOST_CPC;
> ^~~~~~~~~~~~~~~~~~~~~~~~~~
> gnutls.c:1837:8: error: 'GNUTLS_PKCS_PBES2_GOST_CPD' undeclared (first use in this function)
> rv |= GNUTLS_PKCS_PBES2_GOST_CPD;
> ^~~~~~~~~~~~~~~~~~~~~~~~~~
>
I can work on this tomorrow and fix it. I think it needs preprocessor guards on the version.
Regards,
Nikolaos Chatzikonstantinou
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Sat, 31 Dec 2022 07:26:02 GMT)
Full text and
rfc822 format available.
Message #136 received at 50507 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Fri, 30 Dec 2022 21:45:10 +0100
> Cc: 50507 <at> debbugs.gnu.org,
> Robert Pluim <rpluim <at> gmail.com>,
> Eli Zaretskii <eliz <at> gnu.org>
>
> After e9983b1b63, the build of master fails on emba.gnu.org which perhaps uses a slightly older gnutls. Errors below.
Thanks, should be fixed now.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Sat, 31 Dec 2022 07:29:02 GMT)
Full text and
rfc822 format available.
Message #139 received at 50507 <at> debbugs.gnu.org (full text, mbox):
> From: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
> Date: Sat, 31 Dec 2022 00:59:09 +0200
> Cc: 50507 <at> debbugs.gnu.org, Robert Pluim <rpluim <at> gmail.com>,
> Eli Zaretskii <eliz <at> gnu.org>
>
> > gnutls.c:1837:8: error: 'GNUTLS_PKCS_PBES2_GOST_CPD' undeclared (first use in this function)
> > rv |= GNUTLS_PKCS_PBES2_GOST_CPD;
> > ^~~~~~~~~~~~~~~~~~~~~~~~~~
> >
>
> I can work on this tomorrow and fix it. I think it needs preprocessor guards on the version.
Since GnuTLS's documentation doesn't bother specifying when these
constants were introduced (some in 3.5.x, some in 3.6.x), I preferred
to condition the use of each constant by its being defined, instead of
conditioning on versions.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Sat, 31 Dec 2022 07:34:01 GMT)
Full text and
rfc822 format available.
Message #142 received at 50507 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: 50507 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org> , larsi <at> gnus.org
> Date: Fri, 30 Dec 2022 17:41:58 +0100
>
> Done (with a very minor change to the commit message: I added the bug
> number).
>
> I tested with and without GnuTLS builds on GNU/Linux. The MS-Windows
> changes looked sane, but I didnʼt test those.
Thanks, the basic HTTPS connectivity seems to work on MS-Windows after
the change. Are there any special tests of the new functionality I
should try? There aren't any tests for this in the test suite,
AFAICT.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Sat, 31 Dec 2022 08:59:02 GMT)
Full text and
rfc822 format available.
Message #145 received at 50507 <at> debbugs.gnu.org (full text, mbox):
>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Mattias Engdegård <mattias.engdegard <at> gmail.com> Date: Fri,
>> 30 Dec 2022 21:45:10 +0100 Cc: 50507 <at> debbugs.gnu.org, Robert
>> Pluim <rpluim <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
>>
>> After e9983b1b63, the build of master fails on emba.gnu.org which
>> perhaps uses a slightly older gnutls. Errors below.
> Thanks, should be fixed now.
It is. Thank you.
Best wishes,
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Sat, 31 Dec 2022 09:45:02 GMT)
Full text and
rfc822 format available.
Message #148 received at 50507 <at> debbugs.gnu.org (full text, mbox):
31 dec. 2022 kl. 08.25 skrev Eli Zaretskii <eliz <at> gnu.org>:
> Thanks, should be fixed now.
Good -- emba.gnu.org seems happy.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#50507
; Package
emacs
.
(Mon, 02 Jan 2023 10:25:02 GMT)
Full text and
rfc822 format available.
Message #151 received at 50507 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Sat, 31 Dec 2022 09:33:20 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: 50507 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org> , larsi <at> gnus.org
>> Date: Fri, 30 Dec 2022 17:41:58 +0100
>>
>> Done (with a very minor change to the commit message: I added the bug
>> number).
>>
>> I tested with and without GnuTLS builds on GNU/Linux. The MS-Windows
>> changes looked sane, but I didnʼt test those.
Eli> Thanks, the basic HTTPS connectivity seems to work on MS-Windows after
Eli> the change. Are there any special tests of the new functionality I
Eli> should try? There aren't any tests for this in the test suite,
Eli> AFAICT.
There are no tests for TLS connections with client side certificates
at all, let alone password protected ones. They must work, nobody has
ever complained about them 😺
Robert
--
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 30 Jan 2023 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 79 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.