MIR: libgit2, http-parser

[Simon Chopin]

[Availability]
The packages libgit2 and http-parser are already in Ubuntu universe.
They both build for the architectures they are designed to work on.
They currently build and work for architectures: amd64 arm64 armhf i386 s390x ppc64el riscv64
Link to packages:
* [[https://launchpad.net/ubuntu/+source/http-parser]]
* [[https://launchpad.net/ubuntu/+source/libgit2]]

[Rationale]

libgit2 is needed in main as dependencies of src:cargo, and http-parser is a
dependency of libgit2. cargo will be the subject of a separate MIR. Given that
there are several non-trivial dependencies for cargo, I figured splitting them
up in multiple MIRs would make it easier.

Cargo itself will be MIRed as part of the effort to support Rust as a build language for
packages in main.

It would be great and useful to community/processes to have the packages
libgit2 and http-parser in Ubuntu main, but there is no definitive deadline.
In particular, they must not be promoted unless src:cargo enters the archive.

[Security]
The http-parser package originated as part of the nodejs project. Because of that,
while there are no CVE registered for http-parser itself, these CVEs were found that
affected the http-parser code. Sadly, it's usually not obvious which
the issue, only the release itself :slightly_frowning_face:.

* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2086: Fixed in 2.6.1. As evidenced by https://github.com/nodejs/http-parser/commit/e2e467b91262246b339fb3d80c8408d498b4a43b the fix was made privately within the nodeJS project and then backported in a "bulk" commit to the the separate http-parser project.
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2216: Fixed in 2.6.1. See above.
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7159: Fixed in 2.8.1 by https://github.com/nodejs/http-parser/commit/01da95feade5e5612499f5374498e7968c1a4a82, which was also discussed in private within the node project.
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12121: Only valid in the context of client code, the lib itself already provides the necessary APIs
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9900: Originated in envoyproxy but also discussed publicly and fixed in http-parser in 2.9.1 by https://github.com/nodejs/http-parser/pull/469
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8287: Fixed in Ubuntu, but not upstream, despite the fix available as a PR: https://github.com/nodejs/http-parser/pull/530

libgit2 is easier to analyze from a security history PoV, with a dedicated page to list their various security releases: https://libgit2.org/security/

Here are the CVEs that affected libgit2:

* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9390: First round of fix in 0.21.3, with a subsequent related release 0.22.1. Presumably the fixes are in the commits dated Dec 17, 2014 of https://github.com/libgit2/libgit2/commits/v0.21.3 and the last commits of https://github.com/libgit2/libgit2/commits/v0.22.1 . The vulnerability was widespread throughout the Git community, with pretty much all implementations vulnerables: https://git-blame.blogspot.com/2014/12/git-1856-195-205-214-and-221-and.html
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8568 and https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8569 are not listed on the upstream security page (perhaps not considered security issues because "only" DoS?) but were addressed in https://github.com/libgit2/libgit2/pull/3956 subsequently published in 0.24.3
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10128: Affecting 0.24, fixed in 0.24.6, see https://github.com/libgit2/libgit2/commit/4ac39c76c0153d1ee6889a0984c39e97731684b2
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10129 and https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10130 both fixed in 0.24.6 and 0.25.1, published in a bulk security fixes PR: https://github.com/libgit2/libgit2/pull/4076 presumably discussed on a private ML beforehand.
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8098 and https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8099 were fixed in 0.26.2 ( https://github.com/libgit2/libgit2/pull/4575 )
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10887 and https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10888 were both fixed in 0.27.3 in this PR: https://github.com/libgit2/libgit2/pull/4717 which presumably originated from private ML discussions beforehand.
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15501 (found by fuzzing from oss-fuzz) was fixed in releases 0.26.6 and 0.27.4, see https://github.com/libgit2/libgit2/pull/4756 and https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9406
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12278 and https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12279 (NTFS-related vulnerabilities) were both fixed in 0.28.4 and 0.99.0, while not mentioned on the upstream security page.
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1348 and up til https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1354 are all Git CVEs that were also adressed in 0.28.4 and 0.27.10

Please note that there are multiple items mentioned on the upstream security page that do not have an associated CVE.

- no `suid` or `sgid` binaries
- no executables in `/sbin` and `/usr/sbin`
- Packages do not install services, timers or recurring jobs
- Packages do not open privileged ports (ports < 1024)
- Packages do not contain extensions to security-sensitive software

[Quality assurance - function/usage]
As libraries, the packages work well after installation (both the -dev and actual binaries)

[Quality assurance - maintenance]

libgit2 is reasonably well-maintained in Debian, and has a proficient upstream community backed by multiple companies.
Bug lists:
- Ubuntu https://bugs.launchpad.net/ubuntu/+source/libgit2/+bug
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libgit2

There's only one relevant important bug in Debian for it:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990136

http-parser is much more problematic. The package is supported in Debian, see
- Ubuntu https://bugs.launchpad.net/ubuntu/+source/http-parser/+bug
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=http-parser

with the only outstanding important bug being
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914941
which is in fact not an issue for http-parser as a library, as the application level
has all the necessary APIs to modify the debated value. The CVE was only valid for
the particular case of nodejs.

However, the package has recently been explicitly declared unmaintained upstream.
The Foundations team is aware of this fact, and we have concluded internally that,
assuming Security team assent, we would take charge of the maintenance of the library
as long as it's needed by libgit2.

None of those packages deal with exotic hardware we cannot support.

[Quality assurance - testing]
Both packages have non-trivial test suites run at build-time such that their failure
entails build failure.

https://launchpadlibrarian.net/618827392/buildlog_ubuntu-kinetic-amd64.http-parser_2.9.4-5_BUILDING.txt.gz
https://launchpadlibrarian.net/610604824/buildlog_ubuntu-kinetic-amd64.libgit2_1.3.0+dfsg.1-3ubuntu1_BUILDING.txt.gz

RULE: - The package should, but is not required to, also contain
RULE: non-trivial autopkgtest(s).
libgit2 has only one autopkgtest which is relatively trivial (build against libgit2 and call one trivial function)
http-parser has only one autopkgtest that runs the package testsuite against the installed library.

Both packages only have failing tests on i386, which are being investigated
(failing due to i386 only being a partial architecture).

[Quality assurance - packaging]
Both packages have watchfiles, but the libgit2 doesn't seem to work anymore (ongoing investigation)

- debian/control defines a correct Maintainer field

You'll find recent build logs there:
https://launchpadlibrarian.net/618827392/buildlog_ubuntu-kinetic-amd64.http-parser_2.9.4-5_BUILDING.txt.gz
https://launchpadlibrarian.net/610604824/buildlog_ubuntu-kinetic-amd64.libgit2_1.3.0+dfsg.1-3ubuntu1_BUILDING.txt.gz

Lintian overrides are present in http-parser regarding the lack of upstream
changelog, but are now erroneous.
libgit2 defines one override, debian-watch-does-not-check-gpg-signature

None of these packages depend on obsolete packages.

The packages will not be installed by default

Packaging and build are easy:
https://sources.debian.org/src/libgit2/1.3.0%2Bdfsg.1-3/debian/rules/
https://sources.debian.org/src/http-parser/2.9.4-5/debian/rules/

[UI standards]
- Application is not end-user facing (does not need translation)
- End-user applications without desktop file, not needed because they are libraries.

[Dependencies]
- No further depends or recommends dependencies that are not yet in main

[Standards compliance]
- These packages correctly follows FHS and Debian Policy

[Maintenance/Owner]
- Foundations team is already subscribed to the packages
- This does not use static builds
- This does not use vendored code
- This package is not rust based
- The packages successfully built during the most recent test rebuild

[Background information]
The Package descriptions explains the package well
Upstream Name is libgit2, see https://libgit2.org/
http-parser used to be a nodejs project, now declared unmaintained,
see https://github.com/nodejs/http-parser

[Simon Chopin (schopin)]

Here are the http-parser lintian logs

[Simon Chopin (schopin)]

libgit2 lintian logs

[Didier Roche-Tolomelli (didrocks)]

Review for Package: libgit2

[Summary]
I can’t yet ACK the MIR based on the amount of work needed before getting it approved. Check for the Required and Recommended TODOs.
This will need a security review too, but I’m not assigning ubuntu-security right away as the version is not up to date, and some unpackaged releases contains multiple security fixes.

Also there is one question: do we want libgit2-fixtures to be promoted too?

Notes:
Required TODOs:
- as mentioned on the MIR, we need first http-parser to be approved in main.
- however, both -dev and binary package depends on libssh2-1 which is in universe. This one needs to be MIRed too or checked if we can swap with libssh-4.
- as mention on the initial report, the test suite for autopkgtests is kind of trivial. When we are going to introduce cargo, can we have some tests leveraging the library so that this is better covered by its reverse dependency?
- The 4 last upstream releases (some are many months old > 6 months) are not packaged. In particular, v 1.4.4 includes security fixes. This should be updated before taking any consideration on the security team side so that they check a recent code.
Recommended TODOs:
- There are a lot of warnings, making the logs very hard to read. The good news is that it seems that almost all of them are due to __atomic_exchange call. Can this be investigated?

[Duplication]
There is no other package in main providing the same functionality.

[Dependencies]
OK:
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems:
- as mentioned on the MIR, we need first http-parser to be approved in main.
- however, both -dev and binary package depends on libssh2-1 which is in universe. This one needs to be MIRed too or checked if we can swap with libssh-4.

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have unexpected Built-Using entries
- not a go package, no extra constraints to consider in that regard
- not a rust package, no extra constraints to consider in that regard

[Security]
OK:
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port/socket
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
- does not deal with security attestation (secure boot, tpm, signatures)
- does not deal with cryptography (en-/decryption, certificates, signing, ...)

Problems:
- long list, but mostly well handled history of CVEs. Due to that, I think a security review will always be beneficial.
- parse some data format (git history) from potentially untrusted sources. This is another advocate to have a security check.

[Common blockers]

OK:
- does not FTBFS currently
- does have a test suite that runs at build time
- test suite fails will fail the build upon error.
- no new python2 dependency

Problems:
- as mention on the initial report, the test suite for autopkgtests is kind of trivial. When we are going to introduce cargo, can we have some tests leveraging the library ...

[Simon Chopin (schopin)]

Regarding the new upstream versions, they seemingly bump SONAME on minor versions (1.X), which is why it's not followed closely. However, I'd missed the 1.3.1 and 1.3.2 CVEs, since they're assigned to git rather than libgit2 and not mentioned on their security page :-/. I've just uploaded a new version fixing that, as well as adressing the warnings and fixing the debian/watch file.

I hadn't mentioned excluding libgit2-fixtures because it's a fairly straightforward, self-contained package, but thinking on it a bit more it'd make sense to leave it in universe, otherwise it'd have to be independently seeded.

The libssh2 MIR is there, I'd forgotten that it's a libgit2 direct dependency in addition to cargo: https://bugs.launchpad.net/ubuntu/+source/libssh2/+bug/1991650

[Ioanna Alifieraki (joalif)]

Review for Package: http-parser

[Summary]
I cannot yet ACK or NACK this MIR until we discuss whether the project
not being maintained upstream is a blocker and any alternative solutions.

A few details about this:
* http-parser not maintained upstream. Upstream suggests using llhttp
(https://github.com/nodejs/llhttp)
* http-parser is a dependency of libgit2 so at the end of the day the
question is whether libgit2 will move from http-parser to llhttp.
* Foundations team is aware of the project being unmaintained upstream
and are willing to take charge of the maintenance
* The package is maintained in Debian (e.g the maintainer has pulled in
PRs including a CVE that haven't been merged upstream)

That said, IMO the project not being maintained anymore is not a huge
blocker since Foundations have agreed to take care of that and Debian
actively maintaining it.

This does need a security review, but I will not assign security-team until we decide
whether this is an ACK or NACK.

Please take a look at the recommended TODOs and address as many as possible.

List of specific binary packages to be promoted to main: libhttp-parser2.9, libhttp-parser-dev

Notes:
Recommended TODOs:
1. This is a trivial one concerning the use of malloc. In file contrib/parsetrace.c,
line 122, malloc is used and then the pointer is not checked if memory successfully
allocated before using it.

- The package should get a team bug subscriber before being promoted

[Duplication]
There is no other package in main providing the same functionality.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
  - http-parser checked with `check-mir`
  - all dependencies can be found in `seeded-in-ubuntu` (already in main)
  - none of the (potentially auto-generated) dependencies (Depends
    and Recommends) that are present after build are not in main
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems: None

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have unexpected Built-Using entries
- not a go package, no extra constraints to consider in that regard

Problems: None

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port/socket
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
- does not deal with security attestation (secure boot, tpm, signatures)
- does not deal with cryptography (en-/decryption, certificates, signing, ...)

Problems:
- does parse data formats (files [images, video, audio,
  xml, json, asn.1], network packets, structures, ...) from
  an untrusted source.
- does process arbitrary web content

[Common blockers]
OK:
- does not FTBFS currently
 - does have a test suite that runs at build time
 - test suite fails will fail the build upon error.
- does have a non-trivial test suite that runs as autopkgtest
- no new python2 dependency

Problems: None

[Packaging red flags]
OK:
- U...

[Ioanna Alifieraki (joalif)]

Re: http-parser

After discussing the maintenance problem is MIR meeting, this is an ACK.
I'll assign security-team since it needs sec review.

[Simon Chopin (schopin)]

Re: libgit2 trivial tests

The libgit2 test suite in 1.3.2 is mostly unit-tests, and cannot be run against the final .so, which makes it impractical for autopgktests. Luckily, in the 1.5.0 that just landed in Debian unstable there seem to be some integration tests as well that should be easier to use in that context, which I plan to investigate.

Meanwhile, src:cargo has an extensive test suite, including for its git-related features, and that test suite is run both at build time and in its autopkgtests.

Here are the two test files:

https://git.launchpad.net/~canonical-foundations/ubuntu/+source/cargo/tree/tests/testsuite/git_auth.rs?h=merge-0.62
https://git.launchpad.net/~canonical-foundations/ubuntu/+source/cargo/tree/tests/testsuite/git.rs?h=merge-0.62

While it doesn't cover the entirety of libgit2's feature set, at a glance I see commit, branch and tag creation, as well as submodule handling. The `cargo new` command also creates a new repo using libgit2, but it's not tested in that file.

Does that answer your concerns?

(tentatively marking libgit2 as Confirmed)

[Didier Roche-Tolomelli (didrocks)]

@schopin:
Thanks for the answers on testing/missing build-deps and fixing those. ACK on those notes. The only remaining one is:

> I've just uploaded a new version fixing that, as well as adressing the warnings and fixing the debian/watch file.

I don’t see this version in ubuntu, nor in debian or the unapproved queue. Am I missing anything? I think the security review should be based on the last one and that will help confirming the error/warnings are fixed.

(Please do not change the status, it’s better for the MIR team to set it as such, or you can switch it back to NEW)

[Simon Chopin (schopin)]

I'm talking about this version:
https://launchpad.net/ubuntu/+source/libgit2/1.3.2+dfsg.1-0ubuntu1

FFe bug: https://bugs.launchpad.net/ubuntu/+source/libgit2/+bug/1991636

It'd been stuck for a few days in -proposed and migrated around the time of your post.

[Didier Roche-Tolomelli (didrocks)]

Excellent! This is a ack from the MIR team. Assigning to security.

[Mark Esler (eslerm)]

cargo and dh-cargo are no longer being promoted to main: https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/1957932

Unassigning Security Team as rationale is no longer valid.

[Mark Esler (eslerm)]

Reassigning Security for cargo's https://bugs.launchpad.net/ubuntu/+source/cargo/+bug/1993819

[David Fernandez Gonzalez (litios)]

I reviewed libgit2 1.5.1+ds-1ubuntu1 as checked into mantic. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

Upstream: https://github.com/libgit2/libgit2

libgit2 is a portable, pure C implementation of the Git core methods provided as a re-entrant
linkable library with a solid API, allowing you to write native speed custom Git applications
in any language that supports C bindings.

- CVE History:
  * 14 CVEs, 11 of them are from the 2016-2018 period.
  * Since 2018 the only 3 CVEs found are NFTS-related or certs-related.
  * Only one in the last 3 years (cert-related)
  * In some cases, fixes have been backported officially.
- Build-Depends?
  * debhelper-compat (= 13), python3-minimal:any, pkg-config, ca-certificates, cmake, zlib1g-dev,
    libssl-dev, libssh2-1-dev, libhttp-parser-dev, libpcre2-dev, libkrb5-dev
  * It uses libssl, libssh, libhttp-parser, krb5.
- pre/post inst/rm scripts?
  * None.
- init scripts?
  * None.
- systemd units?
  * None.
- dbus services?
  * None.
- setuid binaries?
  * None.
- binaries in PATH?
  * None.
- sudo fragments?
  * None.
- polkit files?
  * None.
- udev rules?
  * None.
- unit tests / autopkgtests?
  * Autopkgtest test only checks if the library can be loaded and calls version retrieval.
  * It has extensive unit tests, they are run at build time.
- cron jobs?
  * None.
- Build logs:
  * Warn/Error on build logs:
    * Cmake warnings regarding unused variables.
    * Build warning about uninitialized variables, deprecated SSH functions.
  * Some lintian errors on examples (fixture binary).

- Processes spawned?
  * The library does not spawn any processes.
- Memory management?
  * Memory is handled with care, always performing checks and validating the
    return values.
  * Specific structs have been created to manage memory more safely, like
    git_str.
  * Specific macros/functions have been created to perform sensitive operations
    in the safest way possible.
- File IO?
  * File paths are recontstructed from the Git tree.
    If someone can modify the .git tree files then they already have access.
    No security issues.
  * File contents are not sanitized, as expected.
  * Files are created with the umask specified in the Git object.
- Logging?
  * Yes, most of the output is handled by git_str_printf, which does it safely.
- Environment variable usage?
  * They are not sanitized but they don't look like they could be abused.
  * Main use case is reading specific Git env variables or getting the home directory.
- Use of privileged functions?
  * None.
- Use of cryptography / random number sources etc?
  * It relies on libssh2 to perform most of the ssh handling.
  * It relies on openssl for https and sha functions.
  * They do certificate check by default since CVE-2023-22742, but before it would be
    possible to do it if specified.
  * There is hostname checking against cert in verify_server_cert.
- Use of temp files?
  * None.
- Use of networking?
  * Network is used for sync with remote repositories.
  * Input is not filtered/sanitized but that's expected.
- Use of WebKit?
  * None.
- Use of PolicyKit?
  * None.

- Any significant cppcheck result...

[Mark Esler (eslerm)]

The following was written by sahnaseredini:

I reviewed http-parser 2.9.4-5 as checked into lunar. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

http-parser is a parser for http requests/responses.

- CVE History:
  - history of CVEs does not look concerning
  - only one CVE (CVE-2020-8287) which does not seem to be critical
  - The time window between the report date to commiting the patch is around
    two months
- Build-Depends?
  - libc6
- pre/post inst/rm scripts?
  - none
- init scripts?
  - none
- systemd units?
  - none
- dbus services?
  - none
- setuid binaries?
  - none
- binaries in PATH?
  - none
- sudo fragments?
  - none
- polkit files?
  - none
- udev rules?
  - none
- unit tests / autopkgtests?
  - does have a test suite that runs at build time
     - test suite fails will fail the build upon error.
  - does have a non-trivial test suite that runs as autopkgtest
  - CAN YOU SUCCESSFULLY RUN THEM LOCALLY?
    - Yes
- cron jobs?
  - none
- Build logs:
  - ERRORS / WARNINGS?
    - none
  - LINTIAN FAILURES?
      - E: libhttp-parser2.9: malformed-override Unknown tag no-upstream-changelog in line 2

- Processes spawned?
  - none
- Memory management?
  - it uses `malloc` once in a standard way in c
- File IO?
  - they use `fopen` once in a standard way in c
- Logging?
  - looks careful and safe
- Environment variable usage?
  - none
- Use of privileged functions?
  - none
- Use of cryptography / random number sources etc?
  - none
- Use of temp files?
  - none
- Use of networking?
  - Does not directly use the network
- Use of WebKit?
  - none
- Use of PolicyKit?
  - none

- Any significant cppcheck results?
  - none (only on tests!)
- Any significant Coverity results?
  - none
- Any significant shellcheck results?
  - none
- Any significant bandit results?
  - none
- Any significant govulncheck results?
  - N/A

The package (http-parser) is currently not actively maintained.
  - [*Link to the announcement*](https://github.com/nodejs/http-parser/issues/522)
  - [*Link to the package*](https://github.com/nodejs/node/tree/fc70ce08f5818a286fb5899a1bc3aff5965a745e/deps/http_parser)
  - They recommend using [*llhttp*](https://github.com/nodejs/llhttp) and claim that it has
    similar API, feature parity, well maintained and in active use!

Security team propose a conditional ACK for promoting http-parser to main
upon Foundations team's acknowledgment of their commitment in assisting with
the development of security fixes, in the absence of upstream support, as
well as their responsibility to ask for demoting the pacakge in the future
once a suitable alternative is identified and deemed feasible.

[Lukas Märdian (slyon)]

Looks like both of those are (almost) ready.

libgit2: MIR ACK, comment #10 -- SEC ACK, comment #13
http-parser: MIR ACK, comment #6 -- SEC ACK (conditional), comment #14

[Zixing Liu (liushuyu-011)]

> Security team propose a conditional ACK for promoting http-parser to main
> upon Foundations team's acknowledgment of their commitment in assisting with
> the development of security fixes, in the absence of upstream support, as
> well as their responsibility to ask for demoting the pacakge in the future
> once a suitable alternative is identified and deemed feasible.

`http-parser` is required by `libgit2`, which will be replaced by `gitoxide` in
the (not so near) future.

I wonder what responsibilities go with "assisting with the development
of security fixes"? Does the Foundations team need to look for security
issues and vulnerabilities actively?

The Foundations team will take the responsibility to ask for demoting
the package in the future should Cargo switches to `gitoxide`.

[Seth Arnold (seth-arnold)]

Hello Zixing, we're not expecting Foundations to take on active SAST, DAST, test-case development, or code review, to proactively find security issues as part of this MIR process -- but we are expecting that Foundations will dedicate time to issues in this package as they are found if the fixes require "enough" time.

There's a wide spectrum of possible security issues from eg integer overflows that can be fixed with a single line of code through to monster refactors that change internal datastructures and algorithms extensively (hello samba!).

In the ideal case, this will be replaced with a supported parser before the next LTS and we'll never ask for any help.

I would expect in a project like this that an even really gross issue could be sorted -- or mitigated via removing features, etc -- with a week's effort. And there's probably only a few of those problems in this package. So think of it as potentially a week's engineering time every cycle. It'll probably never happen, but if it does, we'd want a response commensurate with our prioritization.

Thanks

[Seth Arnold (seth-arnold)]

Zixing has mentioned in 2023-09-12 MIR team meeting that replacing http-parse with llhttp is another possibility: in case the foundations team can't address a security issue in http-parse, they can replace the library in its entirety in cargo. But rather than front-load this work, we hold off on the switch until such time as http-parse is found to be harder to fix than to replace.

Thanks

[Zixing Liu (liushuyu-011)]

Hi, Security Team and MIR Team,

For the record:

The Foundations Team is committed to assisting with developing security fixes should upstream abandon the project or demote the package if an alternative (likely gitoxide) is identified in the future.

[Mark Esler (eslerm)]

thanks for confirming Zixing

since rustc (containing cargo) has already been promoted in LP#1993819, please promote this ack'd dependency

[Didier Roche-Tolomelli (didrocks)]

With the above discussion and rationale from the MIR and Security team, changing then the status of http-parser as it is ready to be promoted.

[Steve Langasek (vorlon)]

Override component to main
http-parser 2.9.4-6 in mantic: universe/misc -> main
libhttp-parser-dev 2.9.4-6 in mantic amd64: universe/libdevel/extra/100% -> main
libhttp-parser-dev 2.9.4-6 in mantic arm64: universe/libdevel/extra/100% -> main
libhttp-parser-dev 2.9.4-6 in mantic armhf: universe/libdevel/extra/100% -> main
libhttp-parser-dev 2.9.4-6 in mantic i386: universe/libdevel/extra/100% -> main
libhttp-parser-dev 2.9.4-6 in mantic ppc64el: universe/libdevel/extra/100% -> main
libhttp-parser-dev 2.9.4-6 in mantic riscv64: universe/libdevel/extra/100% -> main
libhttp-parser-dev 2.9.4-6 in mantic s390x: universe/libdevel/extra/100% -> main
libhttp-parser2.9 2.9.4-6 in mantic amd64: universe/libs/optional/100% -> main
libhttp-parser2.9 2.9.4-6 in mantic arm64: universe/libs/optional/100% -> main
libhttp-parser2.9 2.9.4-6 in mantic armhf: universe/libs/optional/100% -> main
libhttp-parser2.9 2.9.4-6 in mantic i386: universe/libs/optional/100% -> main
libhttp-parser2.9 2.9.4-6 in mantic ppc64el: universe/libs/optional/100% -> main
libhttp-parser2.9 2.9.4-6 in mantic riscv64: universe/libs/optional/100% -> main
libhttp-parser2.9 2.9.4-6 in mantic s390x: universe/libs/optional/100% -> main
libgit2 1.5.1+ds-1ubuntu1 in mantic: universe/libs -> main
libgit2-1.5 1.5.1+ds-1ubuntu1 in mantic amd64: universe/libs/optional/100% -> main
libgit2-1.5 1.5.1+ds-1ubuntu1 in mantic arm64: universe/libs/optional/100% -> main
libgit2-1.5 1.5.1+ds-1ubuntu1 in mantic armhf: universe/libs/optional/100% -> main
libgit2-1.5 1.5.1+ds-1ubuntu1 in mantic i386: universe/libs/optional/100% -> main
libgit2-1.5 1.5.1+ds-1ubuntu1 in mantic ppc64el: universe/libs/optional/100% -> main
libgit2-1.5 1.5.1+ds-1ubuntu1 in mantic riscv64: universe/libs/optional/100% -> main
libgit2-1.5 1.5.1+ds-1ubuntu1 in mantic s390x: universe/libs/optional/100% -> main
libgit2-dev 1.5.1+ds-1ubuntu1 in mantic amd64: universe/libdevel/extra/100% -> main
libgit2-dev 1.5.1+ds-1ubuntu1 in mantic arm64: universe/libdevel/extra/100% -> main
libgit2-dev 1.5.1+ds-1ubuntu1 in mantic armhf: universe/libdevel/extra/100% -> main
libgit2-dev 1.5.1+ds-1ubuntu1 in mantic i386: universe/libdevel/extra/100% -> main
libgit2-dev 1.5.1+ds-1ubuntu1 in mantic ppc64el: universe/libdevel/extra/100% -> main
libgit2-dev 1.5.1+ds-1ubuntu1 in mantic riscv64: universe/libdevel/extra/100% -> main
libgit2-dev 1.5.1+ds-1ubuntu1 in mantic s390x: universe/libdevel/extra/100% -> main
libgit2-fixtures 1.5.1+ds-1ubuntu1 in mantic amd64: universe/libs/optional/100% -> main
libgit2-fixtures 1.5.1+ds-1ubuntu1 in mantic arm64: universe/libs/optional/100% -> main
libgit2-fixtures 1.5.1+ds-1ubuntu1 in mantic armhf: universe/libs/optional/100% -> main
libgit2-fixtures 1.5.1+ds-1ubuntu1 in mantic i386: universe/libs/optional/100% -> main
libgit2-fixtures 1.5.1+ds-1ubuntu1 in mantic ppc64el: universe/libs/optional/100% -> main
libgit2-fixtures 1.5.1+ds-1ubuntu1 in mantic riscv64: universe/libs/optional/100% -> main
libgit2-fixtures 1.5.1+ds-1ubuntu1 in mantic s390x: universe/libs/optional/100% -> main
37 publications overridden.

[Mark Esler (eslerm)]

http-parser has been deprecated [0] for llhttp [1] in libgit2 \o/

[0] https://github.com/libgit2/libgit2/issues/6074
[1] https://github.com/libgit2/libgit2/pull/6713