TF-M Security Patch Release Process

Updated 903 Days AgoPublic

Actions

Following the discussion on the meeting I would update my comment:

1. ...
2. Suggest providing a fix to the last release only. That means if the current release is v1.3.0 then fix will create v1.3.1 in a new branch.

Here's the original proposal:

Security Vulnerabilities will be fixed as quickly as possible after discovery.

The fix will result in a patch release where the latest major or minor version is updated per Semantic versioning. For example, if a bug is found in v3.1.0, the fix will result in a v3.1.1 patch release.
The fix will also be applied to any LTS branches. So for example, if there is a v2.0.0 LTS version, it will be upgrade to v2.0.1 with the patch.

All released patch versions will be fully regression tested including new test(s) to cover the vulnerability.

TrustedFirmware.org will not release vulnerability code fixes on their own. Fixes will only be released as a complete TF-M package.

Note: Separate but related to this proposal, TF-M needs to have a formalized LTS process and standard.

Here's the proposal with feedback, added inline and discussed in 5/20/21 TSC:

Security Vulnerabilities will be fixed as quickly as possible after discovery.
The fix will result in a patch release where the latest major or minor version is updated per Semantic versioning. For example, if a bug is found in v3.1.0, the fix will result in a v3.1.1 patch release.

Dan Handley: I think we should specifically say the latest vulnerable release. The latest release may already contain the fix (as was the case recently).
DH: Also, I would avoid the reference to semantic versioning since TF-M does not in general use semantic versioning for major/minor releases.
Dave Cocca: TF-M Release Cadence and Process mentions “Trusted Firmware-M uses a semantic versioning scheme.”
https://ci-builds.trustedfirmware.org/static-files/TZFdL484qZZgYcbWIGLS09zbtYWlsNtB4w34XlUj6OUxNjIxNTIzMzczMzM5Ojk6YW5vbnltb3VzOmpvYi90Zi1tLWJ1aWxkLWRvY3MtbmlnaHRseS9sYXN0U3RhYmxlQnVpbGQvYXJ0aWZhY3Q=/trusted-firmware-m/build/docs/user_guide/html/docs/releases/release_process.html#release-cadence-and-process

The fix will also be applied to any LTS branches. So for example, if there is a v2.0.0 LTS version, it will be upgrade to v2.0.1 with the patch.

Joakim Bech: As such I have no concerns patching LTS. I think we debated how far back in history we will patch LTS branches. Should we propose a number? If TF members could give a hint on how "old" versions they are using, then that might give us the answer? At least a starting point.
DH: I don't see that we need to say anything specific about how far back or how many versions number we patch. The LTS policy will specify a lifetime for each LTS branch and we should patch throughout that LTS's lifetime.

All released patch versions will be fully regression tested including new test(s) to cover the vulnerability.

JB: +1
DH: I think in the TSC meeting we said that regression testing would only cover normal CI testing, not all testing associated with making a release. Also, adding new test(s) to cover the vulnerability may not be practical if there is no known exploit or the granularity of the test framework is not sufficient. Perhaps just say "where possible"?
DC: Agree with “where possible”.
What’s the diff between “normal CI testing” and “testing assoc w/ making a release”? Normal CI testing seems OK at least as a starting point.

TrustedFirmware.org will not release vulnerability code fixes on their own. Fixes will only be released as a complete TF-M package.

JB: So instead of sending a set of separate *.patch files for the fixes, we should deliver either a branch or a tag in a Git (shared privately to the trusted stakeholders)? I think that should work. Individual patches are easy to send as attachments via email, but it can become a bit of a challenge to keep track of them when you start sending out fixes to the patches themselves (i.e., patch version > v1). In those cases it's probably easier to just hand out a branch or tag in a private tree.
DH: +1
JB: What options do we have when it comes to sharing branches and tags with stakeholders? I'm currently moving other all security advisories from op-tee.org to instead leverage the security incident reporting at GitHub (under the OP-TEE project). GitHub has the ability to invite people to collaborate and see patches in the works. In TF, all sub-projects have different ways of working with git-trees. So, I'd like to understand if we have the same possibilities for TF-M and others. Having said that, I don't think GitHub is a silverbullet solution either, since I don't believe their security incident feature is created as "security disclosure" with large groups. I think their take on this right now is more collaboration on mitigation fixes with a small group of developers.
DH: I agree that GitHub Security Advisories is not going to work for all projects. But using a known tag format should be applicable across projects.

Note: Separate but related to this proposal, TF-M needs to have a formalized LTS process and standard.

JB: Agree (and probably not only TF-M).

Anton Komlev Reply:
Please find below the view from TF-M perspective :

1. The discussed ideas fits well to the project needs and goals: each fix will increment the hot fix number in TF-M version. (see TF-M Release Cadence and Process)
2. Suggest to update the current and previous releases only. That means if the current release is v1.3.0: a. a new fix makes v1.3.1 and 1.2.x+1 b. releasing v1.4.0 deprecates v1.2.x. This makes TF-M LTSes 8 months life time.
3. Ignore the past releases first time starting the process. (TF-M special case: missing patch in the previous release)
4. Test scope: If a fix is a platform independent then regression suit on a default platform is enough: an521 at the moment.

end

You frequently experience this issue when installing programs mapquest directions on a PC. To prevent the error, you must upgrade the system to a newer version.

You will need to update the system to a more recent version in order to eliminate the problem. basketball stars

fantastic publish i ought to mention and thank you for the data. Education is in truth a sticky difficulty. But, remains the diverse fundamental subjects of our time. I respect your submission and sit up for extra. i am for the primary time right here. I found this board and pay to write my assignment that I in locating it clearly beneficial & it helped me out masses. I'm hoping to offer some components again

Best process thank you for helping many people this is great. Fashion is the most important in our life so upgrade your fashion with this The Today Show Brendon Urie Colorblock Blazer and enjoy the day with your friends.

you have published a very validate process. therefor many people benefit this processing. now a day people has become trend of fashion. and everyone wants to update your fashion ideas and the latest fashion is And Just Like That Season 2 Carrie Bradshaw Plaid Coat.

I'm always excited to read your new posts. They never disappoint. Sex Education Season 4 Otis Jacket

I appreciate reading this blog it is full of knowledge and informative content good work keep it up faux leather aviator jacket womens

It is such an interesting and informative post, thank you for sharing the post
https://www.celebsmoviejackets.com/black-label-society-vest

In the other hand, if you stick with them in a deceptive way, you will be misled. Blow for blow only. Recall that for acceptable prosperity but also profitable affiliation, not literally incredible sustenance is needed. Call Girl in Delhi should pass on what specifications really are, they make you find your way.

Nice article shared you are its very informative and useful for us thanks. you should avail this Purple Leather Jackets from our online shop. thanks

Lerenjack gets your hands on the most exclusive piece by Movie Jackets, and Leather Jackets Apparel with an amazing discount. Cafe Racer Jacket