[Bug 2023531] Re: [MIR] dotnet6

Christian Ehrhardt  2023531 at bugs.launchpad.net
Mon Jul 3 11:51:01 UTC 2023 

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

** Bug watch added: github.com/dotnet/runtime/issues #68837
   https://github.com/dotnet/runtime/issues/68837

** Bug watch added: github.com/dotnet/source-build/issues #3359
   https://github.com/dotnet/source-build/issues/3359

** Bug watch added: github.com/dotnet/source-build/issues #3386
   https://github.com/dotnet/source-build/issues/3386

** Bug watch added: github.com/dotnet/runtime/issues #12281
   https://github.com/dotnet/runtime/issues/12281

** Changed in: dotnet6 (Ubuntu)
     Assignee: Christian Ehrhardt  (paelzer) => Ubuntu Security Team (ubuntu-security)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to dotnet6 in Ubuntu.
https://bugs.launchpad.net/bugs/2023531

Title:
  [MIR] dotnet6

Status in dotnet6 package in Ubuntu:
  New

Bug description:
  [Availability]
   The package dotnet6 is already in Ubuntu universe.
   The package dotnet6 build for the architectures it is designed to work on.
   - See: https://github.com/dotnet/core/blob/main/release-notes/6.0/supported-os.md
   It currently builds and works for architetcures: amd64, arm64
   Link to package https://launchpad.net/ubuntu/+source/dotnet6

  [Rationale]
   - The package dotnet6 is required in Ubuntu main as part of
     Canonicals partnership with Microsoft to shorten the supply
     chain between Canonical and Microsoft and improve the .NET
     developer experience on Ubuntu. Read more here:
     - https://canonical.com/blog/install-dotnet-on-ubuntu
     - https://devblogs.microsoft.com/dotnet/dotnet-6-is-now-in-ubuntu-2204/
   - The package dotnet6 will generally be useful for a large part of
     our user base
   - It would be great and useful to community/processes to have the
     package dotnet6 in Ubuntu main, but there is no definitive deadline.

  [Security]
   - dotnet6 had security issues in the past that have been
     fixed, see trackers:
     - https://ubuntu.com/security/cves?package=dotnet6
     - https://github.com/dotnet/core/blob/main/release-notes/6.0/cve.md
     - NOTE: When searching for .NET CVEs in other trackers,
       keep in mind that .NET Framework and .NET (Core) is not
       the same and that many CVEs do not affect Linux distributions.
   - The Security Team and Foundations Toolchain Squad already
     work together with Microsoft to release security updates
     to Ubuntu.
   - Microsoft has weekly meetings with .NET Security Partners
     (including Canonical) where they get and keep informed
     about Security Issues.
   - .NET Security Partners (including Canonical) have early
     access to .NET releases containing CVE patches.
   - Microsoft and .NET Security Partners (including Canonical)
     coordinate releases to disclose and provide patches for
     security issues on all plattforms at the same time.
   - Microsoft informs Users about (security) issues in the
     monthly release notes where they aslo recommend actions
     to mitigate these issues.
     See example Release Note containing CVE warning:
     https://devblogs.microsoft.com/dotnet/february-2023-updates/
   - no `suid` or `sgid` binaries
   - no executables in `/sbin` and `/usr/sbin`
   - Packages does not open privileged ports (ports < 1024)
   - Packages does not contain extensions to security-sensitive software
     (filters, scanners, plugins, UI skins, ...)

  [Quality assurance - function/usage]
   - The package works well right after install

  [Quality assurance - maintenance]
   - The package is maintained well in Ubuntu/Upstream and does
     not have too many, long-term & critical, open bugs
     - Ubuntu https://bugs.launchpad.net/ubuntu/+source/dotnet6/+bug
     - There are multiple bug trackers upstream for the individual 
       components of the package https://github.com/dotnet
   - The package has no important open bugs
   - The package does not deal with exotic hardware we cannot support

  [Quality assurance - testing]
   - The package runs a test suite on build time, if it fails
     it makes the build fail, link to build logs:
     - mantic amd64: https://launchpad.net/ubuntu/+source/dotnet6/6.0.116-0ubuntu3/+build/26165948
     - mantic arm64: https://launchpad.net/ubuntu/+source/dotnet6/6.0.116-0ubuntu3/+build/26165949
     - lunar amd64: https://launchpad.net/~ubuntu-security/+archive/ubuntu/ppa/+build/25976292
     - lunar arm64: https://launchpad.net/~ubuntu-security/+archive/ubuntu/ppa/+build/25976293
     - kinetic amd64: https://launchpad.net/~ubuntu-security/+archive/ubuntu/ppa/+build/25964381
     - kinetic arm64: https://launchpad.net/~ubuntu-security/+archive/ubuntu/ppa/+build/25964382
     - jammy amd64: https://launchpad.net/~ubuntu-security/+archive/ubuntu/ubuntu-security-staging-private/+build/25974197
     - jammy arm64: https://launchpad.net/~ubuntu-security/+archive/ubuntu/ubuntu-security-staging-private/+build/25974198
   - The package runs an autopkgtest, and is currently passing
     on mantic/lunar/kinetic/jammy amd64/arm64 https://autopkgtest.ubuntu.com/packages/dotnet6
   - The package does NOT have failing autopkgtests tests right now.

  [Quality assurance - packaging]
   - debian/watch is present and works*
     (*Canonical has to work around the debian/watch file to
     consume embargoed releases before the official release)
   - debian/control defines a correct Maintainer field
   - This package does yield massive lintian Warnings/Errors,
     but they are either false-postives or acceptable.
   - Lintian overrides are present, but ok because of false-positive
     lintian warnings. The concrete reasons are explained as a
     comment in the overwrite files.
   - The package will not be installed by default
   - Packaging is complex, but that is ok because the software
     we are packaging is complex and we are working with
     Microsoft to reduce the complexity.

  [UI standards]
   - Application is end-user facing, Translation is NOT present,
     this is ok, as the application just provides a Command Line
     Interface for developers. The CLI output should not be
     translated to maintain online searchable error messages.
   - The exception messages of the .NET Runtime are localized.
   - End-user applications without desktop file, not needed,
     because it just provides libraries and command line tools

  [Dependencies]
   - There are further dependencies that are not yet in main, the MIR
     process for them is handled as part of this bug here.
     - lld binary and source package is in universe
     - llvm binary and source package is in universe
     - locales-all is in universe, but its source glibc is already in main

  [Standards compliance]
   - This package correctly follows FHS and Debian Policy (AFAICT: this package is huge and I have only limited experience)

  [Maintenance/Owner]
   - Team is already subscribed to the package
   - This package has embedded/vendorized dependencies. 
     We are aware of this problem and working on getting rid of them.
   - This package is not rust based
   - The package has been built in the archive more recently than the last
     test rebuild

  [Background information]
   - The Package description explains the package well
   - Upstream Name is ".NET 6"
   - Upstream project: https://github.com/dotnet/source-build
   - This MIR exists in parralel to the MIR for dotnet7

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dotnet6/+bug/2023531/+subscriptions

More information about the foundations-bugs mailing list