Re: Reducing the attack surface caused by Berkeley DB...

[Lionel Debroux]

Hi Guillem,

On 1/27/18 1:42 AM, Guillem Jover wrote:
> On Thu, 2018-01-25 at 23:59:06 +0100, Lionel Debroux wrote:
> > 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 :)
>
> > ---
> > 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 ? :)
> > ---
>
> As with many things in Debian, this was already discussed some years
> ago. :) The maintainers are supposedly even on board, see the thread
> starting at:
>
>   
I suppose I should have searched better :)

Looks like although several packages which (used to) depend on libdb5.3
were removed or modified, most weren't... and an updated version of that
list would therefore not learn us much.
Out of curiosity, which tool was used to obtain this list, BTW ? There's
nothing too obvious to me in apt, apt-get, apt-cache or the Tracker Web
interface.

In order to sort libdb5.3's reverse dependencies by popularity, I could
whip up a q&d Perl script to query the popcon Web interface in a loop,
or probably better, to parse the raw text in the by_inst page. But isn't
there already a way to do that ? :)
A generic search engine query wasn't helpful.


Thanks,
Lionel.

Re: Reducing the attack surface caused by Berkeley DB...

[Lionel Debroux]

Hi Adrian,

On 1/27/18 6:27 AM, Adrian Bunk wrote:
> On Fri, Jan 26, 2018 at 11:49:41PM +0100, Lionel Debroux wrote:
> > ...
> > On 1/26/18 11:39 AM, David Kalnischkies wrote:
> > ...
> > > Finding someone performing the daunting task of actually switching
> > > code, documentation and existing databases over on the other hand…
> > > I at least don't see me enthusiastically raising my arm crying
> > > "let me, let me, …".
> > Heh. Neither do I see myself for such a task :)
> > ...
>
> Open source development does not work by random people on the internet
> telling volunteers in a project what they should do.
I received such requests over the past 15 years I've been contributing
to, and later leading the maintenance and evolution of, less-used open
source software.

But you know the breadth of the task, and therefore the time investment
it requires; it's therefore unsurprising that people like David and
myself (as a Debian user for over a decade, but not really familiar with
Debian procedures) aren't eager to subscribe to the tasks of modifying
core aspects of dozens of foreign code bases, and the corresponding
docs, or contacting significant amounts of packagers and upstreams ;)

Thanks for the heads-up about the potential attitude problem, though.

> Guillem already pointed at a mail thread with the same suggestion
> on this same mailing list 4 years ago.
>
> 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...
and whoever does that and follows up on it (yes, I shall spend some time
on the matter) needs help from Debian developers more familiar with
procedures, at the very least :)

For instance, from another sub-thread: for Buster, would it be feasible
to smoothly split the libdb5.3-dependent binaries from libpam-modules,
apt-utils, libaprutil1 (popcon by_inst #423), the Perl and Python
distributions to new binary packages ?

> Since this is something that is important for you, this is a great
> opportunity for you to get involved in Debian development.
Indeed. In a way, I already started, by spending time writing (partially
redundant, in this case) e-mails about foreign software, rather than
working on code bases more familiar to me, but which have _far_ fewer
users than BDB or earlier and more privately, libmodplug.

> If it is not important enough for you to spend your time on it,
> then 2022 is the estimated date when the next person will start
> a "remove Berkeley DB" discussion on this mailing list...  ;-)
Understood, let's do a bit better than that ;)


Thanks,
Lionel.


> [1] it is not clear whether there will have to be one more
> Debian release with Berkeley DB just for upgrades
If there's such a release, I'm afraid Buster won't be it: in less than a
year, the task of providing an upgrade path and deprecating BDB from
every upstream, or removing the corresponding packages from the archive,
looks way too large...

Bug#888576: ITP: coda -- Library for the Common Data Access framework for Earth science file formats

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: coda
  Version : 2.18.3
  Upstream Author : CODA develpers, 
* URL : https://github.com/stcorp/coda/
* License : BSD
  Programming Lang: C, Fortran, Python
  Description : Library for the Common Data Access framework for Earth 
science file formats

CODA is the Common Data Access framework that allows reading of scientific data
from various data formats, including structured ascii, structured binary, XML,
netCDF, CDF, HDF4, HDF5, GRIB, RINEX and SP3. It provides a single consistent
hierarchical view on data independent of the underlying storage format.

CODA is used as a core component in various ESA software among which the ESA
Atmospheric Toolbox (BEAT) and the Broadview Radar Altimetry Toolbox (BRAT).

The CODA software package comes with interfaces for C, Fortran, IDL, MATLAB,
Python, and Java and several useful command-line tools.

Re: Reducing the attack surface caused by Berkeley DB...

[David Kalnischkies]

On Fri, Jan 26, 2018 at 11:49:41PM +0100, Lionel Debroux wrote:
> > Anyway, the only util in apt-utils making use of libdb is
> > apt-ftparchive which a) isn't used much in Debian – but by some
> > derivatives¹ and b) can operate without the backing of a db, but you
> > don't want to run a large archive without it.
>
> Could that program conceivably be split to another package ?

Not really. apt-utils includes three tools: apt-extracttemplates,
apt-ftparchive and apt-sortpkgs. The later two should be together and
the first one shouldn't even exist… it exists only temporary as
a stopgap as long as there is no dpkg tool (which would be the more
natural place for extracting files from a deb file)[0] for this task.
In other words: We realized only later that its existence is permantent,
like with all good temporary solutions.

Splitting packages now means that the split will reach effect at most in
bullseye… (buster needs at least a recommends for upgraders, likely
depends as there are tools like local-apt-repository depending on
apt-utils to get apt-ftparchive) that might be a bit too far off for
your case, especially as we haven't really gained anything by it. We
just (literally) moved the problem.

(The other aspects I will hopefully answer with another mail in the
gsoc/outreach subthread)


Best regards

David Kalnischkies

[0] https://wiki.debian.org/Teams/Dpkg/RoadMap


signature.asc
Description: PGP signature

Bug#888580: RFA: doxygen - Documentation system for C, C++, Java, Python and other languages

[Matthias Klose]

Package: wnpp

I'd like to drop maintenance of doxygen. I think I hijacked that package in 2004
to be able to build the libstdc++ docs from the GCC sources. Now that the
package needs a concise understanding about the javascript issues (sources,
different upstream versions), I'd like to stay off that maintenance task. Helmut
Grohne has been a substantial help with the javascript issues, but decided to
leave co-maintainership.  Basically I'm asking for a new maintainer with the
understanding of the javascript issues, the implications for Debian policy, and
the willingness to adopt the package to build documentation of Debian packages.

Thanks, Matthias

Re: Reducing the attack surface caused by Berkeley DB...

[Adrian Bunk]

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.

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. ;-)

"small goals" also have the problem that there is no bigger picture.

As an example, I am the maintainer of bogofilter.
bogofilter supports several DB backends, but virtually all users are
using the Berkeley DB one.
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.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Reducing the attack surface caused by Berkeley DB...

[David Kalnischkies]

On Fri, Jan 26, 2018 at 12:24:26PM +0100, Miriam Ruiz wrote:
> 2018-01-26 12:02 GMT+01:00 Colin Watson :
> >> Finding someone performing the daunting task of actually switching code,
> >> documentation and existing databases over on the other hand… I at least
> >> don't see me enthusiastically raising my arm crying "let me, let me, …".
> >
> > I don't blame you!
> 
> Might that be a candidate project for GSOC?

I debated with myself if I should add a comment about gsoc/outreach, so
as the "don't mention it" faction won due to length, let me give the
opposition a chance to comment now:

I don't think so. The size might be alright, but the task itself…
The tasks should usually be something the mentors could and would do
themselves (in less time), but propose them as interesting projects
instead to trap unsuspecting students into not only completing their
project, but hopefully sticking around now that they know the drill.

This task on the other hand… the potential mentor isn't terribly excited
about it: Big warning sign. The bigger problem is through that it is
a dead end: As a student you will learn stuff about the now obsolete
libdb, you are working on apt-ftparchive which is on life support
(personally, I only touch it as testing apt is just easier if it comes
with its own archive tool; for the same reason we have an libapt-based
webserver… tends to be hard to convince other projects to implement
broken behaviour so you can test against it) and after the project is
done your knowledge isn't applicable to any other apt part…

The visibility of your task isn't that great either: I did MultiArch in
APT years ago and people are still complaining about it! That project on
the other hand… not a lot of users – and the few you have will either
never notice that you did something or stumble over a bug and complain
that you did something – usually with a ~2 years delay as basically
nobody is running a big archive on a Debian unstable box (no idea why…).
For newbie motivation reasons you want the exact opposite.

So that task feels more like: Nobody wants to do it, so lets convience
Google/our sponsors to pay a GSoC/Outreach student to do it. (S)he wont
like it, but we got the job done – other orgs do this, but I don't want
Debian to do it, even if it has shortterm benefits (for me/us). If
someone has money to burn we can probably find someone to do the job,
we don't have to waste our perhaps once in a lifetime chance to make
a student a longtime open source contributor with this task.



I guess you can kill both birds with one stone if you go for a "write
libdb-api-compatibility layer for your favorite other db", but that
wouldn't really be a Debian task anymore. Without even thinking a split-
second about the feasibility of this, that might be the more realistic
way of deprecating libdb as I would imagine that most tools still using
it aren't using it because its so great, but because the code exists and
nobody feels like changing it.


To finish the view point of apt-ftparchive: I guess at the time the
libdb remove is immanent we will just remove the database support and be
done. apt-ftparchive is hardly the only tool capable of producing an
archive and most of these tools have a focused upstream… the apt client
needed a server to start rolling, but nowadays this server side hustle
is more a brake than an accelerator.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Re: Reducing the attack surface caused by Berkeley DB...

[Adrian Bunk]

On Sat, Jan 27, 2018 at 12:22:59PM +0100, Lionel Debroux wrote:
>...
> On 1/27/18 1:42 AM, Guillem Jover wrote:
> > On Thu, 2018-01-25 at 23:59:06 +0100, Lionel Debroux wrote:
> > > 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 :)
> >
> > > ---
> > > 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 ? :)
> > > ---
> >
> > As with many things in Debian, this was already discussed some years
> > ago. :) The maintainers are supposedly even on board, see the thread
> > starting at:
> >
> >   
> I suppose I should have searched better :)
> 
> Looks like although several packages which (used to) depend on libdb5.3
> were removed or modified, most weren't... and an updated version of that
> list would therefore not learn us much.
> Out of curiosity, which tool was used to obtain this list, BTW ? There's
> nothing too obvious to me in apt, apt-get, apt-cache or the Tracker Web
> interface.

I don't know what was used, perhaps something like
  sudo apt-get install devscripts ubuntu-dev-tools
  reverse-depends -l -s src:db5.3 | dd-list -i

> In order to sort libdb5.3's reverse dependencies by popularity,
>...

I'm not convinced that would bring much value,
someone would still have to check all packages
for finding all interesting and hard cases.

> Thanks,
> Lionel.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Reducing the attack surface caused by Berkeley DB...

[Adrian Bunk]

On Sat, Jan 27, 2018 at 01:53:54PM +0100, David Kalnischkies wrote:
>...
> I guess you can kill both birds with one stone if you go for a "write
> libdb-api-compatibility layer for your favorite other db", but that
> wouldn't really be a Debian task anymore. Without even thinking a split-
> second about the feasibility of this, that might be the more realistic
> way of deprecating libdb as I would imagine that most tools still using
> it aren't using it because its so great, but because the code exists and
> nobody feels like changing it.
>...

This would only be sufficient for the easy cases where the data stored 
is temporary or cached and can be thrown away.

> Best regards
> 
> David Kalnischkies

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Reducing the attack surface caused by Berkeley DB...

[Miriam Ruiz]

2018-01-27 13:53 GMT+01:00 David Kalnischkies :
> On Fri, Jan 26, 2018 at 12:24:26PM +0100, Miriam Ruiz wrote:
>> 2018-01-26 12:02 GMT+01:00 Colin Watson :
>> >> Finding someone performing the daunting task of actually switching code,
>> >> documentation and existing databases over on the other hand… I at least
>> >> don't see me enthusiastically raising my arm crying "let me, let me, …".
>> >
>> > I don't blame you!
>>
>> Might that be a candidate project for GSOC?

[...]

> I don't think so. The size might be alright, but the task itself…

[...]

Thanks for your clarification. After you have explained the situation
and the reasons, I have to agree with you. Lots of thanks for your
comment!

Greetings,
Miry

Re: Reducing the attack surface caused by Berkeley DB...

[Lionel Debroux]

Replying to myself...

On 1/26/18 11:48 PM, Lionel Debroux wrote:
> Hi Scott,
>
> On 1/26/18 7:05 AM, Scott Kitterman wrote:
> > On Thursday, January 25, 2018 11:59:06 PM Lionel Debroux wrote:
> > >
> > > [...]
> > > ---
> > > 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?
> In some (most ?) cases, it would seem so, indeed.
> But there's now a wider variety of key/value databases (even those
> which don't fork and communicate through *nix or network sockets)
> than, say, a decade ago. I remember that several years ago,
> bitcoind/bitcoin-qt switched from BDB to LevelDB.
>
> > 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.
> liblmdb* or libleveldb* are much less popular in popcon by_inst than
> libdb, yeah...
>
>
> Do we know whether LMDB, and other candidate databases for replacing
> BDB, have received suitable hardening against data corruption and
> fuzzing ?
Well, now I know: some parts of LMDB have not received the appropriate
amount of hardening against data corruption.

A direct LMDB translation of the simple BDB fuzzing run I posted in
Debian BTS #652036:

# apt install lmdb-utils
$ rm -f input*
$ echo -e "key\nvalue" | mdb_load -T -n input
$ zzuf -qcs 0:1000 -C 10 -U 3 mdb_dump -n -l input
$ zzuf -qcs 0:1000 -C 10 -U 3 mdb_dump -n -a input
$ zzuf -qcs 0:1000 -C 10 -U 3 mdb_stat -n -e -fff -r -a input

yields an interesting assortment of SIGFPE, SIGABRT and SIGSEGV...
That's under sid amd64, with lmdb-utils / liblmdb0 0.9.21-1, which
packages the latest upstream release.
I replaced the sources with the latest ones from
https://github.com/LMDB/lmdb , since the commit logs mention e.g. "fix
FIRST_DUP/LAST_DUP cursor bounds check". AFAICS, it changes the set of
symbols, but not the outcome of zzuf... and unsurprisingly, afl-fuzz
following a build with afl-clang-fast destroys both mdb_dump and
mdb_stat within 2 seconds.

Oh well... time to report the issues, after letting afl run for a little
while longer, probably until tomorrow morning.


Bye,
Lionel.

Bug#888615: ITP: libweb-api-perl -- simple base module for implementing RESTful APIs

[Christopher Hoskin]

Package: wnpp
Owner: Christopher Hoskin 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libweb-api-perl
  Version : 2.2.3
  Upstream Author : Tobias Kirschstein 
* URL : https://metacpan.org/release/Web-API
* License : BSD-3-clause
  Programming Lang: Perl
  Description : simple base module for implementing RESTful APIs

Web::API is a simple base module to implement almost any RESTful API with just
a few lines of configuration. Implement the RESTful API of your choice in 10
minutes, roughly.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Re: Re: git-build-package broken? pristine-tar broken?

[Gaetano Guerriero]

Bug#888624: ITP: python-josepy -- JOSE implementation for Python

[Harlan Lieberman-Berg]

Package: wnpp
Severity: wishlist
Owner: Harlan Lieberman-Berg 

* Package name: python-josepy
  Version : 1.0.1
  Upstream Author : Certbot Team
* URL : https://pypi.python.org/pypi/josepy
* License : Apache-2.0
  Programming Lang: Python
  Description : JOSE implementation for Python

 This package is a Python implementation of the standards developed by
 IETF Javascript Object Signing and Encryption (Active WG), in
 particular the following RFCs:

 - JSON Web Algorithms (JWA)
 - JSON Web Key (JWK)
 - JSON Web Signature (JWS)

 This package was originally developed as part of the ACME protocol
 implementation in python-acme, but has now been split out into its
 own module.

Re: Reducing the attack surface caused by Berkeley DB...

[Lionel Debroux]

Hi David,

On 1/27/18 1:12 PM, David Kalnischkies wrote:
> On Fri, Jan 26, 2018 at 11:49:41PM +0100, Lionel Debroux wrote:
> > > Anyway, the only util in apt-utils making use of libdb is
> > > apt-ftparchive which a) isn't used much in Debian – but by some
> > > derivatives¹ and b) can operate without the backing of a db, but
> > > you don't want to run a large archive without it.
> >
> > Could that program conceivably be split to another package ?
>
> Not really. apt-utils includes three tools: apt-extracttemplates,
> apt-ftparchive and apt-sortpkgs. The later two should be together and
> the first one shouldn't even exist… it exists only temporary as
> a stopgap as long as there is no dpkg tool (which would be the more
> natural place for extracting files from a deb file)[0] for this task.
> In other words: We realized only later that its existence is
> permanent, like with all good temporary solutions.
Aha. And the page you mention shows that moving to dpkg the
functionality of apt-extracttemplates, which IIUC contributes more to
the popularity of apt-utils than the two other tools in that package,
has nontrivial work dependencies.

> Splitting packages now means that the split will reach effect at most
> in bullseye… (buster needs at least a recommends for upgraders, likely
> depends as there are tools like local-apt-repository depending on
> apt-utils to get apt-ftparchive) that might be a bit too far off for
> your case, especially as we haven't really gained anything by it. We
> just (literally) moved the problem.
Indeed, that would be literally moving the problem, though it might make
sense if it makes it easier to reach the main goals later.

But in this case, AIUI, adding support for another database backend with
suitable reliability, performance and security characteristics to
apt-ftparchive, which you hinted at earlier, would cause less disruption
than my possibly naive idea of splitting packages, wouldn't it ?

> [0] https://wiki.debian.org/Teams/Dpkg/RoadMap


Thanks,
Lionel.

Re: Reducing the attack surface caused by Berkeley DB...

[Lionel Debroux]

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.

Bug#888643: ITP: libmail-chimp3-perl -- interface to mailchimp.com's RESTful Web API v3

[Christopher Hoskin]

Package: wnpp
Owner: Christopher Hoskin 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmail-chimp3-perl
  Version : 0.04
  Upstream Author : Josh Lavin 
* URL : https://metacpan.org/release/Mail-Chimp3
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : interface to mailchimp.com's RESTful Web API v3

Mail::Chimp3 is a Perl package for interacting with The Rocket Science Group's
MailChimp service via its RESTful Web API v3.0. The package makes use of
WEB::API.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.