Control: severity -1 normal Control: merge -1 717679 On Wed, May 06, 2015 at 04:39:05PM +0200, Stefan Schlesinger wrote: > Justification: could cause unwanted versions to be installed without notice > Severity: grave No*. At least if you are careful you have a few chances of noticing it. The -V option e.g. tells you the versions. The download progress tells you were stuff comes from. > Running apt-get update on a system at the same time with other apt commands, > causes apt to resolve package dependencies and policies inconsistently. > > Behavior causes race conditions during package cache update, resulting in altered > candidate versions and you will end up with unwanted versions being installed (eg. > when running 'apt-get upgrade -y’ or working with unattended-upgrades). > > Current stable version in Jessie - 1.0.9.8 is also affected. Every version ever in existence in the last 17 years is effected. That it survived 17 years is reason enough to not give it RC severity. Also note that you need root-rights to run 'apt-get update' (or equivalent) commands, much like you need root-rights to run 'rm -rf /'. rm got over the years safeguards to prevent this, but this will never be perfect and we are much in the same position. In the end root is the only account who can do everything, but it should be asked if that means that it should do everything. Maybe running multiple apt commands in parallel is just in general not a good idea… and btw, neither it is for dpkg or any other package management tool. Many things are heavily interlocked here working in concert to make package installation possible. Sometimes I think 'we' higherlevel parts like apt just made it "too easy". On every other plattform which can be updated nobody would ever ask for running stuff in parallel, simply because those happen in total lockdown… > IMO, this should either be an atomic file/directory move, once package files where > downloaded successfully, or apt-get update should make use of locking as well. This isn't really about the Packages files, but about the Release files and only on a second step about all the other files apt downloads. What sounds like a trivial implementation happily explodes into a code nightmare with only slightly less edgecases than decimal places of pi. We are slowly getting better, but there is only so much you can do with the resources we have… > We saw this issue affecting multiple apt commands and actions: Everyone using libapt is "effected" if you will, so even stuff like the typical software-center. And not all these are started and/or always working as root, so just 'locking' is not an option if you don't happen to forbid every use of libapt as non-root in the process and only allow libapt to be loaded by only one root application at the time. That would immensly cripple the useability for next to no gain… Best regards David Kalnischkies
Attachment:
signature.asc
Description: Digital signature