Web lists-archives.com

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




On Fri, Jan 26, 2018 at 12:24:26PM +0100, Miriam Ruiz wrote:
> 2018-01-26 12:02 GMT+01:00 Colin Watson <cjwatson@xxxxxxxxxx>:
> >> 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

Attachment: signature.asc
Description: PGP signature