[MIR] http-parser, dependency of sssd

[Availability]
Package is in universe since trusty:

$ rmadison http-parser
 http-parser | 2.1-2 | trusty/universe | source
 http-parser | 2.1-2 | xenial/universe | source
 http-parser | 2.1-2 | artful/universe | source
 http-parser | 2.7.1-2 | bionic/universe | source

Upstream: https://github.com/nodejs/http-parser

[Rationale]
sssd uses http-parser in its sssd-secrets service [https://docs.pagure.org/SSSD.sssd/design_pages/secrets_service.html], which has a REST API over a unix socket.

The Debian sssd package has the secrets service enabled, and disabling it in the Ubuntu package is part of the delta we carry.

The secrets service can be used as a generic key/value database for secrets, and one of its users is a kerberos KDC via KCM (Kerberos Cache Manager), implemented by sssd-kcm.

sssd-secrets is unix socket activated and won't be running until there is a connection to that socket.

The goal of this MIR is then twofold:
a) drop a delta we have with regards to debian
b) provide the sssd-secrets service for Ubuntu users

bug #1754365 has an MP and tests for the sssd-secrets service.

[Security]
ubuntu-security review in comment https://bugs.launchpad.net/ubuntu/+source/http-parser/+bug/1638957/comments/9

There are still no CVEs for http-parser or libhttp-parser.

OSS security mailing list search returns no hits for http-parser or libhttp-parser

No hits on the Ubuntu CVE Tracker.

No security relevant binaries in the package. The only indirect security implication is that this enables a new service in sssd: sssd-secrets, used to store secrets by wanting applications.

[Quality assurance]
 * After installing the package it must be possible to make it working with a reasonable effort of configuration and documentation reading.
It's a library and it installs without further configuration.

 * The package must not ask debconf questions higher than medium if it is going to be installed by default. The debconf questions must have reasonable defaults.
There are no debconf questions needed.

 * There are no long-term outstanding bugs which affect the usability of the program to a major degree. To support a package, we must be reasonably convinced that upstream supports and cares for the package.
There are 3 ubuntu open bugs, of which this is one, and no closed bugs. These are the other 2 bugs:
bug #1677865: missing dep8 tests
bug #1733554: disable a failing test, caused by new http-parser

That last bug is a bit scarce on details.

 * The status of important bugs in Debian's, Ubuntu's, and upstream's bug tracking systems must be evaluated. Important bugs must be pointed out and discussed in the MIR report.

Debian has the same bug open regarding the failing test:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882308

There are, as of now, 27 open issues in upstream's bug tracker:
https://github.com/nodejs/http-parser/issues

 * The package is maintained well in Debian/Ubuntu (check out the Debian PTS)
The low number of bugs may indicate it's not used a lot, or that it's not maintained at all.

A good number of upstream bugs have feedback.

* The package should not deal with exotic hardware which we cannot support.
Not the case here.

* If the package ships a test suite, and there is no obvious reason why it cannot work during build (e. g. it needs root privileges or network access), it should be run during package build, and a failing test suite should fail the build.
The test suite runs at package build time:
   dh_auto_test
 make -j4 test
make[1]: Entering directory '/home/ubuntu/http-parser-2.7.1'
cc -Wdate-time -D_FORTIFY_SOURCE=2 -I. -DHTTP_PARSER_STRICT=1 -g -O2 -fdebug-prefix-map=/home/ubuntu/http-parser-2.7.1=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wextra -Werror -O0 -g -c http_parser.c -o http_parser_g.o
cc -Wdate-time -D_FORTIFY_SOURCE=2 -I. -DHTTP_PARSER_STRICT=1 -g -O2 -(...)
./test_g
http_parser v2.7.1 (0x020701)
sizeof(http_parser) = 32
response scan 1/2 100%
response scan 2/2 100%
responses okay
request scan 1/4 100%
request scan 2/4 100%
request scan 3/4 100%
request scan 4/4 100%
requests okay
./test_fast
http_parser v2.7.1 (0x020701)
sizeof(http_parser) = 32
response scan 1/2 100%
response scan 2/2 100%
responses okay
request scan 1/4 100%
request scan 2/4 100%
request scan 3/4 100%
request scan 4/4 100%
requests okay

* The package uses a debian/watch file whenever possible. In cases where this is not possible (e. g. native packages), the package should either provide a debian/README.source file or a debian/watch file (with comments only) providing clear instructions on how to generate the source tar file.
There is a debian/watch file:
version=3

https://github.com/joyent/http-parser/tags .*/v?(\d.*)\.(?:tgz|tbz2|tar\.(?:gz|bz2|xz))

* The package should not rely on obsolete or about to be demoted packages. That currently includes package dependencies on Python2 (without providing Python3 packages), and packages depending on GTK2.
The only dependency of the library binary is libc6:
$ dpkg --info libhttp-parser2.7.1_2.7.1-2_amd64.deb|grep ^\ Depends
 Depends: libc6 (>= 2.2.5)

The dev package only depends on the counterpart binary package:
$ dpkg --info libhttp-parser-dev_2.7.1-2_amd64.deb |grep ^\ Depends
 Depends: libhttp-parser2.7.1 (= 2.7.1-2)

[Dependencies]
* All binary dependencies (including Recommends:) must be satisfiable in main (i. e. the preferred alternative must be in main). If not, these dependencies need a separate MIR report (this can be a separate bug or another task on the main MIR bug)
From d/control:
Build-Depends: debhelper (>= 10~), dh-exec
There are no recommends or suggests.
Runtime Depends is only libc6, automatically selected.

[Standards compliance]
* The package should meet the FHS and Debian Policy standards. Major violations should be documented and justified. Also, the source packaging should be reasonably easy to understand and maintain.
From d/control:
Standards-Version: 4.1.1
There don't seem to be any standards violations.

[Maintenance]
This is a simple library package, which produces just two binary packages: the library itself and the dev package.
It's a straight sync from debian.

[Background information]
The summary and description of the package are well described:
Description: parser for HTTP messages written in C
 It parses both requests and responses. The parser is designed to be used in
 performance HTTP applications. It does not make any syscalls nor allocations,
 it does not buffer data, it can be interrupted at anytime. Depending on your
 architecture, it only requires about 40 bytes of data per message stream (in
 a web server that is per connection).