** Description changed: [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).
-- You received this bug notification because you are a member of Ubuntu Server, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1638957 Title: [MIR] http-parser, dependency of sssd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/http-parser/+bug/1638957/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
