You have been invited to the following event.
Title: Mbed TLS Virtual Workshop
Hi,Trustedfirmware.org community project would like to invite you to the
Mbed TLS Virtual Workshop. The purpose of the workshop is to bring
together the Mbed TLS community including maintainers, contributors and
users to discussThe future direction of the project andWays to improve
community collaborationHere is the agenda for the workshop.Topic
Time (in GMT)Welcome
2.00 - 2.10pmConstant-time code
2.10
– 2.30pmProcesses - how does work get scheduled? 2.30 –
2.50pmPSA Crypto APIs
2.50 –
3.20pmPSA Crypto for Silicon Labs Wireless MCUs
- Why, What, Where and When 3.20 –
3.50pmBreak
Roadmap,
TLS1.3 Update
4.10
– 4.30pmMbed TLS 3.0 Plans, Scope
4.30 – 5.00pmHow do I contribute my first review
and be an effective Mbed TLS reviewer
5.00 – 5.30pmRegards,Don Harbin Trusted Firmware Community
Manager==============Zoom details below:====================Trusted
Firmware is inviting you to a scheduled Zoom meeting.Topic: Mbed TLS
Virtual WorkshopTime: Nov 3, 2020 02:00 PM Greenwich Mean TimeJoin Zoom
Meetinghttps://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT09Meeting
ID: 953 1520 0315Passcode: 143755One tap mobile+16699009128,,95315200315#
US (San Jose)+12532158782,,95315200315# US (Tacoma)Dial by your
location +1 669 900 9128 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston) +1 646 558 8656 US
(New York) +1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
888 788 0099 US Toll-free 877 853 5247 US
Toll-freeMeeting ID: 953 1520 0315Find your local number:
https://linaro-org.zoom.us/u/apL3hgti4
When: Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix
Where: Zoom:
https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…
Calendar: mbed-tls(a)lists.trustedfirmware.org
Who:
* Don Harbin - creator
* shebu.varghesekuriakose(a)arm.com
* mbed-tls(a)lists.trustedfirmware.org
* psa-crypto(a)lists.trustedfirmware.org
* dave.rodgman(a)arm.com
Event details:
https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
mbed-tls(a)lists.trustedfirmware.org because you are an attendee of this
event.
To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organizer and be added to the guest list, or invite others regardless
of their own invitation status, or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
Hi,
tls.mbed.org currently sends mixed signals regarding
the license of future MbedTLS releases.
Quoting https://tls.mbed.org/download:
| In packaged form, mbed TLS 2.1.0 to mbed TLS 2.16 are
| available in both an Apache 2.0 licensed version (our
| primary open source license) and in a GPL 2.0 licensed version.
|
| Newer versions will be available under the Apache 2.0 license.
Quoting https://tls.mbed.org/how-to-get:
| All the current versions of the mbed TLS library are distributed
| under the Apache 2.0 license and available from our Download area.
| In addition there are packaged versions of the mbed TLS library
| that are distributed with the GNU Public License Version 2.0 (GPL v2.0).
|
| The Apache-licensed and GPL-licensed versions of mbed TLS are
| identical in source code (with the exception of the license
| headers at the top of files).
|
| We plan to keep both licensed versions around.
Can anyone estimate when "newer releases" will no longer
be dual licensed?
We recently added MbedTLS support for Privoxy and a
MbedTLS license switch from dual license to Apache 2.0
complicates the license terms.
Thanks
Fabian
Hi Dave,
Thanks for your reply.
The particular reasons for bringing up 2.7 and 2.16 first is that my
employer is currently using 2.7 and would prefer using a small increment.
Having said that, if adding features to LTS is not advisable (especially
given that 2.7 has less than 6 months of projected life), I think I can
present the arguments against using the 2.7.
Additional consideration is the timing. My employer needs fragmentation
support as soon as possible, with the intent of running it on a desktop
environment. Historically, when the engineers are able to provide my
employer with what is needed now, they are allowed more time for
incremental improvements.
The third consideration involves the MPS project by Hanno Becker. I've been
collaborating with Hanno, and with Hannes Tschofenig and Thomas Fosetti on
the project of adding QUIC support to mbedTLS. This goal depends on TLS 1.3
support (Hannes has written a prototype, which I was able to add QUIC in an
internal version), and on MPS. I would like to avoid putting a duplicate
effort into non-MPS fragmentation support.
Unfortunately, if I want to meet the timing requirements of my employer, I
will not be able to use MPS, since it needs more maturing.
Because of the above considerations, I would like to suggest the following
plan of actions:
As the first step, I would like to add the MVP (minimal viable product)
fragmentation to the development version. The MVP takes the following
assumptions:
1. The RAM footprint is not a concern for the MVP (my employer is going
to run it in the desktop environment).
2. Unification of the fragmentation between TLS and DTLS is not a
concern for the MVP
3. LTS is not a concern for the MVP (potentially not at all)
Because of the above simplifying assumptions, I believe that the change can
be small and focused. I think I can have code ready for review in a couple
of weeks.
As the second step, I would like to put my effort into helping Hanno Becker
with his MPS system. Once sufficiently mature, the MPS will supersede the
MVP fragmentation, and will open the doors for adding support for QUIC. The
simplifying assumptions 1. (RAM) and 2. (TLS <=> DTLS) will be addressed by
MPS. Addressing the last assumption may not be required.
What are your thoughts?
On Wed, Oct 14, 2020 at 10:28 AM Dave Rodgman <dave.rodgman(a)arm.com> wrote:
> Hi Omer,
>
>
>
> Thanks for offering to help us with this feature.
>
>
>
> Normally, we wouldn’t add new features directly to an older branch, for a
> few reasons. 2.7 is quite old and is in fact only guaranteed to be
> supported until Feb 21, so it’s not the ideal place to spend effort on new
> features. Introducing new features here would also create the situation
> where 2.7 has features not in development, and vice-versa, creating an
> upgrade dilemma for users (unless we were to port the feature to all
> supported branches). And adding significant new features to LTS branches
> can always introduce some risk of destabilising it.
>
>
>
> So for these reasons, we would normally recommend targeting the
> development branch for new features (with backports only where there is a
> strong reason to do so), and then picking up the next stable release that
> contains the new feature.
>
>
>
> Is there a particular reason you’re focusing on 2.7, rather than
> development, or would it be viable for you to add this to development and
> pick up the next release?
>
>
>
> Thanks
>
>
>
> Dave
>
>
>
> *From: *mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf
> of Omer Shapira via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
> *Reply to: *Omer Shapira <omer.shapira(a)gmail.com>
> *Date: *Monday, 12 October 2020 at 20:04
> *To: *"mbed-tls(a)lists.trustedfirmware.org" <
> mbed-tls(a)lists.trustedfirmware.org>
> *Subject: *[mbed-tls] Working on TLS handshake record fragmentation
> (#1840)
>
>
>
> Hello,
>
> My employer (Facebook) is willing to give me some time to TLS handshake
> fragmentation support to MbedTLS 2.7 [0] . This would be my first
> contribution to MbedTLS, and I have several novice questions:
>
> 1. What is the best way to add the feature to MbedTLS 2.7?
> 2. Trade-off between the consistency of the fragmentation code across the
> branches, vs. the consistency of the branches.
>
>
> Question 1: Best way to add the feature to MbedTLS 2.7
>
> One constraint that I am facing is the code must be added to the upstream
> branch that is as close as possible to the 2.7.xx. My understanding of the
> Contribution Guidelines[1] is that while the LTS branches are mostly meant
> for the bug fixes, backporting of the new features is welcomed as long as
> the API/ABI compatibility is maintained and the disruption to the users is
> minimized.
>
> If adding support to the LTS branches is not advisable, are there any
> other possibilities of contributing the code to an upstream branch that is
> very close to the 2.7.xx?
>
> Question 2: Trade-off between the consistency of the fragmentation code
> across the branches, vs. the consistency of the branches.
>
> Assuming that adding features to 2.7 (and 2.16) *is* possible, there is a
> trade-off between the consistency of the fragmentation code across the
> branches, vs. the consistency of the branches. The `development` branch
> supports variable-length buffers[2] . Variable messages sizes would make
> the fragmentation easier in the development branch. In addition, there is
> the MPS effort by Hanno Becker which would make the fragmentation support
> even easier in the development branch. None of that is present in the 2.7
> or the 2.16 branches.
>
> What is the preferable trade-off in such a situation:
> a. Minimizing the change to the "host" version (2.7 or 2.16), on the
> expense the implementation of the feature differ between 2.7 and
> `development`, or
> b. Minimizing the differences in the implementation of the feature, on
> the expense of more intrusive changes to the earlier versions?
>
>
> [0] https://github.com/ARMmbed/mbedtls/issues/1840
> [1] https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md
> [2]
> https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.…
>
> --
>
> Sincerely Yours,
> Omer Shapira
>
--
Sincerely Yours,
Omer Shapira
--
Sincerely Yours,
Omer Shapira
Hi Omer,
Thanks for offering to help us with this feature.
Normally, we wouldn’t add new features directly to an older branch, for a few reasons. 2.7 is quite old and is in fact only guaranteed to be supported until Feb 21, so it’s not the ideal place to spend effort on new features. Introducing new features here would also create the situation where 2.7 has features not in development, and vice-versa, creating an upgrade dilemma for users (unless we were to port the feature to all supported branches). And adding significant new features to LTS branches can always introduce some risk of destabilising it.
So for these reasons, we would normally recommend targeting the development branch for new features (with backports only where there is a strong reason to do so), and then picking up the next stable release that contains the new feature.
Is there a particular reason you’re focusing on 2.7, rather than development, or would it be viable for you to add this to development and pick up the next release?
Thanks
Dave
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Omer Shapira via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Reply to: Omer Shapira <omer.shapira(a)gmail.com>
Date: Monday, 12 October 2020 at 20:04
To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] Working on TLS handshake record fragmentation (#1840)
Hello,
My employer (Facebook) is willing to give me some time to TLS handshake fragmentation support to MbedTLS 2.7 [0] . This would be my first contribution to MbedTLS, and I have several novice questions:
1. What is the best way to add the feature to MbedTLS 2.7?
2. Trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches.
Question 1: Best way to add the feature to MbedTLS 2.7
One constraint that I am facing is the code must be added to the upstream branch that is as close as possible to the 2.7.xx. My understanding of the Contribution Guidelines[1] is that while the LTS branches are mostly meant for the bug fixes, backporting of the new features is welcomed as long as the API/ABI compatibility is maintained and the disruption to the users is minimized.
If adding support to the LTS branches is not advisable, are there any other possibilities of contributing the code to an upstream branch that is very close to the 2.7.xx?
Question 2: Trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches.
Assuming that adding features to 2.7 (and 2.16) *is* possible, there is a trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches. The `development` branch supports variable-length buffers[2] . Variable messages sizes would make the fragmentation easier in the development branch. In addition, there is the MPS effort by Hanno Becker which would make the fragmentation support even easier in the development branch. None of that is present in the 2.7 or the 2.16 branches.
What is the preferable trade-off in such a situation:
a. Minimizing the change to the "host" version (2.7 or 2.16), on the expense the implementation of the feature differ between 2.7 and `development`, or
b. Minimizing the differences in the implementation of the feature, on the expense of more intrusive changes to the earlier versions?
[0] https://github.com/ARMmbed/mbedtls/issues/1840
[1] https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md
[2] https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.…
--
Sincerely Yours,
Omer Shapira
While waiting for opinions regarding the question of adding features to the
LTS versions, I have written a draft design doc.
I discussed the "design review process" with Hanno Becker, and we decided
to try and use GitHub for the design review.
I have created PR #3783 [0], which
includes `docs/proposed/hs_fragmentation.md` [1].
I will appreciate your comments, and will update the design doc following
the feedback.
Once there is clarity on the approach, I will proceed with the
implementation PRs.
[0] https://github.com/ARMmbed/mbedtls/pull/3783
[1]
https://github.com/ARMmbed/mbedtls/pull/3783/commits/8be34f22237ee3cd3c1db2…
On Mon, Oct 12, 2020 at 12:04 PM Omer Shapira via mbed-tls <
mbed-tls(a)lists.trustedfirmware.org> wrote:
> Hello,
>
> My employer (Facebook) is willing to give me some time to TLS handshake
> fragmentation support to MbedTLS 2.7 [0] . This would be my first
> contribution to MbedTLS, and I have several novice questions:
>
> 1. What is the best way to add the feature to MbedTLS 2.7?
> 2. Trade-off between the consistency of the fragmentation code across the
> branches, vs. the consistency of the branches.
>
> Question 1: Best way to add the feature to MbedTLS 2.7
>
> One constraint that I am facing is the code must be added to the upstream
> branch that is as close as possible to the 2.7.xx. My understanding of the
> Contribution Guidelines[1] is that while the LTS branches are mostly meant
> for the bug fixes, backporting of the new features is welcomed as long as
> the API/ABI compatibility is maintained and the disruption to the users is
> minimized.
>
> If adding support to the LTS branches is not advisable, are there any
> other possibilities of contributing the code to an upstream branch that is
> very close to the 2.7.xx?
>
> Question 2: Trade-off between the consistency of the fragmentation code
> across the branches, vs. the consistency of the branches.
>
> Assuming that adding features to 2.7 (and 2.16) *is* possible, there is a
> trade-off between the consistency of the fragmentation code across the
> branches, vs. the consistency of the branches. The `development` branch
> supports variable-length buffers[2] . Variable messages sizes would make
> the fragmentation easier in the development branch. In addition, there is
> the MPS effort by Hanno Becker which would make the fragmentation support
> even easier in the development branch. None of that is present in the 2.7
> or the 2.16 branches.
>
> What is the preferable trade-off in such a situation:
> a. Minimizing the change to the "host" version (2.7 or 2.16), on the
> expense the implementation of the feature differ between 2.7 and
> `development`, or
> b. Minimizing the differences in the implementation of the feature, on
> the expense of more intrusive changes to the earlier versions?
>
>
> [0] https://github.com/ARMmbed/mbedtls/issues/1840
> [1] https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md
> [2]
> https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.…
>
> --
> Sincerely Yours,
> Omer Shapira
> --
> mbed-tls mailing list
> mbed-tls(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
>
--
Sincerely Yours,
Omer Shapira
Hello,
My employer (Facebook) is willing to give me some time to TLS handshake
fragmentation support to MbedTLS 2.7 [0] . This would be my first
contribution to MbedTLS, and I have several novice questions:
1. What is the best way to add the feature to MbedTLS 2.7?
2. Trade-off between the consistency of the fragmentation code across the
branches, vs. the consistency of the branches.
Question 1: Best way to add the feature to MbedTLS 2.7
One constraint that I am facing is the code must be added to the upstream
branch that is as close as possible to the 2.7.xx. My understanding of the
Contribution Guidelines[1] is that while the LTS branches are mostly meant
for the bug fixes, backporting of the new features is welcomed as long as
the API/ABI compatibility is maintained and the disruption to the users is
minimized.
If adding support to the LTS branches is not advisable, are there any other
possibilities of contributing the code to an upstream branch that is very
close to the 2.7.xx?
Question 2: Trade-off between the consistency of the fragmentation code
across the branches, vs. the consistency of the branches.
Assuming that adding features to 2.7 (and 2.16) *is* possible, there is a
trade-off between the consistency of the fragmentation code across the
branches, vs. the consistency of the branches. The `development` branch
supports variable-length buffers[2] . Variable messages sizes would make
the fragmentation easier in the development branch. In addition, there is
the MPS effort by Hanno Becker which would make the fragmentation support
even easier in the development branch. None of that is present in the 2.7
or the 2.16 branches.
What is the preferable trade-off in such a situation:
a. Minimizing the change to the "host" version (2.7 or 2.16), on the
expense the implementation of the feature differ between 2.7 and
`development`, or
b. Minimizing the differences in the implementation of the feature, on the
expense of more intrusive changes to the earlier versions?
[0] https://github.com/ARMmbed/mbedtls/issues/1840
[1] https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md
[2]
https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.…
--
Sincerely Yours,
Omer Shapira
Hi All,
Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop on November 3rd (Tuesday) from 2pm to 6pm GMT.
The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss
* The future direction of the project and
* Ways to improve community collaboration
The workshop will be hosted in Zoom open to all. The invitation with the zoom link will be send in the Mbed TLS, PSA Crypto* mailing lists in the coming days.
Here are some of the proposed agenda topics. Please reply if there is anything else you would like us or you to present during the workshop that will be interesting to the community
* Constant-time code
* How to be an effective Mbed TLS reviewer
* Processes - how does work get scheduled?
* Roadmap, Mbed TLS3.0
* PSA Crypto APIs
* How Do I contribute my first review.
Thanks,
Shebu
(TrustedFirmware.org Co-Chair,
Mbed TLS Technology Manager)
* https://lists.trustedfirmware.org/mailman/listinfo/mbed-tlshttps://lists.trustedfirmware.org/mailman/listinfo/psa-crypto
Hi Innocenti,
The official list of defects is available on github:
https://github.com/ARMmbed/mbedtls/issues?q=is%3Aissue+is%3Aopen+label%3Abug
The revision of fixing is in the Bugfix sections of the ChangeLog file in the source. Eg. for the latest release:
https://github.com/ARMmbed/mbedtls/blob/mbedtls-2.24.0/ChangeLog
The entries here usually reference the issue number they fixed.
Is this something that you can use for your evaluation?
Regards,
Janos
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of "Innocenti, Michele via mbed-tls" <mbed-tls(a)lists.trustedfirmware.org>
Reply to: "Innocenti, Michele" <michele_innocenti(a)baxter.com>
Date: Thursday, 1 October 2020 at 14:04
To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] Official bug list
Hi,
We are evaluating Mbed TLS library and we need to know if it’s available an official list of defects and revision of fixing.
I’m not looking for CVEs but for bugs in the library.
Thanks!
Michele
Hi,
We are evaluating Mbed TLS library and we need to know if it's available an official list of defects and revision of fixing.
I'm not looking for CVEs but for bugs in the library.
Thanks!
Michele
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
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
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
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,
>
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
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
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
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
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
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
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
Good morning to all,
I am currently trying to perform RSA encryption, so I am using a file containing a public key (generated by OpenSSL) to do this.
So at the beginning I use the "mbedtls_pk_parse_keyfile" function to read it, as you can see on the image below. Unfortunately, I find the following error : ERROR 3E00 : Read/write of file failed.
Do someone have an idea of why I have this error ? Or should I change my way to read this file ?
Thanks a lot, have a nice Weekend
[cid:image002.png@01D68839.7B058100]
Hi,
Unrelated comment from my side, adding on to Manuel's comment:
It appears that ST supplies a binary blob which does make use of their
hardware crypto accelerator.
https://www.st.com/en/embedded-software/x-cube-cryptolib.html
Cheers,
Manu
On Wed, Sep 9, 2020 at 1:21 PM Manuel Pegourie-Gonnard via mbed-tls
<mbed-tls(a)lists.trustedfirmware.org> wrote:
>
> Hi,
>
> On those CPUs, the AES implementation in Mbed TLS is pure C, it doesn't use any hand-written assembly. The only platforms where it does so so far are x86-64 (to take advantage of the AES-NI extension if available), and some Via CPUs (x86) that have AES acceleration as well.
>
> Regards,
> Manuel.
> ________________________________
> From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Areeb Asad via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
> Sent: 09 September 2020 08:32
> To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
> Subject: [mbed-tls] Query related to ARM - MbedTLS
>
> Hi,
>
> I hope you are doing well. I am using the mbedTLS AES library in my projects, part of my master thesis at Uppsala University.
>
> I would like to know whether the mbedTLS AES library uses any assemble specific code for operations? I am using this library on Cortex-M23 and Cortex M0+.
>
> Looking forward to hearing from you.
>
>
> Best regards,
> Hafiz Areeb Asad
> --
> mbed-tls mailing list
> mbed-tls(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
Hi,
On those CPUs, the AES implementation in Mbed TLS is pure C, it doesn't use any hand-written assembly. The only platforms where it does so so far are x86-64 (to take advantage of the AES-NI extension if available), and some Via CPUs (x86) that have AES acceleration as well.
Regards,
Manuel.
________________________________
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Areeb Asad via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Sent: 09 September 2020 08:32
To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] Query related to ARM - MbedTLS
Hi,
I hope you are doing well. I am using the mbedTLS AES library in my projects, part of my master thesis at Uppsala University.
I would like to know whether the mbedTLS AES library uses any assemble specific code for operations? I am using this library on Cortex-M23 and Cortex M0+.
Looking forward to hearing from you.
Best regards,
Hafiz Areeb Asad
Hi,
I hope you are doing well. I am using the mbedTLS AES library in my
projects, part of my master thesis at Uppsala University.
I would like to know whether the mbedTLS AES library uses any assemble
specific code for operations? I am using this library on Cortex-M23 and
Cortex M0+.
Looking forward to hearing from you.
Best regards,
Hafiz Areeb Asad