Review for Source Package: dotnet6

[Summary]
Given the size and complexity of this package and the implication of supporting
the language environment this is in a better state than I expected. Sure I found
some rough edges, but not too bad IMHO.
=> MIR team ACK under the constraint to resolve the below listed TODOs

This does need a security review, so I'll assign ubuntu-security

List of specific binary packages to be promoted to main: dotnet6 dotnet-host dotnet-hostfxr-6.0 dotnet-runtime-6.0 aspnetcore-runtime-6.0 dotnet-templates-6.0 dotnet-sdk-6.0 dotnet-targeting-pack-6.0 netstandard-targeting-pack-2.1 aspnetcore-targeting-pack-6.0 dotnet-apphost-pack-6.0

Specific binary packages built, but NOT to be promoted to main: dotnet-sdk-6.0-source-built-artifacts
This is only needed for future builds and an aspect of the bootstrapping process.

Notes:
TODO: - add todos, issues or special cases to discuss
Required TODOs:
#1a
- Please further clarify the future handling of updates
  Thanks Dviererbe for sharing more details on what happens after EOL.
  Is there a prior example of "providing a transitional package that uninstalls
  all binaries". While I totally understand the motivation it is also
  rather rude.
  People might say "I didn't care for detail X" but now I can't use it
  anymore - or similar.
  Is that approach an established pattern that I missed so far?
  If not we should probably run this by the SRU team (and they decide if also by the TB).
#1b
- And just to be double sure, you do not intent to e.g. move them
  dotnet6 -> dotnet8, but uninstall it right?
#1c
- Finally, generally and given the impact of the above, is there a draft
  of that "with a clear indication of the MS end of support date in the
  package itself" content? Because with the plan of removal it isn't just
  "the MS end of support" it is "the MS and Ubuntu end of support
  and existence".
#3a
- You mentioned to need lld and llvm. Please be aware that I've only seen
  build time dependencies to those which since a long time you no more
  strictly need in main. Even then runtime dependencies of things embedding
  llvm features are usually just needing libllvm13/14/15... and those are
  in main already. So do you need to correct your template or have I missed
  how you depend on them?
#3b
- If I somehow missed them, even then the MIRs for lld and llvm should not
  be in this bug (it is complex enough) but a new one each and refer to here.
  Just like with the versions here (dotnet6, dotnet7, ...) please ensure you
  keep the list of fully supported releases at a well selected minimum. For
  example rustc pulls llvm-13 into jammy. You use the default which is v14
  on jammy - which would imply two versions in main. I do not even mind on
  which side this is sorted out, but it would help to use the same
  where possible.
#4
- Please point me to the build time tests (More details below in the
  [Common blockers] section.

Recommended TODOs:
#2
- I understand that this oddity of needing .git structures is unavoidable
  right now. But it would be great if you would find a way to patch this
  out in a nice way or at least chime in and adopt upstream issue 3359
  once resolved. I say "a nice way" because if the alternative makes it worse
  there is no benefit.
#5
- have a look at filtering d/watch to only one major version (more see in the
  [Packaging red flags] section below)
#6
- while classic symbols tracking isn't very applicable this has way too many
  shared objects that not thinking about it would be ok. More details about
  this request below the [Packaging red flags] section.
#7
- In the context of tests (#4) and ABI tests (#6) I've seen mentioning of a
  JIT test (https://github.com/dotnet/runtime/issues/68837) which refers to
  https://github.com/dotnet/runtime/blob/main/docs/project/jit-testing.md
  I've not seen that on build not autopkgtest time.
  They mention running on Ubuntu 18.04 so it should generally work, could
  adding that to autopkgtests could be a great addition? Please have a look
  at that. Only recommended as I'm not having enough experience on this, the
  request might be unfulfillable.


[Duplication]
There is no other package in main providing the same functionality.
There are different versions served and Foundations has outlined how they
intent to not duplicate all of it so that we do not end up supporting
all versions for all time.

I still want to clarify further what users can rely on and what to expect,
for that I've added a few more questions to the required tasks.

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

Problems:
- depending on git entries, I know you tried and you are aware. But please
  never stop trying to get rid of this dependency. Even if it happens
  (https://github.com/dotnet/source-build/issues/3359) it won't apply to
  dotnet6, but you should try to chime in and poke on trying to make this
  package more normal. It is complex enough without this.
  => see recommended todo #2
- other Dependencies to MIR due to this
  you've written "There are further dependencies that are not yet in main,
  the MIR process for them is handled as part of this bug here." but (so far)
  there isn't content for it in this bug. OTOH I didn't see why you need them.
  => See required todo #3

[Embedded sources and static linking]
OK:
- no embedded source present, although this is hard to answer right in this
  case. dotnet6 as packaged and release by upstream is a conglomerate of
  many repositories. So in a way it has embedded sources, many of them.
  But OTOH a selection of all those repos is what makes dotnet6 and gladly
  AFAICS none of these components is used for anything else which would imply
  the demand for separating them.
- 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:
- 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 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)

Problems:
- history of CVEs does not look concerning, but because it is such a complex
  thing always will have something. Also for the chance of toolchain bug that
  affect anything built with it it would be a high value attack target.
- does deal with cryptography (en-/decryption, certificates, signing, ...).
  While it tries to delegate to system libraries where possible, due to
  platform differences there is crypto code in dotnet and in any case the
  calls flow through the wrappers even if delegated to system libraries.
- does parse data formats (files [images, video, audio,
  xml, json, asn.1], network packets, structures, ...), but we can consider
  it mostly from a trusted source.

=> Overall it seems clear, this needs a security review as well

[Common blockers]
OK:
- does not FTBFS currently
- does have a non-trivial test suite that runs as autopkgtest
- This does not need special HW for build or test
- no new python2 dependency

Problems:
- You stated in your report "The package runs a test suite on build time,
  if it fails it makes the build fail". But I was looking and I'm unsure
  about that. I only found the "Detailed Build Summary". I asked a bit around
  and learned that running the intended smoke tests can not be done in the
  build env (https://github.com/dotnet/source-build/issues/3386)
  I might only be blind and that is fine, would you point me to where/which
  tests run in a build log please so I can give you a pass or request
  for more testing?
  Note: in some cases build time tests are too hard, but I see you have added
  plenty of autopkgtest already and worst case you might add more there
  as this environment is a bit more flexible.


[Packaging red flags]
OK:
- Ubuntu does not carry a delta as this is only packaged in Ubuntu
- Upstream update history is good
- Debian/Ubuntu update history is good (While there is no help from Debian as
  it only exists in Ubuntu, it has a team behind it and due to that updates
  are good so far)
- the current release is packaged (relatively, you are one week too old, but
  there is a limit to updates - this is not "too old")
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings and mostly overridden and documented
  what the reason is or which bug you wait on to get rid of them.
- debian/rules is rather clean given how complex it is

Problems:
- debian/watch is present and works, but it does not filter main versions
  so 6.x warns about v7.0.305 and such. Maybe have a look if that can be
  improved.
- symbols tracking is not in place and you might say "that is not applicable".
  But it provides 13 .so files and 509 DLLs which are libs just as much.
  I'm sure with such complexity they will already need to have some symbols
  tracking in place, could you check if that runs in our build, provide an
  example of it failing on patching things badly (simulating a future SRU
  upload). I've found that e.g. libcoreclr.so isn't meant for that
  https://github.com/dotnet/runtime/issues/12281: "We consider the set of
  APIs exported by libcoreclr.so to be internal implementation detail and
  changing it frequently". But is that also true for all the other .so files?
  Is it also true for all the DLLs? It would be great if you could do some
  research and either link&state why it isn't needed or how you will cover it.
- It is not on the lto-disabled list, but locally has LTO disabled. I think
  there is not much we can do other than maybe asking for an upstream issue
  to be filed, but even that is unlikely to be acted - not filing a TODO
  for this.

[Upstream red flags]
OK:
- no Errors/warnings during the build that caught my attention
- I must state that on I feel unable to state if there are incautious use
  of malloc/sprintf. But this needs to go to security review anyway
  and the scanner tools there are much better at finding those anyway.
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (only in tests and docs)
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks
- translations are somewhat present in the source using the dotnet style
  with resx files. But there is only a small portion translated. So small
  that it would not help to package that up. OTOH this isn't for the
  unexperienced user, it is part of a developer story where going untranslated
  isn't perfect but acceptable

Problems: None