[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 security review for sure [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 (user visible)? - not a python package, no extra constraints to consider int hat regard - Go package that uses dh-golang Problems: - does have a test suite that runs as autopkgtest Not going into details of this again ... - the build time tests do not cover all endpoint providers, which is another +1 on splitting up the package. - The package has a team bug subscriber [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 sporadic (just commits, no releases, not many changes per year) - 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 (only the resulting binary will) - Go Package that follows the Debian Go packaging guidelines Problems: - Debian/Ubuntu update history is slow (picking up commits ~ once per year or less) - the current release is not packaged (mid 2019, which is more than a year off - e.g. the Jira endpoint isn't working due to that which is another +1 at splitting) - The source is rather crowded containing the functional oauth2 core and a whopping 34 endpoint providers. The Google endpoint provider was broken out into a separate binary package, but depends on what is left for the core. As outlined above multiple times the test coverage, maintenance and other things differ a lot between such endpoints. Also in the current structure all of them would be supported and all of them need to be MIR&Security agreeable. If you'd consider splitting the other providers into extra packages as well (and probably provide a meta package -all if one wants that) it would tremendously help to reduce the scope. [Upstream red flags] OK: - no Errors/warnings during the build - no incautious use of malloc/sprintf (well 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 Problems: - 69 upstream bugs and some of them active (205 closed), but also a few as old as 5 year without any comment - not even "hey provide this to continue" which isn't perfect triage policy. To be clear many of the other packages in this overall MIR don't have any track record, I assume they might be even worse but here at least we see it. That indicates we might need to step up debug and contribute to this (and other of these) package upstream as well when we consider supporting it fully. E.g. do we need [1] or [2], I don't know but we can't just rely on upstream releases as there are none. I think you now see what I try to suggest by saying there will likely be more work/engagement needed for this (kind of) package. [1]: https://github.com/golang/oauth2/issues/428 [2]: https://github.com/golang/oauth2/issues/391 ** Bug watch added: github.com/golang/oauth2/issues #428 https://github.com/golang/oauth2/issues/428 ** Bug watch added: github.com/golang/oauth2/issues #391 https://github.com/golang/oauth2/issues/391 ** Changed in: golang-golang-x-oauth2 (Ubuntu) Assignee: Christian Ehrhardt (paelzer) => Balint Reczey (rbalint) ** Changed in: golang-golang-x-oauth2 (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1894731 Title: [MIR] golang-*, Go build dependencies of google-guest-agent To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/golang-github-gcp-guest-logging-go/+bug/1894731/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
