From simon at josefsson.org Mon Jul 7 10:59:42 2025 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 07 Jul 2025 10:59:42 +0200 Subject: [gnutls-help] guile-gnutls copy at codeberg Message-ID: <874ivo4br5.fsf@josefsson.org> Hi I pushed the guile-gnutls git repository to codeberg: https://codeberg.org/guile-gnutls/guile-gnutls This is a manually maintained repository to explore if we could move guile-gnutls to codeberg. What do you think? I feel I don't have a lot authority over this project, so I don't know if there are any opinions on this -- I tried to cc some possibly relevant people (sorry if I missed anyone, anyone else on gnutls-help feel free to chime in with opinions). I'd like to co-maintain this (send me your codeberg username), and I'm also okay reverting back to gitlab if people think moving codeberg is a negative. Further things I'm aware of: - GitLab issue tracker - should we keep this read-write, or turn it read-only? Is there any point in migrating issues to codeberg? Is such migration even possible? - Gitlab Merge requests - same question - GitLab Pipelines - this is a very important QA tool and I wouldn't want to release anything without having all those tests. So whatever we do, the GitLab CI/CD will be important for some time still. I don't speak Forgejo CI/CD but will try to learn, but it appears far behind GitLab CI/CD feature-wise. I don't see any problem having a GitLab read-only mirror project for CI/CD purposes, I do that for some other projects without GitLab presence. - GitLab release pages - I've been using this feature as a learning excercise, but I'm not sure how important it is. I guess codeberg has something similar. I find these pages rather ugly, and prefer old school HTTPS/FTP publication with stable URLs and a mirror network. Savannah and ftp.gnu.org provides this, and we can continue use that (or not). Btw, I pushed a copy of GitLab 'master' branch to a 'main' branch on Codeberg since it seemed like a nice time to change branch name too. If anyone has a guile-gnutls contribution they would like to open a pull request for on codeberg, we can test the new way of working. I expect to manually merge things back to gitlab for some time, pending feedback. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1251 bytes Desc: not available URL: From ametzler at bebt.de Mon Jul 7 14:49:49 2025 From: ametzler at bebt.de (Andreas Metzler) Date: Mon, 7 Jul 2025 14:49:49 +0200 Subject: [gnutls-help] guile-gnutls copy at codeberg In-Reply-To: <874ivo4br5.fsf@josefsson.org> References: <874ivo4br5.fsf@josefsson.org> Message-ID: On 2025-07-07 Simon Josefsson wrote: > Hi > I pushed the guile-gnutls git repository to codeberg: > https://codeberg.org/guile-gnutls/guile-gnutls > This is a manually maintained repository to explore if we could move > guile-gnutls to codeberg. What do you think? > I feel I don't have a lot authority over this project, so I don't know > if there are any opinions on this -- I tried to cc some possibly > relevant people (sorry if I missed anyone, anyone else on gnutls-help > feel free to chime in with opinions). I'd like to co-maintain this > (send me your codeberg username), and I'm also okay reverting back to > gitlab if people think moving codeberg is a negative. > Further things I'm aware of: [ stuff that would need to resolved ] Hello Simon, you seem to to have elaborated in detail why the move might be hard, but the rationale for investing the effort seems to be missing. I guess this is about moving from a profit to a non-profit organisation? 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 simon at josefsson.org Mon Jul 7 22:39:41 2025 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 07 Jul 2025 22:39:41 +0200 Subject: [gnutls-help] guile-gnutls copy at codeberg In-Reply-To: (Andreas Metzler's message of "Mon, 7 Jul 2025 14:49:49 +0200") References: <874ivo4br5.fsf@josefsson.org> Message-ID: <87ldozpwfm.fsf@josefsson.org> Andreas Metzler writes: > On 2025-07-07 Simon Josefsson wrote: >> Hi > >> I pushed the guile-gnutls git repository to codeberg: > >> https://codeberg.org/guile-gnutls/guile-gnutls > >> This is a manually maintained repository to explore if we could move >> guile-gnutls to codeberg. What do you think? > >> I feel I don't have a lot authority over this project, so I don't know >> if there are any opinions on this -- I tried to cc some possibly >> relevant people (sorry if I missed anyone, anyone else on gnutls-help >> feel free to chime in with opinions). I'd like to co-maintain this >> (send me your codeberg username), and I'm also okay reverting back to >> gitlab if people think moving codeberg is a negative. > >> Further things I'm aware of: > [ stuff that would need to resolved ] > > Hello Simon, > > you seem to to have elaborated in detail why the move might be hard, but the > rationale for investing the effort seems to be missing. I guess this is > about moving from a profit to a non-profit organisation? I don't have any strong motivation beyond my own learning process -- if people can articulate good reasons for or against, that would help clarify things. I like both savannah and gitlab actually, but many in the guile and guix community (which are the main sources of contributions to guile-gnutls) seems to be migrating projects to codeberg. I think some contributors has expressed a desire to not be on gitlab. What may actually have been more on my mind was that I recall seeing that the gitlab GnuTLS group lost its OSS status recently, reverting it back to free services, and I thought that archiving the guile-gnutls project may somehow help to regain the premium features, making the group easier to review for licensing. This is not substantiated though. I don't think moving is hard or require a lot of effort -- as far as I know, the only things that matters are to decide how to handle gitlab issue tracker, merge requests, release page and continuous integration. There are is one simple way to handle that: make the guile-gnutls project on gitlab a read-only project, and setup a gitlab mirror repository for CI/CD purposes. But we can keep both codeberg and gitlab, which will probably need to happen for some time anyway. What do you think about moving? For debian packaging I don't think it matters: the watch file downloads things from ftp.gnu.org, which I suppose will continue. Or do you have other concerns? /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1251 bytes Desc: not available URL: From ametzler at bebt.de Tue Jul 8 18:14:58 2025 From: ametzler at bebt.de (Andreas Metzler) Date: Tue, 8 Jul 2025 18:14:58 +0200 Subject: [gnutls-help] guile-gnutls copy at codeberg In-Reply-To: <87ldozpwfm.fsf@josefsson.org> References: <874ivo4br5.fsf@josefsson.org> <87ldozpwfm.fsf@josefsson.org> Message-ID: On 2025-07-07 Simon Josefsson wrote: > Andreas Metzler writes: [...] > > you seem to to have elaborated in detail why the move might be hard, but the > > rationale for investing the effort seems to be missing. I guess this is > > about moving from a profit to a non-profit organisation? [ Simon explained ] > What do you think about moving? For debian packaging I don't think it > matters: the watch file downloads things from ftp.gnu.org, which I > suppose will continue. Or do you have other concerns? Hello Simon, thank you for the explanation. I am fine either way, I agree that it would not matter for Debian packaging. 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 Wed Jul 9 07:01:58 2025 From: ueno at gnu.org (Daiki Ueno) Date: Wed, 09 Jul 2025 14:01:58 +0900 Subject: [gnutls-help] gnutls 3.8.10 Message-ID: <8734b6vtx5.fsf-ueno@gnu.org> Hello, We have just released gnutls-3.8.10. This is a bug fix, security and enhancement release on the 3.8.x branch. We would like to thank everyone who contributed in this release: Alexander Sosedkin, Andrew Hamilton, Angel Yankov, Daiki Ueno, Daniel P. Berrang?, David Dudas, Doekin, Franti?ek Kren?elok, Jiasheng Jiang, Richard Hughes, and Zoltan Fridrich. The detailed list of changes follows: * Version 3.8.10 (released 2025-07-08) ** libgnutls: Fix NULL pointer dereference when 2nd Client Hello omits PSK Reported by Stefan B?hler. [GNUTLS-SA-2025-07-07-4, CVSS: medium] [CVE-2025-6395] ** libgnutls: Fix heap read buffer overrun in parsing X.509 SCTS timestamps Spotted by oss-fuzz and reported by OpenAI Security Research Team, and fix developed by Andrew Hamilton. [GNUTLS-SA-2025-07-07-1, CVSS: medium] [CVE-2025-32989] ** libgnutls: Fix double-free upon error when exporting otherName in SAN Reported by OpenAI Security Research Team. [GNUTLS-SA-2025-07-07-2, CVSS: low] [CVE-2025-32988] ** certtool: Fix 1-byte write buffer overrun when parsing template Reported by David Aitel. [GNUTLS-SA-2025-07-07-3, CVSS: low] [CVE-2025-32990] ** libgnutls: PKCS#11 modules can now be used to override the default cryptographic backend. Use the [provider] section in the system-wide config to specify path and pin to the module (see system-wide config Documentation). ** libgnutls: Linux kernel version 6.14 brings a Kernel TLS (kTLS) key update support. The library running on the aforementioned version now utilizes the kernel?s key update mechanism when kTLS is enabled, allowing uninterrupted TLS session. The --enable-ktls configure option as well as the system-wide kTLS configuration(see GnuTLS Documentation) are still required to enable this feature. ** libgnutls: liboqs support for PQC has been removed For maintenance purposes, support for post-quantum cryptography (PQC) is now only provided through leancrypto. The experimental key exchange algorithm, X25519Kyber768Draft00, which is based on the round 3 candidate of Kyber and only supported through liboqs has also been removed altogether. ** libgnutls: TLS certificate compression methods can now be set with cert-compression-alg configuration option in the gnutls priority file. ** libgnutls: All variants of ML-DSA private key formats are supported While the previous implementation of ML-DSA was based on draft-ietf-lamps-dilithium-certificates-04, this updates it to draft-ietf-lamps-dilithium-certificates-12 with support for all 3 variants of private key formats: "seed", "expandedKey", and "both". ** libgnutls: ML-DSA signatures can now be used in TLS The ML-DSA signature algorithms, ML-DSA-44, ML-DSA-65, and ML-DSA-87, can now be used to digitally sign TLS handshake messages. ** API and ABI modifications: GNUTLS_PKCS_MLDSA_SEED: New enum member of gnutls_pkcs_encrypt_flags_t GNUTLS_PKCS_MLDSA_EXPANDED: New enum member of gnutls_pkcs_encrypt_flags_t Getting the Software ================ GnuTLS may be downloaded directly from https://www.gnupg.org/ftp/gcrypt/ 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.8/gnutls-3.8.10.tar.xz Here are OpenPGP detached signatures signed using key: 462225C3B46F34879FC8496CD605848ED7E69871 https://www.gnupg.org/ftp/gcrypt/gnutls/v3.8/gnutls-3.8.10.tar.xz.sig Note that it has been signed with my openpgp key: pub rsa4096 2009-07-23 [SC] [expires: 2026-06-29] 462225C3B46F34879FC8496CD605848ED7E69871 uid [ultimate] Daiki Ueno uid [ultimate] Daiki Ueno 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: From ludo at gnu.org Fri Jul 11 11:45:14 2025 From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=) Date: Fri, 11 Jul 2025 11:45:14 +0200 Subject: [gnutls-help] guile-gnutls copy at codeberg In-Reply-To: <874ivo4br5.fsf@josefsson.org> (Simon Josefsson's message of "Mon, 07 Jul 2025 10:59:42 +0200") References: <874ivo4br5.fsf@josefsson.org> Message-ID: <87cya7awnp.fsf@gnu.org> Hi Simon, Simon Josefsson writes: > I pushed the guile-gnutls git repository to codeberg: > > https://codeberg.org/guile-gnutls/guile-gnutls > > This is a manually maintained repository to explore if we could move > guile-gnutls to codeberg. What do you think? I would support such a move. > I feel I don't have a lot authority over this project, so I don't know > if there are any opinions on this -- I tried to cc some possibly > relevant people (sorry if I missed anyone, anyone else on gnutls-help > feel free to chime in with opinions). I'd like to co-maintain this > (send me your codeberg username), and I'm also okay reverting back to > gitlab if people think moving codeberg is a negative. IMO you have all the authority to do it! > Further things I'm aware of: > > - GitLab issue tracker - should we keep this read-write, or turn it > read-only? Is there any point in migrating issues to codeberg? Is > such migration even possible? > > - Gitlab Merge requests - same question I see you merely cloned the repo instead of migrating the project. I would suggest migrating the project (including issues and PRs): it?s a super easy and mostly lossless process with Codeberg. I think you?ll first need to delete this repo and then click on ?+? in the blue banner at the top and then ?New migration?. > - GitLab Pipelines - this is a very important QA tool and I wouldn't > want to release anything without having all those tests. So whatever > we do, the GitLab CI/CD will be important for some time still. I > don't speak Forgejo CI/CD but will try to learn, but it appears far > behind GitLab CI/CD feature-wise. I don't see any problem having a > GitLab read-only mirror project for CI/CD purposes, I do that for some > other projects without GitLab presence. Yeah, that I don?t know. There?s the integrated Woodpecker CI but I?ve never used it. > - GitLab release pages - I've been using this feature as a learning > excercise, but I'm not sure how important it is. I guess codeberg has > something similar. I find these pages rather ugly, and prefer old > school HTTPS/FTP publication with stable URLs and a mirror network. > Savannah and ftp.gnu.org provides this, and we can continue use that > (or not). I would just use Git tags these days, but then that rules out complicated pre-processing ? la Gnulib. > Btw, I pushed a copy of GitLab 'master' branch to a 'main' branch on > Codeberg since it seemed like a nice time to change branch name too. Agreed. Thanks, Ludo?. From simon at josefsson.org Fri Jul 11 23:25:23 2025 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 11 Jul 2025 23:25:23 +0200 Subject: [gnutls-help] guile-gnutls copy at codeberg In-Reply-To: <87cya7awnp.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Fri, 11 Jul 2025 11:45:14 +0200") References: <874ivo4br5.fsf@josefsson.org> <87cya7awnp.fsf@gnu.org> Message-ID: <874ivi1ku4.fsf@biskvi.sjd.se> Ludovic Court?s writes: >> https://codeberg.org/guile-gnutls/guile-gnutls > > I would support such a move. ... > IMO you have all the authority to do it! Thank you! > I would suggest migrating the project (including issues and PRs): it?s > a super easy and mostly lossless process with Codeberg. I think you?ll > first need to delete this repo and then click on ?+? in the blue banner > at the top and then ?New migration?. Done! Now https://gitlab.com/gnutls/guile is a read-only archived project. I'll try to push out a new release to put a flag down that guile-gnutls is now on codeberg and that we are open for business there. >> - GitLab Pipelines - this is a very important QA tool and I wouldn't >> want to release anything without having all those tests. So whatever >> we do, the GitLab CI/CD will be important for some time still. I >> don't speak Forgejo CI/CD but will try to learn, but it appears far >> behind GitLab CI/CD feature-wise. I don't see any problem having a >> GitLab read-only mirror project for CI/CD purposes, I do that for some >> other projects without GitLab presence. > > Yeah, that I don?t know. There?s the integrated Woodpecker CI but I?ve > never used it. I've setup a read-only GitLab CI/CD project: https://gitlab.com/gsasl/guile-gnutls/-/pipelines For as long as we have the .gitlab-ci.yml file in the guile-gnutls project, people can push the codenerh repository to their personal gitlab space and CI/CD will just work there. I wonder if codeberg merge requests can be thought to point or use GitLab CI/CD status, but I don't think this is important. >> - GitLab release pages - I've been using this feature as a learning >> excercise, but I'm not sure how important it is. I guess codeberg has >> something similar. I find these pages rather ugly, and prefer old >> school HTTPS/FTP publication with stable URLs and a mirror network. >> Savannah and ftp.gnu.org provides this, and we can continue use that >> (or not). > > I would just use Git tags these days, but then that rules out > complicated pre-processing ? la Gnulib. The migration migrated the release page too. But I'm not sure there is any value in these? We still push tarballs to ftp.gnu.org. We put a copy of relevant gnulib files in guile-gnutls's git, so no gnulib is necessary. But adding autoconf+automake as a build dependency for everyone may not be nice (is guile-gnutls part of the guix bootstrap? is it before autoconf/automake?), so maybe there is some utility in publishing curated tarballs for some time still. >> Btw, I pushed a copy of GitLab 'master' branch to a 'main' branch on >> Codeberg since it seemed like a nice time to change branch name too. > > Agreed. The migration re-created the master branch, but I pushed it as main now. I'm not sure we should remove the master branch? We can just stop push to it. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1251 bytes Desc: not available URL: From ametzler at bebt.de Sat Jul 12 11:35:37 2025 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 12 Jul 2025 11:35:37 +0200 Subject: [gnutls-help] guile-gnutls copy at codeberg In-Reply-To: <874ivi1ku4.fsf@biskvi.sjd.se> References: <874ivo4br5.fsf@josefsson.org> <87cya7awnp.fsf@gnu.org> <874ivi1ku4.fsf@biskvi.sjd.se> Message-ID: On 2025-07-11 Simon Josefsson wrote: [...] > The migration re-created the master branch, but I pushed it as main now. > I'm not sure we should remove the master branch? We can just stop push > to it. [...] please remove master, imho it is misleading if it exists but does not have the expect role (the branch where I can find latest/greatest). 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 simon at josefsson.org Sun Jul 13 00:31:16 2025 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 13 Jul 2025 00:31:16 +0200 Subject: [gnutls-help] guile-gnutls-5.0.0 released [stable] Message-ID: <87zfd9jb2j.fsf@biskvi.sjd.se> This is to announce guile-gnutls-5.0.0, a stable release. Guile-GnuTLS provides Guile bindings for the GnuTLS library. There have been 41 commits by 4 people in the 35 weeks since 4.0.1. See the NEWS below for a brief summary. Thanks to everyone who has contributed! The following people contributed changes to this release: Dariqq (4) Helmut Grohne (1) Simon Josefsson (35) Vivien Kraus (1) Happy Hacking, Simon ================================================================== Here is the GNU guile-gnutls home page: https://codeberg.org/guile-gnutls/guile-gnutls/ The release is available here: https://codeberg.org/guile-gnutls/guile-gnutls/releases/tag/v5.0.0 Here are the compressed sources and a GPG detached signature: https://ftp.gnu.org/gnu/gnutls/guile-gnutls-5.0.0.tar.gz https://ftp.gnu.org/gnu/gnutls/guile-gnutls-5.0.0.tar.gz.sig Here is minimal source-only "git archive" sources: https://ftp.gnu.org/gnu/gnutls/guile-gnutls-v5.0.0-src.tar.gz https://ftp.gnu.org/gnu/gnutls/guile-gnutls-v5.0.0-src.tar.gz.sig Here are Sigsum Proofs: https://ftp.gnu.org/gnu/gnutls/guile-gnutls-5.0.0.tar.gz.proof https://ftp.gnu.org/gnu/gnutls/guile-gnutls-v5.0.0-src.tar.gz.proof Use a mirror for higher download bandwidth: https://www.gnu.org/order/ftp.html Here are the SHA1 and SHA256 checksums: d11213282d49147ab15f930e5a0a33c934eb9e2d guile-gnutls-5.0.0.tar.gz oCCUCphahPqvQjuKN7tj5pczYEUPaO9TcTz7AxVAw3M= guile-gnutls-5.0.0.tar.gz 76f2dffe735899efadfcf772df2ccae306126f55 guile-gnutls-v5.0.0-src.tar.gz hWspJe4AjI5uKuobHnv/iyFY/1NWGgqh8olSBJpmSDg= guile-gnutls-v5.0.0-src.tar.gz Verify the base64 SHA256 checksum with cksum -a sha256 --check from coreutils-9.2 or OpenBSD's cksum since 2007. Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify guile-gnutls-5.0.0.tar.gz.sig The signature should match the fingerprint of the following key: pub ed25519 2019-03-20 [SC] B1D2 BD13 75BE CB78 4CF4 F8C4 D73C F638 C53C 06BE uid Simon Josefsson If that command fails because you don't have the required public key, or that public key has expired, try the following commands to retrieve or refresh it, and then rerun the 'gpg --verify' command. gpg --locate-external-key simon at josefsson.org gpg --recv-keys 51722B08FE4745A2 As a last resort to find the key, you can try the official GNU keyring: wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg gpg --keyring gnu-keyring.gpg --verify guile-gnutls-5.0.0.tar.gz.sig This release is based on the guile-gnutls git repository, available as git clone https://codeberg.org/guile-gnutls/guile-gnutls.git with commit 110dc4e52728ff782ba5647a690fc7e5f5bd23f5 tagged as v5.0.0. For a summary of changes and contributors, see: https://codeberg.org/guile-gnutls/guile-gnutls/compare/v4.0.1...v5.0.0 or run this command from a git-cloned guile-gnutls directory: git shortlog v4.0.1..v5.0.0 This release was bootstrapped with the following tools: Autoconf 2.71 Automake 1.16.5 Makeinfo 7.1.1 Libtoolize 2.4.7 Gnulib 2025-02-01 c89cd2fbd3b9f3d7c5a146247256599714c91ec7 NEWS * Noteworthy changes in release 5.0.0 (2025-07-12) [stable] ** Guile-GnuTLS moved to https://codeberg.org/guile-gnutls/guile-gnutls GitLab is still used for CI/CD: https://gitlab.com/gsasl/guile-gnutls ** Fix GnuTLS 3.8.9+ compilation due to new MLDSA/MLKEM1024 support. ** Fix GnuTLS 3.8.7+ compilation due to new MLKEM768 support. ** EdDSA curve manipulation should use #f for the y parameter of the public-key. ** The release tarball is now reproducible. ** We publish a minimal source-only tarball generated by 'git archive'. ** The release tarball uses tar --format=ustar. ** SRP is now disable by default, similar to GnuTLS. ** Update gnulib files and various build/maintenance fixes. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1251 bytes Desc: not available URL: From simon at josefsson.org Sun Jul 13 00:32:41 2025 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 13 Jul 2025 00:32:41 +0200 Subject: [gnutls-help] guile-gnutls copy at codeberg In-Reply-To: (Andreas Metzler's message of "Sat, 12 Jul 2025 11:35:37 +0200") References: <874ivo4br5.fsf@josefsson.org> <87cya7awnp.fsf@gnu.org> <874ivi1ku4.fsf@biskvi.sjd.se> Message-ID: <87v7nxjb06.fsf@biskvi.sjd.se> Andreas Metzler writes: > On 2025-07-11 Simon Josefsson wrote: > [...] >> The migration re-created the master branch, but I pushed it as main now. >> I'm not sure we should remove the master branch? We can just stop push >> to it. > [...] > > please remove master, imho it is misleading if it exists but does not > have the expect role (the branch where I can find latest/greatest). I removed it now. I am a bit worried that old merge requests may be invalid if there is no 'master' branch, but I'm not sure there is any big loss as a result of that either... /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1251 bytes Desc: not available URL: From simon at josefsson.org Sun Jul 13 15:37:48 2025 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 13 Jul 2025 15:37:48 +0200 Subject: [gnutls-help] guile-gnutls-5.0.1 released [stable] Message-ID: <87v7nww6s3.fsf@biskvi.sjd.se> This is to announce guile-gnutls-5.0.1, a stable release. Guile-GnuTLS provides Guile bindings for the GnuTLS library. There have been 17 commits by 2 people in the 15 hours since 5.0.0. See the NEWS below for a brief summary. Thanks to everyone who has contributed! The following people contributed changes to this release: Dariqq (3) Simon Josefsson (14) Happy Hacking, Simon ================================================================== Here is the Guile-GnuTLS home page: https://codeberg.org/guile-gnutls/guile-gnutls/ Manual: https://gsasl.gitlab.io/guile-gnutls/manual/ https://gsasl.gitlab.io/guile-gnutls/manual/gnutls-guile.html - HTML format https://gsasl.gitlab.io/guile-gnutls/manual/gnutls-guile.pdf - PDF format If you need help to use Guile-GnuTLS, or want to help others, you are invited to join our mailing list, see: https://lists.gnupg.org/mailman/listinfo/gnutls-help The release is available here: https://codeberg.org/guile-gnutls/guile-gnutls/releases/tag/v5.0.1 Here are the compressed sources and a GPG detached signature: https://ftp.gnu.org/gnu/gnutls/guile-gnutls-5.0.1.tar.gz https://ftp.gnu.org/gnu/gnutls/guile-gnutls-5.0.1.tar.gz.sig Here is minimal source-only "git archive" sources: https://ftp.gnu.org/gnu/gnutls/guile-gnutls-v5.0.1-src.tar.gz https://ftp.gnu.org/gnu/gnutls/guile-gnutls-v5.0.1-src.tar.gz.sig Here are Sigsum Proofs: https://ftp.gnu.org/gnu/gnutls/guile-gnutls-5.0.1.tar.gz.proof https://ftp.gnu.org/gnu/gnutls/guile-gnutls-v5.0.1-src.tar.gz.proof Use a mirror for higher download bandwidth: https://www.gnu.org/order/ftp.html https://ftpmirror.gnu.org/gnutls/guile-gnutls-5.0.1.tar.gz https://ftpmirror.gnu.org/gnutls/guile-gnutls-5.0.1.tar.gz.sig https://ftpmirror.gnu.org/gnutls/guile-gnutls-5.0.1.tar.gz.proof https://ftpmirror.gnu.org/gnutls/guile-gnutls-v5.0.1-src.tar.gz https://ftpmirror.gnu.org/gnutls/guile-gnutls-v5.0.1-src.tar.gz.sig https://ftpmirror.gnu.org/gnutls/guile-gnutls-v5.0.1-src.tar.gz.proof Here are the SHA1 and SHA256 checksums: c2b8474e170c4255df09f91b88ae62ac405d80a9 guile-gnutls-5.0.1.tar.gz zABn8+60IbwXJHFAlipJCG31RQ8NPnHFW/VBotK57ys= guile-gnutls-5.0.1.tar.gz 9725a700f1007330ea09f5837e6077f03d912db1 guile-gnutls-v5.0.1-src.tar.gz sZAEfO4Gj2sipejUnKSaJCWtRZOQG5rIlA+IQrp/Fk8= guile-gnutls-v5.0.1-src.tar.gz Verify the base64 SHA256 checksum with cksum -a sha256 --check from coreutils-9.2 or OpenBSD's cksum since 2007. Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify guile-gnutls-5.0.1.tar.gz.sig The signature should match the fingerprint of the following key: pub ed25519 2019-03-20 [SC] B1D2 BD13 75BE CB78 4CF4 F8C4 D73C F638 C53C 06BE uid Simon Josefsson If that command fails because you don't have the required public key, or that public key has expired, try the following commands to retrieve or refresh it, and then rerun the 'gpg --verify' command. gpg --locate-external-key simon at josefsson.org gpg --recv-keys 51722B08FE4745A2 As a last resort to find the key, you can try the official GNU keyring: wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg gpg --keyring gnu-keyring.gpg --verify guile-gnutls-5.0.1.tar.gz.sig Use the .proof files to verify the Sigsum proof. These files are like signatures but with extra transparency: you can cryptographically verify that every signature is logged in a public append-only log, so you can say with confidence what signatures exists. This makes hidden releases no longer deniable for the same public key. Releases are Sigsum-signed with the following public key: cat < jas-sigsum-key.pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILzCFcHHrKzVSPDDarZPYqn89H5TPaxwcORgRg+4DagE EOF Run a command like this to verify downloaded artifacts: wget -q -Otrust.txt https://gnu.org/s/gsasl/sigsum-policy-20250309.txt sigsum-verify -k jas-sigsum-key.pub -p trust.txt \ guile-gnutls-5.0.1.tar.gz.proof < guile-gnutls-5.0.1.tar.gz You may learn more about Sigsum concepts and find instructions how to download the tools here: https://www.sigsum.org/getting-started/ This release is based on the guile-gnutls git repository, available as git clone https://codeberg.org/guile-gnutls/guile-gnutls.git with commit 55eb81ee7bcd295695be08488b609e61b3bea695 tagged as v5.0.1. For a summary of changes and contributors, see: https://codeberg.org/guile-gnutls/guile-gnutls/compare/v5.0.0...v5.0.1 or run this command from a git-cloned guile-gnutls directory: git shortlog v5.0.0..v5.0.1 This release was bootstrapped with the following tools: Autoconf 2.71 Automake 1.16.5 Git 2.50.1 Gnulib 9297749090b01720888dceeb5f6dab3d52dcef40 Gzip 1.13 Libtoolize 2.4.7 Make 4.4.1 Makeinfo 7.1.1 Tar 1.34 Guix 8ee456e2bda8f72ccaf2398a1709a85e6e32d952 NEWS * Noteworthy changes in release 5.0.1 (2025-07-13) [stable] ** Build fixes for 32-bit platforms wrt time_t. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1251 bytes Desc: not available URL: From ludo at gnu.org Tue Jul 15 14:16:46 2025 From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=) Date: Tue, 15 Jul 2025 14:16:46 +0200 Subject: [gnutls-help] guile-gnutls copy at codeberg In-Reply-To: <874ivi1ku4.fsf@biskvi.sjd.se> (Simon Josefsson's message of "Fri, 11 Jul 2025 23:25:23 +0200") References: <874ivo4br5.fsf@josefsson.org> <87cya7awnp.fsf@gnu.org> <874ivi1ku4.fsf@biskvi.sjd.se> Message-ID: <875xfty7gx.fsf@gnu.org> Hi! Simon Josefsson writes: > Now https://gitlab.com/gnutls/guile is a read-only archived project. > > I'll try to push out a new release to put a flag down that guile-gnutls > is now on codeberg and that we are open for business there. Nice! > I've setup a read-only GitLab CI/CD project: > > https://gitlab.com/gsasl/guile-gnutls/-/pipelines > > For as long as we have the .gitlab-ci.yml file in the guile-gnutls > project, people can push the codenerh repository to their personal > gitlab space and CI/CD will just work there. Cool, taking advantage of GitLab Corp?s resources. :-) >> I would just use Git tags these days, but then that rules out >> complicated pre-processing ? la Gnulib. > > The migration migrated the release page too. But I'm not sure there is > any value in these? We still push tarballs to ftp.gnu.org. Interestingly, the release pages were migrated, but not the files they refer to. See for instance . But since those tarballs are also on ftp.gnu.org, it?s okay. > We put a copy of relevant gnulib files in guile-gnutls's git, so no > gnulib is necessary. But adding autoconf+automake as a build dependency > for everyone may not be nice (is guile-gnutls part of the guix > bootstrap? is it before autoconf/automake?), so maybe there is some > utility in publishing curated tarballs for some time still. Actually you?re right: Guix currently requires a tarball for bootstrapping reasons. > The migration re-created the master branch, but I pushed it as main now. > I'm not sure we should remove the master branch? We can just stop push > to it. Yes, it?s probably best to remove the ?master? branch and make ?main? the default. Thank you for all this!! Ludo?. From simon at josefsson.org Sat Jul 19 13:32:57 2025 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 19 Jul 2025 13:32:57 +0200 Subject: [gnutls-help] guile-gnutls copy at codeberg In-Reply-To: <875xfty7gx.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Tue, 15 Jul 2025 14:16:46 +0200") References: <874ivo4br5.fsf@josefsson.org> <87cya7awnp.fsf@gnu.org> <874ivi1ku4.fsf@biskvi.sjd.se> <875xfty7gx.fsf@gnu.org> Message-ID: <87ms90v2ja.fsf@josefsson.org> Ludovic Court?s writes: >> I've setup a read-only GitLab CI/CD project: >> >> https://gitlab.com/gsasl/guile-gnutls/-/pipelines >> >> For as long as we have the .gitlab-ci.yml file in the guile-gnutls >> project, people can push the codenerh repository to their personal >> gitlab space and CI/CD will just work there. > > Cool, taking advantage of GitLab Corp?s resources. :-) The above is actually a paid gitlab group. Gratis gitlab CI cycles have been reduced to an unusable minimum. I see no other choice until we get reliable Woodpecker CI up and running, I don't feel comfortable making any changes without regression testing... Even with woodpecker the gitlab CI may still be useful, just like the many github CI projects for GNU projects provide good QA coverage. >>> I would just use Git tags these days, but then that rules out >>> complicated pre-processing ? la Gnulib. >> >> The migration migrated the release page too. But I'm not sure there is >> any value in these? We still push tarballs to ftp.gnu.org. > > Interestingly, the release pages were migrated, but not the files they > refer to. See for instance > . I opened https://codeberg.org/Codeberg/Community/issues/2031 about that. > But since those tarballs are also on ftp.gnu.org, it?s okay. I wonder if these codeberg release page provide value. They take some manual time to prepare... maybe we should just disable it. OTOH, I like having redundancy for tarball distribution, and using gnu.org's gnutls area seems a bit weird too. Maybe the release pages can be automatically populated from the git tag somehow. I'll continue use it to gain experience with it. At least the URLs are predictable, and hopefully even discoverable automatically? Like this one: https://codeberg.org/guile-gnutls/guile-gnutls/releases/download/v5.0.1/guile-gnutls-5.0.1.tar.gz >> We put a copy of relevant gnulib files in guile-gnutls's git, so no >> gnulib is necessary. But adding autoconf+automake as a build dependency >> for everyone may not be nice (is guile-gnutls part of the guix >> bootstrap? is it before autoconf/automake?), so maybe there is some >> utility in publishing curated tarballs for some time still. > > Actually you?re right: Guix currently requires a tarball for > bootstrapping reasons. Is it possible to relax that to use a tarball of the git content instead? Then autoconf, automake, libtool, and maybe some more like texinfo will be required. Or would that create a bootstrapping dependency bloat problem? How to tell? Updating Guix to use latest guile-gnutls would be good too... >> The migration re-created the master branch, but I pushed it as main now. >> I'm not sure we should remove the master branch? We can just stop push >> to it. > > Yes, it?s probably best to remove the ?master? branch and make ?main? > the default. Removing the 'master' branch automatically closed all open merge requests that were migrated from gitlab. We only had two open requests, and Dariqq quickly opened new merge requests on codeberg, so I think we are good, but it may be worth remembering for other migrations. Old merge requests may become broken if there is no 'master' branch too. It would be nice if gitlab->codeberg migration process could have an option to rename branches like 'master' -> 'main'... https://codeberg.org/Codeberg/Community/issues/2032 /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1251 bytes Desc: not available URL: From lars.nooden at gmx.com Tue Jul 22 11:08:24 2025 From: lars.nooden at gmx.com (=?UTF-8?Q?Lars_Nood=C3=A9n?=) Date: Tue, 22 Jul 2025 12:08:24 +0300 Subject: [gnutls-help] Signing an x509 Certificate Signing Request (CSR) with a smart card Message-ID: <7db7a075-c010-4bbe-859d-56502496382f@gmx.com> Hello, I have a smart card which contains 1) an authentication and encryption certificate, plus a matching private key, and 2) a signature certificate, plus a matching private key. The card (or at least its reader) is seen by the GnuTLS PKCS #11 tool, but that is as far as I get, in part due to a PIN and in part due to my ignorance on the topic: $ p11tool --list-tokens Token 0: URL: pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust Label: System Trust Type: Trust module Flags: uPIN uninitialized Manufacturer: PKCS#11 Kit Model: p11-kit-trust Serial: 1 Module: p11-kit-trust.so What I would like to do is use this card to sign a CSR (x509 Certificate Signing Request) file using the card's private signing key. I presume that is right up GnuTLS' alley. I am grateful for any help, advice, or pointers in that direction. /Lars PS. Context: $ apt-cache policy gnutls-bin | head -n 2 gnutls-bin: Installed: 3.8.3-1.1ubuntu3.4 $ lsb_release -rd No LSB modules are available. Description: Linux Mint 22.1 Release: 22.1 $ uname -srm Linux 6.8.0-64-generic x86_64 From zfridric at redhat.com Fri Jul 25 12:45:35 2025 From: zfridric at redhat.com (Zoltan Fridrich) Date: Fri, 25 Jul 2025 12:45:35 +0200 Subject: [gnutls-help] Signing an x509 Certificate Signing Request (CSR) with a smart card In-Reply-To: <7db7a075-c010-4bbe-859d-56502496382f@gmx.com> References: <7db7a075-c010-4bbe-859d-56502496382f@gmx.com> Message-ID: Hello Lars, I think you can sign a CSR with certtool, the command might look something like this: *$ certtool --generate-certificate --load-request= --load-ca-privkey= --load-ca-certificate= --outfile=* but instead of providing file paths, you can provide PKCS#11 URIs which would look something like this "pkcs11:p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust". You can specify the concrete cert and keys by adding type,id and label to the uri, so maybe something like: "pkcs11:p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust;type=;object=