Hello,
You are concerned if: you contribute to Mbed TLS, or you maintain local patches to Mbed TLS.
You are not concerned if: you just use Mbed TLS.
We are going to change the C coding style in Mbed TLS. The new style is mostly what you'd find in The C Programming Language, 2nd edition, by Brian Kernighan and Dennis Ritchie (K&R2). The main changes compared to the current style are:
* Spaces outside parentheses, not inside. No space in f(x).
* Opening braces on the same line as if(), for(), etc., but on a separate line for functions.
Indentation remains 4 spaces. The recommended maximum line length remains 80 columns. There are a few deviations from K&R2, documentation will be available shortly.
The new code style will be enforced by the CI testing. This means that style that's rejected by the tool will not be merged, full stop. This also means that sometimes we'll have code that looks a bit less good to humans because the tool insists on it. We're doing this to avoid wasting reviewers' and contributors' time with style violations in code review.
The tool we're using is uncrustify<https://github.com/uncrustify/uncrustify>. You can see how your code will look like by installing uncrustify 0.75.1 and running scripts/code_style.py from mbedtls-3.3.0 or mbedtls-2.28.2. There are previews of the rewritten branches at https://github.com/Mbed-TLS/mbedtls/tree/features/new-code-style/development and https://github.com/Mbed-TLS/mbedtls/tree/features/new-code-style/mbedtls-2.… (updated every few days until the real branches are rewritten). If you're now starting work on a new feature or bugfix, it will probably be easier to start from those branches, and do an easy rebase once they become official.
If you've been working on a branch, we will provide a script to rebase the branch and rewrite it to the new style commit by commit. You'll need to have uncrustify 0.75.1.
Concretely, when we change the code style:
* If you've started to work on a branch but review has not started yet, we'll ask you to adapt your branch to the new code style.
* If your work is under review, you'll need to adapt your branch to the new code style before it can be merged. Rebasing a branch is disruptive for reviews, so please synchronize with the reviewers to decide on a good time.
We plan to do the switch during the first week of January 2023.
Best regards,
--
Gilles Peskine
Mbed TLS developer
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Mbed TLS users,
We are pleased to announce the release of Mbed TLS versions 3.3.0 and 2.28.2.
These releases of Mbed TLS address several security issues, provide bug fixes, and bring other minor changes. Full details are available in the release notes (https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-3.3.0 and https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.28.2 ).
We recommend all users to consider whether they are impacted, and to upgrade appropriately.
The releases are available from
https://github.com/Mbed-TLS/mbedtls/releases
Dave Rodgman
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Mbed TLS users,
We have released Mbed TLS version 3.2.1.
This release is functionally identical to 3.2.0, but includes a file that was missing from the 3.2.0 release (see https://github.com/Mbed-TLS/mbedtls/issues/6084).
Full details are available in the release notes (https://github.com/Mbed-TLS/mbedtls/releases/tag/v3.2.1).
We recommend all users to consider whether they are impacted, and to upgrade appropriately.
Many thanks,
Mbed TLS Team.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Mbed TLS users,
We have released Mbed TLS versions 3.2.0 and 2.28.1.
These releases of Mbed TLS address several security issues, provide bug fixes, and for 3.2.0, add various features. Full details are available in the release notes (https://github.com/Mbed-TLS/mbedtls/releases/tag/v3.2.0, https://github.com/Mbed-TLS/mbedtls/releases/tag/v2.28.1).
We recommend all users to consider whether they are impacted, and to upgrade appropriately.
Dave Rodgman
Hello,
This is my first message to this list. I'm also new to mbedTLS and TLS in
general, apologies in advance if I make any mistakes with my questions.
I have installed mbedTLS on a STM32H7 with CMSIS/Keil, using the Network
module and the mbedTLS pack (v2.6.0)
<https://www.keil.com/pack/doc/mbedTLS/html/index.html>. I have created a
server on the MCU, and as a client I am using a desktop application written
with Nodejs. Client and server communicate via ethernet interface and I
manage to transmit data between them. My priority is to develop the server,
not so much the client.
I have a specific requirement to use the cipher suite
“TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256”. As far as I understand, the
client must show a list of cipher suites to the server, and the server
chooses according to its priority. The priority is set with the macro
“MBEDTLS_SSL_CIPHERSUITES” When inspecting the communication with *WireShark
*I see that among the list sent by the client there is the cipher I need:
“TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)”
On the other hand in my mbedTLS_config.h file I have activated the
following macro:
#define MBEDTLS_SSL_CIPHERSUITES
MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
When the client connects an error occurs in the handshake, the method
“mbedtls_ssl_handshake()” returns the return code -0x7380
(MBEDTLS_ERR_SSL_NO_CIPHER_CHOSEN).
If I comment the macro “MBEDTLS_SSL_CIPHERSUITES” the handshake method does
not return error and works correctly, but the cipher I am looking for is
not used, but “TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384”.
Maybe I am forgetting some configuration macro to be able to use the
mentioned cipher? Any idea?
--
Jordi Enguídanos Naranjo
Hi all,
Please note that in the next couple of weeks, we will migrate Mbed TLS to a new GitHub organisation. Your existing scripts, links etc for accessing Mbed TLS on GitHub should not be affected.
This will change the url from https://github.com/ARMmbed/mbedtls to https://github.com/Mbed-TLS/mbedtls . GitHub will redirect any accesses to the old URL for the foreseeable future, but we would recommend updating your links once the migration is complete.
All of the Mbed TLS repositories will migrate to this new organisation, i.e.:
mbedtls
mbedtls-docs
mbedtls-test
Thanks
Dave Rodgman
Hi ,
*Problem description :*
Trying to run example
https://github.com/ARMmbed/mbedtls/blob/master/programs/ssl/ssl_server2.c .
Updated ssl_server2 port to listen on 7777 for incoming client request
,ssl_server2
will be waiting for remote connection continuously.
There was no client request for connection on this port, but still server
is getting some spurious connection request and goes for handshake and
fails with below error code.
Error code: mbedtls_ssl_handshake returned error -30976
*Steps to reproduce: =============*
1. start ssl_server2 program
2. Monitor for ssl_server2 connection waiting , observe ssl_server2 will
accept spurious connection request and goes for handshake and fails
with above
mentioned error code.
*Expected behavior:*
ssl_server2 wait for remote connection infinitely and connect to valid
client request and perform handshake every time.
*Actual behavior:*
Occasionally ssl_server2 will accept spurious connection request and goes
for handshake and fails with below error code.
Error code:
mbedtls_ssl_handshake returned error -30976 on ssl_server2
*Analysis:*
As per below logs what we understand is ssl_server2 will accept spurious
connection request and goes for handshake and fails with error code
-30796 ,MBEDTLS_ERR_SSL_BAD_HS_CLIENT_HELLO
on ssl_server2 side .
Can you please help us to understand this behavior?
What could be the reason for ssl_server2 to connect to a spurious
connection request?, as mentioned above there was no client request for
connection on this ssl_server2 port( 7777) .
We have tried this on other SERVER_PORT as well .
*Logs Snippet:*
*==========*
. Seeding the random number generator... ok
. Loading the CA root certificate ... ok (0 skipped)
. Loading the server cert. and key... ok
. Bind on tcp://*:7777/ ... ok
. Setting up the SSL/TLS structure... ok
. Waiting for a remote connection ...ok
. Performing the SSL/TLS handshake... failed
! mbedtls_ssl_handshake returned -0x7900
Last error was: -30976 - SSL - Processing of the ClientHello handshake
message failed
. Waiting for a remote connection ... ok
. Performing the SSL/TLS handshake... failed
! mbedtls_ssl_handshake returned -0x7900
Last error was: -30976 - SSL - Processing of the ClientHello handshake
message failed
. Waiting for a remote connection ... ok
. Performing the SSL/TLS handshake... failed
! mbedtls_ssl_handshake returned -0x7900
Last error was: -30976 - SSL - Processing of the ClientHello handshake
message failed
Regards
Mahesh
Hi,
We are pleased to announce the release of Mbed TLS 2.16.12, 2.28.0 and 3.1.0.
These releases of Mbed TLS address several security issues, provide bug fixes, and new features, including initial support for TLS 1.3 in Mbed TLS 3.1.0.
Full details are available in the release notes (https://github.com/ARMmbed/mbedtls/releases/tag/v3.1.0, https://github.com/ARMmbed/mbedtls/releases/tag/v2.28.0, https://github.com/ARMmbed/mbedtls/releases/tag/v2.16.12).
Mbed TLS 2.16.12 will be the last release in the 2.16 LTS; it will no longer be supported.
Mbed TLS 2.28 is the new long-term support release, and will be supported with bug-fixes and security fixes until end of 2024.
We recommend all users to consider whether they are impacted, and to upgrade appropriately.
Dave Rodgman
Hi,
On Monday at 10am UK time, we will hold the Mbed TLS Tech Forum. This is an open forum conference call for anyone to participate; please reply here if there are any agenda topics you would like to raise.
Zoom details are in the TF calendar: https://www.trustedfirmware.org/meetings/mbed-tls-technical-forum/ or see below
Dave
Join Zoom Meeting
https://linaro-org.zoom.us/j/99948462765?pwd=SGlHYlF1Z2owUDNFWWppaGlSRDh5UT…
Meeting ID: 999 4846 2765
Passcode: 196117
One tap mobile
+12532158782,,99948462765# US (Tacoma)
+13462487799,,99948462765# US (Houston)
Dial by your location
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 669 900 9128 US (San Jose)
+1 301 715 8592 US (Washington DC)
+1 312 626 6799 US (Chicago)
+1 646 558 8656 US (New York)
888 788 0099 US Toll-free
877 853 5247 US Toll-free
Meeting ID: 999 4846 2765
Find your local number: https://linaro-org.zoom.us/u/anpWWkRdt
Hi,
Mbed TLS 2.16 LTS is approaching the end of its support period – it was originally announced that it would be maintained for at least 3 years up until the end of 2021 – and currently there is no other LTS branch.
To ensure that there is no period of time without a supported LTS branch, we plan to release 2.28 LTS in the near future (which will have the usual 3 year support period). We will continue supporting 2.16 LTS until this is available. The expectation is that as 2.28 will be API-compatible with 2.16, users of 2.16 LTS will be able to upgrade to 2.28 very easily.
Progress towards 2.28 LTS can be followed here: https://github.com/orgs/ARMmbed/projects/18#column-15836286
Dave Rodgman
