| 2016-11-03 15:27:45 |
Matthias Klose |
bug |
|
|
added bug |
| 2016-11-03 15:28:10 |
Matthias Klose |
http-parser (Ubuntu): assignee |
|
Ubuntu Server Team (ubuntu-server) |
|
| 2016-11-03 15:28:22 |
Matthias Klose |
http-parser (Ubuntu): importance |
Undecided |
High |
|
| 2016-11-03 15:28:32 |
Matthias Klose |
http-parser (Ubuntu): milestone |
|
ubuntu-16.11 |
|
| 2016-11-03 15:28:47 |
Matthias Klose |
bug |
|
|
added subscriber MIR approval team |
| 2016-11-03 17:52:55 |
Michael Terry |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795492 |
|
| 2016-11-23 22:31:06 |
Joshua Powers |
bug |
|
|
added subscriber Ubuntu Server Team |
| 2017-01-17 17:31:43 |
Michael Terry |
http-parser (Ubuntu): assignee |
Ubuntu Server Team (ubuntu-server) |
Ubuntu Security Team (ubuntu-security) |
|
| 2017-02-07 19:34:33 |
Robie Basak |
bug |
|
|
added subscriber Robie Basak |
| 2017-02-21 08:55:13 |
Timo Aaltonen |
http-parser (Ubuntu): status |
Incomplete |
Confirmed |
|
| 2017-02-21 08:55:13 |
Timo Aaltonen |
http-parser (Ubuntu): milestone |
ubuntu-16.11 |
|
|
| 2017-02-21 08:55:52 |
Timo Aaltonen |
http-parser (Ubuntu): milestone |
|
ubuntu-17.04 |
|
| 2017-06-20 15:16:24 |
Mathieu Trudel-Lapierre |
http-parser (Ubuntu): milestone |
ubuntu-17.04 |
ubuntu-17.10 |
|
| 2017-08-05 02:43:29 |
Seth Arnold |
bug |
|
|
added subscriber Seth Arnold |
| 2017-08-05 02:43:34 |
Seth Arnold |
http-parser (Ubuntu): assignee |
Ubuntu Security Team (ubuntu-security) |
|
|
| 2018-02-02 07:40:15 |
Christian Ehrhardt |
bug |
|
|
added subscriber Andreas Hasenack |
| 2018-02-02 07:40:33 |
Christian Ehrhardt |
bug |
|
|
added subscriber Timo Aaltonen |
| 2018-03-06 15:12:40 |
Andreas Hasenack |
description |
[MIR] http-parser, dependency of sssd |
[Availability]
[Rationale]
[Security]
[Quality assurance]
[Dependencies]
[Standards compliance]
[Maintenance]
[Background information] |
|
| 2018-03-06 15:14:55 |
Andreas Hasenack |
description |
[Availability]
[Rationale]
[Security]
[Quality assurance]
[Dependencies]
[Standards compliance]
[Maintenance]
[Background information] |
[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
[Rationale]
[Security]
[Quality assurance]
[Dependencies]
[Standards compliance]
[Maintenance]
[Background information] |
|
| 2018-03-08 14:00:29 |
Andreas Hasenack |
description |
[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
[Rationale]
[Security]
[Quality assurance]
[Dependencies]
[Standards compliance]
[Maintenance]
[Background information] |
[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
[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
[Security]
[Quality assurance]
[Dependencies]
[Standards compliance]
[Maintenance]
[Background information] |
|
| 2018-03-08 14:07:09 |
Andreas Hasenack |
description |
[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
[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
[Security]
[Quality assurance]
[Dependencies]
[Standards compliance]
[Maintenance]
[Background information] |
[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
[Security]
ubuntu-security review in comment https://bugs.launchpad.net/ubuntu/+source/http-parser/+bug/1638957/comments/9
[Quality assurance]
[Dependencies]
[Standards compliance]
[Maintenance]
[Background information] |
|
| 2018-03-08 14:08:54 |
Andreas Hasenack |
description |
[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
[Security]
ubuntu-security review in comment https://bugs.launchpad.net/ubuntu/+source/http-parser/+bug/1638957/comments/9
[Quality assurance]
[Dependencies]
[Standards compliance]
[Maintenance]
[Background information] |
[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
[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.
[Quality assurance]
[Dependencies]
[Standards compliance]
[Maintenance]
[Background information] |
|
| 2018-03-08 14:13:16 |
Andreas Hasenack |
description |
[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
[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.
[Quality assurance]
[Dependencies]
[Standards compliance]
[Maintenance]
[Background information] |
[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
[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.
[Quality assurance]
[Dependencies]
libhttp-parser2.7.1
Reverse Depends:
libhttp-parser-dev
tcpflow-nox
tcpflow
tang-nagios
tang
ruby-http-parser.rb
purple-matrix
ocserv
jabberd2
libgit2-26
[Standards compliance]
[Maintenance]
[Background information] |
|
| 2018-03-08 14:33:53 |
Andreas Hasenack |
description |
[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
[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.
[Quality assurance]
[Dependencies]
libhttp-parser2.7.1
Reverse Depends:
libhttp-parser-dev
tcpflow-nox
tcpflow
tang-nagios
tang
ruby-http-parser.rb
purple-matrix
ocserv
jabberd2
libgit2-26
[Standards compliance]
[Maintenance]
[Background information] |
[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
[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.
[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.
There are no open debian bug reports.
[Dependencies]
libhttp-parser2.7.1
Reverse Depends:
libhttp-parser-dev
tcpflow-nox
tcpflow
tang-nagios
tang
ruby-http-parser.rb
purple-matrix
ocserv
jabberd2
libgit2-26
[Standards compliance]
[Maintenance]
[Background information] |
|
| 2018-03-08 14:40:40 |
Andreas Hasenack |
description |
[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
[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.
[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.
There are no open debian bug reports.
[Dependencies]
libhttp-parser2.7.1
Reverse Depends:
libhttp-parser-dev
tcpflow-nox
tcpflow
tang-nagios
tang
ruby-http-parser.rb
purple-matrix
ocserv
jabberd2
libgit2-26
[Standards compliance]
[Maintenance]
[Background information] |
[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
[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.
[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.
There are no open debian bug reports.
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
[Dependencies]
libhttp-parser2.7.1
Reverse Depends:
libhttp-parser-dev
tcpflow-nox
tcpflow
tang-nagios
tang
ruby-http-parser.rb
purple-matrix
ocserv
jabberd2
libgit2-26
[Standards compliance]
[Maintenance]
[Background information] |
|
| 2018-03-08 14:43:56 |
Andreas Hasenack |
description |
[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
[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.
[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.
There are no open debian bug reports.
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
[Dependencies]
libhttp-parser2.7.1
Reverse Depends:
libhttp-parser-dev
tcpflow-nox
tcpflow
tang-nagios
tang
ruby-http-parser.rb
purple-matrix
ocserv
jabberd2
libgit2-26
[Standards compliance]
[Maintenance]
[Background information] |
[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
[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.
[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.
There are no open debian bug reports.
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
[Dependencies]
libhttp-parser2.7.1
Reverse Depends:
libhttp-parser-dev
tcpflow-nox
tcpflow
tang-nagios
tang
ruby-http-parser.rb
purple-matrix
ocserv
jabberd2
libgit2-26
* 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)
[Standards compliance]
[Maintenance]
[Background information] |
|
| 2018-03-08 14:57:10 |
Andreas Hasenack |
description |
[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
[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.
[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.
There are no open debian bug reports.
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
[Dependencies]
libhttp-parser2.7.1
Reverse Depends:
libhttp-parser-dev
tcpflow-nox
tcpflow
tang-nagios
tang
ruby-http-parser.rb
purple-matrix
ocserv
jabberd2
libgit2-26
* 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)
[Standards compliance]
[Maintenance]
[Background information] |
[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
[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.
[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]
[Background information] |
|
| 2018-03-08 15:01:28 |
Andreas Hasenack |
description |
[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
[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.
[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]
[Background information] |
[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
[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.
[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). |
|
| 2018-03-08 15:05:58 |
Andreas Hasenack |
description |
[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
[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.
[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). |
[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
[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). |
|
| 2018-03-08 15:42:16 |
Andreas Hasenack |
tags |
zesty |
bionic |
|
| 2018-03-08 15:58:01 |
Andreas Hasenack |
description |
[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
[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). |
[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). |
|
| 2018-03-08 15:58:45 |
Eric Desrochers |
bug |
|
|
added subscriber Eric Desrochers |
| 2018-03-21 15:30:22 |
Nish Aravamudan |
http-parser (Ubuntu): assignee |
|
Nish Aravamudan (nacc) |
|
| 2018-03-21 16:15:38 |
Nish Aravamudan |
http-parser (Ubuntu): status |
Confirmed |
Fix Committed |
|
| 2018-03-21 19:22:11 |
Steve Langasek |
http-parser (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2018-03-21 19:22:11 |
Steve Langasek |
http-parser (Ubuntu): milestone |
ubuntu-17.10 |
|
|
