Our preference is to use GitHub for communication. The reason for that is that it is an open source project, so there should be no real reason to hide discussions from other people. GitHub also makes it possible for anyone to chime in into discussion etc. So besides sending patches as pull requests on GitHub we also encourage people to use the “issues” to report bugs, give suggestions, ask questions etc.

Please try to use the “issues” in the relevant git. I.e., if you want to discuss something related to optee_client, then use “issues” at optee_client and so on. If you have a general question etc about OP-TEE that doesn’t really belong to a specific git, then please use issues at optee_os in that case.


You can reach the Core Team by sending an email to op-tee[at] However note that it’s a public mailinglist and not just TrustedFirmware engineers behind that email address.

For pure Linux kernel patches, please use the appropriate Linux kernel mailinglist, basically run the script in the Linux kernel tree to figure out where to send your patches.

$ cd <linux-kernel>
$ ./scripts/ drivers/tee/


Some of the OP-TEE developers can be reached at Freenode ( at channel #linaro-security. Having that said, the activity there is a bit limited, so it is probably not the best place to discuss OP-TEE.

Vulnerability reporting

As part of the organization, the OP-TEE project uses the security incident procedure outlined on the security incident page. We offer two methods for reporting security issues. The first is the traditional method of sending email to the addresses listed on the Mailing Aliases page. The alternative method is through GitHub’s GitHub Security Advisories page for OP-TEE.

We prefer the GitHub Security Advisories page because they simplify the sharing and communication of reports. However, this also requires a GitHub account and we recognize that not everyone can or has the ability to report security issues via GitHub; therefore, we also accept reports via email.

Note that OP-TEE is a reference implementation for developers and device manufacturers and by being a reference implementation it is not always running a secure device configuration by default (see Platform ports for more information). Therefore we ask people to think twice whether the security incident report should go to:

  1. The OP-TEE project? Is it an issue in the generic code?

  2. The chipmaker? Does it only affect a certain platform? Is it a configuration described only under NDA?

  3. The ones making the end product? Is the issue only present on a certain device?

In some cases, the OP-TEE team works directly with chipmakers. However, it is not uncommon for products to be manufactured using OP-TEE without the OP-TEE project’s knowledge. In such instances, we recommend sending the security issue report to the manufacturer of the final product, who should then, if necessary, contact the OP-TEE project and/or the chipmaker.

Core Team

The core team consists of engineers. See also “THE REST” in the OP-TEE MAINTAINERS file, which oversees the essential activities, such as performing releases, merging patches, and being the first to respond to security incidents.