libjxl

FORK: libjxl patches used on blog
git clone https://git.neptards.moe/blog/libjxl.git
Log | Files | Refs | Submodules | README | LICENSE

SECURITY.md (3232B)


      1 # Security and Vulnerability Policy for libjxl
      2 
      3 ## TL;DR:
      4 
      5 CPE prefix: `cpe:2.3:a:libjxl_project:libjxl`
      6 
      7 To report a security issue, please email libjxl-security@google.com.
      8 
      9 Include in your email a description of the issue, the steps you took to create
     10 the issue, affected versions, and if known, mitigations for the issue. Our
     11 vulnerability management team will acknowledge receiving your email within 3
     12 working days.
     13 
     14 This project follows a 90 day disclosure timeline.
     15 
     16 For all other bugs, where there are no security implications about disclosing
     17 the unpatched bug, open a [new issue](https://github.com/libjxl/libjxl/issues)
     18 checking first for existing similar issues. If in doubt about the security
     19 impact of a bug you discovered, email first.
     20 
     21 ## Policy overview
     22 
     23 libjxl's Security Policy is based on the [Google Open Source program
     24 guidelines](https://github.com/google/oss-vulnerability-guide) for coordinated
     25 vulnerability disclosure.
     26 
     27 Early versions of `libjxl` had a different security policy that didn't provide
     28 security and vulnerability disclosure support. Versions up to and including
     29 0.3.7 are not covered and won't receive any security advisory.
     30 
     31 Only released versions, starting from version 0.5, are covered by this policy.
     32 Development branches, arbitrary commits from `main` branch or even releases with
     33 backported features externally patched on top are not covered. Only those
     34 versions with a release tag in `libjxl`'s repository are covered, starting from
     35 version 0.5.
     36 
     37 ## What's a "Security bug"
     38 
     39 A security bug is a bug that can potentially be exploited to let an attacker
     40 gain unauthorized access or privileges such as disclosing information or
     41 arbitrary code execution. Not all fuzzer-found bugs and not all assert()
     42 failures are considered security bugs in libjxl. For a detailed explanation and
     43 examples see our [Security Vulnerabilities Playbook](doc/vuln_playbook.md).
     44 
     45 ## What to expect
     46 
     47 To report a security issue, please email libjxl-security@google.com with all the
     48 details about the bug you encountered.
     49 
     50  * Include a description of the issue, steps to reproduce, etc. Compiler
     51    versions, flags, exact version used and even CPU are often relevant given our
     52    usage of SIMD and run-time dispatch of SIMD instructions.
     53 
     54  * A member of our security team will reply to you within 3 business days. Note
     55    that business days are different in different countries.
     56 
     57  * We will evaluate the issue and we may require more input from your side to
     58    reproduce it.
     59 
     60  * If the issue fits in the description of a security bug, we will issue a
     61    CVE, publish a fix and make a new minor or patch release with it. There is
     62    a maximum of 90 day disclosure timeline, we ask you to not publish the
     63    details before the 90 day deadline or the release date (whichever comes
     64    first).
     65 
     66  * In the case that we publish a CVE we will credit the external researcher who
     67    reported the issue. When reporting security issues please let us know if you
     68    need to include specific information while doing so, like for example a
     69    company affiliation.
     70 
     71 Our security team follows the [Security Vulnerabilities
     72 Playbook](doc/vuln_playbook.md). For more details about the process and policies
     73 please take a look at it.