[Impact]
Users who import and run the uaclient.apt.get_pkg_candidate_version function will have their apt_pkg configuration pointed to the ubuntu-advantage-tools managed esm cache while running the same process.
The fix is to use the same context manager used for security-status, which guarantees that the configuration is the same before and after u-a-t access any of the Caches.
[Test Case]
- On any release, in a Python interpreter:
```
import apt
from uaclient.apt import get_pkg_candidate_version
print(len(apt.Cache())
v = get_pkg_candidate_version('vim') # arbitrary choice, may be any package
print(len(apt.Cache())
```
The size of the Cache should match, before and after the function call.
On u-a-t 27.14, this fails.
[Regression Potential]
If we fix this the wrong way, people may still get their apt_pkg config in a state they wouldn't expect for the specific python process they are running. This would be the same as not fixing it. Our test aims to mitigate the possibility of such thing happening.
[Discussion]
There is a really small chance of this bug happening, given there are no user flows including this function being called directly, and process isolation takes care of the rest. However, given the specificities of the apt and apt_pkg integration in u-a-t, it is important to fix this and cover any corner case.
[Impact] apt.get_ pkg_candidate_ version function will have their apt_pkg configuration pointed to the ubuntu- advantage- tools managed esm cache while running the same process.
Users who import and run the uaclient.
The fix is to use the same context manager used for security-status, which guarantees that the configuration is the same before and after u-a-t access any of the Caches.
[Test Case] candidate_ version apt.Cache( )) candidate_ version( 'vim') # arbitrary choice, may be any package apt.Cache( ))
- On any release, in a Python interpreter:
```
import apt
from uaclient.apt import get_pkg_
print(len(
v = get_pkg_
print(len(
```
The size of the Cache should match, before and after the function call.
On u-a-t 27.14, this fails.
[Regression Potential]
If we fix this the wrong way, people may still get their apt_pkg config in a state they wouldn't expect for the specific python process they are running. This would be the same as not fixing it. Our test aims to mitigate the possibility of such thing happening.
[Discussion]
There is a really small chance of this bug happening, given there are no user flows including this function being called directly, and process isolation takes care of the rest. However, given the specificities of the apt and apt_pkg integration in u-a-t, it is important to fix this and cover any corner case.