From poka.prasanna at gmail.com Wed Aug 12 12:09:14 2020 From: poka.prasanna at gmail.com (POKA PRASANNA) Date: Wed, 12 Aug 2020 12:09:14 +0200 Subject: [gnutls-help] Details about the GNU TLS Message-ID: Hi, I am Prasanna Poka pursuing my master's in Chemnitz University of Technology. As part of my Master Thesis, I am looking for a TLS library which is lightweight and supports my requirements. I have gone through the product flyer of the GNU TLS and it almost suits my requirements. Still I could not find some other details. I request you to please let me know about the following details. - What is the range of the memory footprint this library provides? - Can we use this library for ARM Cortex M33 and M4 microcontrollers? - Is the Brain pool curve supported by GNU TLS? - Can this library be used on FreeRTOS, MbedOS? Looking forward to hearing from you. Kind Regards, Prasanna Poka -------------- next part -------------- An HTML attachment was scrubbed... URL: From ueno at gnu.org Thu Aug 13 07:55:53 2020 From: ueno at gnu.org (Daiki Ueno) Date: Thu, 13 Aug 2020 07:55:53 +0200 Subject: [gnutls-help] Details about the GNU TLS In-Reply-To: (POKA PRASANNA's message of "Wed, 12 Aug 2020 12:09:14 +0200") References: Message-ID: <875z9n9jiu.fsf-ueno@gnu.org> Hello Prasanna, Thank you for reaching out to us. POKA PRASANNA writes: > Hi, > I am Prasanna Poka pursuing my master's in Chemnitz University of Technology. As > part of my Master Thesis, I am looking for a TLS library which is lightweight and supports > my requirements. I have gone through the product flyer of the GNU TLS and it almost > suits my requirements. Still I could not find some other details. I request you to please > let me know about the following details. Before answering to those questions, I would like to remind that: - While the portability of GnuTLS is guaranteed by the Gnulib library[1], GnuTLS makes use of the system libraries (p11-kit, libtasn1, etc) which may not be portable enough for your use-case. - The crypto algorithms are implemented in the Nettle library[2], unless they are overridden by the internal acceleration code (lib/accelerated). > * What is the range of the memory footprint this library provides? I think that depends on the configuration (both at the build time and run time), as well as your use-case. I would suggest running the example tools (gnutls-cli, gnutls-serv) under the valgrind massif tool[3] and exercise the desired scenario. > * Can we use this library for ARM Cortex M33 and M4 microcontrollers? That depends on what OS is used; Dmitry (Cc'ed) might have insight on those controllers. > * Is the Brain pool curve supported by GNU TLS? No, Nettle currently doesn't support Brainpool curves. > * Can this library be used on FreeRTOS, MbedOS? I'm unfamiliar with those embedded operating systems, but I guess it's unlikely unless they provide POSIX compatibility. Footnotes: [1] https://www.gnu.org/software/gnulib/ [2] https://www.lysator.liu.se/~nisse/nettle/ [3] https://www.valgrind.org/docs/manual/ms-manual.html Regards, -- Daiki Ueno From ametzler at bebt.de Sun Aug 16 14:44:33 2020 From: ametzler at bebt.de (Andreas Metzler) Date: Sun, 16 Aug 2020 14:44:33 +0200 Subject: [gnutls-help] dh_params - docs Message-ID: <20200816124433.GC1456@argenau.bebt.de> Hello, the API reference manaual says this about gnutls_certificate_set_dh_params(): | gnutls_certificate_set_dh_params is deprecated and should not be used in | newly-written code. | | This function is unnecessary and discouraged on GnuTLS 3.6.0 or later. | Since 3.6.0, DH parameters are negotiated following RFC7919. Which I would read as "when upgrading code to (only) work with gnutls 3.6.0 one should delete any gnutls_certificate_set_dh_params()-invocations since they are unnecessary because GnuTLS will automatically do RFC7919 negotiation." However it looks like (see below) that is not true, there is no automation but gnutls_certificate_set_dh_params needs to be replaced with gnutls_certificate_set_known_dh_params (). To verify this, take ex-serv-x509 and remove gnutls_certificate_set_known_dh_params(x509_cred, GNUTLS_SEC_PARAM_MEDIUM); After this change openssl s_client -connect localhost:5556 -cipher DHE-RSA-AES256-GCM-SHA384 -tls1_2 will fail. cu Andreas https://github.com/rbsec/sslscan/issues/214 https://bugs.debian.org/968145 -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From ueno at gnu.org Mon Aug 17 14:36:25 2020 From: ueno at gnu.org (Daiki Ueno) Date: Mon, 17 Aug 2020 14:36:25 +0200 Subject: [gnutls-help] dh_params - docs In-Reply-To: <20200816124433.GC1456@argenau.bebt.de> (Andreas Metzler's message of "Sun, 16 Aug 2020 14:44:33 +0200") References: <20200816124433.GC1456@argenau.bebt.de> Message-ID: <878sedmoty.fsf-ueno@gnu.org> Andreas Metzler writes: > the API reference manaual says this about gnutls_certificate_set_dh_params(): > > | gnutls_certificate_set_dh_params is deprecated and should not be used in > | newly-written code. > | > | This function is unnecessary and discouraged on GnuTLS 3.6.0 or later. > | Since 3.6.0, DH parameters are negotiated following RFC7919. > > Which I would read as "when upgrading code to > (only) work with gnutls 3.6.0 one should delete any > gnutls_certificate_set_dh_params()-invocations since they are > unnecessary because GnuTLS will automatically do RFC7919 negotiation." > > However it looks like (see below) that is not true, there is no > automation but gnutls_certificate_set_dh_params needs to be replaced with > gnutls_certificate_set_known_dh_params (). > > To verify this, take ex-serv-x509 and remove > gnutls_certificate_set_known_dh_params(x509_cred, GNUTLS_SEC_PARAM_MEDIUM); > > After this change > openssl s_client -connect localhost:5556 -cipher > DHE-RSA-AES256-GCM-SHA384 -tls1_2 > will fail. That was also my expectation, though I suspect that it's saying that it only works when the client advertises the "supported_groups" extension according to the RFC, which is not sent with the above command. In the OpenSSL git master, s_client provides the -groups option for that, and you will be able to connect to the server with: $ openssl s_client -connect localhost:5556 -tls1_3 -groups ffdhe2048 though the option doesn't seem to work with -tls1_2. Regards, -- Daiki Ueno From danielmorrison1989 at gmail.com Fri Aug 21 18:37:51 2020 From: danielmorrison1989 at gmail.com (Daniel Morrison) Date: Fri, 21 Aug 2020 17:37:51 +0100 Subject: [gnutls-help] Change in staleness behaviour of gnutls_x509_crt_t values? Message-ID: Hi! I am new to gnutls so apologies if this is obvious but I've struggled to determine this. The company I work for makes use of gnutls in the following way: 1) initialise "gnutls_x509_crt_t" object using "gnutls_x509_cert_init" 2) populate various values using "gnutls_x509_crt_set_key", "gnutls_x509_crt_set_dn_by_oid" etc. and sign it with "gnutls_x509_crt_sign2", providing it with the issuing CA. 3) Provide the complete chain (including the issuing CA, in order) to the "gnutls_certificate_set_x509_key" function. Recently we upgraded from 3.3.26 to 3.6.7 (a big jump I realise!) and found that the "gnutls_pcert_import_x509_list" call, inside "gnutls_certificate_set_x509_key" is failing to determine that the first certificate is issued by the 2nd cert in the chain. As such it fails to import the rest of the chain during the sort process. Debugging using gdb shows that various fields inside the "gnutls_x509_crt_t" instance, such as "raw_dn" and "raw_issuer_dn" are blank. Exporting the certificate into a raw char buffer via "gnutls_x509_crt_export", and then back into a new "gnutls_x509_crt_t" instance via "gnutls_x509_crt_import" then shows that these fields are correctly populated and all works as expected. Is this the correct expected behaviour (i.e. these fields remain stale until exported/imported) and did this behaviour change at some point during the last few years? Thanks for any assistance. Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From JonasZhou at zhaoxin.com Tue Aug 25 10:41:24 2020 From: JonasZhou at zhaoxin.com (Jonas Zhou(SH-RD)) Date: Tue, 25 Aug 2020 08:41:24 +0000 Subject: [gnutls-help] The difference between _gnutls_hmac_sha_padlock and _gnutls_hmac_sha_padlock_nano Message-ID: <1f0584ded543474e8d5b25654502a562@zhaoxin.com> Hi all The difference between _gnutls_hmac_sha_padlock and _gnutls_hmac_sha_padlock_nano? There are struct gnutls_crypto_mac_st. In file hmac-padlock.c. Thank you. Best Regard Jonas ????? ????????????????????????????????????????????????????? CONFIDENTIAL NOTE: This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From curtis at ipv6.occnc.com Tue Aug 25 02:09:15 2020 From: curtis at ipv6.occnc.com (Curtis Villamizar) Date: Mon, 24 Aug 2020 20:09:15 -0400 Subject: [gnutls-help] generating self signed cert - no way to set spki Message-ID: <20200825113003.C7A5A20AA5@smtp.easymail.ca> I'm working with code that worked with prior releases of gnutls (a year ago?) but with the current version (3.6.14) gnutls_x509_crt_sign2 produces a GNUTLS_E_ASN1_ELEMENT_NOT_FOUND apparently in _gnutls_x509_pkix_sign when it tries _gnutls_privkey_get_spki_params . fyi- My immediate need is to sign some new application certs. I also have a second level CA cert that needs resigning. When the code didn't work I tried generating a new top level CA for testing and that led to some of the issues mentioned here. These keys and certs are normally used internally (mua-msa, mta-mda, imap, spamc-spamd, internal https) and other internal use with a local copy of a CA cert or DANE plus for SMTP with DANE for general email use. Initially I tried gnutls_x509_*_get_spki on the crt, crq to see if I could get a gnutls_x509_spki_t out of any of them. Even the working CA certs return GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE . The ugly short cut is to cheat and copy "typedef struct gnutls_x509_spki_st { ... } gnutls_x509_spki_st;" from crypto-backend.h into my code, fill it in and pass it to gnutls_x509_privkey_set_spki but I don't want to do that and I'm sure no one wants me to do that. The code I used is: struct __spki { gnutls_pk_algorithm_t pk; gnutls_digest_algorithm_t rsa_pss_dig; // RSA-PSS unsigned int salt_size; // RSA-PSS unsigned int legacy; // ignore - set to zero gnutls_digest_algorithm_t dsa_dig; unsigned int flags; // 0 or GNUTLS_PK_FLAG_REPRODUCIBLE }; struct __spki * pt; pt = (struct __spki *) spki; pt->pk = (gnutls_pk_algorithm_t) gnutls_x509_crt_get_pk_algorithm(auth_crt, 0); pt->rsa_pss_dig = GNUTLS_DIG_SHA256; pt->salt_size = 20; pt->legacy = 0; pt->dsa_dig = GNUTLS_DIG_SHA256; There is no function in the interface (documented or that I found in the .h files) to fill in a gnutls_x509_spki_t or alternate way to provide it in signing. There are functions to get it from some struct and set it in something else. There is no spki in the issuer yet since this is a self signing and the crt and issuer pointers are the same and is not yet signed. Chicken and egg? This should only affect the epoch self signing. This used to work as recently as August 2019 based on some of the certs I checked. The certs generated with a prior gnutls contain Subject Public Key Info objects but with only the Public Key Algorith filled in and they have Signature Algorithm from which the digest can be determined. Am I missing something? Having temporarily worked around that with the hack above I got problems in _gnutls_x509_pkix_sign calling _gnutls_x509_der_encode on the cert. Below is some debug code and an interim fix/workaround. The debug code is obvios (writing to stderr and a /tmp file). The fix/workaround is the code involving buf and sizeof buf. In digging into asn1_der_coding I found the this commit https://gitlab.com/gnutls/gnutls/-/commit/49d27a55031e72ade52984f5cd94e82e97b46228 and looked into the coding. The higher level error that I got turned out to be a rejection of a valid (13 char utcTime) tbsCertificate.validity dumped below. name:validity type:SEQUENCE name:notBefore type:CHOICE name:utcTime type:UTC_TIME value:200824000118Z name:notAfter type:CHOICE name:utcTime type:UTC_TIME value:250824000118Z There was a comment by smav at a lower level about an in-place modification for no apparent reason which prompted the buf and sizeof buf hack below. That turned out to fix it, though it should have had no effect. The patch with debug is here (for your entertainment, not to apply the patch). --- lib/x509/common.c.orig 2020-06-01 05:48:13.000000000 -0400 +++ lib/x509/common.c 2020-08-24 21:07:24.264406000 -0400 @@ -843,19 +843,66 @@ _gnutls_x509_der_encode(ASN1_TYPE src, const char *src_name, gnutls_datum_t * res, int str) { + char buf[4096]; // stack space is cheap int size, result; int asize; uint8_t *data = NULL; ASN1_TYPE c2 = ASN1_TYPE_EMPTY; - size = 0; - result = asn1_der_coding(src, src_name, NULL, &size, NULL); + fprintf(stderr, "\n_gnutls_x509_der_encode: %s\n", src_name); + + size = sizeof(buf) - 1; + result = asn1_der_coding(src, src_name, buf, &size, NULL); /* this check explicitly covers the case where size == 0 && result == 0 */ - if (result != ASN1_MEM_ERROR) { + if (result != ASN1_MEM_ERROR && result != 0) { + + FILE *fio = fopen("/tmp/asn1_src", "w"); + asn1_print_structure(fio, src, src_name, ASN1_PRINT_ALL); + + fprintf(stderr, + "\n_gnutls_x509_der_encode: der coding err %s\n", + asn1_strerror(result)); + + if ((result == ASN1_VALUE_NOT_VALID) + && (0 == strcmp(src_name, "tbsCertificate"))) { + const char * strlist[] = { + "tbsCertificate.version", + "tbsCertificate.serialNumber", + "tbsCertificate.signature", + "tbsCertificate.issuer", + "tbsCertificate.validity", + "tbsCertificate.subject", + "tbsCertificate.subjectPublicKeyInfo", + "tbsCertificate.extensions", + 0 + }; + int r2; + const char **pt; + pt = &strlist[0]; + for ( ; *pt; ++pt) { + size = sizeof(buf) - 1; + r2 = asn1_der_coding(src, *pt, + buf, &size, NULL); + if (r2 != ASN1_MEM_ERROR) { + fprintf(stderr, + "\n_gnutls_x509_der_encode: " + "attr %s err %s\n", + *pt, asn1_strerror(r2)); + fprintf(fio, "\n\n"); + asn1_print_structure(fio, src, *pt, + ASN1_PRINT_ALL); + } + } + } + + fclose(fio); + gnutls_assert(); return _gnutls_asn2err(result); } + fprintf(stderr, "\n_gnutls_x509_der_encode alloc\n"); + /* allocate data for the der */ @@ -869,6 +916,8 @@ return GNUTLS_E_MEMORY_ERROR; } + fprintf(stderr, "\n_gnutls_x509_der_encode asn1_der_coding\n"); + result = asn1_der_coding(src, src_name, data, &size, NULL); if (result != ASN1_SUCCESS) { gnutls_assert(); @@ -876,6 +925,8 @@ goto cleanup; } + fprintf(stderr, "\n_gnutls_x509_der_encode str fixup\n"); + if (str) { if ((result = asn1_create_element (_gnutls_get_pkix(), "PKIX1.pkcs-7-Data", @@ -903,6 +954,8 @@ asn1_delete_structure(&c2); } + + fprintf(stderr, "\n_gnutls_x509_der_encode done!\n\n"); res->data = data; res->size = (unsigned) size; The part of the patch that constitutes a fix/workaround (that works for no good reason) is here. --- lib/x509/common.c.orig 2020-06-01 05:48:13.000000000 -0400 +++ lib/x509/common.c 2020-08-24 22:24:06.668138000 -0400 @@ -843,15 +843,16 @@ _gnutls_x509_der_encode(ASN1_TYPE src, const char *src_name, gnutls_datum_t * res, int str) { + char buf[4096]; // stack space is cheap int size, result; int asize; uint8_t *data = NULL; ASN1_TYPE c2 = ASN1_TYPE_EMPTY; - size = 0; - result = asn1_der_coding(src, src_name, NULL, &size, NULL); + size = sizeof(buf) - 1; + result = asn1_der_coding(src, src_name, buf, &size, NULL); /* this check explicitly covers the case where size == 0 && result == 0 */ - if (result != ASN1_MEM_ERROR) { + if (result != ASN1_MEM_ERROR && result != 0) { gnutls_assert(); return _gnutls_asn2err(result); } So there are two issues here: 1. No way to fill in a spki struct. I may be missing something. 2. Fix/workaround in _gnutls_x509_der_encode that works for no apparent reason and may point to an issue downstack with a modify in place according to a comment or may be something else but is an issue. It causes a legitimate struct to be rejected by asn1_der_coding which is itself a bug and why the patch above fixes it is a mystery. I'm not even sure how to form a bug report (or two bugs) on this but in both cases I have an interim workaround. I have not cooked this down to a simple test case to reproduce the error. Not being familiar with the internals here I figured I'd ask before filing a bug report. Thanks in advance, Curtis From JonasZhou at zhaoxin.com Wed Aug 26 05:11:32 2020 From: JonasZhou at zhaoxin.com (Jonas Zhou(SH-RD)) Date: Wed, 26 Aug 2020 03:11:32 +0000 Subject: [gnutls-help] padlock phe have two branch Message-ID: <9147c3858c62449db06ba9c970063f46@zhaoxin.com> Hi I am Jonas Zhou. When I look at the code of x86-common.c, I found that there are two branches under padlock phe. One is padlock sha1 and sha256(partial) accelerator, another is padlock sha1 and sha256 accelerator. I request you to please let me know about the following details. l What is the difference between the algorithms registered in these two branches?(In gnutls-cli -benchmark-ciphers, I found that the functions they call are the same.) Best Regard Jonas Zhou ????? ????????????????????????????????????????????????????? CONFIDENTIAL NOTE: This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ueno at gnu.org Wed Aug 26 15:48:11 2020 From: ueno at gnu.org (Daiki Ueno) Date: Wed, 26 Aug 2020 15:48:11 +0200 Subject: [gnutls-help] generating self signed cert - no way to set spki In-Reply-To: <20200825113003.C7A5A20AA5@smtp.easymail.ca> (Curtis Villamizar's message of "Mon, 24 Aug 2020 20:09:15 -0400") References: <20200825113003.C7A5A20AA5@smtp.easymail.ca> Message-ID: <87y2m1cyck.fsf-ueno@gnu.org> Hello Curtis, Curtis Villamizar writes: There are quite a lot here and I can't tell what is the root cause until I see the code. Would it be possible to provide a standalone reproducer? > So there are two issues here: > > 1. No way to fill in a spki struct. I may be missing something. This one is easy to answer: you can use gnutls_x509_spki_init, gnutls_x509_spki_set_rsa_pss_params, and gnutls_x509_spki_deinit. Regards, -- Daiki Ueno From curtis at ipv6.occnc.com Wed Aug 26 07:48:41 2020 From: curtis at ipv6.occnc.com (Curtis Villamizar) Date: Wed, 26 Aug 2020 01:48:41 -0400 Subject: [gnutls-help] generating self signed cert - no way to set spki In-Reply-To: Your message of "Wed, 26 Aug 2020 15:48:11 +0200." <87y2m1cyck.fsf-ueno@gnu.org> Message-ID: <20200826170936.02C286057B@smtp.easymail.ca> That is OK if using RSA. Doesn't help with EC CA certs. Curtis In message <87y2m1cyck.fsf-ueno at gnu.org> Daiki Ueno writes: > > Hello Curtis, > > Curtis Villamizar writes: > > There are quite a lot here and I can't tell what is the root cause until > I see the code. Would it be possible to provide a standalone > reproducer? > > > So there are two issues here: > > > > 1. No way to fill in a spki struct. I may be missing something. > > This one is easy to answer: you can use gnutls_x509_spki_init, > gnutls_x509_spki_set_rsa_pss_params, and gnutls_x509_spki_deinit. > > Regards, > -- > Daiki Ueno From ueno at gnu.org Thu Aug 27 13:26:13 2020 From: ueno at gnu.org (Daiki Ueno) Date: Thu, 27 Aug 2020 13:26:13 +0200 Subject: [gnutls-help] generating self signed cert - no way to set spki In-Reply-To: (Curtis Villamizar's message of "Wed, 26 Aug 2020 01:48:41 -0400") References: Message-ID: <87imd4fhyi.fsf-ueno@gnu.org> Curtis Villamizar writes: > That is OK if using RSA. Doesn't help with EC CA certs. Yes, because the gnutls_x509_spki_t structure was introduced to cover the use-case of RSA-PSS. The question is why you determine that it's the cause of the failure you are facing; if you are dealing with EC certs, that structure shouldn't be used at all. That's why I'm asking for a reproducer. Aren't you able to achieve the same task with certtool either? See also: https://www.chiark.greenend.org.uk/~sgtatham/bugs.html#symptoms :-) Regards, > Curtis > > > In message <87y2m1cyck.fsf-ueno at gnu.org> > Daiki Ueno writes: >> >> Hello Curtis, >> >> Curtis Villamizar writes: >> >> There are quite a lot here and I can't tell what is the root cause until >> I see the code. Would it be possible to provide a standalone >> reproducer? >> >> > So there are two issues here: >> > >> > 1. No way to fill in a spki struct. I may be missing something. >> >> This one is easy to answer: you can use gnutls_x509_spki_init, >> gnutls_x509_spki_set_rsa_pss_params, and gnutls_x509_spki_deinit. >> >> Regards, >> -- >> Daiki Ueno > > !DSPAM:5f46975d31589564056514466! From curtis at ipv6.occnc.com Sat Aug 29 13:31:12 2020 From: curtis at ipv6.occnc.com (Curtis Villamizar) Date: Sat, 29 Aug 2020 07:31:12 -0400 Subject: [gnutls-help] generating self signed cert - no way to set spki In-Reply-To: Your message of "Fri, 28 Aug 2020 13:45:58 -0400." Message-ID: <20200829225218.AA6257FF57@smtp.easymail.ca> A bug report has been created. https://gitlab.com/gnutls/gnutls/-/issues/1078 testcase c++ file provided. gnutls patch provided. testcases with unpatch gnutls fails. With gnutls patch testcases that are expected to work do work. Patch may mask the problem rather than fix it. Details in the bug report. Email here is just to close the thread and move any further discussion to the bug report. Curtis In message Curtis Villamizar writes: In message <87imd4fhyi.fsf-ueno at gnu.org> Daiki Ueno writes: > > Curtis Villamizar writes: > > > That is OK if using RSA. Doesn't help with EC CA certs. > > Yes, because the gnutls_x509_spki_t structure was introduced to cover > the use-case of RSA-PSS. The question is why you determine that it's > the cause of the failure you are facing; if you are dealing with EC > certs, that structure shouldn't be used at all. That's why I'm asking > for a reproducer. Right. I thought what I found in the core dump was a hint as to why I was trying to initialize an spki struct. I'm working with code that worked with prior releases of gnutls (a year ago?) but with the current version (3.6.14) gnutls_x509_crt_sign2 produces a GNUTLS_E_ASN1_ELEMENT_NOT_FOUND apparently in _gnutls_x509_pkix_sign when it tries _gnutls_privkey_get_spki_params . This is from taking a core file and then putting debug statements in the gnutls code. If it should not be asking for a spki struct then that is a possible hint (for me to look at my code). I couldn't read the spki from the key since gnutls_x509_*_get_spki produced GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE looking for spki parameters applicable only to RSA-PSS. I've tried a bunch of things using my older working key and cert files and certtool and got various errors from certtool but nothing that sheds much light on this so I'll have to produce cooked down source code to reproduce the errors. > Aren't you able to achieve the same task with certtool either? I use my own software to generate keys and certs from configuration files. I had many years ago used a perl program that did execs to openssl and looked at the gnutls command line tools as well. This was very cumbersome. Too much info would need to go into perl program generated config files to run either openssl or gnutls command line tools and there were some things that were a pain to do (such as check to see if params in the keys and certs in use matched the latest configs which required parsing the ascii output). > See also: > https://www.chiark.greenend.org.uk/~sgtatham/bugs.html#symptoms > :-) Thanks for the useful pointer. > Regards, Thanks for looking at this. I didn't want to leave the conversation hanging but can't get to this right away. After getting cooked down c code to simplify reproducing this I'll get back to you. > > Curtis > > > > > > In message <87y2m1cyck.fsf-ueno at gnu.org> > > Daiki Ueno writes: > >> > >> Hello Curtis, > >> > >> Curtis Villamizar writes: > >> > >> There are quite a lot here and I can't tell what is the root cause until > >> I see the code. Would it be possible to provide a standalone > >> reproducer? > >> > >> > So there are two issues here: > >> > > >> > 1. No way to fill in a spki struct. I may be missing something. > >> > >> This one is easy to answer: you can use gnutls_x509_spki_init, > >> gnutls_x509_spki_set_rsa_pss_params, and gnutls_x509_spki_deinit. > >> > >> Regards, > >> -- > >> Daiki Ueno > > > > !DSPAM:5f46975d31589564056514466!