- mbed-tls - lists.trustedfirmware.org

Re: MBEDTLS_PLATFORM_TIME_TYPE_MACRO for custom mbedtls_time_t

by Gilles Peskine

That's a good question. I don't know the answer offhand. I've filed an issue to clarify that: https://github.com/Mbed-TLS/mbedtls/issues/10846 -- Best regards, Gilles Peskine On 29/07/2026 17:42, Huber, Ralf wrote: > > Hello Gilles, > > Thank you for your reply. I can try submitting a patch, but I have > never worked with Github so far, so I first need to figure out how > that works 😃 > > After digging a bit deeper, I have some concerns about the types that > can reasonably be used for MBEDTLS_PLATFORM_TIME_TYPE_MACRO. I’m > hesitant to submit a patch unless I understand its effects. > > From x509.c: > > int mbedtls_x509_time_gmtime(mbedtls_time_t tt, mbedtls_x509_time *now) > > { > > struct tm tm; > > if (mbedtls_platform_gmtime_r(&tt, &tm) == NULL) { > > return -1; > > } > > now->year = tm.tm_year + 1900; > > now->mon = tm.tm_mon + 1; > > now->day = tm.tm_mday; > > now->hour = tm.tm_hour; > > now->min = tm.tm_min; > > now->sec = tm.tm_sec; > > return 0; > > } > > static int x509_get_current_time(mbedtls_x509_time *now) > > { > > return mbedtls_x509_time_gmtime(mbedtls_time(NULL), now); > > } > > x509_get_current_time() passes the output of the custom mbedtls_time() > directly to mbedtls_x509_time_gmtime(), where it is immediately passed > to mbedtls_platform_gmtime_r(). > > For this particular piece of code, MBEDTLS_PLATFORM_TIME_TYPE_MACRO > could be anything (basic type, structure, function pointer, etc.), as > long as the custom mbedtls_platform_gmtime_r() can process the return > value from the custom mbedtls_time(). > > However, if the return value of mbedtls_time() is used somewhere in > Mbed TLS without passing it through mbedtls_platform_gmtime_r(), then > the caller likely expects that mbedtls_time() behaves like the time() > function of <time.h>. MBEDTLS_PLATFORM_TIME_TYPE_MACRO must then have > the same properties as time_t (as defined in the C standard), or at > least it must have those properties that Mbed TLS relies on. > > To add a compile-time check for suitable configurations of > MBEDTLS_PLATFORM_TIME_TYPE_MACRO, I would need to know what properties > Mbed TLS expects from it, and then somehow check if the custom > MBEDTLS_PLATFORM_TIME_TYPE_MACRO type has these properties. > > We only use a subset of Mbed TLS in our application. Using uint32_t > for MBEDTLS_PLATFORM_TIME_TYPE_MACRO might work for us, but maybe > there are other features in Mbed TLS where it would fail. I haven’t > searched through the whole Mbed TLS code. > > Is it certain that the only thing that is ever done with the return > value of mbedtls_time(), is that it is being passed to > mbedtls_platform_gmtime_r()? I.e. the only purpose of > MBEDTLS_PLATFORM_TIME_TYPE_MACRO is to align the return type of > mbedtls_time() with the type of the first parameter of > mbedtls_platform_gmtime_r()? > > Best regards, > > Ralf > > > *KION Supply Chain Solutions* > > *Von:*Gilles Peskine <gilles.peskine(a)arm.com> > *Gesendet:* Montag, 20. Juli 2026 18:51 > *An:* Huber, Ralf <ralf.huber(a)kiongroup.com>; > mbed-tls(a)lists.trustedfirmware.org > *Betreff:* Re: [mbed-tls] MBEDTLS_PLATFORM_TIME_TYPE_MACRO for custom > mbedtls_time_t > > *WARNING: This email originated outside of the company. DO NOT CLICK > links or attachments or enter any information into forms unless you > trust the sender and know the content is safe.* > > Hello, > > I agree that this looks like a mistake. The various platform > interfaces are subtly different, and I suspect that this was inspired > by a similar check for a different interface that doesn't apply here. > This is not tested (I think we have no tests for custom platform types). > > Can you please submit a patch? > > -- > Best regards, > > Gilles Peskine > TF-PSA-Crypto and Mbed TLS developer > > On 18/07/2026 15:15, Huber, Ralf via mbed-tls wrote: > > Dear Mbed TLS contributors, > > We are using mbedtls v4 for X.509 certificate verification on a 32 > bit microcontroller. The device has an RTC chip and we use its > time for mbedtls by defining MBEDTLS_PLATFORM_TIME_ALT. This is > working so far. > > The compiler provides <time.h>, with time_t being a signed 32 bit > type. I would like to stop mbedtls from using the date and time > functions of <time.h> and change mbedtls_time_t to _unsigned_ 32 > bit to avoid the year 2038 problem (when signed 32 bit time_t will > overflow). To do this, I defined > > #define MBEDTLS_PLATFORM_TIME_TYPE_MACRO unsigned long > > I also changed the custom time function > (MBEDTLS_PLATFORM_TIME_ALT) to return unsigned values and I > defined MBEDTLS_PLATFORM_GMTIME_R_ALT and provided a custom > mbedtls_platform_gmtime_r() that accepts unsigned values. > > When I build mbedtls with these settings, I get an error from > tf_psa_crypto_check_config.h: > > #if defined(MBEDTLS_PLATFORM_TIME_TYPE_MACRO) &&\ > > ( defined(MBEDTLS_PLATFORM_STD_TIME) ||\ > > defined(MBEDTLS_PLATFORM_TIME_ALT) ) > > #error "MBEDTLS_PLATFORM_TIME_TYPE_MACRO and > MBEDTLS_PLATFORM_STD_TIME/MBEDTLS_PLATFORM_TIME_ALT cannot be > defined simultaneously" > > #endif > > I wonder if this check is actually necessary or maybe a mistake? > Actually, I expected the opposite, i.e. > > #if defined(MBEDTLS_PLATFORM_TIME_TYPE_MACRO) &&\ > > !( defined(MBEDTLS_PLATFORM_STD_TIME) ||\ > > defined(MBEDTLS_PLATFORM_TIME_ALT) ) > > #error "Must provide alternate time() function compatible with > type defined by MBEDTLS_PLATFORM_TIME_TYPE_MACRO" > > #endif > > Could somebody please explain why MBEDTLS_PLATFORM_TIME_TYPE_MACRO > can’t be used with MBEDTLS_PLATFORM_TIME_ALT? Can/Should I comment > out the #error? I tried that and the library compiles without > errors, and the software using the library also compiles without > errors, but I have not yet checked, if it actually works. > > Best regards, > > Ralf Huber > > KION Supply Chain Solutions > > Linde Material Handling GmbH, > Sitz der Gesellschaft: Aschaffenburg, Registergericht: > Aschaffenburg HRB9963, Ust-IdNr. DE814809128, Geschäftsführung: > Andreas Krinninger (Vorsitzender), Dr. Karoline Jung-Senssfelder, > Ulrike Just, Dr. Frank Schepp, Vorsitzende des Aufsichtsrats: > Valeria Gargiulo > > > > Linde Material Handling GmbH, > Sitz der Gesellschaft: Aschaffenburg, Registergericht: Aschaffenburg > HRB9963, Ust-IdNr. DE814809128, Geschäftsführung: Andreas Krinninger > (Vorsitzender), Dr. Karoline Jung-Senssfelder, Ulrike Just, Dr. Frank > Schepp, Vorsitzende des Aufsichtsrats: Valeria Gargiulo >

16 hours, 11 minutes

1
0
0 0

Post quantum support, x25519mlkem768

by Christian Huitema

Do we have support for x25519mlkem768 in Mbed TLS? -- Christian Huitema

5 days, 15 hours

2
1
0 0

MBEDTLS_PLATFORM_TIME_TYPE_MACRO for custom mbedtls_time_t

by Huber, Ralf

Dear Mbed TLS contributors, We are using mbedtls v4 for X.509 certificate verification on a 32 bit microcontroller. The device has an RTC chip and we use its time for mbedtls by defining MBEDTLS_PLATFORM_TIME_ALT. This is working so far. The compiler provides <time.h>, with time_t being a signed 32 bit type. I would like to stop mbedtls from using the date and time functions of <time.h> and change mbedtls_time_t to unsigned 32 bit to avoid the year 2038 problem (when signed 32 bit time_t will overflow). To do this, I defined #define MBEDTLS_PLATFORM_TIME_TYPE_MACRO unsigned long I also changed the custom time function (MBEDTLS_PLATFORM_TIME_ALT) to return unsigned values and I defined MBEDTLS_PLATFORM_GMTIME_R_ALT and provided a custom mbedtls_platform_gmtime_r() that accepts unsigned values. When I build mbedtls with these settings, I get an error from tf_psa_crypto_check_config.h: #if defined(MBEDTLS_PLATFORM_TIME_TYPE_MACRO) &&\ ( defined(MBEDTLS_PLATFORM_STD_TIME) ||\ defined(MBEDTLS_PLATFORM_TIME_ALT) ) #error "MBEDTLS_PLATFORM_TIME_TYPE_MACRO and MBEDTLS_PLATFORM_STD_TIME/MBEDTLS_PLATFORM_TIME_ALT cannot be defined simultaneously" #endif I wonder if this check is actually necessary or maybe a mistake? Actually, I expected the opposite, i.e. #if defined(MBEDTLS_PLATFORM_TIME_TYPE_MACRO) &&\ !( defined(MBEDTLS_PLATFORM_STD_TIME) ||\ defined(MBEDTLS_PLATFORM_TIME_ALT) ) #error "Must provide alternate time() function compatible with type defined by MBEDTLS_PLATFORM_TIME_TYPE_MACRO" #endif Could somebody please explain why MBEDTLS_PLATFORM_TIME_TYPE_MACRO can't be used with MBEDTLS_PLATFORM_TIME_ALT? Can/Should I comment out the #error? I tried that and the library compiles without errors, and the software using the library also compiles without errors, but I have not yet checked, if it actually works. Best regards, Ralf Huber KION Supply Chain Solutions Linde Material Handling GmbH, Sitz der Gesellschaft: Aschaffenburg, Registergericht: Aschaffenburg HRB9963, Ust-IdNr. DE814809128, Gesch?ftsf?hrung: Andreas Krinninger (Vorsitzender), Dr. Karoline Jung-Senssfelder, Ulrike Just, Dr. Frank Schepp, Vorsitzende des Aufsichtsrats: Valeria Gargiulo

1 week, 2 days

2
1
0 0

Publish Mbed TLS security advisories in machine-readable format for SBOM scanners

by Schlegelmilch, Nils

Hi Mbed TLS team, I would like to ask whether Mbed TLS could publish security advisories in a machine-readable format, for example GitHub Security Advisories or OSV. Security fixes are currently visible in release notes and documentation before they appear in NVD/GHSA/OSV. This creates a detection gap for automated vulnerability scanners such as Dependency-Track, because they rely on structured advisory data with affected versions, fixed versions, and identifiers such as CPE, PURL, or Git ranges. For example, when a security release is available, Dependency-Track may not alert until the corresponding CVE or advisory appears in one of its vulnerability data sources. This can delay automated remediation even though a patched Mbed TLS version is already released. Would the project consider publishing machine-readable advisories at release time, or is there already a preferred process for this? Thanks! Nils Schlegelmilch Development Phone +49 7836 50-9883 E-Mail n.schlegelmilch(a)vega.com<mailto:n.schlegelmilch@vega.com> [cid:image001.png@01DD1042.23E9BE30] VEGA Grieshaber KG | Am Hohenstein 113 | 77761 Schiltach | Germany [cid:image002.png@01DD1042.23E9BE30]<https://de.linkedin.com/company/vega-grieshaber-kg>[cid:image003.png@01DD1042.23E9BE30]<https://www.vega.com/>[cid:image004.png@01DD1042.23E9BE30]<https://www.youtube.com/vegagrieshaberkg> Unsere Datenschutzhinweise und somit auch die Informationen gem. Art. 13 DSGVO finden Sie im Internet unter www.vega.com/datenschutz VEGA Grieshaber KG Kommanditgesellschaft mit Sitz in Wolfach Registergericht: Freiburg HRA 680 687 Persönlich haftende Gesellschafter: Isabel Grieshaber Grieshaber Holding GmbH Sitz: Wolfach Registergericht: Freiburg HRB 680 271 Geschäftsführer: Isabel Grieshaber, Markus Kniesel USt.-Id.-Nr.: DE143030199

2 weeks, 2 days

2
1
0 0

Mbed TLS and TF-PSA-Crypto releases now available

by Minos Galanakis

Hi Mbed TLS users, We are pleased to announce the release of Mbed TLS 4.2.0, Mbed TLS 4.1.1, Mbed TLS 3.6.7, TF-PSA-Crypto 1.2.0, and TF-PSA-Crypto 1.1.1. These releases address several security issues, include bug fixes, and bring other improvements. Mbed TLS 4.1 and TF-PSA-Crypto 1.1 remain Long Term Support (LTS) releases and are supported until March 2029. Mbed TLS 3.6 remains supported until March 2027. We recommend all users review the changes, assess any impact, and upgrade as appropriate. Full details are available in the release notes: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-4.2.0 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-4.1.1 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.7 https://github.com/Mbed-TLS/TF-PSA-Crypto/releases/tag/tf-psa-crypto-1.2.0 https://github.com/Mbed-TLS/TF-PSA-Crypto/releases/tag/tf-psa-crypto-1.1.1 Kind regards, The Mbed TLS Team

3 weeks, 1 day

1
0
0 0

[Mbed-tls-announce] Mbed TLS and TF-PSA-Crypto releases now available

by Minos Galanakis via Mbed-tls-announce

Hi Mbed TLS users, We are pleased to announce the release of Mbed TLS 4.2.0, Mbed TLS 4.1.1, Mbed TLS 3.6.7, TF-PSA-Crypto 1.2.0, and TF-PSA-Crypto 1.1.1. These releases address several security issues, include bug fixes, and bring other improvements. Mbed TLS 4.1 and TF-PSA-Crypto 1.1 remain Long Term Support (LTS) releases and are supported until March 2029. Mbed TLS 3.6 remains supported until March 2027. We recommend all users review the changes, assess any impact, and upgrade as appropriate. Full details are available in the release notes: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-4.2.0 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-4.1.1 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.7 https://github.com/Mbed-TLS/TF-PSA-Crypto/releases/tag/tf-psa-crypto-1.2.0 https://github.com/Mbed-TLS/TF-PSA-Crypto/releases/tag/tf-psa-crypto-1.1.1 Kind regards, The 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. -- Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org

3 weeks, 1 day

1
0
0 0

mbedTLS 3.6.6 TLS 1.3: Heap corruption issue

by Sielatchom, Cesaire

Hello, while setting up a TLS 1.3 client based on mbedTLS 3.6.6, I am facing a memory corruption issue and would appreciate any advice on how to debug it further. Initial symptoms ================ Originally I was using FreeRTOS heap_4 as the allocator. During the TLS handshake I eventually hit one of the following assertions inside the FreeRTOS heap implementation: configASSERT( heapBLOCK_IS_ALLOCATED( pxLink ) != 0 ); configASSERT( pxLink->pxNextFreeBlock == heapPROTECT_BLOCK_POINTER( NULL ) ); This suggested corruption of the heap block header structures. Isolation attempt ================= To exclude interactions with the FreeRTOS heap allocator, I reconfigured mbedTLS to use a dedicated static memory pool by enabling: MBEDTLS_MEMORY_BUFFER_ALLOC_C I allocated a dedicated 1 MB memory pool located in external RAM and initialized it via: mbedtls_memory_buffer_alloc_init(...); No other software component is intended to access this memory area. New failure =========== With the dedicated memory pool in place, the TLS 1.3 handshake now fails inside memory_buffer_alloc.c with the following consistency check: if (cur->alloc != 0) { #if defined(MBEDTLS_MEMORY_DEBUG) mbedtls_fprintf(stderr, "FATAL: block in free_list but allocated data\n"); #endif mbedtls_exit(1); } The execution stops with: FATAL: block in free_list but allocated data This appears to indicate that a block found in the free list still has its allocation flag set. What I have checked so far ========================== - Initially I suspected FreeRTOS heap corruption. - I added hardware watchpoints at the beginning and end of the affected memory blocks. - No obvious buffer overflow was detected using those watchpoints. - Secure and Non-Secure heaps are separated. - I experimented with MPU guard regions. - The issue is reproducible under TLS/WebSocket traffic. - mbedTLS is now running from a dedicated static memory pool. - The dedicated mbedTLS pool is approximately 1 MB and is not shared with the FreeRTOS heap. Platform ======== - STM32U585 - TrustZone enabled - FreeRTOS - mbedTLS 3.6.6 - TLS 1.3 enabled - WebSocket over TLS Are there recommended debugging options or allocator diagnostics that could help identify the offending allocation or the block whose metadata became inconsistent? Has anyone experienced similar issues specifically with TLS 1.3 handshakes, especially during key share generation? Relevant handshake log ====================== init connect[1] . Performing the SSL/TLS handshake...[TLS][2] ../SRV_TLS/mbedtls/library/ssl_tls.c:4670: => handshake [TLS][2] ../SRV_TLS/mbedtls/library/ssl_msg.c:2356: => flush output [TLS][2] ../SRV_TLS/mbedtls/library/ssl_msg.c:2365: <= flush output [TLS][2] ../SRV_TLS/mbedtls/library/ssl_tls.c:4589: client state: MBEDTLS_SSL_HELLO_REQUEST [TLS][3] ../SRV_TLS/mbedtls/library/ssl_misc.h:1353: handshake state: 0 (MBEDTLS_SSL_HELLO_REQUEST) -> 1 (MBEDTLS_SSL_CLIENT_HELLO) [TLS][2] ../SRV_TLS/mbedtls/library/ssl_msg.c:2356: => flush output [TLS][2] ../SRV_TLS/mbedtls/library/ssl_msg.c:2365: <= flush output [TLS][2] ../SRV_TLS/mbedtls/library/ssl_tls.c:4589: client state: MBEDTLS_SSL_CLIENT_HELLO [TLS][2] ../SRV_TLS/mbedtls/library/ssl_client.c:921: => write client hello [TLS][3] ../SRV_TLS/mbedtls/library/ssl_client.c:487: dumping 'client hello, random bytes' (32 bytes) [TLS][3] ../SRV_TLS/mbedtls/library/ssl_client.c:487: 0000: 9a 99 37 69 fa 5e 07 f7 ff c8 5b ac 56 fe 45 1a ..7i.^....[.V.E. [TLS][3] ../SRV_TLS/mbedtls/library/ssl_client.c:487: 0010: 53 d1 a1 d6 27 f6 5d 5a 4e 5b 2a 80 4c 1e 9b cb S...'.]ZN[*.L... [TLS][3] ../SRV_TLS/mbedtls/library/ssl_client.c:512: dumping 'session id' (0 bytes) [TLS][3] ../SRV_TLS/mbedtls/library/ssl_client.c:370: client hello, add ciphersuite: 1301, TLS1-3-AES-128-GCM-SHA256 [TLS][3] ../SRV_TLS/mbedtls/library/ssl_client.c:388: adding EMPTY_RENEGOTIATION_INFO_SCSV [TLS][3] ../SRV_TLS/mbedtls/library/ssl_client.c:397: client hello, got zu cipher suites [TLS][3] ../SRV_TLS/mbedtls/library/ssl_tls13_client.c:57: client hello, adding supported versions extension [TLS][3] ../SRV_TLS/mbedtls/library/ssl_tls13_client.c:80: supported version: [3:4] [TLS][3] ../SRV_TLS/mbedtls/library/ssl_tls13_client.c:86: supported version: [3:3] [TLS][3] ../SRV_TLS/mbedtls/library/ssl_tls13_client.c:573: no cookie to send; skip extension [TLS][3] ../SRV_TLS/mbedtls/library/ssl_tls13_client.c:285: client hello: adding key share extension [TLS][1] ../SRV_TLS/mbedtls/library/ssl_tls13_generic.c:1552: Perform PSA-based ECDH/FFDH computation. FATAL: block in free_list but allocated data Any suggestions, debugging techniques, or similar experiences would be greatly appreciated. Thank you very much. Best regards, Cesaire Mit freundlichen Grüßen / Best regards i. A. Cesaire Sielatchom Konstrukteur und Entwickler [BKS_4c.gif] BKS GmbH Entwicklung Elektronik Heidestr. 71 D-42549 Velbert Telefon +49 2051 201 528<tel:+49%202051%20201%20528> Cesaire.Sielatchom(a)bks.de<mailto:Cesaire.Sielatchom@bks.de> www.bks.de<https://www.bks.de/de-de> BKS GmbH Sitz der Gesellschaft: Velbert Amtsgericht Wuppertal, HRB 17711 GF: Thomas Polonyi Vorsitzender des Aufsichtsrats: Dirk Leuker WEEE-Reg.-Nr. DE 14737171 [Email_Footer SicherheitsExpo 2026.jpg] Diese Mail ist vertraulich. Wenn Sie nicht der beabsichtigte Empfänger sind, dürfen Sie die Informationen nicht offenlegen, benutzen, kopieren oder verteilen. Wenn Sie diese Mail durch einen Fehler bekommen haben, teilen Sie uns dies bitte dadurch mit, dass Sie diese Mail an den Absender zurückschicken. Bitte löschen Sie danach diese Mail und alle Anhänge. Danke. This e-mail message including any attachment is intended for the sole use of the individual or entity named above. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others; also please notify the sender by replying to this message and then delete it and all attachments from your system.Thank you.

4 weeks

2
1
0 0

Updated invitation with note: MBed-TLS Technical Forum - Asia @ Every 4 weeks from 10am to 10:50am on Monday (GMT) (mbed-tls@lists.trustedfirmware.org)

by Shaun Longhorn

This event has been updated with a note: "Pushing meeting link" Changed: location MBed-TLS Technical Forum - Asia Every 4 weeks from 10am to 10:50am on Monday United Kingdom Time Location https://linaro-org.zoom.us/j/97758661706?pwd=baMjUvnWbY20z3ignQca7QVahhozkI… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9775866… Join Zoom Meeting https://linaro-org.zoom.us/j/99853938085?pwd=D3au597hb9J1veo1W74pIqkvY6VaDI… Join by phone (US) +1 833-548-0282 passcode: 12278212 Joining instructions https://www.google.com/url?q=https://applications.zoom.us/addon/invitation/… Joining notes Meeting host: shaun.longhorn(a)linaro.org Join Zoom Meeting: https://linaro-org.zoom.us/j/99853938085?pwd=D3au597hb9J1veo1W74pIqkvY6VaDI… ──────────https://linaro-org.zoom.us/j/99853938085?pwd=D3au597hb9J1veo1W74pIqkvY6VaDI.1&jst=2Joining Instructions────────── Guests mbed-tls(a)lists.trustedfirmware.org psa-crypto(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NjI4c3NnYjFoZHRh… Reply for mbed-tls(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NjI4c3NnYjFoZHRh… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

4 weeks, 1 day

1
0
0 0

Synced invitation: MBed-TLS Technical Forum - Asia @ Every 4 weeks from 10am to 10:50am on Monday (BST) (mbed-tls@lists.trustedfirmware.org)

by Shaun Longhorn

This email keeps the event up to date in your calendar. MBed-TLS Technical Forum - Asia Every 4 weeks from 10am to 10:50am on Monday United Kingdom Time Location https://linaro-org.zoom.us/j/97758661706?pwd=baMjUvnWbY20z3ignQca7QVahhozkI… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9775866… Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: MBed-TLS Technical Forum - AsiaTime: Jun 16, 2025 10:00 AM London Every 4 weeks on Mon, 39 occurrence(s)Please download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJMqcuGuqDotGtIbACm498ytl0ZhydWKdu1b/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/97758661706?pwd=baMjUvnWbY20z3ignQca7QVahhozkI.1Meeting ID: 977 5866 1706Passcode: 577208---One tap mobile+16892781000,,97758661706# US+17193594580,,97758661706# US---Dial by your location• +1 689 278 1000 US• +1 719 359 4580 US• +1 253 205 0468 US• +1 253 215 8782 US (Tacoma)• +1 301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• +1 312 626 6799 US (Chicago)• +1 346 248 7799 US (Houston)• +1 360 209 5623 US• +1 386 347 5053 US• +1 507 473 4847 US• +1 564 217 2000 US• +1 646 558 8656 US (New York)• +1 646 931 3860 US• +1 669 444 9171 US• +1 669 900 9128 US (San Jose)• 833 548 0282 US Toll-free• 833 928 4608 US Toll-free• 833 928 4609 US Toll-free• 833 928 4610 US Toll-free• 877 853 5247 US Toll-free• 888 788 0099 US Toll-free• 833 548 0276 US Toll-freeMeeting ID: 977 5866 1706Find your local number: https://linaro-org.zoom.us/u/acdtApJNbc Guests mbed-tls(a)lists.trustedfirmware.org psa-crypto(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

4 weeks, 1 day

1
0
0 0

Updated invitation with note: MBed TLS Technical Forum - US @ Every 4 weeks from 4:30pm to 5:30pm on Monday (BST) (mbed-tls@lists.trustedfirmware.org)

by Shaun Longhorn

This event has been updated with a note: "Pushing to fix meeting link issue" Changed: location MBed TLS Technical Forum - US Every 4 weeks from 4:30pm to 5:30pm on Monday United Kingdom Time Location https://linaro-org.zoom.us/j/93546216467?pwd=ja9Nxd0uLBn04jg1Be0NTy17Konzfl… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9354621… Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: MBed TLS Technical Forum - USTime: May 4, 2026 04:30 PM LondonEvery 4 weeks on Mon, 38 occurrence(s)Please download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJcoc--qrz0uHNNmuZMtfpylBgIZjC2so7xz/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/93546216467?pwd=ja9Nxd0uLBn04jg1Be0NTy17Konzfl.1Meeting ID: 935 4621 6467Passcode: 683772---One tap mobile+13126266799,,93546216467# US (Chicago)+13462487799,,93546216467# US (Houston)---Dial by your location• +1 312 626 6799 US (Chicago)• +1 346 248 7799 US (Houston)• +1 360 209 5623 US• +1 386 347 5053 US• +1 507 473 4847 US• +1 564 217 2000 US• +1 646 558 8656 US (New York)• +1 646 931 3860 US• +1 669 444 9171 US• +1 669 900 9128 US (San Jose)• +1 689 278 1000 US• +1 719 359 4580 US• +1 253 205 0468 US• +1 253 215 8782 US (Tacoma)• +1 301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• 833 928 4609 US Toll-free• 833 928 4610 US Toll-free• 877 853 5247 US Toll-free• 888 788 0099 US Toll-free• 833 548 0276 US Toll-free• 833 548 0282 US Toll-free• 833 928 4608 US Toll-freeMeeting ID: 935 4621 6467Find your local number:https://linaro-org.zoom.us/u/azKzC20VI Guests psa-crypto(a)lists.trustedfirmware.org mbed-tls(a)lists.trustedfirmware.org hordijk(a)aurora.tech Ben Taylor cjej65eug(a)gmail.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=dm9wcGhnbnZvMnRh… Reply for mbed-tls(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=dm9wcGhnbnZvMnRh… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

4 weeks, 1 day

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

mbed-tls