Hi
I'd like to discuss the tooling at TrustedFirmware.org (i.e. Cgit, Gerrit, Phabricator) to understand the rationale for the current toolset, what alternatives were considered/discounted and what future tools/enhancements could potentially help us. I expect any proposed changes will require much deeper analysis/discussion but it would be good to have an initial baseline discussion.
Regards
Dan.
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Abhishek Pandit via TSC
Sent: 18 March 2020 17:13
To: tsc(a)lists.trustedfirmware.org
Subject: [TF-TSC] TSC Agenda 19 Mar 2020
Hi All,
Any agenda items for the TSC meeting this week?
TF-A & TF-M team have been working on defining a clear maintenance process. The initial draft has been uploaded for review -
https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…
We can have a quick overview in the meeting.
Thanks,
Abhishek
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.
Hi Abhishek,
I also propose we come back on the emails exchanged on the TSC mailing list concerning the on the Security incident handling process
Regards,
Eric Finco
[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: logo_big5]
Eric FINCO | Tel: +33 (0)2 4402 7154
MDG | Technical Specialist
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Abhishek Pandit via TSC
Sent: mercredi 18 mars 2020 18:13
To: tsc(a)lists.trustedfirmware.org
Subject: [TF-TSC] TSC Agenda 19 Mar 2020
Hi All,
Any agenda items for the TSC meeting this week?
TF-A & TF-M team have been working on defining a clear maintenance process. The initial draft has been uploaded for review -
https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…
We can have a quick overview in the meeting.
Thanks,
Abhishek
Hi All,
Any agenda items for the TSC meeting this week?
TF-A & TF-M team have been working on defining a clear maintenance process. The initial draft has been uploaded for review -
https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…
We can have a quick overview in the meeting.
Thanks,
Abhishek
Hi Dan, all,
I've read the updated version(s), I'm happy with them as they are written
here in the 0.5 version (that implies that Linaro is happy with them).
External process:
- It'd be nice at some point to complement the text with a graphical
timeline showing the boundaries at each step.
Internal process:
- CVSSv3 or something else to identify the severity? I know OP-TEE isn't
using CVSSv3. I'd be happy to change OP-TEE to align with other TF projects.
- Regarding people on op-tee-security(a)trustedfirmware.org, for now I think
it's sufficient to have Jens + the global address (
security(a)trustedfirmware.org).
Maniphest:
- I have no experience, but that'll probably get the job done as any other
tools would have done.
Regards,
Joakim
On Wed, 19 Feb 2020 at 19:00, Dan Handley via TSC <
tsc(a)lists.trustedfirmware.org> wrote:
> Hi TF TSC
>
>
>
> This is a v0.5 update to the proposed tf.org security incident handling
> process, which I sent previously.
>
>
>
> Changes:
>
> * Expanded the Trusted Stakeholder embargo request period to 3 working
> days (in their timezone).
>
> * Expanded the ESS definition to include suppliers to ESSes (e.g. distros).
>
> * Allowed projects to optionally use severity scoring (CVSSv3 preferred
> but not mandated).
>
> * Allowed for flexibility in disclosure plan to accommodate reporter's
> disclosure plan.
>
> * Allowed for the fact that some projects cannot deliver vulnerability
> fixes to a restricted audience for export control reasons.
>
>
>
> I've also included an internal facing process for the first time, mainly
> aimed at members of the security team(s) so they know how to execute the
> process.
>
>
>
> I propose the next steps are:
>
> * Discuss the latest changes in the 20th Feb TSC meeting.
>
> * Set a date for approval of the external process (e.g. mid-March).
>
> * Identify the right people to be on the security teams.
>
> * Work with tf.org infra people and each project's security teams to
> propose a plan for when this process can be made active. Should we try to
> make this active for all projects at the same time or as each project is
> ready?
>
>
>
> Regards
>
>
>
> Dan.
>
>
> 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.
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
Hi Dan and all,
We have had an ST internal review of the processes (internal and external)
I did not hear any significant remarks from my colleagues on the processes themselves but one question related to the implementation of the processes:
Obviously, any suspected security flaw can be reported to the TF security team using the dedicated email defined. However, can we have (for information only ) a view on the class of vulnerability the security team will handle ? For instance will they analyze and look for a fix to side channel attack or even hardware attack ?
Regards,
Eric Finco
[Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: logo_big5]
Eric FINCO | Tel: +33 (0)2 4402 7154
MDG | Technical Specialist
From: TSC <tsc-bounces(a)lists.trustedfirmware.org> On Behalf Of Joakim Bech via TSC
Sent: lundi 2 mars 2020 14:52
To: Dan Handley <Dan.Handley(a)arm.com>
Cc: tsc(a)lists.trustedfirmware.org
Subject: Re: [TF-TSC] Proposed tf.org security incident handling process (v0.5)
Hi Dan, all,
I've read the updated version(s), I'm happy with them as they are written here in the 0.5 version (that implies that Linaro is happy with them).
External process:
- It'd be nice at some point to complement the text with a graphical timeline showing the boundaries at each step.
Internal process:
- CVSSv3 or something else to identify the severity? I know OP-TEE isn't using CVSSv3. I'd be happy to change OP-TEE to align with other TF projects.
- Regarding people on op-tee-security(a)trustedfirmware.org<mailto:op-tee-security@trustedfirmware.org>, for now I think it's sufficient to have Jens + the global address (security(a)trustedfirmware.org<mailto:security@trustedfirmware.org>).
Maniphest:
- I have no experience, but that'll probably get the job done as any other tools would have done.
Regards,
Joakim
On Wed, 19 Feb 2020 at 19:00, Dan Handley via TSC <tsc(a)lists.trustedfirmware.org<mailto:tsc@lists.trustedfirmware.org>> wrote:
Hi TF TSC
This is a v0.5 update to the proposed tf.org<http://tf.org> security incident handling process, which I sent previously.
Changes:
* Expanded the Trusted Stakeholder embargo request period to 3 working days (in their timezone).
* Expanded the ESS definition to include suppliers to ESSes (e.g. distros).
* Allowed projects to optionally use severity scoring (CVSSv3 preferred but not mandated).
* Allowed for flexibility in disclosure plan to accommodate reporter's disclosure plan.
* Allowed for the fact that some projects cannot deliver vulnerability fixes to a restricted audience for export control reasons.
I've also included an internal facing process for the first time, mainly aimed at members of the security team(s) so they know how to execute the process.
I propose the next steps are:
* Discuss the latest changes in the 20th Feb TSC meeting.
* Set a date for approval of the external process (e.g. mid-March).
* Identify the right people to be on the security teams.
* Work with tf.org<http://tf.org> infra people and each project's security teams to propose a plan for when this process can be made active. Should we try to make this active for all projects at the same time or as each project is ready?
Regards
Dan.
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.
--
TSC mailing list
TSC(a)lists.trustedfirmware.org<mailto:TSC@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tsc
Hi all,
The Trusted Firmware TSC has undertaken to review the TrustedFirmware.org
website and propose changes. Some TF website review headings and criteria
are listed in a wiki document we've created to capture review comments.
Please edit this document to add review inputs.
https://developer.trustedfirmware.org/w/collaboration/website/
It would be helpful if you could add your initials to contributions.
Version history is also tracked.
Best regards
Bill
--
[image: Linaro] <http://www.linaro.org/>
*Bill Fletcher* | *Field Engineering*
T: +44 7833 498336 <+44+7833+498336>
bill.fletcher(a)linaro.org | Skype: billfletcher2020
Attendees
Abhishek Pandit (Arm)
Dan Handley (Arm)
Kevin Townsend (Linaro)
Joakim Bech (Linaro)
Christian Daudt (Cypress)
Eric Finco (ST)
Mark Grosen (TI)
Bill Mills (TI)
Bill Fletcher (Linaro Community Projects)
Minutes
DH: Security handling process. Projects to be incorporated have different
ways to handle security … Kernel has an upstream/early approach to get
thefix in. In Mbed TLS etc work very closely with crypto researchers to
disclose at the same time. Not sure if the latest wording is enough to
satisfy them. Flexibility - if the reporter has a different plan. Maybe
holding back the fix until you make the disclosure. Skilled researcher
could reverse engineer the fix. Also an export control issue. Can’t release
fixes to a restricted audience and keep waiver from EAR. Will send an
update soon. Try to agree a date for approval - mid March? Then see when we
could make it active after approval. Are we trying to make it active for
all projects at the same time?
AP: Wording looked ok for me e.g. for export restrictions. Currently our
TSC list is closed. Think we should open it. Any objection to opening
minutes on a public page?
EF: If we open it, will allow anyone to review the security document?
AP: To be able to point people showing we have an ongoing process. How to
track that everyone has agreed?
DH: On a project-by-project basis. Expand to everyone on the security team.
Give a plan for when it might happen that they adopt it.
AP: Create a quick form for everyone to check.
DH: Suggest a separate meeting with those people on the details. Proposed
some next steps in the email. Will try to drive things forward.
AP: Suggest you and Joakim come up with a deadline to review/agree.
DH: Could go for a final approval but want to avoid someone vetoing at a
late stage.
JB: From Linaro point-of-view we’re ok with it.
DH: Action: will send a reply to mail to say like to know that approval is
acceptable to everyone. Will then ask for final approval on the text of the
process.
AP: Visibility of TSC Minutes. Should we open the mailing list archives to
be public without logging in?
CD: In principle OK. Trying to think of instances where we might not want
everything public.
BF: Mailing list archives are open to all members of the list and the list
is open to anyone who wants to subscribe.
AP: Action: will send a yes/no vote mail to see if people are ok to open
the archive.
KT: Provisioning. No feedback responses on certificate chains
https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md
David has been thinking more about factory provisioning. Early vs late
bindings. I replied to thread with Jamie identified some issues for late
bindings where need to store in secure storage. Definitely some overlap.
Some feedback would be nice.
EF: Can’t disconnect from real world product implementation. People have
questions about if it is ‘affordable’ on an MCU product. Something that is
being targetted for implementation outside of TF-M.
KT: A lot of functionality already exists. Not supporting certificate chain
today. In order to work with a certificate chain there are some missing
pieces. Need to generate cert signing request on TF-M side. Has to happen
on secure processing side. Need to expose this functionality in the PSA API.
EF: Usecase understood. Initial feedback - purpose understood. Based on
this response will ask for a more in-depth opinion.
KT: Looks like extra 25-30kbytes of Flash.
JB: Did you look into the PSA specification for this?
KT: Email from Jamie wasn’t on our radar.
JB: Seems Arm is pushing various documents into PSA. Maybe the way to go to
get it aligned with PSA.
AP: Leave this to next TSC meeting - too early to set a deadline.
AP: Coding standards. Divided into which standards we target and also
identify a few experienced team members who can make decisions. Would like
to put a deadline on this for next TSC and will send out a follow up for
‘enforcers’.
MG: Where do we want the codebase to go from a standards point of view? In
the automotive space - MISRA - do we care about that?
AP: How to take this forward - form a breakaway group for people who are
interested?
MG: TI definitely interested in having a codebase we could certify to e.g.
ISO26262. Need to decide which ones.
JB: For all the projects - do we need to specify which projects will
follow which conventions.
CD: Don’t think can have an overarching one over all projects.
AP: TF-M could just do with something set up now to aim for something in a
year’s time. Answer doesn’t seem to be coming in this call. Need a
breakaway group.
CD: Acceptable. Think starting point could be TF-A and OP-TEE as a
baseline.
Action: Christian will send out an email with a date for a meeting
AP: Also platform folders have different coding standards. Think this needs
specifying.
JB: I was asked about FIPS certification - has anyone had a request?
DH: Have never accepted this as a requirement to the project.
AP: Platform maintainers and core maintainers. Platform - desire is to make
it easier. Core maintainers - are open to adding more. Not pushing, but
openness is there.
AP: Website review. Had initial discussion last time around. Haven’t seen
any response.
Action: Will work with Bill to produce a document. Then people can go and
add comments.
KT: Agree to create a shared document. Need somewhere to post images
BF: Could either be Googledoc or on Phabricator wiki.
AOB
BF: Private workflow on Maniphest raised by Dan?
DH: Commenting now. Will follow up on return.
--
[image: Linaro] <http://www.linaro.org/>
*Bill Fletcher* | *Field Engineering*
T: +44 7833 498336 <+44+7833+498336>
bill.fletcher(a)linaro.org | Skype: billfletcher2020
Hi TF TSC
This is a v0.5 update to the proposed tf.org security incident handling process, which I sent previously.
Changes:
* Expanded the Trusted Stakeholder embargo request period to 3 working days (in their timezone).
* Expanded the ESS definition to include suppliers to ESSes (e.g. distros).
* Allowed projects to optionally use severity scoring (CVSSv3 preferred but not mandated).
* Allowed for flexibility in disclosure plan to accommodate reporter's disclosure plan.
* Allowed for the fact that some projects cannot deliver vulnerability fixes to a restricted audience for export control reasons.
I've also included an internal facing process for the first time, mainly aimed at members of the security team(s) so they know how to execute the process.
I propose the next steps are:
* Discuss the latest changes in the 20th Feb TSC meeting.
* Set a date for approval of the external process (e.g. mid-March).
* Identify the right people to be on the security teams.
* Work with tf.org infra people and each project's security teams to propose a plan for when this process can be made active. Should we try to make this active for all projects at the same time or as each project is ready?
Regards
Dan.
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.
Hi All,
Any agenda items for the TSC meeting this week?
There are some ongoing discussions from previous meetings which we can cover anyway.
Thanks,
Abhishek
Hi All,
In previous TSC meeting, we discussed the topic of reviewing the trustedfirmware.org website in terms of contents and structure. You can find some of the comments in the TSC meeting minutes. I took an action to kick off an email thread so that we can capture all the inputs in one place.
Can you please reply to this thread if you have any improvements suggestions?
Thanks,
Abhishek
