Re: State of ampache: we should declare it unsupported
The vulnerabilities are important and upstream does not provide any
This means all ampache installations (Debian and non-Debian) are at risk.
It would be worth explaining the situation to upstream and requesting
his explicit stance on the matter.
I believe this will make the decision easier, and contribute to raise
awareness about good security practices.
On 04/10/2019 14:56, Roberto C. Sánchez wrote:
> Summary: ampache appears to not be supportable and I'd like to recommend
> that we simply declare it as no longer supported in jessie.
> If no objections are raised to my recommendation, I intend to proceed
> with the necessary updates (i.e., update to debian-security-support,
> associated announcement, and whatever else is needed) at the end of next
> Read on for deatils:
> So, I decided to have a look at the ampache package (open CVEs:
> CVE-2019-12385, CVE-2019-12386). The vulnerabilities are potentially
> quite serious (SQL injection and cross-site scripting), though since I
> don't use ampache it is not clear how common it is to host in a
> configuration exposed to the public Internet.
> That said, ampache was triaged into dla-needed.txt 6 weeks ago (on 25th
> August) and at that point the discussion on the GitHub issue 
> associated with the two open CVEs appears to have concluded (last
> comment was on 23rd July), with no additional comments since then.
> The factors which prompted me to recommend that we consider declaring
> ampache as unsupported in jessie rather than attempting to fix the
> vulnerabilities are:
> + upstream has supposedly "fixed" the issues, but the changes are part
> of a single very large commit that prepares the code base for
> development of the next major release of ampache
> + the package exists only in jessie, with a very low popcon of 19
> + the version in jessie appears to be a pre-release snapshot that was
> made at least two years prior to jessie release and it is not clear
> that upstream ever made an official release from that line of
> The commit which is refrenced in the GitHub issue has a commit message
> which is a bulleted list of 115 entries (indicating that it is likely a
> squash of at least that many individual commits). In the issue
> discussion, in response to a question about the specific commits/PRs
> that address the CVEs, the upstream references the aforementioned commit
> and lists 7 "specific changes" that resolve the CVE's. However, the
> "specific changes" do not correspond to anything described in the single
> large commit message. Additionally, searching the git history (with the
> help of the --grep option) did not reveal any of the "specific changes"
> identified by the author. I also searched within his own fork of the
> canonical upstream repository and found nothing helpful there either.
> For context, the diffstat of the single large commit in question ends
> 642 files changed, 18132 insertions(+), 20952 deletions(-)
> Given that it is likely impossible to extract the necessary targeted
> changes to address the CVEs, and that even if such a task were feasible
> the likelihood that the changes would apply to a pre-release snapshot
> more than 6 years old, and that there does not appear to be sufficient
> information to validate that the fixes are effective (the reporter
> provides PoCs via an article published after the initial report, but it
> is not clear that the information there is sufficiently complete), it
> seems like the effort to properly maintain ampache is too great.
> Marking the vulnerabilities as "no-dsa" or "ignore" does not seem right,
> as they are rather serious, so declaring ampache as unsupported seems
> the only viable alternative.
>  https://github.com/ampache/ampache/issues/1872