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@lists.trustedfirmware.org on behalf of Omer Shapira via mbed-tls mbed-tls@lists.trustedfirmware.org Reply to: Omer Shapira omer.shapira@gmail.com Date: Monday, 12 October 2020 at 20:04 To: "mbed-tls@lists.trustedfirmware.org" mbed-tls@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.h... -- Sincerely Yours, Omer Shapira