Re: Concerns about how the Security information is presented on Debian.org
On Sun, Dec 19, 2021 at 05:37:40PM +0100, Max WillB wrote:
> Davide Prina <davide.prina@gmail.com>wrote:
>
> > you must understand that who report a security problem can be a
> > different person
>
> The point is, to quote the paper:
>
> "a vast majority of vulnerabilities and their corresponding security
> patches remain beyond public exposure"
>
> Vulnerabilities are fixed in fresh versions of software. The versions in
> Stable stay vulnerable, even if all CVEs are reported to Debian
> (which I don't think is the case) and even if they are all fixed quickly
> (which is definitely not the case) It's a limitation of Debian's and RH's
> approach, compared to the rolling-release approach. This is one of the
> two things I mentioned that debian.org/security is not telling you.
>
> > chromium has been removed from testing
>
> That doesn't help people who trusted debian.org/security and are running it.
>
>
>
Dear Max,
In this - and in your previous message to the list - you imply that this
reticence is malicious and that Debian is withholding the truth.
If upstream projects don't declare and share vulnerabilites - we all suffer.
Responsible disclosure generally means that all distributions collaborate
and fix vulnerabilities together - and you notice this where distributions
are given 30 or 90 days notice of a vuln. that is embargoed while everyone
fixes it - all then release fixes more or less together. See lots of kernel
vulnerabilities, for example
CVEs are generally available. Debian folk who find vulns. also tend to talk
to upstream. For some packages, problems are Debian-specific: most people
don't care if a given package doesn't build on armhf / arm64 or i386.
Patches to get Debian building Firefox on those arches may not be top
priority on Mozilla's list.
Specifically for Firefox and Chromium: these are large packages, very
frequently released. Debian's not hiding problems particularly and is
working to build these packages for all supported distributions.
Dependency chains within them may mean building specific toolchains just
for Mozilla, for example, to enable the packages to be built on stable
and oldstable. That work is going on: the progress isn't hidden.
Debian's work helps inform Ubuntu and other .deb based distributions that
may have their own priorities (and their own security problems).
Ultimately, though - Debian's a do-ocracy: there comes a point at which
we have to rely on upstream to fix htings and take notice, we need more
volunteers to help test/file bugs/test fixed things or we fall back on the
comprehensive warranty statements we provide with each package.
Telling the Project as a whole that we're not doing the right thing
doesn't particularly help motivate the people who are working to do the right
thing and doesn't provide useful feedback on existing efforts.
Given the difficulties in building say, Firefox - 3.7M lines of code,
profuse dependencies, integrated unstable version Rust toolchains that
change versions regularly and an upstream that changes very regularly - and
given the fact that you feel we're not doing our job - what insight persuades
you that a rolling distribution from the same people with the same constraints
would handle security any better in a shorter timeframe?
This discussion would be better on debian-security: if you want to see the
output of Debian's security focused developers, check out the archives
for debian-security-announce mailing list - you'll find the fixes for
log4j are there with minimum delay, for example.
With every good wish, as ever,
Andrew Cater
> --
> Sent with https://mailfence.com
> Secure and private email
>
Reply to: