[Touch-packages] [Bug 1737441] Re: python-apt crashes if objects of one cache are passed to depcache belonging to another cache
This bug was fixed in the package unattended-upgrades - 1.1ubuntu1.18.04.7~16.04.2 --- unattended-upgrades (1.1ubuntu1.18.04.7~16.04.2) xenial; urgency=medium * Don't check blacklist too early and report updates from not allowed origins as kept back. (LP: #1781176) * test/test_blacklisted_wrong_origin.py: Fix and enable test * Filter out progress indicator from dpkg log (LP: #1599646) * Clear cache when autoremoval fails (LP: #1779157) * Find autoremovable kernel packages using the patterns in APT's way (LP: #1815494) unattended-upgrades (1.1ubuntu1.18.04.7~16.04.1) xenial; urgency=medium * Start service after systemd-logind.service to be able to take inhibition lock (LP: #1806487) * Handle gracefully when logind is down (LP: #1806487) unattended-upgrades (1.1ubuntu1.18.04.7~16.04.0) xenial; urgency=medium * Backport to Xenial (LP: #1702793) * Revert to build-depending on debhelper (>= 9~) and dh-systemd * Revert configuration example changes to avoid triggering a debconf question * debian/postinst: Update recovery to be triggered on Xenial's package versions unattended-upgrades (1.1ubuntu1.18.04.7) bionic; urgency=medium * Trigger unattended-upgrade-shutdown actions with PrepareForShutdown() Performing upgrades in service's ExecStop did not work when the upgrades involved restarting services because systemd blocked other stop/start actions making maintainer scripts time out and be killed leaving a broken system behind. Running unattended-upgrades.service before shutdown.target as a oneshot service made it run after unmounting filesystems and scheduling services properly on shutdown is a complex problem and adding more services to the mix make it even more fragile. The solution of monitoring PrepareForShutdown() signal from DBus allows Unattended Upgrade to run _before_ the jobs related to shutdown are queued thus package upgrades can safely restart services without risking causing deadlocks or breaking part of the shutdown actions. Also ask running unattended-upgrades to stop when shutdown starts even in InstallOnShutdown mode and refactor most of unattended-upgrade-shutdown to UnattendedUpgradesShutdown class. (LP: #1778219) * Increase logind's InhibitDelayMaxSec to 30s. (LP: #1778219) This allows more time for unattended-upgrades to shut down gracefully or even install a few packages in InstallOnShutdown mode, but is still a big step back from the 30 minutes allowed for InstallOnShutdown previously. Users enabling InstallOnShutdown node are advised to increase InhibitDelayMaxSec even further possibly to 30 minutes. - Add NEWS entry about increasing InhibitDelayMaxSec and InstallOnShutdown changes * Ignore "W503 line break before binary operator" because it will become the best practice and breaks the build * Stop using ActionGroups, they interfere with apt.Cache.clear() causing all autoremovable packages to be handled as newly autoremovable ones and be removed by default. Dropping ActionGroup usage does not slow down the most frequent case of not having anything to upgrade and when there are packages to upgrade the gain is small compared to the actual package installation. Also collect autoremovable packages before adjusting candidates because that also changed .is_auto_removable attribute of some of them. (LP: #1803749) (Closes: #910874) unattended-upgrades (1.1ubuntu1.18.04.6) bionic; urgency=medium * Unlock for dpkg operations with apt_pkg.pkgsystem_unlock_inner() when it is available. Also stop running when reacquiring the lock fails. Thanks to Julian Andres Klode for original partial patch (LP: #1789637) * Skip rebuilding python-apt in upgrade autopkgtests. Python-apt has a new build dependency making the rebuilding as is failing and the reference handling issue is worked around in unattended-upgrades already. (LP: #1781586) * Stop trying when no adjustment could be made and adjust package candidates only to lower versions (LP: #1785093) * Skip already adjusted packages from being checked for readjusting. This makes it clearer that the recursion ends and can also be a bit quicker. (LP: #1785093) unattended-upgrades (1.1ubuntu1.18.04.5) bionic; urgency=medium * Stop updating the system when reacquiring the dpkg system lock fails. (LP: #1260041) unattended-upgrades (1.1ubuntu1.18.04.4) bionic; urgency=medium * Redirect stderr output in upgrade-between-snapshots, too, otherwise it breaks the test sometimes (LP: #1781446) unattended-upgrades (1.1ubuntu1.18.04.3) bionic; urgency=medium * Redirect stderr output in upgrade-all-security, otherwise it breaks the test (LP: #1781446) unattended-upgrades (1.1ubuntu1.18.04.2) bionic; urgency=medium [ Balint Reczey ] * Clear cache when autoremoval is invalid for a package set marked for removal and
[Touch-packages] [Bug 1737441] Re: python-apt crashes if objects of one cache are passed to depcache belonging to another cache
This bug was fixed in the package python-apt - 0.9.3.5ubuntu3 --- python-apt (0.9.3.5ubuntu3) trusty-proposed; urgency=medium * DepCache: Check that candidate we are setting belongs to package * Raise CacheMismatchError if objects passed to DepCache are from different cache (LP: #1737441); also includes the following regression fixes from bionic: - apt.Cache: Remap objects when reopening cache (LP: 1773316 in bionic+), incl. regression fixes: + Add more extensive test cases for cache remapping + Regression fix: Do not override __hash__ in apt.package.Package (LP: 1780099 in bionic+) * CI / pre-build / data changes: - Replace broken travis CI integration with current docker-based one - utils/get_debian_mirrors.py: Get data from salsa (for pre-build hook) - debian/control: Point to salsa instead of anonscm - debian/gbp.conf: Point to ubuntu/trusty branch - Updated mirror list -- Julian Andres Klode Tue, 10 Jul 2018 16:59:07 +0200 ** Changed in: python-apt (Ubuntu Trusty) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1737441 Title: python-apt crashes if objects of one cache are passed to depcache belonging to another cache Status in python-apt package in Ubuntu: Fix Released Status in unattended-upgrades package in Ubuntu: Fix Released Status in python-apt source package in Trusty: Fix Released Status in unattended-upgrades source package in Trusty: Won't Fix Status in python-apt source package in Xenial: Fix Released Status in unattended-upgrades source package in Xenial: Won't Fix Status in python-apt source package in Bionic: Fix Released Status in unattended-upgrades source package in Bionic: Fix Released Bug description: [Impact] Some applications, like unattended-upgrades or update-manager, reopen the apt cache. They also keep around old apt.Package objects however, and operate on them after reopening. Under the hood, this means that apt_pkg.Package objects belonging to an old cache are passed to a new cache. APT relies on the ID of the package (it's position in the cache) for it's operation. So if a package has ID 0 in the old cache, and a different package has ID 0 in the new cache, performing operations on the old package would perform it on the new package. If the old package's ID is out of bounds in the new cache, the behavior is undefined - it's an out of bounds array access. [Test case] The attached test case has a list of packages 0-9, a-z; stores the package "z" into a variable, then reopens the cache. It then marks z for deletion. This either segfaults or does nothing; when it should mark z for deletion. More test cases like this are in the autopkgtest. [Regression potential] The initial fix introduced bug 1780099, there might be similar bugs lurking. However, these bugs would have been undefined behavior before and might have caused segmentation faults or did the wrong thing. It seems likely that any regression cannot possibly be worse than the current state. [Other info] The xenial SRU also includes the change "python/tag.cc: Fix invalid read in TagFileNext". We don't have any specific verification for it, as we just saw weird crashes on the error tracker, and this seemed like the culprit. We released bionic with it, and it seems fine. The fix is fairly obvious: We were copying the char array "Start" which was not nul terminated in an odd way, without using the lenght. [Original bug report] The Ubuntu Error Tracker has been receiving reports about a problem regarding unattended-upgrades. This problem was most recently seen with package version 0.98ubuntu1, the problem page at https://errors.ubuntu.com/problem/727153285ba3335a07f801a298a3d94cbe6ba05d contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1737441/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1737441] Re: python-apt crashes if objects of one cache are passed to depcache belonging to another cache
This bug was fixed in the package python-apt - 1.1.0~beta1ubuntu0.16.04.2 --- python-apt (1.1.0~beta1ubuntu0.16.04.2) xenial; urgency=medium * python/tag.cc: Fix invalid read in TagFileNext * DepCache: Check that candidate we are setting belongs to package * Raise CacheMismatchError if objects passed to DepCache are from different cache (LP: #1737441); also includes the following regression fixes from bionic: - apt.Cache: Remap objects when reopening cache (LP: 1773316 in bionic+), incl. regression fixes: + Add more extensive test cases for cache remapping + Regression fix: Do not override __hash__ in apt.package.Package (LP: 1780099 in bionic+) * CI / pre-build / data changes: - Replace broken travis CI integration with current docker-based one - utils/get_debian_mirrors.py: Get data from salsa (for pre-build hook) - debian/control: Point to salsa instead of anonscm - debian/gbp.conf: Point to 1.1.y-xenial branch - Updated mirror list -- Julian Andres Klode Tue, 10 Jul 2018 12:47:50 +0200 ** Changed in: python-apt (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1737441 Title: python-apt crashes if objects of one cache are passed to depcache belonging to another cache Status in python-apt package in Ubuntu: Fix Released Status in unattended-upgrades package in Ubuntu: Fix Released Status in python-apt source package in Trusty: Fix Released Status in unattended-upgrades source package in Trusty: Won't Fix Status in python-apt source package in Xenial: Fix Released Status in unattended-upgrades source package in Xenial: Won't Fix Status in python-apt source package in Bionic: Fix Released Status in unattended-upgrades source package in Bionic: Fix Released Bug description: [Impact] Some applications, like unattended-upgrades or update-manager, reopen the apt cache. They also keep around old apt.Package objects however, and operate on them after reopening. Under the hood, this means that apt_pkg.Package objects belonging to an old cache are passed to a new cache. APT relies on the ID of the package (it's position in the cache) for it's operation. So if a package has ID 0 in the old cache, and a different package has ID 0 in the new cache, performing operations on the old package would perform it on the new package. If the old package's ID is out of bounds in the new cache, the behavior is undefined - it's an out of bounds array access. [Test case] The attached test case has a list of packages 0-9, a-z; stores the package "z" into a variable, then reopens the cache. It then marks z for deletion. This either segfaults or does nothing; when it should mark z for deletion. More test cases like this are in the autopkgtest. [Regression potential] The initial fix introduced bug 1780099, there might be similar bugs lurking. However, these bugs would have been undefined behavior before and might have caused segmentation faults or did the wrong thing. It seems likely that any regression cannot possibly be worse than the current state. [Other info] The xenial SRU also includes the change "python/tag.cc: Fix invalid read in TagFileNext". We don't have any specific verification for it, as we just saw weird crashes on the error tracker, and this seemed like the culprit. We released bionic with it, and it seems fine. The fix is fairly obvious: We were copying the char array "Start" which was not nul terminated in an odd way, without using the lenght. [Original bug report] The Ubuntu Error Tracker has been receiving reports about a problem regarding unattended-upgrades. This problem was most recently seen with package version 0.98ubuntu1, the problem page at https://errors.ubuntu.com/problem/727153285ba3335a07f801a298a3d94cbe6ba05d contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1737441/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1737441] Re: python-apt crashes if objects of one cache are passed to depcache belonging to another cache
The updates work fine, as can be seen by the autopkgtest, and a manual run also confirms it: = xenial = $ run test Changed [] <..crash..> $ add proposed and upgrade Unpacking python3-apt (1.1.0~beta1ubuntu0.16.04.2) over (1.1.0~beta1ubuntu0.16.04.1) $ run test Changed [] = trusty = $ run test Changed [] <..crash..> $ add proposed and upgrade Unpacking python3-apt (0.9.3.5ubuntu3) over (0.9.3.5ubuntu2) ... $ run test Changed [] ** Tags removed: verification-needed verification-needed-trusty verification-needed-xenial ** Tags added: verification-done verification-done-trusty verification-done-xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1737441 Title: python-apt crashes if objects of one cache are passed to depcache belonging to another cache Status in python-apt package in Ubuntu: Fix Released Status in unattended-upgrades package in Ubuntu: Fix Released Status in python-apt source package in Trusty: Fix Committed Status in unattended-upgrades source package in Trusty: Won't Fix Status in python-apt source package in Xenial: Fix Committed Status in unattended-upgrades source package in Xenial: Won't Fix Status in python-apt source package in Bionic: Fix Released Status in unattended-upgrades source package in Bionic: Fix Released Bug description: [Impact] Some applications, like unattended-upgrades or update-manager, reopen the apt cache. They also keep around old apt.Package objects however, and operate on them after reopening. Under the hood, this means that apt_pkg.Package objects belonging to an old cache are passed to a new cache. APT relies on the ID of the package (it's position in the cache) for it's operation. So if a package has ID 0 in the old cache, and a different package has ID 0 in the new cache, performing operations on the old package would perform it on the new package. If the old package's ID is out of bounds in the new cache, the behavior is undefined - it's an out of bounds array access. [Test case] The attached test case has a list of packages 0-9, a-z; stores the package "z" into a variable, then reopens the cache. It then marks z for deletion. This either segfaults or does nothing; when it should mark z for deletion. More test cases like this are in the autopkgtest. [Regression potential] The initial fix introduced bug 1780099, there might be similar bugs lurking. However, these bugs would have been undefined behavior before and might have caused segmentation faults or did the wrong thing. It seems likely that any regression cannot possibly be worse than the current state. [Other info] The xenial SRU also includes the change "python/tag.cc: Fix invalid read in TagFileNext". We don't have any specific verification for it, as we just saw weird crashes on the error tracker, and this seemed like the culprit. We released bionic with it, and it seems fine. The fix is fairly obvious: We were copying the char array "Start" which was not nul terminated in an odd way, without using the lenght. [Original bug report] The Ubuntu Error Tracker has been receiving reports about a problem regarding unattended-upgrades. This problem was most recently seen with package version 0.98ubuntu1, the problem page at https://errors.ubuntu.com/problem/727153285ba3335a07f801a298a3d94cbe6ba05d contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1737441/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1737441] Re: python-apt crashes if objects of one cache are passed to depcache belonging to another cache
Hello errors.ubuntu.com, or anyone else affected, Accepted python-apt into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/python- apt/1.1.0~beta1ubuntu0.16.04.2 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! ** Changed in: python-apt (Ubuntu Xenial) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-xenial ** Changed in: python-apt (Ubuntu Trusty) Status: New => Fix Committed ** Tags added: verification-needed-trusty -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1737441 Title: python-apt crashes if objects of one cache are passed to depcache belonging to another cache Status in python-apt package in Ubuntu: Fix Released Status in unattended-upgrades package in Ubuntu: Fix Released Status in python-apt source package in Trusty: Fix Committed Status in unattended-upgrades source package in Trusty: Won't Fix Status in python-apt source package in Xenial: Fix Committed Status in unattended-upgrades source package in Xenial: Won't Fix Status in python-apt source package in Bionic: Fix Released Status in unattended-upgrades source package in Bionic: Fix Released Bug description: [Impact] Some applications, like unattended-upgrades or update-manager, reopen the apt cache. They also keep around old apt.Package objects however, and operate on them after reopening. Under the hood, this means that apt_pkg.Package objects belonging to an old cache are passed to a new cache. APT relies on the ID of the package (it's position in the cache) for it's operation. So if a package has ID 0 in the old cache, and a different package has ID 0 in the new cache, performing operations on the old package would perform it on the new package. If the old package's ID is out of bounds in the new cache, the behavior is undefined - it's an out of bounds array access. [Test case] The attached test case has a list of packages 0-9, a-z; stores the package "z" into a variable, then reopens the cache. It then marks z for deletion. This either segfaults or does nothing; when it should mark z for deletion. More test cases like this are in the autopkgtest. [Regression potential] The initial fix introduced bug 1780099, there might be similar bugs lurking. However, these bugs would have been undefined behavior before and might have caused segmentation faults or did the wrong thing. It seems likely that any regression cannot possibly be worse than the current state. [Other info] The xenial SRU also includes the change "python/tag.cc: Fix invalid read in TagFileNext". We don't have any specific verification for it, as we just saw weird crashes on the error tracker, and this seemed like the culprit. We released bionic with it, and it seems fine. The fix is fairly obvious: We were copying the char array "Start" which was not nul terminated in an odd way, without using the lenght. [Original bug report] The Ubuntu Error Tracker has been receiving reports about a problem regarding unattended-upgrades. This problem was most recently seen with package version 0.98ubuntu1, the problem page at https://errors.ubuntu.com/problem/727153285ba3335a07f801a298a3d94cbe6ba05d contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1737441/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1737441] Re: python-apt crashes if objects of one cache are passed to depcache belonging to another cache
** Description changed: [Impact] Some applications, like unattended-upgrades or update-manager, reopen the apt cache. They also keep around old apt.Package objects however, and operate on them after reopening. Under the hood, this means that apt_pkg.Package objects belonging to an old cache are passed to a new cache. APT relies on the ID of the package (it's position in the cache) for it's operation. So if a package has ID 0 in the old cache, and a different package has ID 0 in the new cache, performing operations on the old package would perform it on the new package. If the old package's ID is out of bounds in the new cache, the behavior is undefined - it's an out of bounds array access. [Test case] The attached test case has a list of packages 0-9, a-z; stores the package "z" into a variable, then reopens the cache. It then marks z for deletion. This either segfaults or does nothing; when it should mark z for deletion. More test cases like this are in the autopkgtest. [Regression potential] The initial fix introduced bug 1780099, there might be similar bugs lurking. However, these bugs would have been undefined behavior before and might have caused segmentation faults or did the wrong thing. It seems likely that any regression cannot possibly be worse than the current state. + [Other info] + The xenial SRU also includes the change "python/tag.cc: Fix invalid read in TagFileNext". We don't have any specific verification for it, as we just saw weird crashes on the error tracker, and this seemed like the culprit. We released bionic with it, and it seems fine. The fix is fairly obvious: We were copying the char array "Start" which was not nul terminated in an odd way, without using the lenght. + [Original bug report] The Ubuntu Error Tracker has been receiving reports about a problem regarding unattended-upgrades. This problem was most recently seen with package version 0.98ubuntu1, the problem page at https://errors.ubuntu.com/problem/727153285ba3335a07f801a298a3d94cbe6ba05d contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1737441 Title: python-apt crashes if objects of one cache are passed to depcache belonging to another cache Status in python-apt package in Ubuntu: Fix Released Status in unattended-upgrades package in Ubuntu: Fix Released Status in python-apt source package in Trusty: Fix Committed Status in unattended-upgrades source package in Trusty: Won't Fix Status in python-apt source package in Xenial: Fix Committed Status in unattended-upgrades source package in Xenial: Won't Fix Status in python-apt source package in Bionic: Fix Released Status in unattended-upgrades source package in Bionic: Fix Released Bug description: [Impact] Some applications, like unattended-upgrades or update-manager, reopen the apt cache. They also keep around old apt.Package objects however, and operate on them after reopening. Under the hood, this means that apt_pkg.Package objects belonging to an old cache are passed to a new cache. APT relies on the ID of the package (it's position in the cache) for it's operation. So if a package has ID 0 in the old cache, and a different package has ID 0 in the new cache, performing operations on the old package would perform it on the new package. If the old package's ID is out of bounds in the new cache, the behavior is undefined - it's an out of bounds array access. [Test case] The attached test case has a list of packages 0-9, a-z; stores the package "z" into a variable, then reopens the cache. It then marks z for deletion. This either segfaults or does nothing; when it should mark z for deletion. More test cases like this are in the autopkgtest. [Regression potential] The initial fix introduced bug 1780099, there might be similar bugs lurking. However, these bugs would have been undefined behavior before and might have caused segmentation faults or did the wrong thing. It seems likely that any regression cannot possibly be worse than the current state. [Other info] The xenial SRU also includes the change "python/tag.cc: Fix invalid read in TagFileNext". We don't have any specific verification for it, as we just saw weird crashes on the error tracker, and this seemed like the culprit. We released bionic with it, and it seems fine. The fix is fairly obvious: We were copying the char array "Start" which was not nul terminated in an odd way, without using the lenght. [Original bug report] The Ubuntu Error Tracker has been receiving reports about a
