Bug#1053931: restinio: [src:restinio] Uses embedded code copies

[Amin Bandali]

Hi Tobi,

Thanks for the report. :-)

I just uploaded 0.6.19+ds-1 to unstable, repacking the
orig upstream tarball to remove several embedded copies;
namely:

- dev/asio/*
- dev/fmt/*
- dev/nodejs/http_parser/*
- dev/rapidjson/*
- dev/restinio/third_party/zlib/*

I believe none of these were actually being used, but
as you said, it's good to remove them to be sure of that.

dev/catch2/ is a bit more tricky, because restinio is currently only
compatible with the v2 series, whereas catch2 has released their v3
series (packaged in unstable as well), which appears to be backward
incompatible with v2.  Per restinio developers[1], adapting restinio
to catch2 v3 may be a non-trivial effort, and will have to wait until
they start work on their next major series.  As such, it seems we'll
have to continue including dev/catch2/ for a while longer until
restinio developers get around to porting restinio to catch v3.
So, I didn't close this bug in the changelog entry for 0.6.19+ds-1,
but will keep an eye on the situation for when restinio is ported to
catch2, at which point I'd make the change to exclude it from the
tarball as well and use the system package.

Best,
-a

[1] https://github.com/Stiffstream/restinio/issues/158

Bug#1053931: restinio: [src:restinio] Uses embedded code copies

[Tobias Frost]

Source: restinio
Severity: important

Hi,

restino uses embedded code copies. This is against policy 4.13.

The directory dev/* contains for example
- catch2
- rapidjson
- nodejs/http_parser

There is also dev/restinio/third_party/zlib, which claims to be
  version 1.2.11, January 15th, 2017
This version might be suspectible to several security vulnerabilties.
I've not checked if it is used, though.

catch2 is declared as Build-Depends, but obviously not used:
When removing catch2, the package FTBFS.

Please use the packaged version whenever possible and to make sure
that they are used, remove the embedded code copies before building,
e.g in d/clean.

(Alternatively, repackaging the source package, would be possible,
as there is currently no upstream signature to verify)

Cheers,
tobi