Hi All,
We didn't get to discuss the next meeting slot in our previous meeting but I would like to suggest Thursday 16th May 16:00 UK time. Hope that works.
>From June onwards, we can setup a regular call e.g. on every 2nd Thursday of the month. Let's discuss and finalize in the next call.
Any Agenda items that you would like to add for next meeting?
Thanks,
Abhishek
Hi Paul, all,
I think this is a good proposal. As a side note, we've just completed that
exercise for the OP-TEE project [1] and in general it seems like most
people appreciate the change. One thing where our process differs compared
to what you've proposed is that we are still using GitHub for everything
and that is connected directly to https://readthedocs.io using webhooks,
which has the nifty feature that as soon as a patch (pull request) has been
merged at GitHub, readthedocs will automatically be notified (webhooks) and
will immediately rebuild the documentation and publish it. I.e., we always
have the latest version available and published and there is no extra cost
involved in manually having to deploy the "_build/*" stuff. I'm not sure if
that is doable with existing TF infrastructure, but I think it's worth
investigating whether someone like that is possible to do, since it saves
us from doing "unnecessary" work.
[1] https://optee.readthedocs.io/ and https://github.com/OP-TEE/optee_docs/
Regards,
Joakim
On Tue, 30 Apr 2019 at 11:18, Paul Beesley via TSC <
tsc(a)lists.trustedfirmware.org> wrote:
> Hi all,
>
>
>
> Please find attached a set of slides detailing proposed formats and
> processes for TF-M documentation; these proposals cover both existing
> documentation and documents produced for the purpose of design review.
> Abhishek previously presented a version of these slides to the TSC and we
> are now circulating them via the mailing list.
>
>
>
> Though it is not explicitly mentioned in the slides, we will look to
> implement similar changes in Trusted Firmware-A as well, aligning the two
> projects where possible.
>
>
>
> As always, comments and feedback on these proposed changes are welcome.
>
>
>
> Thanks,
>
> Paul
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
Hi all,
Please find attached a set of slides detailing proposed formats and processes for TF-M documentation; these proposals cover both existing documentation and documents produced for the purpose of design review. Abhishek previously presented a version of these slides to the TSC and we are now circulating them via the mailing list.
Though it is not explicitly mentioned in the slides, we will look to implement similar changes in Trusted Firmware-A as well, aligning the two projects where possible.
As always, comments and feedback on these proposed changes are welcome.
Thanks,
Paul
Attendees
Abhishek - Arm
Kumar - Linaro
MarkG - TI
RemiD - Linaro
DaveP - Linaro
Eric - ST
MatteoC - Arm
ShebuK - Arm
BillM - TI
Christian -Cypress
DonH - Linaro
SobyM - Arm
Joakim - Linaro
DavidB - Linaro
BillF - Linaro Community Projects
Pending action items
CI discussion - slides circulated
Security incident handling - postponed as DanH cannot attend
Notes
Won’t use TSC-private mailing list any more (will be reactivated if needed)
Attestation script home - Arm team will upstream initial patch.
Dean to send test cases running on MPS2. Dean is going to do some
deployment today (or ASAP). Follow up with Christian if nothing comes from
Dean
Proposal from documentation - Abhishek to send out initial proposal. Will
be circulated after Connect.
TF-A Roadmap
JB: Will the roadmap be circulated publicly?
MC: Would make sense to circulate a version publicly. For now this is the
Arm roadmap. Would be a combination of contributions from project, other
parties and infrastructure plans from Arm. Don’t know if advance which
platforms are coming in from Partners
JB: Not exactly clear what should publish. Maybe some kind of lightweight
roadmap.
SK: Have always published cut down version in TF-M dashboard.
(MC shows slides from monthly report on tf.org)
(MC shows “Trusted Firmware-A Evolution” #5 slide - this slide will be
circulated afterwards). Data is public so follow-up discussions can happen
on a public list.
Arm & Google discussing to have Hafnium as secure EL2 firmware
EF: Any assumption in terms of architecture?
MC: v8 systems 32 & 64 bit. Not maintaining v7 TF.
MC: Code is moving from GitHub to tf.org git/gerrit
JB: Functional safety (2020?)
MC: Good topic for TF. Happy to have a discussion on MISRA-C etc. Can’t
certify with Arm toolchain linker. Partners need to do own platform port.
(SV shows “TF-M v1.0-Beta @ Embedded World’19” - slide, backlog & Roadmap)
SV: All work items public under Phabricator. Have 4 engineers working under
tf.org.
AP: Platform support? Worth to have something along with the roadmap to
show which platforms are planned to be upstream.
CD: List of platforms that will be supported? All for that.
EF: We can create ticket when we work on an upstream platform. Would be
easier than putting this in a public roadmap. Should discuss what are the
coding rules and what we plan to put in /platform/x/target (?). Action Eric
to make a proposal on upstream platforms & tickets
AP: Stay away from complete freedom to put code conforming to any code
convention in one of the directories.
KG: Anyone looking at infrastructure for the project? MISRA, Coverity?
(question open)
LAVA topic
(slides LAVA Remote Labs - previously shared)
CD: raised question about having local master to help admin overhead.
RD: Linaro believes that it’s better to have from local IT point of view to
have single master. Currently lava has either admin or submitter. Linaro
working on adding mid-level. It’s a shared master with multiple admins.
CD: Already have lava setup internally (with local master?)
DP: Remote worker model is not necessarily for everyone.
CD: Less shared management is a good proposition if you don’t have already
that in place.
DP: Provided further input on this.
KG: How the hardware is done has impact on adding something in the CI loop
Original use case is companies wanting to put device in LAVA without
shipping device to a central lab. Different model for sharing open CI with
all projects vs making it easier within the companies.
After some further discussion we decided to put a pin on this for
discussing offline.
--
EMEA Field Engineering
Linaro Ltd
Harston Mill CB22 7GG
Cambridge UK
+44 7833 498336 <+44%207833%20498336>
LAVA Remote Labs slides
Best regards
Bill
On Wed, 3 Apr 2019 at 08:42, Bill Fletcher via TSC <
tsc(a)lists.trustedfirmware.org> wrote:
> As part of the action on CI infrastructure I have the action to describing
> a proposal for a distributed CI instance called Remote Labs.
>
> Regards
>
> Bill
>
> On Wed, 3 Apr 2019 at 08:05, Abhishek Pandit via TSC <
> tsc(a)lists.trustedfirmware.org> wrote:
>
> > Hi All,
> >
> > Any agenda items for this week's TSC meeting?
> >
> > Currently this is what I have for the agenda:
> >
> >
> > * Pending action items
> > * Major roadmap items for the next quarter
> > * Next meeting
> >
> > Thanks
> > Abhishek
> >
> > --
> > TSC mailing list
> > TSC(a)lists.trustedfirmware.org
> > https://lists.trustedfirmware.org/mailman/listinfo/tsc
> >
>
>
> --
>
>
> EMEA Field Engineering
> Linaro Ltd
> Harston Mill CB22 7GG
> Cambridge UK
> +44 7833 498336 <+44%207833%20498336>
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
--
EMEA Field Engineering
Linaro Ltd
Harston Mill CB22 7GG
Cambridge UK
+44 7833 498336 <+44%207833%20498336>
On Thu, Apr 04, 2019 at 02:44:35PM +0000, Dan Handley via TSC wrote:
>If you think you have found a security vulnerability, then please send an email
>to the Trusted Firmware security team at <[1]security(a)trusted-firmware.org>.
>This is a private team of security officers who will help verify the security
>vulnerability, develop and release a fix, and disclose the vulnerability
>details responsibly. Please give us time to implement the disclosure plan
>described in the next section before going public. We do our best to respond
>and fix any issues quickly.
I realize that the Linux docs don't mention encryption here, but there
will probably be some reporters that will want to send encrypted
email. It might be a good idea to have a few people on this list that
have well-known PGP keys, and can respond to those people with what
key to send a sensitive report to.
David
Hi TF TSC
This is write up of the proposed tf.org security incident handling process, which is one of my actions from the last TSC. I wanted to circulate this before Friday's TSC meeting. I know there's not much time for you to review before then but perhaps you can have some initial discussion (without me) and we can go into more detail at the next TSC?
I've included some comment/rationale in square brackets to aid discussion. All comments welcome.
Regards
Dan.
----
This security incident handling process proposal is broadly based on the kernel process [1], with influence from the existing TF-A [2] and OP-TEE [3] processes.
Reporting
=========
If you think you have found a security vulnerability, then please send an email to the Trusted Firmware security team at <security(a)trusted-firmware.org<mailto:security@trusted-firmware.org>>. This is a private team of security officers who will help verify the security vulnerability, develop and release a fix, and disclose the vulnerability details responsibly. Please give us time to implement the disclosure plan described in the next section before going public. We do our best to respond and fix any issues quickly.
[DH: Note security(a)kernel.org<mailto:security@kernel.org> is exclusively about fixing the vulnerability; disclosure is delegated to linux-distros(a)vs.openwall.org<mailto:linux-distros@vs.openwall.org> [4]. This proposal combines these activities.]
As with any bug, the more information you provide, the easier it is to diagnose and fix. If you already have a fix, please include it with your report, as that can speed up the process considerably. Any exploit code is very helpful. The security team may bring in extra help from area maintainers to understand and fix the vulnerability. The security team may share any information you provide with trusted third parties and eventually the public unless you request otherwise.
[DH: Note, security(a)kernel.org<mailto:security@kernel.org> provides stronger confidentiality guarantees because it is only interested in fixes, not disclosure. In practice, I'd expect members of the security team to be sensitive with confidential information as with any other open source interactions, and to get explicit approval from the reporter for disclosure of sensitive information, e.g. identity, organization, product information,...]
If the security team consider the bug not to be a security vulnerability, you will be informed and the bug directed to the standard bug fixing process.
[DH: Do we need to indicate target reporter response times? TF-A has an internal target of 1 day for an initial response and 1 week for a considered response. Other processes (including TF-A) do not specify a target here. Perhaps one can assume it will always be ASAP?]
Disclosure
==========
The general security vulnerability disclosure plan is as follows:
1. For confirmed security vulnerabilities, develop a robust fix as soon as possible. During this time, information is only shared with the reporter, those needed to develop the fix and Especially Sensitive Stakeholders (ESSes), in particular organizations with large scale deployments of Trusted Firmware providing bare-metal access on multi-tenancy systems.
2. After a robust fix becomes available, our preference is to publicly release it as soon as possible. This will automatically happen if the vulnerability is already publicly known. However, release may be deferred if the reporter or an ESS requests it within 1 calendar day of the fix becoming available, and the security team agree the criticality of the vulnerability requires more time. The requested deferral period should be as short as possible and no more than 14 calendar days after the fix becomes available. The only valid reason for this release deferral is to accommodate deployment of the fix by ESSs. If it is immediately clear that ESSes are unaffected by the vulnerability then this stage is skipped. This 0-14 day deferral is the primary embargo period.
[DH: Note, this stage is only relevant for TF-A currently.]
[DH: I removed the nuance between 7 and 14 days used in the kernel process. I don't think it essentially changes the process.]
[DH: Note, this assumes that ESS security teams operate 7 days a week.]
3. After the primary embargo period, the fix and relevant vulnerability information are shared with registered Trusted Stakeholders (see below section). Fix release may be deferred further if a Trusted Stakeholder requests it within 1 working day (Monday to Friday) of being notified, and the security team agree the criticality of the vulnerability requires more time. The requested deferral period should be as short as possible and no more than 14 calendar days after the Trusted Stakeholder receives it. The only valid reason for this further release deferral is to accommodate deployment of the fix by a Trusted Stakeholder. This further 1-14 day deferral is the secondary embargo period.
Note, security fixes contain the minimum information required to fix the bug. The accompanying vulnerability details are disclosed later.
[DH: Note, I've slightly relaxed the Trusted Stakeholder required response time to 1 working day, as oppose to 1 calendar day. Is this reasonable?]
[DH: Note, this aggressive release of security fixes is aligned with the kernel process. The existing TF-A process allows for early release of fixes, which we generally do in practice, but that process doesn't really specify a fix embargo period. However it does specify a 4 week embargo on the subsequent security advisory. Also note that OP-TEE's fix embargo period is 90 days, which is aligned with Google's policy.]
4. After the fix is released, details of the security vulnerability are consolidated into a security advisory. This includes a CVE number and the security team will request one if not already done by the reporter. It also includes credit to the reporter unless they indicate otherwise. Drafts of the security advisory are circulated with the reporter, ESSes and Trusted Stakeholders as they become available.
[DH: Note, the existing TF-A process only shares information with Trusted Stakeholders in the form of security advisories. This proposal is more aligned with the kernel process and means we can focus on fix development by sharing raw vulnerability information in the early stages.]
5. 90 days after the vulnerability was reported, the security advisory is made public on https://www.trustedfirmware.org/. This 90 day window is the public embargo period.
[DH: This public embargo period aligns with Google and OP-TEE processes, although this proposal releases fixes earlier.]
In exceptional cases, the above disclosure plan may be extended in consultation with the reporter, ESSes and Trusted Stakeholders, for example if it is very difficult to develop or deploy a fix, or wider industry consultation is needed.
[DH: I'm accommodating for the Spectre/Meltdown case here, but does this encourage Trusted Stakeholders to invoke "exceptional cases" casually?]
Handling embargoed information
==============================
On receipt of embargoed information, you must not disclose any of the provided information beyond the group of people in your organization that need to know about it. During the primary and secondary embargo periods, that group of people should be limited to those entrusted to assess the impact of the vulnerability on your organization and deploy fixes to your products. After the secondary embargo period but during the public embargo period, that group of people may be expanded in order to prepare your organization's public response. The embargoed information must not be shared outside your organization during the public embargo period under any circumstances. If you think another individual/organization requires access to the embargoed information, then please ask them to register as a Trusted Stakeholder (see next section). If you believe there has been a leak of embargoed information then please notify the security team immediately.
[DH: This section is stronger than the existing TF-A and OP-TEE processes, but not as strong as the linux distros policy [4]. I hope I've struck the right balance here.]
The security team welcomes feedback on embargoed information at any time.
Trusted Stakeholder registration
================================
[DH: This is broadly based on the OP-TEE policy.]
The security team maintains a vetted list of organizations and individuals who are considered Trusted Stakeholders of Trusted Firmware security vulnerabilities. Contact <security(a)trusted-firmware.org<mailto:security@trusted-firmware.org>> if you wish to be added to the list, providing the following information:
1. A justification of why you need to know about security vulnerabilities and have access to security fixes before they are made public. A valid reason for example, is that you use Trusted Firmware in a deployed product.
2. An organization email address (not gmail, yahoo or similar addresses). It is preferable for each organization to provide an email alias that you can manage yourselves rather than providing a long list of individual addresses.
3. Confirmation that your Trusted Stakeholders will handle embargoed information responsibly as described in the previous section.
Note, the security team reserves the right to deny registration or revoke membership to the Trusted Stakeholders list, for example if it has concerns about the confidentiality of embargoed information.
[DH: Note, becoming a Trusted Stakeholder in the current TF-A process requires having a valid NDA with Arm and requesting to be added via Arm account management. Should Arm automatically add existing stakeholders to the new process or invite them to be part of it?]
[DH: Note, I expect each TF project to have its own Trusted Stakeholder list.]
[DH: Note, I've not included severity scoring in this proposal, as I think the only value of a score is helping to determine whether a bug is a security vulnerability or not, which in the end has a subjective element. I'm open to the idea of adding this to the process but I'd prefer it to be optional and aligned with CVSSv3 as used by CVE.]
[DH: Note, I haven't specified use of PGP/GPG in this proposal. It makes the process much more difficult to administer in practice for questionable additional security IMO. If we did allow reporters to use PGP, then it implies all recipients of embargoed information should provide a PGP key, and that embargoed information should be decrypted and re-encrypted with recipient keys as it is passed around. I think this is too much effort but if we don't have it, will it put off reporters? The current TF-A process allows optional use of PGP but relies on GitHub security for access to embargoed information. security(a)kernel.org<mailto:security@kernel.org> does not support PGP, though linux-distros(a)vs.openwall.org<mailto:linux-distros@vs.openwall.org> does. OP-TEE does not support it.]
[DH: Note, this proposal assumes a single security email alias for all tf.org projects, which was agreed at a previous board/TSC meeting to make things simpler from a reporter's perspective. However, I'm having 2nd thoughts about that. The additional triage stage could unnecessarily delay handling and there will need to be project specific security aliases anyway, whether they're publicly visible or not.]
[1] https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html
[2] https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmw…
[3] https://optee.readthedocs.io/general/disclosure.html
[4] https://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the…
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.
As part of the action on CI infrastructure I have the action to describing
a proposal for a distributed CI instance called Remote Labs.
Regards
Bill
On Wed, 3 Apr 2019 at 08:05, Abhishek Pandit via TSC <
tsc(a)lists.trustedfirmware.org> wrote:
> Hi All,
>
> Any agenda items for this week's TSC meeting?
>
> Currently this is what I have for the agenda:
>
>
> * Pending action items
> * Major roadmap items for the next quarter
> * Next meeting
>
> Thanks
> Abhishek
>
> --
> TSC mailing list
> TSC(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tsc
>
--
EMEA Field Engineering
Linaro Ltd
Harston Mill CB22 7GG
Cambridge UK
+44 7833 498336 <+44%207833%20498336>
Hi All,
Any agenda items for this week's TSC meeting?
Currently this is what I have for the agenda:
* Pending action items
* Major roadmap items for the next quarter
* Next meeting
Thanks
Abhishek
Attendees
David Brown - Linaro
Bill Fletcher - Linaro
Joakim Bech - Linaro
Bill Mills - TI
Matteo Carlini - Arm
Eric Finco - ST
Mark Groesen - TI
Shebu Kirakose - Arm
Abhishek Pandit - Arm
Julius Werner - Google
Christian Daudt - Cypress
Andrew Davis - TI
Dean Arnold - Arm
Actions noted
Binary repository implementation proposal (name, path, mechanism) - Dan
Propose slot for TSC call co-timed with Connect - Abhishek
Proposal on incident handling list - Dan
Reconcile mailing lists with attendees - Bill
Attestation script home - Abhishek to talk with David
Dean to send test cases running on MPS2 to Christian
Agenda
1. CI system discussion.
2. Security Incident Process.
3. Binary Contribution Policy. Draft has already been circulated.
4. Attestation Token Validation script
Arm team has created a validation script for checking the initial
attestation token (CBOR/COSE). We would like to open source this script as
it helps TF-M users.
Would it make sense to have this in tf.org?
5. TF-M Documentation Proposal
We have been working on a better documentation proposal for TF-M. I can
briefly introduce this to TSC then it can be followed by mailing list
discussion.
6. Next meeting – BKK19 F2F?
7. Mailing list subscription status.
8. If time permits we can discus major work items for the next quarter.
9. AOB
Minutes
Binary Contribution Policy
JW: Circulated via Board. Already have some instances. Will have separate
repository for TF Binaries. Policy describes rules that need to be followed
to upload to the repository. We review case-by-case. Policy describes the
process where they discuss with the TSC. How to technically implement this
- propose it should be a git submodule. Board has already approved the
policy.
AP: Expect to send some questions by email. Any other questions?
JW: Can we start implementing - creating the repository?
DH: All we need is a location and a name for the repo. Do we have a generic
(non TF-A, TF-M) namespace? Unified repo.
JW: Need someone from Arm to create the submodule repo.
Action: Dan to suggest path/name
Incident Handling
DH: TF-A has an incident handling process. So does OP-TEE (different). TF-M
doesn’t have one. Need to have (need from hyperscalers) a very restricted
list for who can contribute to the fix before publicizing it. Similar to
kernel.
MC: In the kernel - restricted to non-disclosed list of security experts.
Second list of people for controlled disclosure that are under a linux
distro mailing alias.
CD: Not quite clear on the distinction. Board discussion was a single entry
point. Think the grand goal was to make it simpler reporting. Don’t create
artificial separation. Should be obvious to submitter. If could have 2-3
triagers forwarding to TF-A and TF-M. Who are those 2-3 people?
DH: Arm looking for them to be Arm people.
MC: Distinction is based on individual merit rather than specific
companies. Core developers for A & M are currently Arm. Disclosure comes
afterwards.
CD: 3rd level - an inform list?
DH: Yes. Currently would be people with an NDA with Arm.
CD: If there’s an embargo don’t want it going to even a semi-open list.
Action: Dan to come up with a proposal
MC: cf Linux kernel policy. Aim is to push the fix as soon as possible but
acknowledge the needs of hyperscalers
JB: For OPTEE initial proposal was seen as too tight. Google has 90 days.
Difference is if the problem is out in the wild and then fix as quickly as
possible.
DH: Feedback from hyperscaler vendors that they only need 2 weeks. Even
Linux distros only ask for another 2 weeks on top. For TF-A, 4 weeks after
initial disclosure it goes public. In kernel process don’t get involved in
CVE and severity scoring. Leave that to reports. Anyone have any initial
thoughts
JB: Not saying TF should use same policy as OPTEE but if there are no other
ideas.
DH: Reason OPTEE doesn’t use CVSS?
JB: Not really. Needed to tweak it with OPTEE wording.
JW: Propose to follow Linux policy of releasing the patch as soon as
possible. Some project, patching is public
Mailing list subscription service
AP: Please can everyone check their subscription status.
BF: If any issues with lists.trustedfirmware.org then mail BillF
Action: Bill to reconcile the mailing lists vs attendees
CD: Should maybe consider TSC to be TSC “announce”.
BF: TSC was aimed to be as open/transparent as possible
Attestation token:
AP: Team in Arm has been working on a script. Team have asked if it can be
upstreamed somewhere. TF-M generates this token. Does it make sense to
create a repo to host this script. Would be someone assigned as maintainer
from Arm side.
CD: Already a tools directory in TF-M with some Python scripts. Why not
there?
AP: Might apply to other projects
SK: It’s an ITF standard. Just happens that TF-M uses that format
DB: Suggest to put it in the repo
CD: What open source project do you want it to live under, or does it need
it’s own project? Don’t see why it would be in TF. Can import it into TF
for use.
DB: Cbor implementations tend to be for specific uses. Not sure it’s the
trend we want to follow.
CD: But if not, someone needs to make sure it’s generic enough. Level of
ownership needed. Otherwise throw it in TF-M.
DB: Question - who is going to work on generalising it. Will only be when
someone has the resources
AP: Propose to take input from David [action]
CI
DA: Have a set up of Jenkins/Build Slaves and LAVA. Will meet with Linaro
next week to see how to move that onto their infrastructure.
CD: Test cycle is via a LAVA instance testing
DA: Yes via MPS2
CD: Is just boot?
DA: Have a couple of test cases. Can find out. [action]
CD: Is the plan to move this to the LAVA lab?
BF: There are a few options, as well as physical location in the lab we
have a federated/distributed lab instance concept. Builds and results are
central but board farm has instances at vendor sites. Helps avoid lab
bottlenecks and shipping boards.
CD: Like kernel CI?
BF: Yes. Will look at putting together a deck with some more information
MG: Does the CI use simulation? i.e. qemu or fast model?
DA: TF-A use fast models. Qemu - not done anything at the moment.
BF: Does TF-A Test support qemu?
DH: Can check
MG: Recently has been some more support pushed.
CD: LAVA supports qemu.
EF: Distributed instance supports TF-A and TF-M?
BF: For LAVA infrastructure - yes
AP: Next meeting. Board is meeting at Linaro Connect. Any interest in a TSC
meeting?
(confirmed several TSC members will be there)
EF: Yes. Welcome opportunity to discuss work items for the next quarter
AP: Documentation - brief overview. Slides to be circulated by email.
JB: Done same activity for OPTEE and done same activity. Nice think with
Sphinx - interlinking within the documentation is very easy. Like this
idea.
CD: If RFC discussed in gerrit code review then that could get lost.
AP: Should still say in draft folder in the doc.
CD: Basically the history of thingks that were discussed by not accepted.
AP: review happens on the mailing list
CD: So there is history in git if something is turned down
AP: And mailing list has the discussion.
DB: Reference: https://github.com/rust-lang/rfcs
--
EMEA Field Engineering
Linaro Ltd
Harston Mill CB22 7GG
Cambridge UK
+44 7833 498336 <+44%207833%20498336>
