apt/test/integration, branch 2.1.4

Check satisfiability for versioned provides, not providing version

2020-05-19T09:22:19Z

References: dcdfb4723a9969b443d1c823d735e192c731df69

Recognize propagated protected in pkgProblemResolver

2020-05-18T13:55:36Z

Turns out that pkgDepCache and pkgProblemResolver maintain two (semi) independent sets of protected flags – except that a package if marked protected in the pkgProblemResolver is automatically also marked in the pkgDepCache as protected. This way the pkgProblemResolver will have as protected only the direct user requests while pkgDepCache will (hopefully) propagate the flag to unavoidable dependencies of these requests nowadays. The pkgProblemResolver was only checking his own protected flag though and based on that calls our Mark* methods usually without checking return, leading to it believing it could e.g. remove packages it actually can't remove as pkgDepCache will not allow it as it is marked as protected there. Teaching it to check for the flag in the pkgDepCache instead avoids it believing in the wrong things eventually giving up. The scoring is keeping the behaviour of adding the large score boost only for the direct user requests though as there is no telling which other sideeffects this might have if too many packages get too many points from the get-go. Second part of fixing #960705, now with pkgProblemResolver output which looks more like the whole class of problem is resolved rather than a teeny tiny edgecase it was before.

Propagate protected to already satisfied dependencies

2020-05-18T13:55:36Z

The previous commit deals with negative, now we add the positive side of things as well which makes this a recursive endevour. As we can push the protected flag forward only if a single solution for a dependency exists it is easy for trees to not get it, so if resolving becomes difficult it won't help at all.

Propagate protected to already satisfied conflicts

2020-05-18T13:55:36Z

If we propagate protected e.g. due to a user request we should also act upon (at the moment) satisfied negative dependencies so that the resolver knows that installing this package later is not an option. That the problem resolver is trying bad solutions is a bug by itself which existed before and after and should be worked on. Closes: #960705

Keep going if a dep is bad for user requests to improve errors

2020-05-18T13:55:36Z

We exit early from installing dependencies of a package only if it is not a user request to avoid polluting the state with installs which might not be needed (or detrimental even) for alternative choices. We do continue with installing dependencies though if it is a user request as it will improve error reporting for apt and can even help aptitude not hang itself so much as we trim the problem space down for its resolver dealing with all the easy things. Similar things can be said about the testcase I have short-circuit previously… keep going test, do what you should do to report errors!

Fix location of testdeb in added regression tests

2020-05-13T20:04:13Z

SECURITY UPDATE: Fix out of bounds read in .ar and .tar implementation (CVE-2020-3810)

2020-05-12T16:55:55Z

When normalizing ar member names by removing trailing whitespace and slashes, an out-out-bound read can be caused if the ar member name consists only of such characters, because the code did not stop at 0, but would wrap around and continue reading from the stack, without any limit. Add a check to abort if we reached the first character in the name, effectively rejecting the use of names consisting just of slashes and spaces. Furthermore, certain error cases in arfile.cc and extracttar.cc have included member names in the output that were not checked at all and might hence not be nul terminated, leading to further out of bound reads. Fixes Debian/apt#111 LP: #1878177

Allow aptitude to MarkInstall broken packages via FromUser

2020-05-08T13:52:14Z

apt marks packages coming from the commandline among others as protected to ensure the various resolver parts do not fiddle with the state of these packages. aptitude (and potentially others) do not so the state is modified (to a Keep which for uninstalled means it is not going to be installed) due to being uninstallable before the call fails – basically reverting at least some state changes the call made before it realized it has to fail, which is usually a good idea, except if users expect you to not do it. They do set the FromUser option though which has beside controlling autobit also gained the notion of "the user is always right" over time and can be used for this one here as well preventing the state revert. References: 0de399391372450d0162b5a09bfca554b2d27c3d Reported-By: Jessica Clarke on IRC

apt list: Fix behavior of regex vs fnmatch vs wildcards

2020-05-04T11:08:33Z

Previously (and still in cacheset), patterns where only allowed to start with ? or ~, which ignores the fact that a pattern might just as well start with a negation, such a !~nfoo. Also, we ignored the --regex flag if it looked like this, which was somewhat bad. Let's change this all: * If --regex is given, arguments are always interpreted as regex * If it is a valid package wildcard (name or * characters), then it will be interpreted as a wildcard - this set of characters is free from meaningful overlap with patterns. * Otherwise, the argument is interpreted as a pattern. For a future version, we need to adapt parsing for cacheset and list to use a common parser, to avoid differences in their interpretation. Likely, this code will go into the pattern parser, such that it generates a pattern given a valid fnmatch argument for example.

Reinstate * wildcards

2020-05-04T10:48:56Z

Reinstate * wildcards as they are safe to use, but do not allow any other special characters such as ? or []. Notably, ? would overlap with patterns, and [] might overlap with future pattern extensions (alternative bracketing style), it's also hard to explain. Closes: #953531 LP: #1872200