Re: Reducing the attack surface caused by Berkeley DB...
Hi Adrian,
On 1/27/18 1:35 PM, Adrian Bunk wrote:
> On Sat, Jan 27, 2018 at 12:25:20PM +0100, Lionel Debroux wrote:
> > Hi Adrian,
>
> Hi Lionel,
>
> > On 1/27/18 6:27 AM, Adrian Bunk wrote:
> > ...
> > > There doesn't seem to be any disagreement on the general idea,
> > > the only thing missing is a person doing the work on getting
> > > all Debian packages ported away from Berkeley DB while ensuring
> > > that users don't lose data due to that.[1]
> > Alright.
> > Before we can envision reaching such an ambitious, longer-term goal,
> > we'll collectively have to work on small, achievable goals and
> > tasks...
> > ...
>
> "collectively" = noone is feeling responsible and nothing gets done
>
> In a project the size of Debian there are plenty of tasks this size or
> even bigger, and usually they get done if and only if there are one
> or few people who consider themselves responsible.
I see. You've been around for a while, you know better than I do :)
> In the case of Berkeley DB, this means there has to be someone who
> takes care of that for several years until the removal is finished.
> Someone might have the name Lionel. ;-)
Heh. I'm much more of a programmer than a (project) manager ;)
Learning APIs, analyzing C/C++ code, contributing C/C++ code (producing
a new storage back-end, benchmarking, writing upgrade code and/or
refactoring existing code to add support for multiple storage
back-ends), fuzzing, and interacting with maintainers, is something I
can do.
Preferably one project at a time, and at first, focusing on projects
which are popular enough among the smallish sample of computers which
report to popcon. I agree with you that in the end, *all* packages will
have to be checked, then fixed or removed by someone - but unpopular
packages contribute less to the popularity of BDB and to the attack
surface than popular ones.
However, honestly, I fear that being _responsible_ for contacting and
following up with downstream packagers and upstream maintainers for
dozens of projects (some of which haven't had a release in this decade),
in addition to / instead of the above, probably for years, could be
biting more than I can chew :)
It would arguably make for an interesting learning experience, and the
fact that all distros have the same problem should help sharing the load
(e.g. with the person in Fedora pointed by Timo in another
sub-thread)... but oversubscribing is a good way not to get much done.
And I'd like to do something useful, for real.
> "small goals" also have the problem that there is no bigger picture.
The small(er) goals should all participate in fulfilling the old,
overarching goal of eventually removing BDB from the archive of Debian
(and other distros), for security reasons (dozens of full DoS, according
to Oracle's triage in their CPUs).
Such small(er) goals could be:
* ensuring that other databases, starting with LMDB, meet reliability,
performance and of course security requirements;
* for programs which already support multiple back-ends, for future
installs, switching the default backend from BDB to another one, if it
improves security and it does not adversely impact performance and
reliability in most cases;
* adding support for other database backends (and presumably especially
LMDB) to e.g. apt-ftparchive, per the sub-thread with David.
As usual, the devil's in the details...
> As an example, I am the maintainer of bogofilter.
A popular package, for what popcon is worth.
> bogofilter supports several DB backends, but virtually all users are
> using the Berkeley DB one.
I see that both upstream (configure.ac) and the Debian package
(Depends:) use this default. I'm just stating the fact (which you of
course know), I'm not qualified to judge whether changing the default
for future installs would be uniformly good.
> If I would drop the Berkeley DB backend in a release where Debian
> does still support Berkeley DB, I'd just screw the users of my
> package for no good reason.
Thanks,
Lionel.
Reply to: