- mbed-tls - lists.trustedfirmware.org

by Janos Follath

Hi, There is no FIPS validated/certified version of Mbed TLS. In general most of the components should be very close to FIPS/NIST standards, but I don’t know of any that would have undergone a validation/certification process. Regards, Janos (Mbed TLS developer) From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Subramanian Gopi Krishnan via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: Subramanian Gopi Krishnan <gopikrishnan.subramanian(a)kone.com> Date: Thursday, 1 October 2020 at 07:38 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] FIPS Hi, Do we have FIPS compliant for mbedtls; similar to openssl fips? Thanks, Gopi Krishnan

6 years

1
0
0 0

FIPS

by Subramanian Gopi Krishnan

Hi, Do we have FIPS compliant for mbedtls; similar to openssl fips? Thanks, Gopi Krishnan

6 years

1
0
0 0

Re: [mbed-tls] Building a collaborative Mbed TLS community

by Frank Bergmann

Hi Gilles, actually I meant that the creator of the PR tries to make a first estimation. Maybe even this could be helpful. :-) Frank On Wed, Sep 30, 2020 at 09:47:41AM +0000, Gilles Peskine via mbed-tls wrote: > Hi Frank, > > Thanks for the suggestion. Sorry for not replying earlier. A time > estimate can help with scheduling, but our problem isn't so much > scheduling as a lack of bandwidth. Also we've found it very difficult to > estimate the time a review will take: some innocuous-looking patches end > up raising time-consuming questions about security or compatibility, > while some large patches turn out to be easy because they don't affect > risky areas much. > > The way we currently work is to schedule large contributions as part of > our sprint planning, but for most reviews we put them in a queue > (https://github.com/orgs/ARMmbed/projects/3). We've found that for our > team, having people pull from that queue works better than designating > reviewers a priori. > > -- > Gilles Peskine > Mbed TLS developer > > On 21/09/2020 07:35, Frank Bergmann via mbed-tls wrote: > > Hi Gilles, > > > > when I ask in our team to review a PR I usually provide an estimation about > > it. Of course a time base estimation and not an agile one in values of > > complexity. ;-) > > One could also provide an estimation about priority. > > Maybe these tiny rules may help somewhat. At least it can provide a better > > overview if you have tons of PRs. > > > > sincerely, > > Frank > > > > On Sun, Sep 20, 2020 at 10:27:44PM +0000, Gilles Peskine via mbed-tls wrote: > >> Hello, > >> > >> Historically, Mbed TLS has been maintained by Arm as an open-source > >> project, accepting external contributions, but with with priorities and > >> plans mostly driven only by Arm. Since earlier this year, Mbed TLS is an > >> open governance project under the umbrella of TrustedFirmware, with the > >> objective of making it a community led project, allowing community to > >> contribute and collaborate on the design and development of the project. > >> In practice, however, the project effectively still has some barriers of > >> entry. We would like to lift these barriers. > >> > >> The Mbed TLS team at Arm have already identified some concrete actions, > >> filed on the Mbed TLS epic board > >> https://github.com/ARMmbed/mbedtls/projects/2#column-10667107 > >> under “Facilitating community contributions”. A few more should be up > >> soon as the result of some internal brainstorming. > >> > >> We've also identified some problem areas which we're tracking as > >> separate topics. > >> > >> * Probably the biggest topic: review was and is a bottleneck. We are > >> working to streamline the review process where possible, without > >> lowering the quality bar, and to prioritize reviews better over new > >> work. (Having personally often been on both sides of the coin, I can > >> confirm that having a pull request sit around for years without getting > >> reviews is frustrating, and so is seeing all these pull request and not > >> having the time to review them all.) We would also like to enable, > >> encourage and value reviews from people who are not project maintainers. > >> > >> * We will migrate the CI to a publicly available platform hosted by > >> TrustedFirmware. However this platform will not be available until 2021. > >> > >> * We are working on a new documentation platform, where we'll transfer > >> both the information available on the current website and information > >> that is currently recorded in an Arm internal wiki. > >> > >> To all of you who have contributed to Mbed TLS, who have tried, or who > >> are considering it, what difficulties have you encountered? What else > >> can we do to make contributing easier? > >> > >> Best regards, > >> > >> -- > >> Gilles Peskine > >> Mbed TLS developer > >> > >> > >> -- > >> mbed-tls mailing list > >> mbed-tls(a)lists.trustedfirmware.org > >> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls -- Frank Bergmann, Pödinghauser Str. 5, D-32051 Herford, Tel. +49-5221-9249753 SAP Hybris & Linux LPIC-3, E-Mail tx2014(a)tuxad.de, USt-IdNr DE237314606 http://tdyn.de/freel -- Redirect to profile at freelancermap http://www.gulp.de/freiberufler/2HNKY2YHW.html -- Profile at GULP

6 years

1
0
0 0

Re: [mbed-tls] Building a collaborative Mbed TLS community

by Gilles Peskine

Hi Frank, Thanks for the suggestion. Sorry for not replying earlier. A time estimate can help with scheduling, but our problem isn't so much scheduling as a lack of bandwidth. Also we've found it very difficult to estimate the time a review will take: some innocuous-looking patches end up raising time-consuming questions about security or compatibility, while some large patches turn out to be easy because they don't affect risky areas much. The way we currently work is to schedule large contributions as part of our sprint planning, but for most reviews we put them in a queue (https://github.com/orgs/ARMmbed/projects/3). We've found that for our team, having people pull from that queue works better than designating reviewers a priori. -- Gilles Peskine Mbed TLS developer On 21/09/2020 07:35, Frank Bergmann via mbed-tls wrote: > Hi Gilles, > > when I ask in our team to review a PR I usually provide an estimation about > it. Of course a time base estimation and not an agile one in values of > complexity. ;-) > One could also provide an estimation about priority. > Maybe these tiny rules may help somewhat. At least it can provide a better > overview if you have tons of PRs. > > sincerely, > Frank > > On Sun, Sep 20, 2020 at 10:27:44PM +0000, Gilles Peskine via mbed-tls wrote: >> Hello, >> >> Historically, Mbed TLS has been maintained by Arm as an open-source >> project, accepting external contributions, but with with priorities and >> plans mostly driven only by Arm. Since earlier this year, Mbed TLS is an >> open governance project under the umbrella of TrustedFirmware, with the >> objective of making it a community led project, allowing community to >> contribute and collaborate on the design and development of the project. >> In practice, however, the project effectively still has some barriers of >> entry. We would like to lift these barriers. >> >> The Mbed TLS team at Arm have already identified some concrete actions, >> filed on the Mbed TLS epic board >> https://github.com/ARMmbed/mbedtls/projects/2#column-10667107 >> under “Facilitating community contributions”. A few more should be up >> soon as the result of some internal brainstorming. >> >> We've also identified some problem areas which we're tracking as >> separate topics. >> >> * Probably the biggest topic: review was and is a bottleneck. We are >> working to streamline the review process where possible, without >> lowering the quality bar, and to prioritize reviews better over new >> work. (Having personally often been on both sides of the coin, I can >> confirm that having a pull request sit around for years without getting >> reviews is frustrating, and so is seeing all these pull request and not >> having the time to review them all.) We would also like to enable, >> encourage and value reviews from people who are not project maintainers. >> >> * We will migrate the CI to a publicly available platform hosted by >> TrustedFirmware. However this platform will not be available until 2021. >> >> * We are working on a new documentation platform, where we'll transfer >> both the information available on the current website and information >> that is currently recorded in an Arm internal wiki. >> >> To all of you who have contributed to Mbed TLS, who have tried, or who >> are considering it, what difficulties have you encountered? What else >> can we do to make contributing easier? >> >> Best regards, >> >> -- >> Gilles Peskine >> Mbed TLS developer >> >> >> -- >> mbed-tls mailing list >> mbed-tls(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

6 years

1
0
0 0

Re: [mbed-tls] Proposed change: no longer credit contributors in the ChangeLog file

by Gilles Peskine

Hello, We're going ahead with this new process. For changes made since the last release (2.24.0 and corresponding updates to long-time support branches), the ChangeLog file will only record user-visible changes, and entries will not be used to credit contributors. We're updating ChangeLog.d/00README.md accordingly (https://github.com/ARMmbed/mbedtls/pull/3726). -- Gilles Peskine Mbed TLS developer On 20/09/2020 23:41, Gilles Peskine via mbed-tls wrote: > Hello, > > The Mbed TLS team is soliciting feedback on a proposed change of our > contributor acknowledgement policy. > > Background: our current policy is to acknowledge all contributors who > are not Arm employees in the ChangeLog files. This is a tradition that > dates back from when the version control history of Mbed TLS (then > PolarSSL) was not public. > > Proposed change: the ChangeLog file will no longer mention who > contributed a patch (“Contributed by …”). A patch will require a > ChangeLog entry only if it makes a user-visible changes, regardless of > who contributed it. We will still credit reporters in the ChangeLog > file, at least for security issues. > > Rationale: the ChangeLog file had a dual purpose: informing users, and > acknowledging contributors. It will now have the single purpose of > informing users. There are better ways of acknowledging contributors > nowadays: the Git history is public, and your contributions are visible > from your GitHub profile. (Note that we don't squash commits, and > attempt to preserve authorship as much as possible when we have to > rebase a patch.) Furthermore, writing a good ChangeLog entry often turns > out to require some back-and-forth, so lessening this requirement will > make it easier to accept contributions and to merge them faster (this is > in fact our primary motivation for the change). > > We are also thinking of creating an acknowledgement page out-of-tree. It > isn't clear yet what its scope would be, but it would include > acknowledging contributions in the form of reviews, which we wish to > encourage. (Please stay tuned for future announcements and discussions > regarding the Mbed TLS review process.) > > Question to potential contributors, or people who have participated in > other open-source projects: do you think that there is any value in > keeping acknowledgements in a file that is distributed with Mbed TLS? Is > there any value in maintaining an exhaustive list of contributors in a > form other than the Git history? > > Best regards, >

6 years

1
0
0 0

Information about CI failures on pull requests to Mbed TLS

by Gilles Peskine

Hello, If you've made a pull request to Mbed TLS, you've noticed that some of the continuous integration happens on a private server run by Arm. For jobs that ran since yesterday, if there are failures, you can now see the name of the failed tasks next to “PR-NNN-head TLS Testing” or “PR-NNN-merge TLS Testing”. See https://developer.trustedfirmware.org/w/mbed-tls/testing/ci/#identifying-je… for more details. If this isn't enough, an Arm employee can copy the logs from the server. Please ask in a comment. We hope to post logs automatically (https://github.com/ARMmbed/mbedtls/issues/3633) but I can't give a due date for that. We are planning to move to a public server run by TrustedFirmware, but this can't happen until some time in 2021. Please bear with us in the meantime, and thank you for your contributions. -- Gilles Peskine Mbed TLS developer

6 years

1
0
0 0

MbedTLS Webserver

by Thomas Schwarz

Hello everyone, I want to set up a webserver on my ESP32 Dev Module based von MbedTLS. Therefore I view the ssl_server example on github. Now my question: How can I connect the ssl_server to my local WIFI-network. What extra code do I need? And where is the SSID and the password configurable? Thanks for your help! Best regards Thomas Tel.: +49833460134418 MULTIVAC Info Box MULTIVAC Sepp Haggenmüller SE & Co. KG - Bahnhofstr. 4 - D-87787 Wolfertschwenden - Germany Tel.: +49(0)8334/601-0 - Fax: +49(0)8334/601-199 - multivac(a)multivac.de Kommanditgesellschaft Sitz: 87787 Wolfertschwenden Amtsgericht: Memmingen HRA 8040 USt-IdNr.: DE 129082475 - Steuer-Nr.: 138/169/51105 - WEEE-Reg.-Nr.: DE 16576440 Persönlich haftende Gesellschafterin: MULTIVAC Sepp Haggenmüller Verwaltungs SE Sitz: 87787 Wolfertschwenden Amtsgericht: Memmingen HRB 16659 Geschäftsführende Direktoren: Guido Spix, Christian Traumann Verwaltungsratsvorsitzender: Elmar Fischer Bankverbindung: Deutsche Bank Memmingen . IBAN: DE 31 7337 0008 0123 6330 00 . BIC: DEUT DE MM 733 Banner

6 years

1
0
0 0

DTLS server

by Mehdi Karimi

I am using v16 of the mbedTLS library to setup DTLS server. However, I observe that the handshake does not work well and there are several issues starting with the cookie exchange. Do I necessarily have to update to the latest version of mbedTLS? Are there known issues with DTLS server setup using previous versions (as far as I could tell from the ChangeLog). Thanks Mehdi

6 years, 1 month

1
0
0 0

Re: [mbed-tls] Proposed change: no longer credit contributors in the ChangeLog file

by Frank Bergmann

Hi Gilles, as you said: Git is public. As long as it is kept public there's no reason to "duplicate details". My 2 cents. sincerely, Frank On Sun, Sep 20, 2020 at 09:41:26PM +0000, Gilles Peskine via mbed-tls wrote: > Hello, > > The Mbed TLS team is soliciting feedback on a proposed change of our > contributor acknowledgement policy. > > Background: our current policy is to acknowledge all contributors who > are not Arm employees in the ChangeLog files. This is a tradition that > dates back from when the version control history of Mbed TLS (then > PolarSSL) was not public. > > Proposed change: the ChangeLog file will no longer mention who > contributed a patch (“Contributed by …”). A patch will require a > ChangeLog entry only if it makes a user-visible changes, regardless of > who contributed it. We will still credit reporters in the ChangeLog > file, at least for security issues. > > Rationale: the ChangeLog file had a dual purpose: informing users, and > acknowledging contributors. It will now have the single purpose of > informing users. There are better ways of acknowledging contributors > nowadays: the Git history is public, and your contributions are visible > from your GitHub profile. (Note that we don't squash commits, and > attempt to preserve authorship as much as possible when we have to > rebase a patch.) Furthermore, writing a good ChangeLog entry often turns > out to require some back-and-forth, so lessening this requirement will > make it easier to accept contributions and to merge them faster (this is > in fact our primary motivation for the change). > > We are also thinking of creating an acknowledgement page out-of-tree. It > isn't clear yet what its scope would be, but it would include > acknowledging contributions in the form of reviews, which we wish to > encourage. (Please stay tuned for future announcements and discussions > regarding the Mbed TLS review process.) > > Question to potential contributors, or people who have participated in > other open-source projects: do you think that there is any value in > keeping acknowledgements in a file that is distributed with Mbed TLS? Is > there any value in maintaining an exhaustive list of contributors in a > form other than the Git history? > > Best regards, > > -- > Gilles Peskine > Mbed TLS developer > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls -- Frank Bergmann, Pödinghauser Str. 5, D-32051 Herford, Tel. +49-5221-9249753 SAP Hybris & Linux LPIC-3, E-Mail tx2014(a)tuxad.de, USt-IdNr DE237314606 http://tdyn.de/freel -- Redirect to profile at freelancermap http://www.gulp.de/freiberufler/2HNKY2YHW.html -- Profile at GULP

6 years, 1 month

1
0
0 0

Re: [mbed-tls] Building a collaborative Mbed TLS community

by Frank Bergmann

Hi Gilles, when I ask in our team to review a PR I usually provide an estimation about it. Of course a time base estimation and not an agile one in values of complexity. ;-) One could also provide an estimation about priority. Maybe these tiny rules may help somewhat. At least it can provide a better overview if you have tons of PRs. sincerely, Frank On Sun, Sep 20, 2020 at 10:27:44PM +0000, Gilles Peskine via mbed-tls wrote: > Hello, > > Historically, Mbed TLS has been maintained by Arm as an open-source > project, accepting external contributions, but with with priorities and > plans mostly driven only by Arm. Since earlier this year, Mbed TLS is an > open governance project under the umbrella of TrustedFirmware, with the > objective of making it a community led project, allowing community to > contribute and collaborate on the design and development of the project. > In practice, however, the project effectively still has some barriers of > entry. We would like to lift these barriers. > > The Mbed TLS team at Arm have already identified some concrete actions, > filed on the Mbed TLS epic board > https://github.com/ARMmbed/mbedtls/projects/2#column-10667107 > under “Facilitating community contributions”. A few more should be up > soon as the result of some internal brainstorming. > > We've also identified some problem areas which we're tracking as > separate topics. > > * Probably the biggest topic: review was and is a bottleneck. We are > working to streamline the review process where possible, without > lowering the quality bar, and to prioritize reviews better over new > work. (Having personally often been on both sides of the coin, I can > confirm that having a pull request sit around for years without getting > reviews is frustrating, and so is seeing all these pull request and not > having the time to review them all.) We would also like to enable, > encourage and value reviews from people who are not project maintainers. > > * We will migrate the CI to a publicly available platform hosted by > TrustedFirmware. However this platform will not be available until 2021. > > * We are working on a new documentation platform, where we'll transfer > both the information available on the current website and information > that is currently recorded in an Arm internal wiki. > > To all of you who have contributed to Mbed TLS, who have tried, or who > are considering it, what difficulties have you encountered? What else > can we do to make contributing easier? > > Best regards, > > -- > Gilles Peskine > Mbed TLS developer > > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls -- Frank Bergmann, Pödinghauser Str. 5, D-32051 Herford, Tel. +49-5221-9249753 SAP Hybris & Linux LPIC-3, E-Mail tx2014(a)tuxad.de, USt-IdNr DE237314606 http://tdyn.de/freel -- Redirect to profile at freelancermap http://www.gulp.de/freiberufler/2HNKY2YHW.html -- Profile at GULP

6 years, 1 month

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

mbed-tls