[MIR] golang-*, Go build dependencies of google-guest-agent

[Balint Reczey]

History worth to know:
https://bugs.launchpad.net/ubuntu/+bug/1885603
https://bugs.launchpad.net/ubuntu/+bug/1870314

[Availability]
The packages are present in universe on all architectures / the 'all' architecture.

[Rationale]
The packages are build dependencies of google-guest-agent and according to the special status of Golang packages Golang build dependencies of packages in main must also be in main (except for build dependencies used only in the tests).

[Security]
No known open CVE-s.

[Quality assurance]
Packaging is minimal.

Maintained by the Debian Go Packaging Team:

golang-github-go-ini-ini:
- 0 bug reports in Ubuntu and Debian, several open issues at upstream, but they upstream is active solving issues
- No Ubuntu delta
- Debian is behind by many upstream releases

golang-github-golang-groupcache:
- 0 bug reports in Ubuntu and Debian, several open issues at upstream, but they upstream is somewhat active solving issues
- No Ubuntu delta
- Upstream makes no releases, Debian is behind by many upstream commits

golang-github-kardianos-service:
- 0 bug reports in Ubuntu and Debian, several open issues at upstream, but they upstream is active solving issues
- No Ubuntu delta
- Debian and Ubuntu are up to date with latest upstream release

golang-github-kardianos-osext:
- 0 bug reports in Ubuntu, Debian and at upstream, upstream is active solving issues
- No Ubuntu delta
- Upstream makes no releases, Debian is behind by only a few not interesting upstream commits

golang-github-tarm-serial:
- 0 bug reports in Ubuntu and Debian, several open issues at upstream, but upstream is somewhat active solving issues
- No Ubuntu delta
- Upstream makes no releases, Debian is behind by many upstream commits

golang-google-protobuf (build depenency of golang-google-genproto):
- 0 bug reports in Ubuntu, 1 RC in Debian, which is stating that golang-protobuf (>> 1.4) is needed which is in groovy-proposed at the moment
- several open issues at upstream, but upstream is active solving issues
- No Ubuntu delta
- Debian and Ubuntu are up to date with latest upstream release

golang-github-google-btree:
- 0 bug reports in Ubuntu and Debian, several open issues at upstream, but upstream is somewhat active solving issues
- No Ubuntu delta
- Package is up to date with latest upstream release

golang-golang-x-sys:
- 1 unimportant bug report in Debian and 0 in Ubuntu, several open issues at upstream, but upstream is active solving issues
- No Ubuntu delta
- Upstream makes no releases, Debian is behind by many upstream commits

golang-golang-x-net:
- 1 unimportant bug report in Debian and 0 in Ubuntu, several open issues at upstream, but upstream is active solving issues
- No Ubuntu delta
- Upstream makes no releases, Debian is behind by many upstream commits

golang-golang-x-time:
- 0 bug reports in Ubuntu and Debian, several open issues at upstream, but upstream is active solving issues upstream issues are tracked at https://github.com/golang/go/issues/
- No Ubuntu delta
- Upstream makes no releases, Debian is behind by many upstream commits
- TODO No watch file, old policy version

golang-golang-x-oauth2:
- 0 bug reports in Ubuntu and Debian, several open issues at upstream, but upstream is active solving issues upstream issues are tracked at https://github.com/golang/go/issues/
- No Ubuntu delta
- Upstream makes no releases, Debian is behind by a few upstream commits

Maintained only in Ubuntu:

golang-github-gcp-guest-logging-go:
- 0 bug reports in Ubuntu and at upstream
- Upstream makes no releases, Ubuntu has the latest commit

[UI Standards]
Not applicable.

[Dependencies]
The packages depend on each other, golang-github-google-go-cmp-dev is just a build-time dependency.

[Standards Compliance]
Conforms to a recent Debian Policy version.

[Maintenance]
TODO: This package is to be owned by the Ubuntu Foundations team.

TODO: MIR golang-google-cloud golang-google-genproto dependencies
 These lead further down to much more further dependencies:
  - golang-github-chzyer-readline-dev
  - golang-github-golang-mock-dev
  - golang-github-google-go-cmp-dev
  - golang-github-google-martian-dev
  - golang-github-google-pprof-dev
  - golang-github-googleapis-gax-go-dev
  - golang-github-hashicorp-golang-lru-dev
  - golang-github-ianlancetaylor-demangle-dev
  - golang-glog-dev
  - golang-go.opencensus-dev

  - golang-golang-x-sync-dev
  - golang-golang-x-text-dev
  - golang-golang-x-xerrors-dev
  - golang-google-api-dev
  - golang-google-cloud-compute-metadata-dev
  - golang-google-cloud-dev
  - golang-google-genproto-dev
  - golang-google-grpc-dev
  - golang-goprotobuf-dev
  - golang-rsc-binaryregexp-dev
  - protobuf-compiler
  Depended but in main alreday:
  - zlib1g-dev
  - libprotobuf23
  - libprotoc23
  - libprotobuf-lite23
  - libprotobuf-dev
  Depended but already requested here:
  - golang-github-gcp-guest-logging-go-dev
  - golang-github-google-btree-dev
  - golang-golang-x-net-dev
  - golang-golang-x-oauth2-dev / golang-golang-x-oauth2-google-dev
  - golang-golang-x-sys-dev
  - golang-golang-x-time-dev
That would be 25 packages more - please confirm that you really intend to promote and maintain all those - in that case do an initial evaluation of quality and todos on your own (as it is part of the MIR request steps) of them and add them to the MIR request here. If you think you can cut those dependencies before pulling in all of these please do so in package uploads.

TODO: get foundation-bugs subscribed to all those packages

[Christian Ehrhardt  (paelzer)]

[Summary]
MIR team ACK under the condition that the subscription is added and someone
takes a look at the build and autopkgtest tests.
This also does need a security review, so I'll assign ubuntu-security.

Specific binary packages to be promoted to main:
- golang-github-kardianos-service-dev

Required:
- subscribe foundations to the package

(Strongly) Recommended TODOs:
- Tests are actively disabled in d/rules atm, any chance to evalate, fix and
  enable them?
- Also this integrates go packages with systemd which we know to change quite
  a bit a autopkgtest would be awesome to ensure future systemd upgrades won't
  break it.
I was torn if this is strictly required or recommended, foundations will own it
either way - with bugs detected early or late - so it is up to you. But I really
recommend adding/enabling tests on this one.

[Duplication]
There also is golang-gopkg-hlandau-service.v2-dev but that isn't in main.
So no other (Go) package in main providing the same functionality yet.

[Dependencies]
OK:
- no other Dependencies to MIR due to this (onlygolang-github-kardianos-osext
  which is part of this MIR already)
- one -dev packages for auto-include but not crit dependencies

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking (well Go)

[Security]
OK:
- history of CVEs does not look concerning
- does not open a port
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats
- 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)

Problems:
- does run a daemon as root - running services is the core task of this.
  So a lot of things might be set up right / wrong by it and therefore a
  security evaluation should happen.

[Common blockers]
OK:
- does not FTBFS currently
- no translation present, but none needed for this case (user visible)?
- not a python package, no extra constraints to consider int hat regard
- Go package that uses dh-golang

TODO: Problems:
- does have a test suite that runs at build time
  - test suite fails will fail the build upon error.
- does have a test suite that runs as autopkgtest
=> The build time tests are actively disabled and should be enabled if possible.
   Also this integrates go packages with systemd which we know to change quite
   a bit a autopkgtest would be awesome to ensure future systemd upgrades won't
   break it.
- The package has no team bug subscriber (Should be Foundations, please
  subscribe)

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Upstream update history is ok (code is 6 years old, only releases last
  two years - but then steady)
- Debian/Ubuntu update history is ok
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- Does not have Built-Using
- Go Package that follows the Debian Go packaging guidelines

[Upstream red flags]
OK:
- no Erro...

[Christian Ehrhardt  (paelzer)]

[Summary]
MIR Nack due to duplicate functionality - see details below.

Required TODOs:
Kill the dependency from golang-github-kardianos-service it should no more be
needed. If it turns out to be needed for odd reasons please explain in detail
and we will re-evaluate.

[Duplication]
Since golang 1.8 and later (Which maps to >=Bionic for Ubuntu) golang has
this in the standard lib:
  => https://golang.org/pkg/os/#Executable
The package does not use it's own code >=1.8 and therefore is a non needed no-op
in the proposed context of the MIR scope.
Please give it a try to build and use golang-github-kardianos-service without
this.

Due to the above I have skipped the following sections:
[Dependencies]
[Embedded sources and static linking]
[Security]
[Common blockers]
[Packaging red flags]
[Upstream red flags]

[Christian Ehrhardt  (paelzer)]

[Summary]
MIR Team Ack from packaging POV.
This does need a security review, so I'll assign ubuntu-security

List specific binary packages to be promoted to main: golang-github-google-btree-dev

[Duplication]
Well, there are a lot of competing projects, the archive along has four btree
implementations:
- golang-github-petar-gollrb-dev
- golang-github-tidwall-btree-dev
- golang-github-cznic-b-dev
- golang-github-google-btree-dev
But the wider go community seems to have even more as you can see on this
comparison: https://github.com/tv42/benchmark-ordered-map

None of them is in main yet, so no duplication issue for support.
But with more go packages coming this is one of the cases where unfortunately
this is often a code-away behavior and not yet having a few de-facto libs
the community settled on. At least golang-github-google-btree-dev seems to
be high up in the usage count - so it might be the right decision anyway.

golang-github-google-btree-dev was designed to follow the API of another common
one golang-github-petar-gollrb-dev being a drop in replacement (at least
intended to be that). By the docs of golang-github-google-btree-dev it is called
  "This implementation is designed to be a drop-in replacement to gollrb.LLRB
   trees, (http://github.com/petar/gollrb), an excellent and probably the most
   widely used ordered tree implementation in the Go ecosystem currently."

This is ok for now, but if later golang-github-petar-gollrb-dev MIRs come by we
might want to consider change them to use golang-github-google-btree-dev or
vice versa. It seems functionally gollrb is a superset so that replacement only
works in one direction, but OTOH gollrb is outdated (2013) so
golang-github-google-btree-dev might be better after all for main.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion

[Embedded sources and static linking]
OK:
- no embedded source present (also no vendored code)
- no static linking (well, go but nothing else)

[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
- 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)

Problems:
- does parse data formats to build the tree
  This should be trivial and safe but there were CVEs on btree functions in
  the past (in pther projects) since this is <2k LOC a security review should
  be fast.

[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.
- The package has a team bug subscriber
- no translation present, but none needed for this case (user visible)?
- not a python package, no extra constraints to consider int hat regard
- Go package that uses dh-golang

Problems:
- does not have a test suite that runs as autopkgtest
  For a low level lib unit&high-level tests are often the same, so that is not
  perfect but probably ok.

[Packaging red flags]
OK:
- Ubuntu does not ...

[Christian Ehrhardt  (paelzer)]

One addendum for golang-github-google-btree package thou, the suggested subscription of Foundations isn't present yet. Please fix that up.

In general (for all of those), please just subscribe the Team when starting a MIR to avoid it being forgotten later.

[Christian Ehrhardt  (paelzer)]

The evaluation of golang-github-gcp-guest-logging-go has uncovered much more dependencies (thanks go :-/) that are active here, I have updated your existing TODO section in the description.

Just to get a feeling for it:
root@g:~# apt install golang-github-gcp-guest-logging-go-dev
The following additional packages will be installed:
  golang-github-chzyer-readline-dev golang-github-golang-mock-dev golang-github-google-btree-dev golang-github-google-go-cmp-dev golang-github-google-martian-dev
  golang-github-google-pprof-dev golang-github-googleapis-gax-go-dev golang-github-hashicorp-golang-lru-dev golang-github-ianlancetaylor-demangle-dev golang-glog-dev
  golang-go.opencensus-dev golang-golang-x-net-dev golang-golang-x-oauth2-dev golang-golang-x-oauth2-google-dev golang-golang-x-sync-dev golang-golang-x-sys-dev golang-golang-x-text-dev
  golang-golang-x-time-dev golang-golang-x-xerrors-dev golang-google-api-dev golang-google-cloud-compute-metadata-dev golang-google-cloud-dev golang-google-genproto-dev
  golang-google-grpc-dev golang-goprotobuf-dev golang-rsc-binaryregexp-dev libprotobuf-dev libprotobuf-lite23 libprotobuf23 libprotoc23 protobuf-compiler zlib1g-dev

Maybe some of them are superfluous for golang-github-gcp-guest-logging-go as the o.mod lists "only" 17 of them, but that isn't how dependencies work.
It is up to the team driving this effort to either cut these dependencies (recommended but often hard) or to opt-in and properly evaluate+file for these packages as well.

[Didier Roche-Tolomelli (didrocks)]

golang-github-go-ini-ini

[Summary]
MIR team ACK under the condition that the subscription is added.
This also does need a security review, so I'll assign ubuntu-security.

Required:
- subscribe foundations to the package

TODOs:
- Tests are actively disabled in d/rules atm. TA check for enabling them before promoting will be really appreciated.
- Evaluate updating to a newer version.

[Duplication]
I didn’t find any duplication in main, and this package is the most well known ini parser. It’s imported but a bunch of project: https://pkg.go.dev/github.com/go-ini/ini?tab=importedby

[Dependencies]
OK:
- no other dependencies

[Embedded sources and static linking]
OK:
- no embedded source present
- Go statically link by essence

[Security]
OK:
- history of CVEs does not look concerning
- does not open a port
- does not use webkit1,2
- does not use lib*v8 directly
- 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 run a daemon as root

Problems:
- parse data formats (ini file). A security team check will be required for this reason.

[Common blockers]
OK:
- does not FTBFS currently
- no translation present, but none needed for this case
- not a python package, no extra constraints to consider in that regard
- Go package that uses dh-golang

TODO: Problems:
- does have a test suite that do not run at build time nor as autopkgtests. It has some benchmarks and tests.
I think tests are disabled because it’s using go-convey. But it can be kept as a build-deps only.
- The package has no team bug subscriber (Should be Foundations, please
  subscribe)

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Upstream does regular release
- The package is way behind upstream code (1.61.0 vs 1.32.0) and is 2 years old
- 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
- d/rules is rather clean
- Go Package that follows the Debian Go packaging guidelines

Warning:
- The package is way behind upstream code (1.61.0 vs 1.32.0) and is 2 years old

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (Go)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- 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-*
- no embedded source copies
- not part of the UI for extra checks

[Christian Ehrhardt  (paelzer)]

[Summary]
The further dependencies AND the testing really needs effort to be spent.
But for the package itself from a pure MIR/Packaging POV ACK.
This does need a security review, so I'll assign ubuntu-security

List specific binary packages to be promoted to main: golang-github-gcp-guest-logging-go-dev

TODO for package or context owner:
Another word on testing...:
It is important to mention that all of the packages in this stack are much more
"here a bit code, there a bit code and maybe things work" than huge mature
projects usually are. I understand that this is to some extend the nature of go
ecosystem. But there are go based projects which have coordinated releases of
main and dependent projects and more important coordinated testing end-to-end
as well as individually.
This should really be considered here at least for the scope of the full
guest-agent stack. Maybe there is some CI or end-to-end testing for the guest
agent already (I can't think about google working on this without). If there is
please add to the description what exists and what it tests in which scope.
If it comes down to a matrix of git-hashes (=go style package dependencies)
how could we ensure our combination (or even with SRUs considered plus patches)
is covered or could run the same tests?

[Duplication]
OK:
In terms of loggers there is the standard log api in golang and on top
golang-github-sirupsen-logrus-dev in main (compatible API structured logger).
But this package is not about that - it is about "guest-logging" which is
different.
There is no other package in main providing the same functionality.

[Dependencies]
OK:
- no -dev/-debug/-doc packages that need exclusion

Problems:
- other Dependencies to MIR due to this: golang-google-cloud-dev and
  golang-google-genproto-dev will be needed, but they are already listed as
  known TODO to extend the MIR about.

[Embedded sources and static linking]
- no embedded source present
- no static linking (except golang which makes build-deps real deps)

[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
- 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)

The problem is that many things will flow through here, and history shows that
a simple mistake in an in-between shim layer or such can be eventually fatal.
We should have a security review just to be sure and that might become true for
most of the follow on dependencies for the same reasons.

[Common blockers]
OK:
- does not FTBFS currently
- no translation present, but none needed for this case (user visible)?
- not a python package, no extra constraints to consider int hat regard
- Go package that uses dh-golang

Problems:
- does not have a test suite that runs at build time
- does not have a test suite that runs as autopkgtest
This is a general problem, I've added some words to the summary above.

- The package has a team bug subscriber
  As I said please subscribe the t...

[Didier Roche-Tolomelli (didrocks)]

Another missing dep for google-protobuf is golang-github-google-go-cmp-dev, which is a build dependencies as listed, but result in final binary. Adding the tasks and please, check that it followes the MIR requirements.

[Didier Roche-Tolomelli (didrocks)]

golang-github-go-ini-ini

[Summary]
Some fixes are needed:
- subscribe foundations to the package
- -cmp- is evaluated and migrates to main.
- riscv64 and armhf builds are failing
This also does need a security review once the above is dealt with.

[Duplication]
This is the only protobuf implementation by google, the other one is using non binary format (gogoprotobuf) and is not supported.

[Dependencies]
KO:
- depends on -cmp-, please check it

[Embedded sources and static linking]
OK:
- no embedded source present
- Go statically link by essence, generates go files to be checked into the project.

[Security]
OK:
- history of CVEs does not look concerning
- does not open a port
- does not use webkit1,2
- does not use lib*v8 directly
- 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 run a daemon as root

Problems:
- parse data formats (binary protobuf format). A security team check will be required for this reason.

[Common blockers]
OK:
- no translation present, but none needed for this case
- not a python package, no extra constraints to consider in that regard
- Go package that uses dh-golang

TODO: Problems:
- FTBFS currently on armhf and riscv64 and needs to be fixed.
- The package has no team bug subscriber (Should be Foundations, please
  subscribe)

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Upstream does regular release
- The package is up to date with recent releases
- 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
- d/rules is rather clean
- Testsuite is running as part of the build
- Go Package that follows the Debian Go packaging guidelines.

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (Go)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- 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-*
- no embedded source copies
- not part of the UI for extra checks
- good testsuite

[Didier Roche-Tolomelli (didrocks)]

golang.org/x/net/context

[Summary]
Some fixes are needed:
- 4 years old snapshot. Please update to fix in particular the issue below
- related to above depends on the x/net/context package which has been deprecated moons ago
- subscribe foundations to the package

[Duplication]
No duplicate, this is the official google rate limiting used by a number of projects.

[Dependencies]
KO:
- depends on x/net/context, but this one is deprecated and will be removed once updated to a newer git snapshot.

[Embedded sources and static linking]
OK:
- no embedded source present
- Go statically link by essence, generates go files to be checked into the project.

[Security]
OK:
- history of CVEs does not look concerning
- does not open a port
- does not use webkit1,2
- does not use lib*v8 directly
- 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 run a daemon as root
- does not parse data formats

[Common blockers]
OK:
- no translation present, but none needed for this case
- not a python package, no extra constraints to consider in that regard
- Go package that uses dh-golang

[Common blockers]
OK:
- no translation present, but none needed for this case
- not a python package, no extra constraints to consider in that regard
- Go package that uses dh-golang
- builds on all arch

TODO: Problems:
- The package has no team bug subscriber (Should be Foundations, please
  subscribe)

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- 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
- d/rules is rather clean
- Testsuite is running as part of the build
- Go Package that follows the Debian Go packaging guidelines.

Problems:
- the snapshot, as mentioned in the description, is way behind in term of commits. Please either take a git snapshot or backport necessary fixes, like the context one.

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (Go)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- 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-*
- no embedded source copies
- not part of the UI for extra checks
- good testsuite
TODO: Problems:
- FTBFS currently on armhf and riscv64 and needs to be fixed.
- The package has no team bug subscriber (Should be Foundations, please
  subscribe)

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Upstream does regular release
- The package is up to date with recent releases
- 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
- d/rules is rather clean
- Testsuite is running as part of the build
- Go Pa...

[Didier Roche-Tolomelli (didrocks)]

Following previous request, can you check which module from x/net is used? Maybe it’s only x/net/context which shouldn’t be used anymore. Feel free to set it back to New stating what other parts of x/net module is used.
Setting golang-golang-x-net (Ubuntu) as incomplete until hearing some feedback

[Christian Ehrhardt  (paelzer)]

FYI:
golang-x-text-dev (but not golang-golang-x-text-dev despite being the same code) and golang-golang-x-net-dev were in main in xenial already. But that was due to LXD, didn't follow todays MIR process and isn't in main anymore. The subscriber so far (server team) didn't plan to extend on it, so if you want these please drive a normal full MIR (already requested for -net but not yet for -text.

[Christian Ehrhardt  (paelzer)]

Thanks Didier for the x-net eval, I'll also assign back rbalint to make it clear who this incomplete is waiting on.

[Dan Streetman (ddstreet)]

MIR review of golang-github-golang-groupcache:

[Summary]
There are 2 issues that need to be addressed:
- this has a runtime (and build) dep on golang-goprotobuf-dev, which is in universe,
  and is not included in the list of packages for evaluation in this MIR bug
- foundations team needs to subscribe to package

There are 2 additional issues that should be reviewed but are not blockers:
- embedded code 'singleflight' duplicated from golang-x-sync package
- no upstream release (ever) and packaged code is from 2017

I don't see any item requiring a security review.

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

[Dependencies]
OK:
- no -dev/-debug/-doc packages that need exclusion (only binary provided is a -dev package)

Problems:
- this has a runtime (and build) dep on golang-goprotobuf-dev, which is in universe,
  and is not included in the list of packages for evaluation in this MIR bug

[Embedded sources and static linking]
OK:
- go always static links

Problems:
- embedded source present:
  - 'singleflight' is embedded code from golang-golang-x-sync package
    it's not completely clear which package copied which, but it seems
    x-sync was first:
    https://pkg.go.dev/golang.org/x/sync/singleflight?tab=versions
    https://pkg.go.dev/github.com/golang/groupcache/singleflight?tab=versions

[Security]
OK:
- history of CVEs does not look concerning
- does not parse data formats
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port
- 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)

[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 translation present, but none needed for this case (nothing user visible, library only)
- no new python2 dependency
- not Python package
- Go package that uses dh-golang

Problems:
- does not have a test suite that runs as autopkgtest
- The package does not has a team bug subscriber (foundations, please subscribe)

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- Does not have Built-Using
- Go Package that follows the Debian Go packaging guidelines

Problems:
- Upstream update history is slow; there are no upstream releases at all
- the current release is not packaged, as there are no upstream releases
- Debian/Ubuntu update history is slow; current version is from 2017

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as I can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- 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 ...

[Christian Ehrhardt  (paelzer)]

[Summary]
MIR Team Ack once the listed required tasks are completed - you can
make your live easier by breaking up the package - see below for details.

We need to recheck for these once security review is done, but since this will be very very different depending on breaking up the providers or not this is for now incomplete waiting on the driving team to decide and work on that.

Then once that is sorted out - or decided to be ignored and not broken out - this will need a security review. We will have to assign ubuntu-security then.

List specific binary packages to be promoted to main:
- golang-golang-x-oauth2-google-dev
- golang-golang-x-oauth2-dev

Required TODOs:
- MIR dependencies (listed in the known todo section of the MIR already)
- get the Team subscribed to the bug
- Upstreams on some of the packages seem to be partially inactive (only
  active to suite their own projects needs), but otherwise slow or
  inactive to bug reports and such. This isn't super uncommon, but
  history has shown that in that case maintaining it for Ubuntu often
  also means helping upstream - I want to make clear that this should
  be expected and want the foundation team to be aware of that.

Recommended TODOs:
- This will probably take a lot of time in the security team for all the
  different endpoint providers to check. If you would consider breaking
  the packages up further and we limit this to core+google that might be easier
  and reduce the risk to be denied for issues in a subpackage you don't need.
  See below for details.

[Duplication]
OK:
There is golang-github-mrjones-oauth-dev but it is Oauth(1) while what we
need is Oauth2 (also none of the two are in main yet). According to the readme
files of the two libs they know about each other and don't compete for the same
spot. Higher libs unite the lower ones for multi-auth but that again is a
different purpose (like https://github.com/markbates/goth).
It should not cause duplication to promote golang-golang-x-oauth2.

[Dependencies]
OK:
- no -dev/-debug/-doc packages that need exclusion

Problems:
- other Dependencies to MIR due to this
  - golang-golang-x-net-dev (part of this MIR already)
  - golang-google-cloud (in the known TODO section of this MIR description)
  => They are known but need to be tackled

[Embedded sources and static linking]
OK:
- no static linking (well, go - but nothing on top)
- no embedded source present
  There is a lot of code, but it is endpoint plugins and not embedded code that
  exists elsewhere. Yet the source states that they reject the addition
  of further endpoint - so there will be other codebases out there which are
  related.

[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
- does not process arbitrary web content
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)

Problems:
- history of CVEs does look concerning
  This particular package had none yet, but oauth2 in general has
  quite a record which suggests this needs to be checked.
- does parse data formats
- does use centralized online accounts

=> This needs a...

[Didier Roche-Tolomelli (didrocks)]

[Summary]
MIR team ACK from a packaging and code review perspective given the team subscription is done.
This does need a security review, so I'll assign ubuntu-security.

Required:
- subscribe foundations to the package

[Duplication]
There is no other package in main providing the same functionality. This is the main sys package used in the Go community.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking, expect Go

[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
- 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)

Problems:
- Do a lot of syscalls as integrate deeply with the targeter platform. A security team check will be required for this reason.

[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 NOT have a test suite that runs as autopkgtest, but it’s a library which will be statically built.
- no translation present, but none needed for this case?
- Go package that uses dh-golang

Problems:
- The package has no team bug subscriber (Should be Foundations, please
  subscribe)

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Upstream doest not make releases
- Debian update history is sporadic, but there is no new commits necessary right now
- promoting this does not seem to cause issues for MOTUs that so far who maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- Go Package that follows the Debian Go packaging guidelines

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as I can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- 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-*
- no embedded source copies
- not part of the UI for extra checks

[Seth Arnold (seth-arnold)]

Security team NAK on golang-github-kardianos-service at this time.

Here's the notes I've collected while reading the source code. I didn't inspect the packaging in any depth, I understand that we may be changing the packaging, so I've ignored for that now.

I filed two bug reports for the issues that worried me the most. Some of what I found appears to be for non-Linux systems, I'm reporting it in the hopes that it is useful. Some portions of the code don't make sense to me, I don't understand the goals of the isInteractive() or isInContainer() checks:

service_systemd_linux.go configPath() creates important directories mode
777:
https://github.com/kardianos/service/issues/237

./service_upstart_linux.go Install() creates an upstart configuration file
with permissions 666:
https://github.com/kardianos/service/issues/238

example/runner/runner.go run() creates files mode 777. I know it says
example/ in the filename but people copy-paste example code.

service_systemd_linux.go Install() creates a config file before deciding
if it should be populated, and does not clean up after the config file if
an error occurs while rendering the text.

service_linux.go isInteractive() doesn't make sense to me, what's the
purpose?

service_linux.go isInContainer() may suffer from false positives and
perhaps false negatives, is this okay? What's the purpose?

service_systemd_linux.go isSystemd() doesn't handle read errors on
/proc/1/comm (unlikely if the open succeeded)

./service_aix.go getPidOfSvcMaster() could be extremely expensive to
execute; I suggest rewriting isInteractive() to look for information on
the specific process, either via ps(1)'s -p flag or a programmatic API if
one exists. Also consider re-writing the ps -ef regex to use ps -o, and
select only the two fields that appear to matter: uid and comm (or exe?)

Thanks

[Dan Streetman (ddstreet)]

golang-github-tarm-serial:

[Summary]
With the requirement that foundations (or another team) subscribe to the package bugs,
this is an ACK from the MIR team.

Additionally, I will note that the latest packaged version in Debian/Groovy is from
2015, and the Debian/Ubuntu package should be updated to the latest upstream code.
However, the last upstream commit is from 2018, so I won't block MIR on this.

This does not need a security review.

Notes/TODOs:
- specific binary packages to be promoted to main:
  golang-github-tarm-serial-dev

Summary of problems:
- single test case not run during build or as autopkgtest, but appears to require specific hw
- no bug team subscriber
- no debian/watch file
- very slow upstream (last commit from 2018)
- Debian still using upstream code from 2015

I believe the lack of running test case and slow pace of upstream commits can be ignored
as the package is rather simple.

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

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion

[Embedded sources and static linking]
OK:
- no embedded source present
- golang, so static linked

[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
- 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)

[Common blockers]
OK:
- does not FTBFS currently
- no translation present, but none needed for this case
- Go package that uses dh-golang

Problems:
- does have a test suite (single test), but does not run at build time, nor as autopkgtest
  The test case appears to require some specific USB serial device(s), which is likely
  why it isn't run during build or as autopkgtest.
- The package does not have a team bug subscriber

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- promoting this does not seem to cause issues for MOTUs
- no massive Lintian warnings
- d/rules is rather clean
- Does not have Built-Using
- Go Package that follows the Debian Go packaging guidelines

Problems:
- d/watch is not present
- there are no upstream releases
  as there are no upstream releases, the lack of a watch file is not likely a
  serious problem, as there are no new releases to update to.
- Upstream update history is very slow
  the last upstream commit is from 2018, however this package is very simple,
  so the lack of regular upstream commits may not be problematic
- Debian/Ubuntu update history is nonexistent
  the Debian package is using upstream code from 2015, and should be updated
  to the latest upstream code (which, again, is from 2018)

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as I can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, et...

[Dan Streetman (ddstreet)]

setting golang-github-tarm-serial back to @rbalint as it needs a team bug subscriber.

[Seth Arnold (seth-arnold)]

Given the discussion held elsewhere and summarized in https://bugs.launchpad.net/ubuntu/+source/google-osconfig-agent/+bug/1896246 I've unsubscribed the security team from these MIRs to help us better see what work is still pending. If these packages are still needed for a MIR, please do shout.

Thanks

[Christian Ehrhardt  (paelzer)]

Agreed, I keep the "incompletes" that are re-assigned with various tasks in case one wants to ever re-pick-up the approach to de-vendurized this.
All other tasks will go to "Won't Fix" to properly reflect this is aborted.

[Christian Ehrhardt  (paelzer)]

There has been not further update for too long, for now we consider it invalid.
Feel free to re-open if there is effort backing it up and motivation to bring it to main.