Since this project handles very sensitive data, we, the maintainers of credentialsd, take security seriously. This policy outlines our intentions for addressing security issues and practices for security researchers investigating this project.

If you have discovered a security vulnerability in this project, please report it to us privately via the process below.

We use GitHub for private vulnerability disclosure. To report a vulnerability:

1. Go to Security > Advisories > New draft security advisory.
2. Fill out the report and submit the draft.
3. The maintainers will be privately notified about the advisory and get back to you.

We aim to acknowledge the receipt of the report as soon as possible and will work with you. We seek to investigate issues within 30 days.

If the issue is confirmed upon investigation, we will collaborate with you to remediate the vulnerability. Depending on the severity or developer availability, we may request more time to remediate the issue before public disclosure.

We only support the latest published release. We may backport patches when possible to help users running on distributions that package older versions of our software.

We do not currently have a formally defined threat model; we will continue to document it over time. However, the basic security guarantees we would like to achieve are defined below.

Please note, that if you believe you have discovered a security problem outside of this scope, we still want to know about it! We would still like to discuss the issue privately, but we may decide to address it beyond the response time described above.

• privileged client: A client that is allowed to make requests for credentials for any origin.
• unprivileged client: A client that is allowed to make requests for credentials for only a preconfigured set of origins.

Here is the current list of items that are in scope:

• Privileged clients may request credentials via this service¹ for any origin.
• The list of privileged clients cannot change without:
  • root privileges, or
  • user consent²
• The list of unprivileged clients cannot change without:
  • root privileges, or
  • user consent²

We implicitly trust the kernel and D-Bus, so any attacks that exploit those are out of scope for this project.

Some other attacks that are explicitly out of scope are those that require:

• physical access
• direct access to authenticators
• root privilege escalation