bcde0a0e0d
Unfortunately, the GitHub security advisory system has become rife with
abuse. Not a single issue reported using that system has been a
legitimate security vulnerability. Rather, the reported issues have
fallen into the following categories:
- Blatant API abuse, sometimes due to AI-written test harnesses
A few of these exposed opportunities for API hardening, but none was
exploitable. Basically, if a program abused the API in the same way
as the aforementioned test harnesses, then the program could never
work with any image, and such a bug would never make it into the wild.
To put it another way, if a program calls:
unsigned char *buf1 = (unsigned char *)malloc(1);
unsigned char *buf2 = (unsigned char *)malloc(1);
memcpy(buf2, buf1, 2);
then that is not a security vulnerability in the C library. It is a
caller bug.
- Outright test harness bugs (e.g. failing to allocate enough memory for
a packed-pixel output buffer)
- Downstream bugs in other software
- Legitimate but unexploitable bugs in example code that is distributed
as part of the libjpeg-turbo documentation
- Potential but unconfirmed code quality issues reported by automated
tools (possibly bots, because none of the posters replied to followup
questions) against EOL versions of libjpeg-turbo
- One of the known issues reported in
https://libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf
(both of which are endemic to the progressive JPEG format but can be
worked around in both the libjpeg and TurboJPEG APIs)
- User confusion regarding the documented API behavior (which exposed
opportunities to clarify the documentation)
- Nonsensical spam by what appeared to be a bot account fishing for a
security patch reward
Unfortunately, with a high-profile project such as libjpeg-turbo,
certain "security researchers" try to use our project as a springboard
for self-promotion. They file draft security advisories on a knee-jerk
basis, in the hope that one of them will be accepted. Not once has
anyone who filed such a draft advisory demonstrated that they had
actually read our security policy.
Even more unfortunately, GitHub provides no way to make a draft security
advisory public without accepting it as a vulnerability. Thus, some
potentially useful information about the aforementioned issues has
remained hidden from the community. Honestly, I would have no problem
with the system if it simply allowed me to convert a draft security
advisory into a regular GitHub issue.
IMHO, the best way forward is to restrict the filing of draft security
advisories to project admins. The system is still active, and I can
still use it to file draft security advisories if there is a legitimate
need, but regular users will need to report the potential issue to me
first using another method.
2.5 KiB
Security Policy
Supported Versions
Fixes for security vulnerabilities are proactively applied to any applicable branch/release series that is in the Next-Gen, Active, Maintenance, or Extended support category.
What Is a Security Vulnerability?
A security vulnerability is a bug in an official, supported release of libjpeg-turbo whereby an otherwise well-behaved calling program can trigger a potentially exploitable failure (such as a buffer overrun, an uninitialized read, or undefined behavior) in one of the libraries by passing malformed image data to a public API function.
-
If the calling program itself is malformed and could not work properly with any image, then its inevitable failure is not a security vulnerability. Such issues should be reported using a GitHub bug report, and they will be investigated as opportunities for API hardening.
-
If the issue affects only Alpha/Evolving code or has otherwise not officially been released, then it is not (yet) a security vulnerability. Such issues should be reported using a GitHub bug report.
-
If the issue affects only an EOL branch/release series, then it is not a security vulnerability. (Per above, fixes for security vulnerabilities are not proactively applied to EOL branches/release series.) Such issues can be reported using a GitHub bug report, but the suggested remedy will likely be to upgrade to a supported release.
Reporting a Security Vulnerability
Vulnerabilities can be reported in one of the following ways:
-
E-mail the project admin. You can optionally encrypt the e-mail using the provided public GPG key.
-
Beta and Post-Beta code is not expected to be free of bugs, so vulnerabilities that affect only that code (for example, vulnerabilities introduced by a new feature that is not present in a Stable release series) can optionally be reported using a GitHub bug report.