From gnutls-devel at lists.gnutls.org Tue Jun 1 00:19:29 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 31 May 2021 22:19:29 +0000 Subject: [gnutls-devel] GnuTLS | Ed448 keys are indicated as having a 456-bit "security level" (#1231) In-Reply-To: References: Message-ID: Daniel Kahn Gillmor commented: aiui, an elliptic curve of sensible properties that uses N bits is considered to be roughly equivalent to N/2-bit symmetric crypto, so i don't think a new field is necessary,just an adjustment of the math in `lib/pubkey.c#L68`. @dueno, i think you're the author of 07596231f2e which introduces the "57" length for Ed448. If you're not sure why it's 57 instead of 56, maybe we can just correct it to match X448? I'll try to propose a tested correction, and folks can critique/complain if there's something wrong. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1231#note_589433686 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jun 1 12:12:18 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 01 Jun 2021 10:12:18 +0000 Subject: [gnutls-devel] GnuTLS | DTLS client responds to CertificateRequest with Certificate of the wrong type (potential interop. problems) (#1245) In-Reply-To: References: Message-ID: Paul commented: Hi Daiki, I re-ran the test inputs on the master branch and the non-conformance is still there. Essentially, the certificate_types field in CertificateRequest seems to be ignored by the client. As an aside, I notice that the client aborts the handshake in case CertificateRequest does not contain SigHashAlgorithm used in its Certificate. I am unsure this is the behavior you want in this case (I think the client should send an empty Certificate, and let the server decide whether to proceed with the handshake). I attached a [capture](/uploads/9ffa7129123bdd18c2ba5d2933cbcc8d/capture_sighash.pcapng). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1245#note_589830314 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jun 1 22:16:58 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 01 Jun 2021 20:16:58 +0000 Subject: [gnutls-devel] GnuTLS | Ed448 keys are indicated as having a 456-bit "security level" (#1231) In-Reply-To: References: Message-ID: Daniel Kahn Gillmor commented: just switching the 57 to 56 leads to a failure of `tests/privkey-keygen` during testing of an Ed448 signature. privkey creation, pubkey extraction, and signature creation all work fine, but `gnutls_pubkey_verify_data2` returns -89 ("Public key signature verification has failed") on an Ed448 key. I haven't traced it back further than that. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1231#note_590417641 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jun 1 22:43:36 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 01 Jun 2021 20:43:36 +0000 Subject: [gnutls-devel] GnuTLS | Ed448 keys are indicated as having a 456-bit "security level" (#1231) In-Reply-To: References: Message-ID: Daniel Kahn Gillmor commented: Regarding whether "bits" is supposed to be "symmetric-equivalent" or an actual representation in bits: A 2048-bit RSA key is reported as having 2048 bits, and the table of in `lib/algorithms/secparams.c` maps the different number of "bits" in different classes of algorithm to different security levels. So "bits" is about the underlying representation, not the "symmetric equivalence". It might be a bit confusing to the uninitiated reader that the "Key Security Level" informative line includes both an assessment/judgement/label (e.g., "high") and a context-dependent bit length. It's a bit strange to see `Ultra (384 bits)` in one sample and `Low (1024 bits)` in the next. (this could happen if the first is ECC and the second is RSA, for example). But, i'm not sure how to best fix the confusion -- as long as it shows up next to the `Public Key Algorithm` line, that does give it a bit of the context needed. So i guess this bug report should focus on just resolving the 57-vs-56 distinction. Weird that X448 is fine with `.size = 56` while Ed448 is not! i'd expect at least a bit of commentary in the code there for why these sizes are different. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1231#note_590435000 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 4 14:35:49 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 04 Jun 2021 12:35:49 +0000 Subject: [gnutls-devel] GnuTLS | TLS-RFC Compliance (#1247) References: Message-ID: Marcel Maehren created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1247 Hi, we (@jurajsomorovsky @ic0ns @mmaehren @XoMEX @Kavakuo) are performing an analysis of the RFC-compliance of open-source TLS implementations. Below we list our findings for this implementation. We admit that some are rather nit-picky, but we added them for the sake of completeness. We tried to keep the descriptions brief and didn?t want to spam the issues section so feel free to split up the list into individual issues as you see fit. If you disagree with our interpretation of certain RFC statements, please leave feedback as we?re interested in your view. Our results apply to the default configuration of version ***3.7.0***. We used the example implementations for client and server. [S] = Applies to server [C] = Applies to client [C+S] = Applies to both ## Misc - [S] GnuTLS accepts session resumption via session IDs even if the previous session has been terminated by a fatal alert - RFC 5246 - 7.2.2 Error Alerts > Thus, any connection terminated with a fatal alert MUST NOT be resumed. - [S] GnuTLS server enforces that a TLS 1.3 client sends a key share for the first mutually supported group within the supported groups extension. As an example if a client offers secp521r1 and secp256r1 (in this order) but sends a key share for secp256r1, GnuTLS sends a HelloRetryRequest demanding a secp521r1 key share. - [C] GnuTLS seems to struggle with very small records, i.e records with a fragment length of 1, when a HelloRetryRequest is sent. - These records yield a 'decode error' and GnuTLS prints "Fatal error: Error decoding the received TLS packet." - [C] GnuTLS does not ignore the legacy version field in a ServerHello that negotiates TLS 1.3 and aborts the handshake for invalid values like 0x0304 or 0x0505 - RFC 8446 - 4.2.1 Supported Versions > If this extension is present, clients MUST ignore the ServerHello.legacy_version value and MUST use only the "supported_versions" extension to determine the selected version. - Note that the RFC also defines that a server MUST use 0x0303 as the legacy version but specifically says that the client MUST ignore the field when SupportedVersions has been received - [C+S] When encrypt-then-MAC is negotiated, GnuTLS does not validate the padding bytes ## Session not aborted - [S] upon receiving a ClientHello with an unsolicited Cookie extension - RFC 8446 - 4.2.2 Cookie > Clients MUST NOT use cookies in their initial ClientHello in subsequent connections. - [S] upon receiving a ClientHello proposing TLS 1.3 which does not use 0x0303 for the legacy version field - RFC 8446 - 4.1.2 Client Hello > In TLS 1.3, the client indicates its version preferences in the "supported_versions" extension (Section 4.2.1) and the legacy_version field MUST be set to 0x0303, which is the version number for TLS 1.2. - [C] upon receiving a ClientHello message interleaved with a warning alert - Note that this only applies if no HelloRetryRequest has been sent by the server. If a server sends an HRR and interleaves the subsequent ServerHello, GnuTLS closes the connection without an alert. - RFC 8446 - 5.1. Record Layer > Handshake messages MUST NOT be interleaved with other record types. That is, if a handshake message is split over two or more records, there MUST NOT be any other records between them. - [C] upon receiving a TLS 1.3 HelloRetryRequest that does not result in any changes for the subsequent ClientHello - RFC 8446 - 4.1.4 Hello Retry Request > Clients MUST abort the handshake with an "illegal_parameter" alert if the HelloRetryRequest would not result in any change in the ClientHello. - [C] upon receiving a TLS 1.3 HelloRetryRequest that selects an unproposed or TLS 1.2 cipher suite - Note that it is not possible to actually negotiate this cipher suite with a subsequent ServerHello - RFC 8446 - 4.1.4. Hello Retry Request > Upon receipt of a HelloRetryRequest, the client MUST check the legacy_version, legacy_session_id_echo, cipher_suite, and legacy_compression_method as specified in Section 4.1.3 - [C+S] upon receiving a ChangeCipherSpec message with an invalid content (such as 0x7D) as long as this content consists of one byte - RFC 5246 - 7.1 Change Cipher Spec Protocol > The message consists of a single byte of value 1. - [C] when a server chooses a non-CBC cipher suite but negotiates encrypt-then-MAC - RFC 7366 - 3. Applying Encrypt-then-MAC > If a server receives an encrypt-then-MAC request extension from a client and then selects a stream or Authenticated Encryption with Associated Data (AEAD) ciphersuite, it MUST NOT send an encrypt-then-MAC response extension back to the client. - [C] upon receiving a GREASE extension as part of a ServerHello, HelloRetryRequest, or EncryptedExtensions message - Note that this is likely caused by an unknown extension type, not a specific GREASE value - RFC 9701 - 3.1. Client Behavior > In particular, the client MUST fail the connection if a GREASE value appears in any of the following: [...] Any ServerHello extension, [...] Any EncryptedExtensions extension - In general a client MUST reject such an extension if it wasn't proposed - [C] upon receiving a forbidden extension in the EncryptedExtensions message (specifically tested with Padding extension) - RFC 8446 - 4.3.1 Encrypted Extensions > The client MUST check EncryptedExtensions for the presence of any forbidden extensions and if any are found MUST abort the handshake with an "illegal_parameter" alert. - [C] upon receiving a ServerHello negotiating TLS 1.3 that does not echo the empty session ID sent by GnuTLS - RFC 8446 - 4.1.3 Server Hello > A client which receives a legacy_session_id_echo field that does not match what it sent in the ClientHello MUST abort the handshake with an "illegal_parameter" alert. - [S] upon receiving a Padding extension that contains bytes other than 0x00 - Please leave a comment if your implementation does not support this extension and hence ignores the content - RFC 7685 - 3. Padding Extension > The client MUST fill the padding extension completely with zero bytes, although the padding extension_data field may be empty. - [S] upon receiving a SupportedPointFormat extension that only accepts compressed points or an invalid format - 8422 - 5.1. Client Hello Extensions > If the client sends the extension and the extension does not contain the uncompressed point format, and the client has used the Supported Groups extension to indicate support for any of the curves defined in this specification, then the server MUST abort the handshake and return an illegal_parameter alert. ## Only session closed but no alert sent - [C] upon receiving a record with an invalid MAC / AEAD tag or with an invalid padding (for CBC cipher suites) - [C] upon receiving a record without any content - [C] upon receiving a record that exceeds the maximum ciphertext or plaintext fragment length - [C] upon receiving an encrypted legacy ChangeCipherSpec message or an unprotected ChangeCipherSpec after a completed handshake in a TLS 1.3 session ## Different alert sent than defined by the RFC - [S] upon receiving a ClientHello proposing TLS 1.3 without a SignatureAlgorithms extension. GnuTLS sends a 'handshake failure' alert. - RFC 8446 - 4.2.3 Signature Algorithms > If a server is authenticating via a certificate and the client has not sent a "signature_algorithms" extension, then the server MUST abort the handshake with a "missing_extension" alert (see Section 9.2). - [C] upon receiving a ServerHello that negotiates TLS 1.3 and selects an unproposed cipher suite. GnuTLS sends a 'handshake failure' alert. - RFC 8446 - 4.1.3 Server Hello > A client which receives a cipher suite that was not offered MUST abort the handshake with an "illegal_parameter" alert. - [C] upon receiving an EncryptedExtensions message that contains a SupportedVersions extension. GnuTLS sends an 'unsupported extension' alert. - RFC 8446 - 4.3.1 Encrypted Extensions > The client MUST check EncryptedExtensions for the presence of any forbidden extensions and if any are found MUST abort the handshake with an "illegal_parameter" alert. - [C+S] upon receiving a 'close notify' alert during the handshake. GnuTLS sends an 'internal error' - This may be a corner case due to the uncompleted handshake - RFC 5246 7.2.1 Closure Alerts > The other party MUST respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes. - [S] upon receiving a record with the undefined record content type 0xff at the beginning of the handshake, GnuTLS responds with a 'record overflow' alert - Note that this may be related to legacy SSL2 parsing code - RFC 8446 - 5. Record Protocol > If a TLS implementation receives an unexpected record type, it MUST terminate the connection with an "unexpected_message" alert. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1247 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 4 21:06:43 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 04 Jun 2021 19:06:43 +0000 Subject: [gnutls-devel] GnuTLS | TLS-RFC Compliance (#1247) In-Reply-To: References: Message-ID: Michael Catanzaro started a new discussion: https://gitlab.com/gnutls/gnutls/-/issues/1247#note_593365267 > \[C\] GnuTLS seems to struggle with very small records, i.e records with a fragment length of 1, when a HelloRetryRequest is sent. > > * These records yield a 'decode error' and GnuTLS prints "Fatal error: Error decoding the received TLS packet." This might explain https://gitlab.gnome.org/GNOME/glib-networking/-/issues/158...? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1247#note_593365267 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Jun 5 10:32:19 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 05 Jun 2021 08:32:19 +0000 Subject: [gnutls-devel] GnuTLS | TLS-RFC Compliance (#1247) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1247#note_593550730 Possibly, but I can't say much without seeing the actual data exchanged. > [C] GnuTLS seems to struggle with very small records, i.e records with a fragment length of 1, when a HelloRetryRequest is sent. As [discussed](https://mailarchive.ietf.org/arch/msg/tls/PEonr0nlMNumUVpw6bFgNlNjwpE/) in the context of the `record_size_limit` extension, GnuTLS might be enforcing a lower limit of record sizes; I need to double check. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1247#note_593550730 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Jun 5 10:34:37 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 05 Jun 2021 08:34:37 +0000 Subject: [gnutls-devel] GnuTLS | TLS-RFC Compliance (#1247) In-Reply-To: References: Message-ID: Daiki Ueno commented: Thank you for the report! I haven't gone through the issues one by one, but overall looks valid points to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1247#note_593550981 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Jun 6 01:06:33 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 05 Jun 2021 23:06:33 +0000 Subject: [gnutls-devel] GnuTLS | Cross-compilation of the Guile bindings (#1137) In-Reply-To: References: Message-ID: Evgeny Ermakov commented: Ping. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1137#note_593657859 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Jun 6 19:45:05 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 06 Jun 2021 17:45:05 +0000 Subject: [gnutls-devel] GnuTLS | Soft-disabling configuration capabilities should match the hard-disabling ones (#1172) In-Reply-To: References: Message-ID: Daiki Ueno commented: This is my current understanding of the requirements and the proposed design: https://docs.google.com/document/d/1RrKHanHw1leeTqHRLMJ181DXiFPMdhbOl9-BU4vzXcc/edit?usp=sharing Feel free to comment if you have any suggestions. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1172#note_593790971 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jun 8 10:38:22 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 08 Jun 2021 08:38:22 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS should transparently use KTLS if it's available (#1113) In-Reply-To: References: Message-ID: Daniel P_ Berrang? commented: Note that in QEMU, gnutls does not directly get to talk to the raw socket, instead it does I/O via a pair of function callbacks into QEMU's I/O layer. Also note that QEMU is getting support for another kernel networking feature MPTCP - multipath TCP, and I'm told that this is currently mutually exclusive with KTLS. Thus gnutls won't be able to transparently turn on KTLS, without modification of QEMU, and in some scenarios it won't be able to use it at all. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1113#note_595191592 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jun 8 11:18:17 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 08 Jun 2021 09:18:17 +0000 Subject: [gnutls-devel] GnuTLS | GnuTLS should transparently use KTLS if it's available (#1113) In-Reply-To: References: Message-ID: Richard W_M_ Jones commented: In nbdkit you can talk directly to the socket :-) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1113#note_595254913 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jun 9 15:49:23 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 09 Jun 2021 13:49:23 +0000 Subject: [gnutls-devel] GnuTLS | doc: p11tool: mention how CKA_IDs of certs are calculated upon --write (!1446) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1446 Project:Branches: dueno/gnutls:wip/dueno/pkcs11-reuse-key-id to gnutls/gnutls:master Author: Daiki Ueno Add a description of the new feature/bug fix. Reference any relevant bugs. ## Checklist * [ ] Commits have `Signed-off-by:` with name/author being identical to the commit author * [ ] Code modified for feature * [ ] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated / NEWS entry present (for non-trivial changes) * [ ] CI timeout is 2h or higher (see Settings/CICD/General pipelines/Timeout) ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1446 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jun 10 13:46:29 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 10 Jun 2021 11:46:29 +0000 Subject: [gnutls-devel] GnuTLS | SECURITY: use-after-free in PSK binder calculation (#1151) In-Reply-To: References: Message-ID: Boya Xiao commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1151#note_597976742 I installed gnutls(3.7.1-3) in Debian 10.9,but the result for trivy show CRITICAL(CVE-2021-20231, CVE-2021-20232) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1151#note_597976742 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jun 10 18:40:17 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 10 Jun 2021 16:40:17 +0000 Subject: [gnutls-devel] GnuTLS | SECURITY: use-after-free in PSK binder calculation (#1151) In-Reply-To: References: Message-ID: Andreas Metzler commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1151#note_598368491 Boya Xiao @xiaoboya wrote > I installed gnutls(3.7.1-3) in Debian 10.9,but the result for trivy show CRITICAL(CVE-2021-20231, CVE-2021-20232) Afaict trivy has a list of packages and versions which fix the vulnerabilties. It does not *check* whether the issue is fixed or not but simply consults the list. And the list is probably outdated. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1151#note_598368491 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 11 01:38:44 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 10 Jun 2021 23:38:44 +0000 Subject: [gnutls-devel] GnuTLS | RFE: RFC8773 PSK + Certificate auth (#1229) In-Reply-To: References: Message-ID: David Johnston commented: Good Day, I am the originator of this feature request posted on the OpenConnect project. I would like to ask; is it possible to estimate the timeline for this? I'm working on some project delivery plans and this feature is an important part. Let me know if there is anything I can do to assist, Thanks, Dave -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1229#note_598608323 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 11 15:22:21 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 11 Jun 2021 13:22:21 +0000 Subject: [gnutls-devel] GnuTLS | priority: reflect system wide config when constructing sigalgs (!1447) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1447 Project:Branches: dueno/gnutls:wip/dueno/config-sigalgs to gnutls/gnutls:master Author: Daiki Ueno Otherwise the client would advertise signature algorithms which it cannot use and cause handshake to fail. Reported by Philip Schaten in: https://lists.gnupg.org/pipermail/gnutls-help/2021-June/004711.html ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [ ] Code modified for feature * [x] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated / NEWS entry present (for non-trivial changes) * [ ] CI timeout is 2h or higher (see Settings/CICD/General pipelines/Timeout) ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1447 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 11 15:59:14 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 11 Jun 2021 13:59:14 +0000 Subject: [gnutls-devel] GnuTLS | priority: reflect system wide config when constructing sigalgs (!1447) In-Reply-To: References: Message-ID: Alexander Sosedkin started a new discussion on tests/system-override-sig-tls.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1447#note_599305535 > + > +#define PRIO "NORMAL:-VERS-ALL:+VERS-TLS1.3:-SIGN-ALL:" \ > + "+SIGN-RSA-PSS-RSAE-SHA256:+SIGN-RSA-PSS-RSAE-SHA384" > +/* rsa_pss_rsae_sha384 */ > +#define SIGALGS_EXP "\x00\x02\x08\x05" > + > +static int > +ext_callback(void *ctx, unsigned tls_id, > + const unsigned char *data, unsigned size) > +{ > + if (tls_id == 13) { /* signature algorithms */ > + if (size != sizeof(SIGALGS_EXP) - 1) { > + fail("invalid signature_algorithms length: %u != 4\n", > + size); > + } > + if (memcmp(data, SIGALGS_EXP, sizeof(SIGALGS_EXP) - 1) != 0) { I'm confused about that part. `insecure-sig = rsa-pss-rsae-sha384` means we should *not* expect `rsa_pss_rsae_sha384` here, which would be more like `memcmp(data, SIGALGS_UNEXP, sizeof(SIGALGS_UNEXP) - 1) == 0`, correct? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1447#note_599305535 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 11 16:27:31 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 11 Jun 2021 14:27:31 +0000 Subject: [gnutls-devel] GnuTLS | priority: reflect system wide config when constructing sigalgs (!1447) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on tests/system-override-sig-tls.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1447#note_599339481 > + > +#define PRIO "NORMAL:-VERS-ALL:+VERS-TLS1.3:-SIGN-ALL:" \ > + "+SIGN-RSA-PSS-RSAE-SHA256:+SIGN-RSA-PSS-RSAE-SHA384" > +/* rsa_pss_rsae_sha384 */ > +#define SIGALGS_EXP "\x00\x02\x08\x05" > + > +static int > +ext_callback(void *ctx, unsigned tls_id, > + const unsigned char *data, unsigned size) > +{ > + if (tls_id == 13) { /* signature algorithms */ > + if (size != sizeof(SIGALGS_EXP) - 1) { > + fail("invalid signature_algorithms length: %u != 4\n", > + size); > + } > + if (memcmp(data, SIGALGS_EXP, sizeof(SIGALGS_EXP) - 1) != 0) { Oops, indeed (and the test was actually failing due to that). I've modified the wrapper script to force "insecure-sig = rsa-pss-rsae-sha256". -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1447#note_599339481 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 11 16:27:31 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 11 Jun 2021 14:27:31 +0000 Subject: [gnutls-devel] GnuTLS | priority: reflect system wide config when constructing sigalgs (!1447) In-Reply-To: References: Message-ID: All discussions on merge request !1447 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/-/merge_requests/1447 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1447 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 11 16:32:25 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 11 Jun 2021 14:32:25 +0000 Subject: [gnutls-devel] GnuTLS | priority: reflect system wide config when constructing sigalgs (!1447) In-Reply-To: References: Message-ID: Merge request !1447 was approved by Alexander Sosedkin Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1447 Project:Branches: dueno/gnutls:wip/dueno/config-sigalgs to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1447 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 11 17:18:42 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 11 Jun 2021 15:18:42 +0000 Subject: [gnutls-devel] GnuTLS | priority: reflect system wide config when constructing sigalgs (!1447) In-Reply-To: References: Message-ID: Merge request !1447 was scheduled to merge after pipeline succeeds by Daiki Ueno Merge request url: https://gitlab.com/gnutls/gnutls/-/merge_requests/1447 Project:Branches: dueno/gnutls:wip/dueno/config-sigalgs to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1447 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 11 17:18:59 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 11 Jun 2021 15:18:59 +0000 Subject: [gnutls-devel] GnuTLS | priority: reflect system wide config when constructing sigalgs (!1447) In-Reply-To: References: Message-ID: Daiki Ueno commented: Thanks for the review! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1447#note_599391537 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 11 17:19:16 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 11 Jun 2021 15:19:16 +0000 Subject: [gnutls-devel] GnuTLS | doc: p11tool: mention how CKA_IDs of certs are calculated upon --write (!1446) In-Reply-To: References: Message-ID: Merge request !1446 was scheduled to merge after pipeline succeeds by Daiki Ueno Merge request url: https://gitlab.com/gnutls/gnutls/-/merge_requests/1446 Project:Branches: dueno/gnutls:wip/dueno/pkcs11-reuse-key-id to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1446 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 11 17:32:23 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 11 Jun 2021 15:32:23 +0000 Subject: [gnutls-devel] GnuTLS | priority: reflect system wide config when constructing sigalgs (!1447) In-Reply-To: References: Message-ID: Merge request !1447 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1447 Project:Branches: dueno/gnutls:wip/dueno/config-sigalgs to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1447 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 11 17:51:45 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 11 Jun 2021 15:51:45 +0000 Subject: [gnutls-devel] GnuTLS | doc: p11tool: mention how CKA_IDs of certs are calculated upon --write (!1446) In-Reply-To: References: Message-ID: Merge request !1446 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1446 Project:Branches: dueno/gnutls:wip/dueno/pkcs11-reuse-key-id to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1446 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Jun 13 19:26:15 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 13 Jun 2021 17:26:15 +0000 Subject: [gnutls-devel] GnuTLS | RFE: RFC8773 PSK + Certificate auth (#1229) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1229#note_599940805 That seems like an interesting feature, though I'm occupied with other issues (!1427 and FIPS140-3 stuff) right now. It would be greatly appreciated if you come up with an initial implementation as MR; I'm more than happy to review and merge the patches. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1229#note_599940805 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jun 14 16:20:46 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 14 Jun 2021 14:20:46 +0000 Subject: [gnutls-devel] GnuTLS | priority: support allowlisting in configuration file (!1427) In-Reply-To: References: Message-ID: Daiki Ueno changed the draft status of merge request !1427 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jun 15 20:29:58 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 15 Jun 2021 18:29:58 +0000 Subject: [gnutls-devel] GnuTLS | priority: support allowlisting in configuration file (!1427) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: Not a complete review by any means, more like field notes. I got to play with it, and with a rebase on top of 4af2969d50, ``` +++ a/lib/algorithms/ecc.c +++ b/lib/algorithms/ecc.c @@ -295,7 +295,7 @@ const gnutls_ecc_curve_t *gnutls_ecc_curve_list(void) unsigned _gnutls_ecc_curve_is_supported(gnutls_ecc_curve_t curve) { GNUTLS_ECC_CURVE_LOOP( - if (p->id == curve && p->supported && _gnutls_pk_curve_exists(p->id)) + if (p->id == curve && (p->supported || p->supported_revertible) && _gnutls_pk_curve_exists(p->id)) return 1; ); return 0; ``` and `prio` containing ``` [global] override-mode = allowlist [overrides] secure-hash = SHA256 tls-enabled-mac = AEAD secure-sig = RSA-SHA256 secure-sig-for-cert = RSA-SHA256 tls-enabled-cipher = AES-256-GCM tls-enabled-kx = RSA enabled-version = TLS1.2 min-verification-profile = medium [priorities] SYSTEM=NONE ``` I was able to `GNUTLS_SYSTEM_PRIORITY_FILE=prio ./src/gnutls-cli -d999 google.com --priority @SYSTEM`. Not sure why `secure-sig-for-cert` and `--priority @SYSTEM` were needed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_602107176 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jun 16 11:34:23 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 16 Jun 2021 09:34:23 +0000 Subject: [gnutls-devel] GnuTLS | guile: Writes to record ports handle EAGAIN/EINTR transparently. (!1417) In-Reply-To: References: Message-ID: civodul commented: @dueno @gnutls-devel-mail @gnutls Hi! Could you please merge this branch? I don't think I can do it myself. It's an important fix for Guile so I'd really like it to be applied now. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1417#note_602639693 You're receiving this email because you have been mentioned on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jun 16 12:21:30 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 16 Jun 2021 10:21:30 +0000 Subject: [gnutls-devel] GnuTLS | priority: support allowlisting in configuration file (!1427) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: Given we have `_SECURE`, `_INSECURE_FOR_CERTS`, and `_INSECURE`, I guess secure-sig should be weaker than secure-sig-for-cert? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_602726819 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jun 16 14:32:11 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 16 Jun 2021 12:32:11 +0000 Subject: [gnutls-devel] GnuTLS | recvmmsg() and sendmmsg() equivalents for DTLS (#16) In-Reply-To: References: Message-ID: David Woodhouse commented: That isn't what recvmmsg() and sendmmsg() do. They would operate on *multiple* records in a batch, instead of having to send/receive one packet at a time. I think you meant to ask for gnutls_record_writev() and gnutls_record_readv()? That would certainly be nice. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/16#note_602862404 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jun 16 14:35:49 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 16 Jun 2021 12:35:49 +0000 Subject: [gnutls-devel] GnuTLS | Use recvmmsg() for receiving UDP frames (#1248) References: Message-ID: David Woodhouse created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1248 The [`recvmmsg()`](https://lwn.net/Articles/334532/) system call was added to allow userspace to receive *multiple* UDP packets in a single system call, for performance reasons. It would be very useful to be able to use this from GnuTLS. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1248 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jun 16 14:36:46 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 16 Jun 2021 12:36:46 +0000 Subject: [gnutls-devel] GnuTLS | recvmmsg() and sendmmsg() equivalents for DTLS (#16) In-Reply-To: References: Message-ID: Philip Withnall commented: No, I definitely meant to ask for `recvmmsg()` and `sendmmsg()`. They provide batch handling of multiple records *as well as* vectored handling. Each record is a `struct msghdr`, which contains one or more `struct iovec` chunks. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/16#note_602868942 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jun 16 14:41:18 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 16 Jun 2021 12:41:18 +0000 Subject: [gnutls-devel] GnuTLS | recvmmsg() and sendmmsg() equivalents for DTLS (#16) In-Reply-To: References: Message-ID: David Woodhouse commented: Ah right, thanks. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/16#note_602875038 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jun 16 15:03:08 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 16 Jun 2021 13:03:08 +0000 Subject: [gnutls-devel] GnuTLS | TLS-RFC Compliance (#1247) In-Reply-To: References: Message-ID: Marcel Maehren commented: Hey, based on the feedback we received from other developers, we split up the reports to separate cases where the RFC imposes restrictions on a sender but does not require the receiver to enforce these restrictions. You find these at the bottom of the comment. We removed reports of missing alerts in TLS 1.3 as sending alerts is explicitly stated as optional in RFC 8446. We didn't edit the initial report to avoid confusion. ## Misc - [S] GnuTLS accepts session resumption via session IDs even if the previous session has been terminated by a fatal alert - RFC 5246 - 7.2.2 Error Alerts > Thus, any connection terminated with a fatal alert MUST NOT be resumed. - [S] GnuTLS server enforces that a TLS 1.3 client sends a key share for the first mutually supported group within the supported groups extension. As an example if a client offers secp521r1 and secp256r1 (in this order) but sends a key share for secp256r1, GnuTLS sends a HelloRetryRequest demanding a secp521r1 key share. - [C] GnuTLS seems to struggle with very small records, i.e records with a fragment length of 1, when a HelloRetryRequest is sent. - These records yield a 'decode error' and GnuTLS prints "Fatal error: Error decoding the received TLS packet." - [C] GnuTLS does not ignore the legacy version field in a ServerHello that negotiates TLS 1.3 and aborts the handshake for invalid values like 0x0304 or 0x0505 - RFC 8446 - 4.2.1 Supported Versions > If this extension is present, clients MUST ignore the ServerHello.legacy_version value and MUST use only the "supported_versions" extension to determine the selected version. - Note that the RFC also defines that a server MUST use 0x0303 as the legacy version but specifically says that the client MUST ignore the field when SupportedVersions has been received - [C+S] When encrypt-then-MAC is negotiated, GnuTLS does not validate the padding bytes ## Session not aborted - [C] upon receiving a TLS 1.3 HelloRetryRequest that does not result in any changes for the subsequent ClientHello - RFC 8446 - 4.1.4 Hello Retry Request > Clients MUST abort the handshake with an "illegal_parameter" alert if the HelloRetryRequest would not result in any change in the ClientHello. - [C] upon receiving a TLS 1.3 HelloRetryRequest that selects an unproposed or TLS 1.2 cipher suite - Note that it is not possible to actually negotiate this cipher suite with a subsequent ServerHello - RFC 8446 - 4.1.4. Hello Retry Request > Upon receipt of a HelloRetryRequest, the client MUST check the legacy_version, legacy_session_id_echo, cipher_suite, and legacy_compression_method as specified in Section 4.1.3 - [C+S] upon receiving a ChangeCipherSpec message with an invalid content (such as 0x7D) as long as this content consists of one byte - RFC 5246 - 7.1 Change Cipher Spec Protocol > The message consists of a single byte of value 1. - [C] upon receiving a GREASE extension as part of a ServerHello, HelloRetryRequest, or EncryptedExtensions message - Note that this is likely caused by an unknown extension type, not a specific GREASE value - RFC 9701 - 3.1. Client Behavior > In particular, the client MUST fail the connection if a GREASE value appears in any of the following: [...] Any ServerHello extension, [...] Any EncryptedExtensions extension - In general a client MUST reject such an extension if it wasn't proposed - [C] upon receiving a forbidden extension in the EncryptedExtensions message (specifically tested with Padding extension) - RFC 8446 - 4.3.1 Encrypted Extensions > The client MUST check EncryptedExtensions for the presence of any forbidden extensions and if any are found MUST abort the handshake with an "illegal_parameter" alert. - [C] upon receiving a ServerHello negotiating TLS 1.3 that does not echo the empty session ID sent by GnuTLS - RFC 8446 - 4.1.3 Server Hello > A client which receives a legacy_session_id_echo field that does not match what it sent in the ClientHello MUST abort the handshake with an "illegal_parameter" alert. - [S] upon receiving a SupportedPointFormat extension that only accepts compressed points or an invalid format - 8422 - 5.1. Client Hello Extensions > If the client sends the extension and the extension does not contain the uncompressed point format, and the client has used the Supported Groups extension to indicate support for any of the curves defined in this specification, then the server MUST abort the handshake and return an illegal_parameter alert. ## Only session closed but no alert sent - [C] upon receiving a record with an invalid MAC / AEAD tag or with an invalid padding (for CBC cipher suites) - [C] upon receiving a record without any content - [C] upon receiving a record that exceeds the maximum ciphertext or plaintext fragment length ## Different alert sent than defined by the RFC - [S] upon receiving a ClientHello proposing TLS 1.3 without a SignatureAlgorithms extension. GnuTLS sends a 'handshake failure' alert. - RFC 8446 - 4.2.3 Signature Algorithms > If a server is authenticating via a certificate and the client has not sent a "signature_algorithms" extension, then the server MUST abort the handshake with a "missing_extension" alert (see Section 9.2). - [C] upon receiving a ServerHello that negotiates TLS 1.3 and selects an unproposed cipher suite. GnuTLS sends a 'handshake failure' alert. - RFC 8446 - 4.1.3 Server Hello > A client which receives a cipher suite that was not offered MUST abort the handshake with an "illegal_parameter" alert. - [C] upon receiving an EncryptedExtensions message that contains a SupportedVersions extension. GnuTLS sends an 'unsupported extension' alert. - RFC 8446 - 4.3.1 Encrypted Extensions > The client MUST check EncryptedExtensions for the presence of any forbidden extensions and if any are found MUST abort the handshake with an "illegal_parameter" alert. - [C+S] upon receiving a 'close notify' alert during the handshake. GnuTLS sends an 'internal error' - This may be a corner case due to the uncompleted handshake - RFC 5246 7.2.1 Closure Alerts > The other party MUST respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes. - [S] upon receiving a record with the undefined record content type 0xff at the beginning of the handshake, GnuTLS responds with a 'record overflow' alert - Note that this may be related to legacy SSL2 parsing code - RFC 8446 - 5. Record Protocol > If a TLS implementation receives an unexpected record type, it MUST terminate the connection with an "unexpected_message" alert. ## Unenforced sender restrictions **In the following cases, the receiver is not explicitly required to terminate the connection upon detecting a misbehavior of the peer.** - [S] upon receiving a ClientHello with an unsolicited Cookie extension - RFC 8446 - 4.2.2 Cookie > Clients MUST NOT use cookies in their initial ClientHello in subsequent connections. - [S] upon receiving a ClientHello proposing TLS 1.3 which does not use 0x0303 for the legacy version field - RFC 8446 - 4.1.2 Client Hello > In TLS 1.3, the client indicates its version preferences in the "supported_versions" extension (Section 4.2.1) and the legacy_version field MUST be set to 0x0303, which is the version number for TLS 1.2. - [C] upon receiving a ClientHello message interleaved with a warning alert - Note that this only applies if no HelloRetryRequest has been sent by the server. If a server sends an HRR and interleaves the subsequent ServerHello, GnuTLS closes the connection without an alert. - RFC 8446 - 5.1. Record Layer > Handshake messages MUST NOT be interleaved with other record types. That is, if a handshake message is split over two or more records, there MUST NOT be any other records between them. - [C] when a server chooses a non-CBC cipher suite but negotiates encrypt-then-MAC - RFC 7366 - 3. Applying Encrypt-then-MAC > If a server receives an encrypt-then-MAC request extension from a client and then selects a stream or Authenticated Encryption with Associated Data (AEAD) ciphersuite, it MUST NOT send an encrypt-then-MAC response extension back to the client. - [S] upon receiving a Padding extension that contains bytes other than 0x00 - Please leave a comment if your implementation does not support this extension and hence ignores the content - RFC 7685 - 3. Padding Extension > The client MUST fill the padding extension completely with zero bytes, although the padding extension_data field may be empty. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1247#note_602903664 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Jun 19 19:39:41 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 19 Jun 2021 17:39:41 +0000 Subject: [gnutls-devel] GnuTLS | guile: Writes to record ports handle EAGAIN/EINTR transparently. (!1417) In-Reply-To: References: Message-ID: Merge request !1417 was approved by Daiki Ueno Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1417 Project:Branches: civodul/gnutls:guile-egain-eintr to gnutls/gnutls:master Author: civodul Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1417 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Jun 19 19:42:27 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 19 Jun 2021 17:42:27 +0000 Subject: [gnutls-devel] GnuTLS | guile: Writes to record ports handle EAGAIN/EINTR transparently. (!1417) In-Reply-To: References: Message-ID: Daiki Ueno commented: Sorry for the delay; looks good to me (though I can't do thorough review on this due to my lack of knowledge on Guile). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1417#note_605911473 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Jun 19 19:43:45 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 19 Jun 2021 17:43:45 +0000 Subject: [gnutls-devel] GnuTLS | guile: Writes to record ports handle EAGAIN/EINTR transparently. (!1417) In-Reply-To: References: Message-ID: All discussions on merge request !1417 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/-/merge_requests/1417 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1417 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Jun 19 19:43:54 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sat, 19 Jun 2021 17:43:54 +0000 Subject: [gnutls-devel] GnuTLS | guile: Writes to record ports handle EAGAIN/EINTR transparently. (!1417) In-Reply-To: References: Message-ID: Merge request !1417 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1417 Project:Branches: civodul/gnutls:guile-egain-eintr to gnutls/gnutls:master Author: civodul Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1417 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jun 21 21:09:37 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 21 Jun 2021 19:09:37 +0000 Subject: [gnutls-devel] GnuTLS | guile: Writes to record ports handle EAGAIN/EINTR transparently. (!1417) In-Reply-To: References: Message-ID: civodul commented: Thanks, @dueno! :-) -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1417#note_606978894 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jun 21 21:17:19 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 21 Jun 2021 19:17:19 +0000 Subject: [gnutls-devel] GnuTLS | guile: Writes to record ports handle EAGAIN/EINTR transparently. (!1417) In-Reply-To: References: Message-ID: civodul commented: @dueno The `NEWS` excerpt appears under the 3.7.2 heading, but it's not actually fixed in 3.7.2; I guess it should be moved to a new 3.7.3 section? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1417#note_606983607 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jun 22 21:16:58 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 22 Jun 2021 19:16:58 +0000 Subject: [gnutls-devel] GnuTLS | Fix gnutls_certificate_set_trust_list() return value documentation (!1448) References: Message-ID: Michael Catanzaro created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1448 Project:Branches: TheRealMichaelCatanzaro/gnutls:mcatanzaro/set-trust-list-return to gnutls/gnutls:master Author: Michael Catanzaro This function is documented to return an error code, but in fact it has no return value and never fails. Fix this. ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [ ] Code modified for feature * [ ] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated / NEWS entry present (for non-trivial changes) * [x] CI timeout is 2h or higher (see Settings/CICD/General pipelines/Timeout) ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1448 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jun 23 08:36:55 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 23 Jun 2021 06:36:55 +0000 Subject: [gnutls-devel] GnuTLS | guile: Writes to record ports handle EAGAIN/EINTR transparently. (!1417) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1417#note_609011157 Indeed, thanks for pointing that out; let me fix it. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1417#note_609011157 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jun 23 13:34:44 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 23 Jun 2021 11:34:44 +0000 Subject: [gnutls-devel] GnuTLS | +GROUP-X448:+GROUP-X25519 = invalid parameter (#1249) References: Message-ID: Alexander Sosedkin created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1249 ## Description of problem: ## Version of gnutls used: 41ab46a6e0a2406cd0646325b38b0bf627fd0557 ## How reproducible: always Executed against: `./src/gnutls-serv -d9 --x509keyfile keys/server/key.pem --x509certfile keys/server/cert.pem --priority=NORMAL` What works: ``` ./src/gnutls-serv -d9 --x509keyfile keys/server/key.pem --x509certfile keys/server/cert.pem --priority=NORMAL ./src/gnutls-serv -d9 --x509keyfile keys/server/key.pem --x509certfile keys/server/cert.pem --priority=NORMAL:-GROUP-ALL:+GROUP-X25519 ./src/gnutls-serv -d9 --x509keyfile keys/server/key.pem --x509certfile keys/server/cert.pem --priority=NORMAL:-GROUP-ALL:+GROUP-X448 ``` What doesn't: ``` ./src/gnutls-serv -d9 --x509keyfile keys/server/key.pem --x509certfile keys/server/cert.pem --priority=NORMAL:-GROUP-ALL:+GROUP-X448:+GROUP-X25519 ./src/gnutls-serv -d9 --x509keyfile keys/server/key.pem --x509certfile keys/server/cert.pem --priority=NORMAL:-GROUP-ALL:+GROUP-X25519:+GROUP-X448 ``` ## Actual results: ``` |<4>| EXT[0x11af2a0]: Parsing extension 'Key Share/51' (36 bytes) |<4>| HSK[0x11af2a0]: Selected group X25519 (6) |<3>| ASSERT: key_share.c[client_use_key_share]:453 |<3>| ASSERT: key_share.c[key_share_recv_params]:653 |<3>| ASSERT: hello_ext.c[hello_ext_parse]:275 |<3>| ASSERT: extv.c[_gnutls_extv_parse]:69 |<3>| ASSERT: hello_ext.c[_gnutls_parse_hello_extensions]:308 |<3>| ASSERT: handshake.c[read_server_hello]:2080 |<3>| ASSERT: handshake.c[_gnutls_recv_handshake]:1648 |<3>| ASSERT: handshake.c[handshake_client]:3055 *** Fatal error: An illegal parameter has been received. |<5>| REC: Sending Alert[2|47] - Illegal parameter ``` ## Expected results: connection established ## Notes: my limited debugging shows that the values of `session->key.kshare.ecdhx_params` in the comparison at `key_share.c[client_use_key_share]:452` seem to match the other curve, not the `group->pk` one -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1249 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jun 23 16:46:05 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 23 Jun 2021 14:46:05 +0000 Subject: [gnutls-devel] GnuTLS | +GROUP-X448:+GROUP-X25519 = invalid parameter (#1249) In-Reply-To: References: Message-ID: Daiki Ueno commented: For performance reasons, the client tries to pick one to three top key shares, each of which belongs to a different types (i.e., ECDH with NIST curves, ECDH with Edwards curves, and FFDHE). On the other hand, those types are differentiated internally as `gnutls_pk_algorithm_t`, which provide different values for X25519 and X448, and thus the most recent key share overrides the previous one. A solution would be to treat those values as in the same type when sending client key shares, or perhaps to extend the limit from three to four. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1249#note_609608790 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jun 24 15:20:06 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 24 Jun 2021 13:20:06 +0000 Subject: [gnutls-devel] GnuTLS | Fix gnutls_certificate_set_trust_list() return value documentation (!1448) In-Reply-To: References: Message-ID: Merge request !1448 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1448 Project:Branches: TheRealMichaelCatanzaro/gnutls:mcatanzaro/set-trust-list-return to gnutls/gnutls:master Author: Michael Catanzaro Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1448 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jun 24 15:20:15 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 24 Jun 2021 13:20:15 +0000 Subject: [gnutls-devel] GnuTLS | Fix gnutls_certificate_set_trust_list() return value documentation (!1448) In-Reply-To: References: Message-ID: Daiki Ueno commented: Thank you! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1448#note_610691421 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jun 24 15:20:02 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 24 Jun 2021 13:20:02 +0000 Subject: [gnutls-devel] GnuTLS | Fix gnutls_certificate_set_trust_list() return value documentation (!1448) In-Reply-To: References: Message-ID: Merge request !1448 was approved by Daiki Ueno Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1448 Project:Branches: TheRealMichaelCatanzaro/gnutls:mcatanzaro/set-trust-list-return to gnutls/gnutls:master Author: Michael Catanzaro Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1448 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jun 24 19:50:18 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 24 Jun 2021 17:50:18 +0000 Subject: [gnutls-devel] GnuTLS | +GROUP-X448:+GROUP-X25519 = invalid parameter (#1249) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/issues/1249#note_611001057 @asosedkin do you have any preference on the fix? There are basically 3 ways to fix: (1) treat X25519 and X448 as a same type and offer only one of them, (2) treat X25519 and X448 as different types and offer both, (3) remove this grouping logic and respect the preferences supplied by the user, as in NSS https://hg.mozilla.org/projects/nss/file/0262a919f9095c0957b3b8dddafd72fa7d3c1a91/lib/ssl/tls13con.c#l463 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1249#note_611001057 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 25 09:34:36 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 25 Jun 2021 07:34:36 +0000 Subject: [gnutls-devel] GnuTLS | key_share: treat X25519 and X448 as same PK type when advertising (!1449) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1449 Project:Branches: dueno/gnutls:wip/dueno/kshare-x25519-x448 to gnutls/gnutls:master Author: Daiki Ueno Fixes: #1249 ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [ ] Code modified for feature * [x] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated / NEWS entry present (for non-trivial changes) * [ ] CI timeout is 2h or higher (see Settings/CICD/General pipelines/Timeout) ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1449 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 25 11:21:53 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 25 Jun 2021 09:21:53 +0000 Subject: [gnutls-devel] GnuTLS | +GROUP-X448:+GROUP-X25519 = invalid parameter (#1249) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: For the record, I don't have a preference. Not grouping sounds more straightforward, but I don't understand the performance implications. Besides, this ticket is not exactly against grouping as a concept. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1249#note_611445178 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 25 13:48:42 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 25 Jun 2021 11:48:42 +0000 Subject: [gnutls-devel] GnuTLS | key_share: treat X25519 and X448 as same PK type when advertising (!1449) In-Reply-To: References: Message-ID: Merge request !1449 was approved by Alexander Sosedkin Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1449 Project:Branches: dueno/gnutls:wip/dueno/kshare-x25519-x448 to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1449 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 25 13:48:38 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 25 Jun 2021 11:48:38 +0000 Subject: [gnutls-devel] GnuTLS | key_share: treat X25519 and X448 as same PK type when advertising (!1449) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: r+: addresses #1249, code looks fine. Thanks for a prompt fix! -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1449#note_611584250 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 25 14:04:44 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 25 Jun 2021 12:04:44 +0000 Subject: [gnutls-devel] GnuTLS | +GROUP-X448:+GROUP-X25519 = invalid parameter (#1249) In-Reply-To: References: Message-ID: Issue was closed by Daiki Ueno via merge request !1449 (https://gitlab.com/gnutls/gnutls/-/merge_requests/1449) Issue #1249: https://gitlab.com/gnutls/gnutls/-/issues/1249 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1249 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 25 14:05:00 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 25 Jun 2021 12:05:00 +0000 Subject: [gnutls-devel] GnuTLS | key_share: treat X25519 and X448 as same PK type when advertising (!1449) In-Reply-To: References: Message-ID: Daiki Ueno commented: Thanks for the review. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1449#note_611602967 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 25 14:04:45 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 25 Jun 2021 12:04:45 +0000 Subject: [gnutls-devel] GnuTLS | key_share: treat X25519 and X448 as same PK type when advertising (!1449) In-Reply-To: References: Message-ID: Merge request !1449 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1449 Project:Branches: dueno/gnutls:wip/dueno/kshare-x25519-x448 to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1449 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jun 28 07:27:05 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 28 Jun 2021 05:27:05 +0000 Subject: [gnutls-devel] GnuTLS | tests: set SH_LOG_COMPILER so sh tests run under $(SHELL) (!1450) References: Message-ID: Daiki Ueno created a merge request: https://gitlab.com/gnutls/gnutls/-/merge_requests/1450 Project:Branches: dueno/gnutls:wip/dueno/sh-tests to gnutls/gnutls:master Author: Daiki Ueno Add a description of the new feature/bug fix. Reference any relevant bugs. ## Checklist * [x] Commits have `Signed-off-by:` with name/author being identical to the commit author * [ ] Code modified for feature * [ ] Test suite updated with functionality tests * [ ] Test suite updated with negative tests * [ ] Documentation updated / NEWS entry present (for non-trivial changes) * [ ] CI timeout is 2h or higher (see Settings/CICD/General pipelines/Timeout) ## Reviewer's checklist: * [ ] Any issues marked for closing are addressed * [ ] There is a test suite reasonably covering new functionality or modifications * [ ] Function naming, parameters, return values, types, etc., are consistent and according to `CONTRIBUTION.md` * [ ] This feature/change has adequate documentation added * [ ] No obvious mistakes in the code -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1450 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jun 28 08:59:19 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 28 Jun 2021 06:59:19 +0000 Subject: [gnutls-devel] GnuTLS | Use recvmmsg() for receiving UDP frames (#1248) In-Reply-To: References: Message-ID: David Woodhouse commented: Actually, I don't know that I do want GnuTLS doing either recvmmsg()/sendmmsg() or io_uring for me. I think I'd prefer to just do those for myself, and for GnuTLS to offer me a function that encrypts/decrypts DTLS packets in place without managing any of the I/O or buffers at all. Or maybe I should just tell GnuTLS that I'm using kernel offload, but really do it for myself in my applicaftion instead? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1248#note_612635229 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jun 28 09:07:32 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 28 Jun 2021 07:07:32 +0000 Subject: [gnutls-devel] GnuTLS | tests: set SH_LOG_COMPILER so sh tests run under $(SHELL) (!1450) In-Reply-To: References: Message-ID: Merge request !1450 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/1450 Project:Branches: dueno/gnutls:wip/dueno/sh-tests to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1450 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jun 30 00:15:20 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 29 Jun 2021 22:15:20 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_record_get_state() doesn't report EncryptThenMac status (#1250) References: Message-ID: David Woodhouse created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1250 I'd like to experiment with using `gnutls_record_get_state()` to let me do crypto offload (to my own application, which can then use accelerated crypto asm and sendmmsg()/recvmsg() to its heart's desire). But I can't see how I can get GnuTLS to tell me whether it's doing EtM or not. Do I have to force EtM disabled if I want to use `gnutls_record_get_state()`? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1250 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jun 30 02:42:25 2021 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 30 Jun 2021 00:42:25 +0000 Subject: [gnutls-devel] GnuTLS | Nonblocking Sockets and GNUTLS_E_AGAIN (#1251) References: Message-ID: Cinolt Yuklair created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1251 Nonblocking socket operation is crucial for many applications, for example when simultaneously handling many socket connections. When handling a connection, it is necessary for the program to know when there is no more data to be read from the socket. With traditional sockets, the recv(2) system call indicates this case with the EAGAIN errno code. With GnuTLS, (when using gnutls_transport_set_int and default pull/push functions) there is the GNUTLS_E_AGAIN error code, which works some of the time, however I've noticed that there are certain cases when gnutls_record_recv will return this error code even when data has not been exhausted from the connection. Therefore, there is no way for the program to reliably know when data has been exhausted from the connection. In my opinion, gnutls_record_recv should return GNUTLS_E_AGAIN in the exact same semantics that recv returns EAGAIN. I don't see a reason why there are "extra" cases where GNUTLS_E_AGAIN is returned. In these cases, the program will think there is no more data and not handle connections correctly. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1251 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: