Comment 7 for bug 2061217

Review for Source Package: python-boto3

[Summary]
MIR team ACK under the constraint to resolve the below listed
required TODOs and as much as possible having a look at the
recommended TODOs.

List of specific binary packages to be promoted to main: python3-boto3

Specific binary packages built, but NOT to be promoted to main: <none>

This does need a security review, so I'll assign ubuntu-security
But it is also a bit of a special case. On one hand tests are only added right
now while I'm writing this and on the other a security review is required.
But given the context, the former outdated and unmaintained code we have in
python-boto does not have any of that.

But look at these three aspects on their own:
1. testing: In regard to testing we would not lose anything, and we would very
   soon get the testing added improving the situation.
2. security: The old code this replaces is the ancestor of the new code and
   that new code is better maintained, better split and more modern. So it
   should be better even before a review (which we should have)
3. maintenance: The old code is discontinued, we can not expect upstream support
   on issues with the old - so maintenance for bugs as well as security should
   be much better with the new stack.

Under these conditions I'd propose we allow it to be promoted now, will still
enqueue a security review and CPC/Alberto as well as Server will work on
anything found along that (if any).

Required TODOs:
- #1 please add testing as discussed. I've spoken with Alberto and he is
     already on extending the package to have proper tests.

[Rationale, Duplication and Ownership]
There is another package in main providing the same functionality: python-boto.
But that alternative is outdated and discontinued and this request is about
replacing the unmaintainable (and incompatible with the python in noble) old
version with the new one.
=> OK

A team is committed to own long term maintenance of this package.
=> Server, team-subscription already added

The rationale given in the report seems valid and useful for Ubuntu,
for simplestreams as reported and for other users of the library.

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

Problems:
- other Dependencies to MIR due to this, cases are already open and linked here

[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

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 expose any external endpoint (port/socket/... or similar)
- does not process arbitrary web content
- 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, ...)
- this makes appropriate (for its exposure) use of established risk
  mitigation features (being a lib only it can not yet know the use-case
  and thereby not define profiles)

Problems:
- does parse data formats in its interaction with the cloud. Since
  many other things nowadays also provide AWS compatible backends one
  can not safely assume the source can always be trusted.
- does use centralized online accounts to access the privileged AWS resources

[Common blockers]
OK:
- does not FTBFS currently
- This does not need special HW for build or test
- Python package, but using dh_python

Problems:
- does not have a test suite that runs at build time
  - test suite fails will fail the build upon error.
- does not have a non-trivial test suite that runs as autopkgtest

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- debian/watch is present and looks ok
- Upstream update history is good
- Debian/Ubuntu update history is ok
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- debian/rules is rather clean
- It is not on the lto-disabled list

Problems:
- the current release is not packaged, but that is only the case as upstream
  has almost daily releases through CI. We are on the right minor version (.34)
  and subversions are here not that much of a problem.

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (usage is OK inside
  tests)
- no use of user nobody (only nfsnobody for actual nfs use)
- no use of setuid / setgid
- 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 none needed for this case (lib only)

Problems: None