Review for package: cargo

List of specific binary packages to be promoted to main was proposed only cargo, but cargo-doc could go as well IMHO.

MIR team ACK given the constaint of having the security-review processed as it downloads crate from the Internet and acked and the Required TODOs processed
Notes:
Required TODOs:
- There is no autopkgtests and the bug description has a "TODO: cargo autopkgtest that creates a new crate, adds a simple dependency
(anyhow is a good candidate, no transitive deps), vendors it, builds the binary from the vendored crate, and runs it."
I suggest either proceeding with this plan OR write a manual tests before release. I think the autopkgtest has a benefit impact as it will validate rdeps.
- debian/copyright is not correct. For instance  vendor/libgit2-sys/ is listed as Apache2/MIT, but it’s distributed under the GNU GPL v2 with a Linking Exception. The linking exception does not mention Apache2/MIT explicitly but give you unlimited permission to link the compiled version of this library into combinations with other programs, and to distribute those combinations without any restriction coming from the use of this file. I do not think Apache2/MIT is completely accurate and debian/copyright should reflect GPL2 + Linking exception.
A lot of other files are in a similar situation and I suggest you to refresh the debian/copyright file. Maybe I’m wrong and this is a valid "relicensing" in that case, but I would prefer that to be stated explicitly.


Recommended TODOs:
- Ubuntu does carry a delta since November 2020, which could be large. It would be good to either resync or decide that we diverged from it forever (and so, considering remerging rustc and cargo together)
- One lintian error is about a malformed override. It would be good looking into this.
- the vendor directory has 2 files which were due to patch failure:
W: cargo source: debian-adds-patch-failure-file vendor/libnghttp2-sys/build.rs.orig
W: cargo source: debian-adds-patch-failure-file vendor/openssl-sys/Cargo.toml.rej
Would be good to fix those.
- Have a look if the numerous warnings are reported usptream and if they are worked on.

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

[Dependencies]
OK:
- no other Dependencies to MIR due to this outside rustc, which is part of the MIR
   - checked with check-mir
   - not listed in seeded-in-ubuntu
   - 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.

[Embedded sources and static linking]
OK:
- no embedded source present
- some static linking, but it’s rustc as part of rust synced source.
- does not have odd Built-Using entries

OK:
- not a go package, no extra constraints to consider in that regard
- vendoring is used, but the reasoning is obvious due to rustc being split as a separate package by debian.

[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 parse data formats
- does not open a port/socket
- does not process arbitrary web content
- 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)

[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:
- There is no autopkgtests and the bug description has a "TODO: cargo autopkgtest that creates a new crate, adds a simple dependency
(anyhow is a good candidate, no transitive deps), vendors it, builds the binary from the vendored crate, and runs it."
I suggest either proceeding with this plan OR write a manual tests before release. I think the autopkgtest has a benefit impact as it will validate rdeps.TODO-A: - TBD

[Packaging red flags]
OK:
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok (if needed, e.g. non-native)
- Upstream update history is good
- Debian/Ubuntu update history is good
- we are one release behind, but the release cycle is very quick, so ok
- promoting this does not seem to cause issues for MOTUs that so far  maintained the package
TODO: - no massive Lintian warnings not explained in the description
- d/rules is complex but rather clean
- It is not on the lto-disabled list
)

Problems:
- Ubuntu does carry a delta since November 2020, which could be large. It would be good to either resync or decide that we diverged from it forever (and so, considering remerging rustc and cargo together)
- One lintian error is about a malformed override. It would be good looking into this.
- the vendor directory has 2 files which were due to patch failure:
W: cargo source: debian-adds-patch-failure-file vendor/libnghttp2-sys/build.rs.orig
W: cargo source: debian-adds-patch-failure-file vendor/openssl-sys/Cargo.toml.rej
Would be good to fix those.


[Upstream red flags]
OK:
- no incautious use of malloc/sprintf (as far as we can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (usage is OK inside
  tests)
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks
- no translation present, but given the usage not being the finale user, this is ok.

Problems:
- There are a lot of warnings during the package build due to vendored dependencies. Are those logged/worked on upstream?