On Thursday, January 25, 2018 11:59:06 PM Lionel Debroux wrote: > Hi, > > Several days ago, jmm from the security team suggested that I start a > discussion on debian-devel about Berkeley DB, which has known security > issues, because doing so may enable finding a consensus on how to move > away from it in Debian (which is hard). So here's a post :) > > Please keep me CC'ed, I'm not subscribed to debian-devel. > > > Oracle Berkeley DB [1] "is a family of embedded key-value database > libraries providing scalable high-performance data management services > to applications. The Berkeley DB products use simple function-call APIs > for data access and management.". > In practice, Berkeley DB is a core component of most *nix distros. > Debian popcon indicates that libdb5.3 is installed on ~80% of the > computers which report to popcon. > Two generations of Berkeley DB are relevant here: > * BDB < 6.0 are under the original Sleepycat license; they're > unmaintained, and unfixed security issues have been known for years > (e.g. [2]: the library can corrupt a DB in such a way that salvaging it > yields an infinite loop; disk corruption can also cause infinite loops); > > * the 6.x series contains fixes for 44 security issues with CVE numbers > since 2015 [3][4][5] (most are complete DoS); however, the license was > switched to AGPLv3, so it's unsuitable for broadly replacing the 5.x > series (clearly, most projects are not going to switch to a compatible > license) or backporting security fixes to the 5.x series. > > > We can see that we've got a problem here. Absent an unlikely change of > heart from Oracle, reducing the attack surface (which is arguably a > worthwhile goal in general) caused by libdb 5.x would seem to require > reducing, and eventually eliminating, usage of that library... > > While there might be a bit of low-hanging fruit, e.g. packages which > * enable BDB support despite hardly anybody using it (so it might go > away without too many complaints ?); > * depend on BDB but are unmaintained upstream and hardly used downstream > (so they might be removed from the archive without annoying users ?); > * will switch to an AGPLv3-compatible license and be able to depend on > (and require packaging of) libdb 6.x without undesirable side effects on > the ecosystem > the vast majority of the ~170 reverse dependencies of libdb5.3 listed by > `apt-cache rdepends libdb5.3` on sid will require (much) more work to > get rid of that dependency, with impact on backwards compatibility... > Among those packages are: > libperl* libpython2.7* libpython3.* php5-cli > libsvn* libaprutil* > reprepro apt-utils librpm* > postfix exim4-base opensmtpd sendmail-bin claws-mail* > libpam-modules 389-ds-base slapd > memcachedb squid sks > > Headaches for both upstreams (e.g. making libdb usage more optional, > finding and adding support for replacements, making upgrade code) and > distros (e.g. adjusting packaging and maybe policy, coping with > upgrades) will ensue... even without attempting backports to older > upstream releases or older distros. > The fact that many FLOSS developers and packagers do it on their spare > time won't help. > > > --- > Do you think we should start the journey of getting rid of libdb5.3 at a > wide scale ? And if so, how to optimize resource usage in general ? :) > ---
Ultimately BDB is a dead end for non-AGPL projects. So my answer to your first question is a definite yes. I'd like to know what the preferred replacement is. I maintain a few less heavily used packages that use libdb5.3 and I need to know what to tell upstream they should port to. I don't know enough to have a real technical opinion. Is lmdb the general solution? As far as postfix goes (which I also co-maintain) that is a two release cycle project (it's complicated, but upgrades don't work otherwise - if anyone cares see what we did for postfix-sqlite. It's no problem to switch to a difference default map type, but it'd be nice if we could switch it once to something that was otherwise already likely to be installed. Scott K
signature.asc
Description: This is a digitally signed message part.
