From ueno at gnu.org  Wed Dec  2 11:42:38 2020
From: ueno at gnu.org (Daiki Ueno)
Date: Wed, 02 Dec 2020 11:42:38 +0100
Subject: [gnutls-help] gnutls 3.7.0
Message-ID: <878sag32w1.fsf-ueno@gnu.org>

Hello,
 We've just released gnutls 3.7.0. This is the first release on the
3.7.x branch, with several new features and behavior changes.

We'd like to thank everyone who contributed in this release:
Albrecht Dre?, Alexander Sosedkin, Anderson Toshiyuki Sasaki, Andreas
Metzler, Daiki Ueno, Daniel Lenski, Dmitry Baryshkov, Fiona Klute, Hans
Leidekker, James Bottomley, JonasZhou, KrenzelokFrantisek, Lei Maohui,
Michael Catanzaro, Nikolay Sivov, Nikos Mavrogiannopoulos, Petr Pavlu,
Remi Olivier, Sahana Prasad, Steve Lhomme, Tim R?hsen, Tomas Mraz,
Vitezslav Cizek, and ihsinme.

The detailed list of changes follows:

* Version 3.7.0 (released 2020-12-02)

** libgnutls: Depend on nettle 3.6 (!1322).

** libgnutls: Added a new API that provides a callback function to
   retrieve missing certificates from incomplete certificate chains
   (#202, #968, #1100).

** libgnutls: Added a new API that provides a callback function to
   output the complete path to the trusted root during certificate
   chain verification (#1012).

** libgnutls: OIDs exposed as gnutls_datum_t no longer account for the
   terminating null bytes, while the data field is null terminated.
   The affected API functions are: gnutls_ocsp_req_get_extension,
   gnutls_ocsp_resp_get_response, and gnutls_ocsp_resp_get_extension
   (#805).

** libgnutls: Added a new set of API to enable QUIC implementation (#826, #849,
   #850).

** libgnutls: The crypto implementation override APIs deprecated in 3.6.9 are
   now no-op (#790).

** libgnutls: Added MAGMA/KUZNYECHIK CTR-ACPKM and CMAC support (!1161).

** libgnutls: Support for padlock has been fixed to make it work with Zhaoxin
   CPU (#1079).

** libgnutls: The maximum PIN length for PKCS #11 has been increased from 31
   bytes to 255 bytes (#932).

** API and ABI modifications:
gnutls_x509_trust_list_set_getissuer_function: Added
gnutls_x509_trust_list_get_ptr: Added
gnutls_x509_trust_list_set_ptr: Added
gnutls_session_set_verify_output_function: Added
gnutls_record_encryption_level_t: New enum
gnutls_handshake_read_func: New callback type
gnutls_handshake_set_read_function: New function
gnutls_handshake_write: New function
gnutls_handshake_secret_func: New callback type
gnutls_handshake_set_secret_function: New function
gnutls_alert_read_func: New callback type
gnutls_alert_set_read_function: New function
gnutls_crypto_register_cipher: Deprecated; no-op
gnutls_crypto_register_aead_cipher: Deprecated; no-op
gnutls_crypto_register_mac: Deprecated; no-op
gnutls_crypto_register_digest: Deprecated; no-op

Getting the Software
====================

GnuTLS may be downloaded directly from <
ftp://ftp.gnutls.org/gcrypt/gnutls/>;.
A list of GnuTLS mirrors can be found at <
http://www.gnutls.org/download.html>

Here are the XZ compressed sources:

  https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.15.tar.xz

Here are OpenPGP detached signatures signed using key 0x462225C3B46F34879FC8496CD605848ED7E69871:

  https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.15.tar.xz.sig

Note that it has been signed with my openpgp key:
pub   rsa4096 2009-07-23 [SC] [expires: 2023-09-25]
      462225C3B46F34879FC8496CD605848ED7E69871
uid           [ultimate] Daiki Ueno <ueno at unixuser.org>
uid           [ultimate] Daiki Ueno <ueno at gnu.org>
sub   rsa4096 2010-02-04 [E]

Regards,
-- 
Daiki Ueno
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20201202/0ddfae1c/attachment.sig>

From ueno at gnu.org  Thu Dec  3 11:04:22 2020
From: ueno at gnu.org (Daiki Ueno)
Date: Thu, 03 Dec 2020 11:04:22 +0100
Subject: [gnutls-help] gnutls 3.7.0
In-Reply-To: <878sag32w1.fsf-ueno@gnu.org> (Daiki Ueno's message of "Wed, 02
 Dec 2020 11:42:38 +0100")
References: <878sag32w1.fsf-ueno@gnu.org>
Message-ID: <87a6uv2ok9.fsf-ueno@gnu.org>

Daiki Ueno <ueno at gnu.org> writes:

> Here are the XZ compressed sources:
>
>   https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.15.tar.xz
>
> Here are OpenPGP detached signatures signed using key 0x462225C3B46F34879FC8496CD605848ED7E69871:
>
>   https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.15.tar.xz.sig

Oh, of course, the correct URLs are:
https://www.gnupg.org/ftp/gcrypt/gnutls/v3.7/gnutls-3.7.0.tar.xz
https://www.gnupg.org/ftp/gcrypt/gnutls/v3.7/gnutls-3.7.0.tar.xz.sig

The signature was created with the same key mentioned in the original
announcement.

Regards,
-- 
Daiki Ueno
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20201203/29e37240/attachment.sig>

From ametzler at bebt.de  Sun Dec  6 11:48:36 2020
From: ametzler at bebt.de (Andreas Metzler)
Date: Sun, 6 Dec 2020 11:48:36 +0100
Subject: [gnutls-help] gnutls 3.7.0
In-Reply-To: <878sag32w1.fsf-ueno@gnu.org>
References: <878sag32w1.fsf-ueno@gnu.org>
Message-ID: <X8y3BA30nrHZDc4c@argenau.bebt.de>

On 2020-12-02 Daiki Ueno <ueno at gnu.org> wrote:
> Hello,
>  We've just released gnutls 3.7.0. This is the first release on the
> 3.7.x branch, with several new features and behavior changes.
[...]

Hello Daiko,

I am wondering about what to ship in the next Debian release, scheduled
to be frozen in February 2021. Should I stay with 3.6.x or go for 3.7.0?

As far as can tell 3.7.0 is called 3.7.0 because it added the nettle 3.6
requirement and made the crypto override APIs a no-op. But apart from
that the changes and potential for breakage are not biggger than in a
regular 3.6.x release so I would tend to upload 3.7.0 to Debian/unstable
ASAP. Any thoughts on that?

TIA, cu Andreas


-- 
`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 Dec  7 11:23:52 2020
From: ueno at gnu.org (Daiki Ueno)
Date: Mon, 07 Dec 2020 11:23:52 +0100
Subject: [gnutls-help] gnutls 3.7.0
In-Reply-To: <X8y3BA30nrHZDc4c@argenau.bebt.de> (Andreas Metzler's message of
 "Sun, 6 Dec 2020 11:48:36 +0100")
References: <878sag32w1.fsf-ueno@gnu.org> <X8y3BA30nrHZDc4c@argenau.bebt.de>
Message-ID: <87czzlj4nb.fsf-ueno@gnu.org>

Hello Andreas,

Andreas Metzler <ametzler at bebt.de> writes:

> I am wondering about what to ship in the next Debian release, scheduled
> to be frozen in February 2021. Should I stay with 3.6.x or go for 3.7.0?
>
> As far as can tell 3.7.0 is called 3.7.0 because it added the nettle 3.6
> requirement and made the crypto override APIs a no-op. But apart from
> that the changes and potential for breakage are not biggger than in a
> regular 3.6.x release so I would tend to upload 3.7.0 to Debian/unstable
> ASAP. Any thoughts on that?

IMO that is a sensible choice, except this change, which requires
adjustment in calling sites:

  ** libgnutls: OIDs exposed as gnutls_datum_t no longer account for the
     terminating null bytes, while the data field is null terminated.
     The affected API functions are: gnutls_ocsp_req_get_extension,
     gnutls_ocsp_resp_get_response, and gnutls_ocsp_resp_get_extension
     (#805).

As I don't see any matches of those API functions in the codesearch[1]
other than gnutls28 itself, I guess that's probably okay.

Regards,

Footnotes:
[1]  https://codesearch.debian.net/search?q=gnutls_ocsp_req_get_extension%7Cgnutls_ocsp_resp_get_response%7Cgnutls_ocsp_resp_get_extension&literal=0

-- 
Daiki Ueno


From nicolas at babelouest.org  Tue Dec  8 16:00:41 2020
From: nicolas at babelouest.org (Nicolas Mora)
Date: Tue, 8 Dec 2020 10:00:41 -0500
Subject: [gnutls-help] gnutls 3.7.0
In-Reply-To: <878sag32w1.fsf-ueno@gnu.org>
References: <878sag32w1.fsf-ueno@gnu.org>
Message-ID: <79f754fd-b7db-d987-2a05-a1529d5cd030@babelouest.org>

Hello,

Thanks for the new release!

Le 2020-12-02 ? 05 h 42, Daiki Ueno a ?crit?:
> Hello,
>   We've just released gnutls 3.7.0. This is the first release on the
> 3.7.x branch, with several new features and behavior changes.
> 

I'm wondering if AES key wrap has been added in this release?

I've opened an issue about that lately [1] and I've been told this will 
be added in the 3.7.x release.

Is there any news about this?

Thanks!

/Nicolas

[1] https://gitlab.com/gnutls/gnutls/-/issues/976


From ludo at gnu.org  Tue Dec  8 17:56:56 2020
From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=)
Date: Tue, 08 Dec 2020 17:56:56 +0100
Subject: [gnutls-help] Bug#964284: guile-gnutls: update to use guile 3.0
In-Reply-To: <87lfe83heg.fsf@trouble.defaultvalue.org> (Rob Browning's message
 of "Tue, 08 Dec 2020 01:07:19 -0600")
References: <87v9j2204s.fsf@ponder> <877dpymybw.fsf@yucca>
 <87czzm2ehb.fsf@gnu.org> <87lfe83heg.fsf@trouble.defaultvalue.org>
Message-ID: <87a6uoutgn.fsf@gnu.org>

Hi,

(+Cc: gnutls-help.  This is about the failure of
?guile/tests/reauth.scm? observed on Debian.)

Thanks Rob & Vagrant.  The debugging output Vagrant posted reads:

--8<---------------cut here---------------start------------->8---
[10219|3] Peer requested CA: CN=GNUTLS TEST SERVER,OU=GNUTLS,O=FSF,C=GR
[10219|3] Peer requested CA: CN=GNUTLS INTERMEDIATE TEST CA,OU=GNUTLS,O=FSF,C=GR
[10219|4] checking cert compat with RSA-SHA256
[10219|3] ASSERT: ../../../lib/ext/signature.c[_gnutls_session_sign_algo_enabled]:433
[10219|4] Signature algorithm RSA-SHA256 is not enabled
[10219|4] checking cert compat with RSA-PSS-SHA256
[10219|4] 
throw to `gnutls-error' with args (#<gnutls-error-enum Public key signing has failed.> read_from_session_record_port)
checking cert compat with RSA-PSS-RSAE-SHA256
[10219|4] HSK[0x55c505382030]: CERTIFICATE was queued [693 bytes]
[10219|5] REC[0x55c505382030]: Preparing Packet Handshake(22) with length: 693 and min pad: 0
[10219|5] REC[0x55c505382030]: Sent Packet[8906] Handshake(22) in epoch 2 and length: 715
[10219|4] HSK[0x55c505382030]: signing TLS 1.3 handshake data: using RSA-PSS-RSAE-SHA256 and PRF: SHA384
[10219|3] ASSERT: ../../../lib/nettle/pk.c[_rsa_pss_sign_digest_tr]:805
[10219|3] ASSERT: ../../../lib/nettle/pk.c[_wrap_nettle_pk_sign]:1177
[10219|3] ASSERT: ../../../lib/nettle/pk.c[_wrap_nettle_pk_sign]:1190
[10219|3] ASSERT: ../../lib/privkey.c[privkey_sign_and_hash_data]:1300
[10219|3] ASSERT: ../../lib/tls13-sig.c[_gnutls13_handshake_sign_data]:205
[10219|3] ASSERT: ../../lib/tls13/certificate_verify.c[_gnutls13_send_certificate_verify]:210
[10219|3] ASSERT: ../../lib/tls13/post_handshake.c[_gnutls13_reauth_client]:117
[10219|3] ASSERT: ../../lib/handshake-tls13.c[_gnutls13_recv_async_handshake]:661
[10219|3] ASSERT: ../../lib/record.c[record_add_to_buffers]:1016
[10219|3] ASSERT: ../../lib/record.c[_gnutls_recv_in_buffers]:1578
[10219|3] ASSERT: ../../lib/record.c[_gnutls_recv_int]:1776
--8<---------------cut here---------------end--------------->8---

When uncommenting the debugging output statements in ?tests/reauth.scm?
(and only then!), I can reproduce the bug, though it is not
systematically in the same spot.

In all cases, it?s the client failing to reauthenticate.  One example is
?_nettle_rsa_sec_compute_root_tr? returning 0 and thus leading to
GNUTLS_E_PK_SIGN_FAILED as we see above.  The client?s stack at that
point looks like this:

--8<---------------cut here---------------start------------->8---
(rr) bt
#0  _nettle_rsa_sec_compute_root_tr (pub=pub at entry=0x7ffe9499aed0, key=key at entry=0x7ffe9499af00, random_ctx=random_ctx at entry=0x0, random=random at entry=0x7f4535ff91e0 <rnd_nonce_func>, 
    x=x at entry=0x7f4534ff4e00, m=0x7f4534ff4e80, mn=16) at rsa-sign-tr.c:319
#1  0x00007f4535e37a74 in nettle_rsa_compute_root_tr (pub=pub at entry=0x7ffe9499aed0, key=key at entry=0x7ffe9499af00, random_ctx=random_ctx at entry=0x0, 
    random=random at entry=0x7f4535ff91e0 <rnd_nonce_func>, x=x at entry=0x7ffe9499aec0, m=m at entry=0x7ffe9499ae30) at rsa-sign-tr.c:365
#2  0x00007f4535e38de0 in nettle_rsa_pss_sha256_sign_digest_tr (pub=0x7ffe9499aed0, key=0x7ffe9499af00, random_ctx=0x0, random=0x7f4535ff91e0 <rnd_nonce_func>, salt_length=<optimized out>, 
    salt=0xb98230 "\221\251\260\307\351\300\226\326,o\343\303\001\213\340YT\027\023\227\327\004\065\247\374Kje\177C\024_ending eQ", 
    digest=0xb32e70 "\233\255U\366\235I\001\372}\356\261r\257\213b\316\376\fkh\253X", s=0x7ffe9499aec0) at rsa-pss-sha256-sign-tr.c:59
#3  0x00007f4535ffb709 in _rsa_pss_sign_digest_tr (rnd_ctx=0x0, rnd_func=0x7f4535ff91e0 <rnd_nonce_func>, s=0x7ffe9499aec0, digest=<optimized out>, salt_size=<optimized out>, 
    priv=0x7ffe9499af00, pub=0x7ffe9499aed0, dig=<optimized out>) at pk.c:807
#4  _wrap_nettle_pk_sign (algo=<optimized out>, signature=0x7ffe9499b170, vdata=<optimized out>, pk_params=<optimized out>, sign_params=<optimized out>) at pk.c:1175
#5  0x00007f4535f4b374 in privkey_sign_and_hash_data (signer=0xb823a0, se=0x7f4536093a20 <sign_algorithms+224>, data=<optimized out>, signature=0x7ffe9499b170, params=0x7ffe9499b020)
    at privkey.c:1296
#6  0x00007f4535f4b658 in gnutls_privkey_sign_data2 (signer=signer at entry=0xb823a0, algo=<optimized out>, flags=flags at entry=0, data=data at entry=0x7ffe9499b090, 
    signature=signature at entry=0x7ffe9499b170) at privkey.c:1194
#7  0x00007f4535f61203 in _gnutls13_handshake_sign_data (session=session at entry=0xb893d0, cert=<optimized out>, pkey=0xb823a0, context=0x7f4536089200 <cli_ctx>, 
    signature=signature at entry=0x7ffe9499b170, se=se at entry=0x7f4536093a20 <sign_algorithms+224>) at tls13-sig.c:207
#8  0x00007f4535f608db in _gnutls13_send_certificate_verify (session=session at entry=0xb893d0, again=<optimized out>) at tls13/certificate_verify.c:206
#9  0x00007f4535f65305 in _gnutls13_reauth_client (session=0xb893d0) at tls13/post_handshake.c:115
#10 gnutls_reauth (session=session at entry=0xb893d0, flags=flags at entry=0) at tls13/post_handshake.c:251
#11 0x00007f4535f17a9d in _gnutls13_recv_async_handshake (session=session at entry=0xb893d0) at handshake-tls13.c:657
#12 0x00007f4535f117e2 in record_add_to_buffers (recv=0x7ffe9499b320, bufel=0xb84620, seq=0, htype=4294967295, type=GNUTLS_APPLICATION_DATA, session=0xb893d0) at record.c:1013
#13 _gnutls_recv_in_buffers (session=session at entry=0xb893d0, type=type at entry=GNUTLS_APPLICATION_DATA, htype=htype at entry=4294967295, ms=<optimized out>, ms at entry=0) at record.c:1570
#14 0x00007f4535f12221 in _gnutls_recv_int (session=0xb893d0, type=GNUTLS_APPLICATION_DATA, data=0x7f4535c06290 ".rtl-text", data_size=1, seq=0x0, ms=0) at record.c:1773
#15 0x00007f45360a61d6 in read_from_session_record_port (port=<optimized out>, dst=<optimized out>, start=<optimized out>, count=1) at core.c:1051
#16 0x00007f4539f1d280 in scm_i_read_bytes () from /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/lib/libguile-3.0.so.1
--8<---------------cut here---------------end--------------->8---

It looks as though the public or private key were corrupt, but nothing
obvious.

Unfortunately, there doesn?t seem to be a similar test case in C.  The
closest one is ?tls12-rehandshake-cert-auto?, but it uses anonymous
certificates and different priority strings.

Ideas for further debugging would be welcome!

Ludo?.


From ludo at gnu.org  Tue Dec 22 10:45:04 2020
From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=)
Date: Tue, 22 Dec 2020 10:45:04 +0100
Subject: [gnutls-help] Bug#964284: guile-gnutls: update to use guile 3.0
In-Reply-To: <87a6uoutgn.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?=
 =?utf-8?Q?s?= message of "Tue, 08 Dec 2020 17:56:56 +0100")
References: <87v9j2204s.fsf@ponder> <877dpymybw.fsf@yucca>
 <87czzm2ehb.fsf@gnu.org> <87lfe83heg.fsf@trouble.defaultvalue.org>
 <87a6uoutgn.fsf@gnu.org>
Message-ID: <87blem41jz.fsf@gnu.org>

Hi,

Ludovic Court?s <ludo at gnu.org> skribis:

> [10219|3] Peer requested CA: CN=GNUTLS TEST SERVER,OU=GNUTLS,O=FSF,C=GR
> [10219|3] Peer requested CA: CN=GNUTLS INTERMEDIATE TEST CA,OU=GNUTLS,O=FSF,C=GR
> [10219|4] checking cert compat with RSA-SHA256
> [10219|3] ASSERT: ../../../lib/ext/signature.c[_gnutls_session_sign_algo_enabled]:433
> [10219|4] Signature algorithm RSA-SHA256 is not enabled
> [10219|4] checking cert compat with RSA-PSS-SHA256
> [10219|4] 
> throw to `gnutls-error' with args (#<gnutls-error-enum Public key signing has failed.> read_from_session_record_port)
> checking cert compat with RSA-PSS-RSAE-SHA256
> [10219|4] HSK[0x55c505382030]: CERTIFICATE was queued [693 bytes]
> [10219|5] REC[0x55c505382030]: Preparing Packet Handshake(22) with length: 693 and min pad: 0
> [10219|5] REC[0x55c505382030]: Sent Packet[8906] Handshake(22) in epoch 2 and length: 715
> [10219|4] HSK[0x55c505382030]: signing TLS 1.3 handshake data: using RSA-PSS-RSAE-SHA256 and PRF: SHA384
> [10219|3] ASSERT: ../../../lib/nettle/pk.c[_rsa_pss_sign_digest_tr]:805

[...]

> In all cases, it?s the client failing to reauthenticate.  One example is
> ?_nettle_rsa_sec_compute_root_tr? returning 0 and thus leading to
> GNUTLS_E_PK_SIGN_FAILED as we see above.

In the end, it turns out that GMP bignums as used by Nettle are being
overwritten when GC runs.  Here?s an example of key material being
overwritten:

--8<---------------cut here---------------start------------->8---
rsa_sec_check_root (m=0x7f3ecbc6d100, x=0x7f3ecbc6d080, pub=0x7ffd2ca5ac90) at rsa-sign-tr.c:257
257	in rsa-sign-tr.c
(rr) p pub->n._mp_d
$12 = (mp_limb_t *) 0x7f3ecbc6db00
(rr) p *pub->n._mp_d
$13 = 139907683506816
(rr) p *pub->e._mp_d
$14 = 65537
(rr) watch *$12
Hardware watchpoint 5: *$12
(rr) rc
Continuing.

Thread 14 hit Hardware watchpoint 5: *$12

Old value = 139907683506816
New value = 13832525101577573263
0x00007f3ecf963785 in GC_reclaim_generic ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
(rr) bt
#0  0x00007f3ecf963785 in GC_reclaim_generic ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#1  0x00007f3ecf976fef in GC_generic_malloc_many ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#2  0x00007f3ecf9776b3 in GC_malloc_kind ()
   from /gnu/store/zg126cjicrpm2p6zc08ra5vh4ddag7ww-libgc-8.0.4/lib/libgc.so.1
#3  0x00007f3ecbcf98d2 in _nettle_gmp_alloc (n=n at entry=128) at gmp-glue.c:345
#4  0x00007f3ecbcf454f in rsa_sec_blind (mn=16, m=0x7f3ecbc6d180, ri=0x7f3ecbc6d000, c=0x7f3ecbc6d100, 
    random=0x7f3ecbeb61e0 <rnd_nonce_func>, random_ctx=0x0, pub=0x7ffd2ca5ac90) at rsa-sign-tr.c:175
#5  _nettle_rsa_sec_compute_root_tr (pub=pub at entry=0x7ffd2ca5ac90, key=key at entry=0x7ffd2ca5acc0, 
    random_ctx=random_ctx at entry=0x0, random=random at entry=0x7f3ecbeb61e0 <rnd_nonce_func>, x=x at entry=0x7f3ecbc6d100, 
    m=0x7f3ecbc6d180, mn=16) at rsa-sign-tr.c:330
#6  0x00007f3ecbcf4a74 in nettle_rsa_compute_root_tr (pub=pub at entry=0x7ffd2ca5ac90, key=key at entry=0x7ffd2ca5acc0, 
    random_ctx=random_ctx at entry=0x0, random=random at entry=0x7f3ecbeb61e0 <rnd_nonce_func>, x=x at entry=0x7ffd2ca5ac80, 
    m=m at entry=0x7ffd2ca5abf0) at rsa-sign-tr.c:365
#7  0x00007f3ecbcf5de0 in nettle_rsa_pss_sha256_sign_digest_tr (pub=0x7ffd2ca5ac90, key=0x7ffd2ca5acc0, 
    random_ctx=0x0, random=0x7f3ecbeb61e0 <rnd_nonce_func>, salt_length=<optimized out>, 
    salt=0xcf1890 "\003\365\204\222t\363B\334\316~S\227Q\tB\217\037\016\314\326\247U9\360\v\214\313\344`\263\212\316\230\305\313", 
    digest=0xcf1860 "q.\272\251\204\064X\302\fH4\262\263\363\024V5F\225\274\223\360U\fE\237\305$t\004\350u\230", 
    s=0x7ffd2ca5ac80) at rsa-pss-sha256-sign-tr.c:59
#8  0x00007f3ecbeb8709 in _rsa_pss_sign_digest_tr (rnd_ctx=0x0, rnd_func=0x7f3ecbeb61e0 <rnd_nonce_func>, 
    s=0x7ffd2ca5ac80, digest=<optimized out>, salt_size=<optimized out>, priv=0x7ffd2ca5acc0, pub=0x7ffd2ca5ac90, 
    dig=<optimized out>) at pk.c:807
#9  _wrap_nettle_pk_sign (algo=<optimized out>, signature=0x7ffd2ca5af30, vdata=<optimized out>, 
    pk_params=<optimized out>, sign_params=<optimized out>) at pk.c:1175
#10 0x00007f3ecbe08374 in privkey_sign_and_hash_data (signer=0xce1990, se=0x7f3ecbf50a20 <sign_algorithms+224>, 
    data=<optimized out>, signature=0x7ffd2ca5af30, params=0x7ffd2ca5ade0) at privkey.c:1296
#11 0x00007f3ecbe08658 in gnutls_privkey_sign_data2 (signer=signer at entry=0xce1990, algo=<optimized out>, 
    flags=flags at entry=0, data=data at entry=0x7ffd2ca5ae50, signature=signature at entry=0x7ffd2ca5af30) at privkey.c:1194
#12 0x00007f3ecbe1e203 in _gnutls13_handshake_sign_data (session=session at entry=0xcebd40, cert=<optimized out>, 
    pkey=0xce1990, context=0x7f3ecbf46210 <srv_ctx>, signature=signature at entry=0x7ffd2ca5af30, 
    se=se at entry=0x7f3ecbf50a20 <sign_algorithms+224>) at tls13-sig.c:207
#13 0x00007f3ecbe1d8db in _gnutls13_send_certificate_verify (session=session at entry=0xcebd40, again=<optimized out>)
    at tls13/certificate_verify.c:206
#14 0x00007f3ecbdd2fc1 in _gnutls13_handshake_server (session=session at entry=0xcebd40) at handshake-tls13.c:464
#15 0x00007f3ecbdde10d in handshake_server (session=<optimized out>) at handshake.c:3381
#16 gnutls_handshake (session=0xcebd40) at handshake.c:2783
#17 0x00007f3ecbf63e82 in scm_gnutls_handshake (session=<optimized out>) at core.c:196
--8<---------------cut here---------------end--------------->8---

This is because Guile >= 3.0.1 and >= 2.2.7 changes the GMP allocation
functions such that they go through libgc?.  As a result, libgc may
reuse that memory when it becomes unreachable from its point of view; in
this case, since GnuTLS structures are not scanned by libgc, libgc
doesn?t ?see? pointers to those bignums and thus considers they are no
longer reachable.

Where to go from here?  Here are options that come to mind:

  ? Configure Nettle with ?--enable-mini-gmp?.  However, the manual
    mentions that it?s ?slower? and ?more likely to leak side-channel
    information? (info "(nettle) Installation").

  ? Have Guile use mini-GMP; this is not implemented yet.

  ? In Guile-GnuTLS, arrange so that GnuTLS allocations are made through
    libgc.  Unfortunately, ?gnutls_global_set_mem_functions? was
    deprecated in GnuTLS 3.3.0 so this doesn?t look like an option.

  ? Build Guile with ?scm_install_gmp_memory_functions = 0?.  This would
    have a negative impact on the performance of bignum-heavy workloads
    such as the compiler itself.

I can?t think of a good workaround.  Thoughts?

Ludo?.

? https://git.savannah.gnu.org/cgit/guile.git/commit/?id=00fbdfa7345765168e14438eed0b0b8c64c27ab9


From ueno at gnu.org  Wed Dec 30 14:57:33 2020
From: ueno at gnu.org (Daiki Ueno)
Date: Wed, 30 Dec 2020 14:57:33 +0100
Subject: [gnutls-help] Bug#964284: guile-gnutls: update to use guile 3.0
In-Reply-To: <87blem41jz.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?=
 =?utf-8?Q?s?= message of "Tue, 22 Dec 2020 10:45:04 +0100")
References: <87v9j2204s.fsf@ponder> <877dpymybw.fsf@yucca>
 <87czzm2ehb.fsf@gnu.org> <87lfe83heg.fsf@trouble.defaultvalue.org>
 <87a6uoutgn.fsf@gnu.org> <87blem41jz.fsf@gnu.org>
Message-ID: <87v9cjxupe.fsf-ueno@gnu.org>

Hello Ludo,

Ludovic Court?s <ludo at gnu.org> writes:

> This is because Guile >= 3.0.1 and >= 2.2.7 changes the GMP allocation
> functions such that they go through libgc?.  As a result, libgc may
> reuse that memory when it becomes unreachable from its point of view; in
> this case, since GnuTLS structures are not scanned by libgc, libgc
> doesn?t ?see? pointers to those bignums and thus considers they are no
> longer reachable.

That's interesting, though I might not follow completely.

>   ? In Guile-GnuTLS, arrange so that GnuTLS allocations are made through
>     libgc.  Unfortunately, ?gnutls_global_set_mem_functions? was
>     deprecated in GnuTLS 3.3.0 so this doesn?t look like an option.

GnuTLS doesn't call mp_set_memory_functions, so even if it is possible,
I doubt that it would affect the current behavior.  On the other hand,
if GnuTLS (or Nettle) internally allocates an mpz_t, it should be done
using the libgc-backed allocator set by Guile and the pointers should be
reachable until it is no longer, if I understand correctly.  Therefore,
I suspect that there might be some code that confuses libgc to track the
pointers; one thing that comes to my mind is a manual copy of mpz_t
values:
https://gitlab.com/gnutls/gnutls/-/blob/master/lib/nettle/pk.c#L141

If you replace memcpy with mpz_init_set, does it work?

Regards,
-- 
Daiki Ueno