[14:30] <jdstrand> allenpthuang: hey, thanks for the postfix update :)
[14:46] <teward> looks like schopin is pointing this your way, Sec Team, for updating something out-of-band (Xenial, Bionic) that isnt covered by sponsors.  
[14:46] <teward> https://bugs.launchpad.net/ubuntu/+source/google-guest-agent/+bug/2050956
[14:46] -ubottu:#ubuntu-security- Launchpad bug 2050956 in google-guest-agent (Ubuntu Bionic) "[SRU] Update d/control file with dependencies" [Undecided, New]
[14:47] <schopin> I'm honestly unsure of where I should have pointed it so please someone correct me, but I'm fairly sure this is out of the jurisdiction of mere core-devs and MOTUs :)
[15:00] <mdeslaur> I think leosilva is already on it
[17:10] <teward> schopin: i'm also pretty sure that unless it's a critical update and Security wants to update it it won't get updated.  (I've had one or two OOB uploads approved by AAs in edge cases though as a coredev)
[17:10] <teward> but ye it's outside the standard scope
[17:11]  * schopin actually looks at the proposed changes
[17:12] <teward> see this is the thing that makes me pause here
[17:12] <teward> "`google-guest-agent` is a package provided by Google for installation within guests that run on Google Compute Engine (GCE)"
[17:13] <teward> GCE shouldn't be offering those older images still
[17:13] <teward> if they are they're doing something odd/stupid
[17:13] <teward> or rather, they shouldn't offer those images for *NEW* installs IMO
[17:14] <teward> if they simply... disable Xenial / Bionic image selection... that kind of solves the issue already no?
[17:15] <schopin> I'm not much of a cloud person, are dist-upgrades not a thing in that domain?
[17:16] <teward> last i checked GCE behaved like AWS EC2 instances or VPSes, and can dist-upgrade.  I'm not *google* but if this package is provided **for installation within guests** and does something that enables GCE stuff in the VM environment (similar to open-vm-tools for VMware for example), then it would be part of the image on-install
[17:17] <teward> and if the older images are *gone* then the issue is irrelevant since new installs can't be run for those releases
[17:17] <teward> and anything having the image already would already have everything
[17:17] <teward> my 2 cents and cursory untested unvetted thoughts
[17:17] <rbasak> I'm not familiar with their offering but I am aware that you can get instances from cloud vendors that have Ubuntu Pro included, and therefore I infer that it makes sense for cloud vendors to continue offering those instance types until EOL.
[17:17] <teward> rbasak: by EOL do you mean Pro EOL or overall EOL/
[17:18] <teward> and in which case if Pro is enabled shouldn't this be distributed via ESM / Pro and not standard SRU
[17:18] <rbasak> End of Standard Support = 5 years; End of Life = 10 years or whatever Pro ends up being by then.
[17:18] <schopin> Well yes, that's why I directed them to Security (because in my mind Pro updates -> Security)
[17:19] <rbasak> I'm not sure if the agent needs to be special via SRU. We do push the Pro Client via SRU as an exception (details and rationale documented at https://wiki.ubuntu.com/UbuntuAdvantageToolsUpdates)
[17:20] <rbasak> Looking at the bug, sounds like the plan is to put it in via ESM, and it's just a matter of managing the bug tasks appropriately?