** Description changed: [ Impact ] This release brings both bug-fixes and new features for the Pro Client, and we would like to make sure all of our supported customers have access to these improvements on all releases. The most important change is: We are relaxing the onlySeries directive interpretation. This is a special type of token that was designed to allow attach in a single release. For example, a onlySeries Jammy token could only attach to Jammy (not Noble, not Focal, not anything else). - However, this is not how the thing was sold - expectation now is that a onlySeries Jammy token can be used in Jammy *or earlier*. So attaching with it on Focal is fine, but on Noble it should still not work. - + However, this is not how the feature was supposed to work - expectation now is that a onlySeries Jammy token can be used in Jammy *or earlier*. So attaching with it on Focal is fine, but on Noble it should still not work. [ Test Plan ] The following development and SRU process was followed: https://wiki.ubuntu.com/UbuntuAdvantageToolsUpdates The Pro Client developers will be in charge of attaching the artifacts of the appropriate test runs to the bug, and will not mark ‘verification-done’ until this has happened. [ Where problems could occur ] The change to onlySeries is the one that calls for more attention, as mistakes there could lead to many different unwanted scenarios: a) Users not being able to use onlySeries tokens at all b) Users being able to use onlySeries tokens to attach to any series c) Attached machines getting detached because of the rule change d) Users not being able to update to a supported release to a subsequent supported release e) Users being able to update from a supported release to an unsupported release The unlikeliness of a), c) and d) is based on the code change making the check for onlySeries less restrictive than the older check. There seems to be no use case or scenario where a machine would *lose* Pro access after this change, whether by not being able to attach to being detached. b) and e) would be cases where loosening the check would go too far. Besides manual checking, the scenarios above are tested in the new and modified integration tests, executed as part of the validation for this SRU. Another important implementation decision to be noted is that often times in older releases, there is no registry of the new ones in distro-info-data. For example, on Jammy it's possible to get the data for Xenial or Bionic, but on Xenial there is no information about Jammy. As the restriction to the onlySeries token is for future releases, we consider any release that is *not found* in the distro-info-data as a future release, and block the token usage. This was tested and works as expected, but it relies: - on distro-info-data correctness, which we can assume given the importance of the distro-info package - on the backend always setting the correct values for the onlySeries field when defining the tokens. A simple typo there would render the tokens completely useless. Strict validation is in place in the backend to make sure this does not happen. + There is a change in the apparmor profile for esm_cache in this release, + and apparmor is a good suspect of things going in unexpected ways. + However, this change here is to use a proper abstraction for openssl, + which is the correct approach. We have tests for the service, and will + keep an eye on -proposed to make sure no regression happens there. - There is a change in the apparmor profile for esm_cache in this release, and apparmor is a good suspect of things going in unexpected ways. However, this change here is to use a proper abstraction for openssl, which is the correct approach. We have tests for the service, and will keep an eye on -proposed to make sure no regression happens there. - - - FIPS-related services can now be enabled using --access-only, which means getting access to the repositories without actually installing the packages. Users can use this without proper care, and think their systems are FIPS-enabled when it's actually not. To mitigate this impression, we are adding a warning state to FIPS-related services when the entitlement itself is enabled but the ubuntu-fips metapackage (or one of the cloud variants) is not installed. + FIPS-related services can now be enabled using --access-only, which + means getting access to the repositories without actually installing the + packages. Users can use this without proper care, and think their + systems are FIPS-enabled when it's actually not. To mitigate this + impression, we are adding a warning state to FIPS-related services when + the entitlement itself is enabled but the ubuntu-fips metapackage (or + one of the cloud variants) is not installed. The above warning won't work (for now) in containers though, where the FIPS service will still show as enabled even if --access-only was passed when enabling. We don't consider this a regression in --access-only because the same happens with realtime-kernel, for instance, which appears as enabled when the repository access is given and there is no RT kernel in the system. We don't consider this a regression for FIPS services because today if you enable FIPS in a container but the host does not run a FIPS service, you don't actually have FIPS in place but the status says it's enabled. In the end, in all cases, the user needs to know what they are doing. Documentation is our best friend. - [ Changelog ] ubuntu-advantage-tools (36ubuntu0) questing; urgency=medium - * d/apparmor/ubuntu_pro_esm_cache.jinja2: use openssl abstraction in the - apparmor profile - * New upstream release 36: (LP: #2112382) - - api: display all available valid CVEs - - attach: relax the onlySeries directive, so users can attach onlySeries - tokens to all releases older than the target release - - cli: - + anbox-cloud: update installation instructions - + collect-logs: do not overwrite the output file if it exists - + cve/cves: - * return all affected packages for a cve (LP: #2111610) - * handle the case where the vulnerability data doesn't exist for the - Ubuntu release - - fips: - + enable --access-only for all fips related services (GH: #3441) - + allow enablement even when the -updates pocket is not available in the - system (GH: #3439) + * d/apparmor/ubuntu_pro_esm_cache.jinja2: use openssl abstraction in the + apparmor profile + * New upstream release 36: (LP: #2112382) + - api: display all available valid CVEs + - attach: relax the onlySeries directive, so users can attach onlySeries + tokens to all releases older than the target release + - cli: + + anbox-cloud: update installation instructions + + collect-logs: do not overwrite the output file if it exists + + cve/cves: + * return all affected packages for a cve (LP: #2111610) + * handle the case where the vulnerability data doesn't exist for the + Ubuntu release + - fips: + + enable --access-only for all fips related services (GH: #3441) + + allow enablement even when the -updates pocket is not available in the + system (GH: #3439)
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2112382 Title: [SRU] ubuntu-advantage-tools (35.1 -> 36) Xenial, Bionic, Focal, Jammy, Noble, Oracular, Plucky To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/2112382/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
