summaryrefslogtreecommitdiff
path: root/test
Commit message (Collapse)AuthorAgeFilesLines
* Do not set the binary dir in run-tests, it breaks stuffJulian Andres Klode2016-08-101-6/+0
| | | | | | | This breaks -j and does all sort of other weird stuff I did not notice in the previous (non-parallel) runs. Gbp-Dch: ignore
* test: Automatically discover CMake build directoryJulian Andres Klode2016-08-102-1/+27
| | | | | | | Look at the project root, and all directories directly below it and pick the directory with the newest CMakeCache.txt file. Gbp-Dch: ignore
* Get rid of the old buildsystemJulian Andres Klode2016-08-104-163/+0
| | | | Bye, bye, old friend.
* CMake: Add unit testsJulian Andres Klode2016-08-104-8/+31
| | | | | | | | Add support for our GTest based unit tests. By default, CMake will look in /usr/src/gtest for the external GTest project, but this can be overriden by defining GTEST_ROOT when invoking cmake. Gbp-Dch: ignore
* CMake: Switch integration tests and travis overJulian Andres Klode2016-08-064-9/+21
| | | | | | This early support seems a bit hacky, but it's a hard switch: The integration tests do not understand the old build system anymore afterwards. I don't really like that.
* test: Pass -maxdepth 1 when running find in methods dirJulian Andres Klode2016-08-063-3/+3
| | | | | This fixes a test failures in the cmake branch which contains sub directories in the methods output dir.
* (error) va_list 'args' was opened but not closed by va_end()David Kalnischkies2016-07-271-1/+1
| | | | | Reported-By: cppcheck Gbp-Dch: Ignore
* rred: truncate result file before writing to itDavid Kalnischkies2016-07-272-5/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | If another file in the transaction fails and hence dooms the transaction we can end in a situation in which a -patched file (= rred writes the result of the patching to it) remains in the partial/ directory. The next apt call will perform the rred patching again and write its result again to the -patched file, but instead of starting with an empty file as intended it will override the content previously in the file which has the same result if the new content happens to be longer than the old content, but if it isn't parts of the old content remain in the file which will pass verification as the new content written to it matches the hashes and if the entire transaction passes the file will be moved the lists/ directory where it might or might not trigger errors depending on if the old content which remained forms a valid file together with the new content. This has no real security implications as no untrusted data is involved: The old content consists of a base file which passed verification and a bunch of patches which all passed multiple verifications as well, so the old content isn't controllable by an attacker and the new one isn't either (as the new content alone passes verification). So the best an attacker can do is letting the user run into the same issue as in the report. Closes: #831762
* use a configurable location for apport report storageDavid Kalnischkies2016-07-222-1/+5
| | | | | Hardcoding /var/crash means we can't test it properly and it isn't really our style.
* support dpkg debug mode in APT::StateChangesDavid Kalnischkies2016-07-221-1/+1
| | | | Gbp-Dch: Ignore
* create non-existent files in edit-sources with 644 instead of 640David Kalnischkies2016-07-221-0/+39
| | | | | | | | | | If the sources file we want to edit doesn't exist yet GetLock will create it with 640, which for a generic lockfile might be okay, but as this is a sources file more relaxed permissions are in order – and actually required as it wont be readable for unprivileged users causing warnings/errors in apt calls. Reported-By: J. Theede (musca) on IRC
* tests: avoid time-dependent rebuild of cachesDavid Kalnischkies2016-07-221-0/+4
| | | | | | | | | The tests changes the sources.list and the modification time of this file is considered while figuring out if the cache can be good. Usually this isn't an issue, but in that case we have the cache generation produce warnings which appear twice in this case. Gbp-Dch: Ignore
* clean up default-stanzas from extended_states on writeDavid Kalnischkies2016-07-221-0/+8
| | | | | | | | | | The existing cleanup was happening only for packages which had a status change (install -> uninstalled) which is the most frequent but no the only case – you can e.g. set autobits explicitly with apt-mark. This would leave stanzas in the states file declaring a package to be manually installed – which is the default value for a package not listed at all, so we can just as well drop it from the file.
* tests: skip over -flags for first option in autotestsDavid Kalnischkies2016-07-221-1/+9
| | | | | | | Otherwise calls like "apt -q install" end up calling "aptautotest_apt_q" instead of "aptautotest_apt_install" Gbp-Dch: Ignore
* support "install ./foo.changes"David Kalnischkies2016-07-221-4/+5
| | | | | | | | | | | | We support installing ./foo.deb (and ./foo.dsc for source) for a while now, but it can be a bit clunky to work with those directly if you e.g. build packages locally in a 'central' build-area. The changes files also include hashsums and can be signed, so this can also be considered an enhancement in terms of security as a user "just" has to verify the signature on the changes file then rather than checking all deb files individually in these manual installation procedures.
* allow arch=all to override No-Support-for-Architecture-allDavid Kalnischkies2016-07-223-3/+38
| | | | | | | | | | | | | If a user explicitly requests the download of arch:all apt shouldn't get in the way and perform its detection dance if arch:all packages are (also) in arch:any files or not. This e.g. allows setting arch=all on a source with such a field (or one which doesn't support all at all, but has the arch:all files like Debian itself ATM) to get only the arch:all packages from there instead of behaving like a no-op. Reported-By: Helmut Grohne on IRC
* don't hardcode /var/lib/dpkg/status as dir::state::statusDavid Kalnischkies2016-07-191-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Theoretically it should be enough to change the Dir setting and have apt pick the dpkg/status file from that. Also, it should be consistently effected by RootDir. Both wasn't really the case through, so a user had to explicitly set it too (or ignore it and have or not have expected sideeffects caused by it). This commit tries to guess better the location of the dpkg/status file by setting dir::state::status to a naive "../dpkg/status", just that this setting would be interpreted as relative to the CWD and not relative to the dir::state directory. Also, the status file isn't really relative to the state files apt has in /var/lib/apt/ as evident if we consider that apt/ could be a symlink to someplace else and "../dpkg" not effected by it, so what we do here is an explicit replace on apt/ – similar to how we create directories if it ends in apt/ – with dpkg/. As this is a change it has the potential to cause regressions in so far as the dpkg/status file of the "host" system is no longer used if you set a "chroot" system via the Dir setting – but that tends to be intended and causes people to painfully figure out that they had to set this explicitly before, so that it now works more in terms of how the other Dir settings work (aka "as expected"). If using the host status file is really intended it is in fact easier to set this explicitely compared to setting the new "magic" location explicitely.
* ensure Cnf::FindFile doesn't return files below /dev/nullDavid Kalnischkies2016-07-191-0/+28
| | | | | | | Very unlikely, but if the parent is /dev/null, the child empty and the grandchild a value we returned /dev/null/value which doesn't exist, so hardly a problem, but for best operability we should be consistent in our work and return /dev/null always.
* tests: activate dpkg multi-arch even if test is single archDavid Kalnischkies2016-07-152-33/+36
| | | | | | | | | | | | | | Most tests are either multiarch, do not care for the specific architecture or do not interact with dpkg, so really effect by this is only test-external-installation-planner-protocol, but its a general issue that while APT can be told to treat any architecture as native dpkg has the native architecture hardcoded so if we run tests we must make sure that dpkg knows about the architecture we will treat as "native" in apt as otherwise dpkg will refuse to install packages from such an architecture. This reverts f883d2c3675eae2700e4cd1532c1a236cae69a4e as it complicates the test slightly for no practical gain after the generic fix.
* Use native arch in test-external-installation-planner-protocolJulian Andres Klode2016-07-151-22/+23
| | | | Hardcoding amd64 broke the tests.
* tests: fix external solver/planner directory setupDavid Kalnischkies2016-07-081-10/+7
| | | | | The setup didn't prepare the directories as expected by newer version of tthe external tests in an autopkgtests environment.
* Add kernels with "+" in the package name to APT::NeverAutoRemoveAndrew Patterson2016-07-081-3/+9
| | | | | | | | | Escape "+" in kernel package names when generating APT::NeverAutoRemove list so it is not treated as a regular expression meta-character. [Changed by David Kalnischkies: let test actually test the change] Closes: #830159
* don't change owner/perms/times through file:// symlinksDavid Kalnischkies2016-07-063-1/+21
| | | | | | | | | | | | | If we have files in partial/ from a previous invocation or similar such those could be symlinks created by file:// sources. The code is expecting only real files through and happily changes owner, modification times and permission on the file the symlink points to which tend to be files we have no business in touching in this way. Permissions of symlinks shouldn't be changed, changing owner is usually pointless to, but just to be sure we pick the easy way out and use lchown, check for symlinks before chmod/utimes. Reported-By: Mattia Rizzolo on IRC
* tests: disable EIPP logging in test-compressed-indexesDavid Kalnischkies2016-07-051-1/+2
| | | | | | | | | | | The test makes heavy use of disabling compression types which are usually available some way or another like xz which is how the EIPP logs are compressed by default. Instead of changing this test to change the filename according to the compression we want to test we just disable EIPP logging for this test as that is easier and has the same practical effect. Gbp-Dch: Ignore
* tests: allow setting environment in extra fileDavid Kalnischkies2016-07-051-0/+4
| | | | | | | | It can be handy to set apt options for the testcases which shouldn't be accidentally committed like external planner testing or workarounds for local setups. Gbp-Dch: Ignore
* Make the test case executableJulian Andres Klode2016-07-051-0/+0
| | | | Gbp-Dch: ignore
* indextargets: Check that cache could be built before using itJulian Andres Klode2016-07-051-0/+27
| | | | | | This caused a crash because the cache was a nullptr. Closes: #829651
* use +0000 instead of UTC by default as timezone in outputDavid Kalnischkies2016-07-022-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | All apt versions support numeric as well as 3-character timezones just fine and its actually hard to write code which doesn't "accidently" accepts it. So why change? Documenting the Date/Valid-Until fields in the Release file is easy to do in terms of referencing the datetime format used e.g. in the Debian changelogs (policy §4.4). This format specifies only the numeric timezones through, not the nowadays obsolete 3-character ones, so in the interest of least surprise we should use the same format even through it carries a small risk of regression in other clients (which encounter repositories created with apt-ftparchive). In case it is really regressing in practice, the hidden option -o APT::FTPArchive::Release::NumericTimezone=0 can be used to go back to good old UTC as timezone. The EDSP and EIPP protocols use this 'new' format, the text interface used to communicate with the acquire methods does not for compatibility reasons even if none of our methods would be effected and I doubt any other would (in these instances the timezone is 'GMT' as that is what HTTP/1.1 requires). Note that this is only true for apt talking to methods, (libapt-based) methods talking to apt will respond with the 'new' format. It is therefore strongly adviced to support both also in method input.
* warn if apt-key is used in scripts/its output parsedDavid Kalnischkies2016-07-012-2/+11
| | | | | | | | | apt-key needs gnupg for most of its operations, but depending on it isn't very efficient as apt-key is hardly used by users – and scripts shouldn't use it to begin with as it is just a silly wrapper. To draw more attention on the fact that e.g. 'apt-key add' should not be used in favor of "just" dropping a keyring file into the trusted.gpg.d directory this commit implements the display of warnings.
* do not treat same-version local debs as downgradeDavid Kalnischkies2016-07-011-1/+5
| | | | | | As the volatile sources are parsed last they were sorted behind the dpkg/status file and hence are treated as a downgrade, which isn't really what you want to happen as from a user POV its an upgrade.
* reinstalling local deb file is no downgradeDavid Kalnischkies2016-07-011-7/+17
| | | | | | | | | | | | If we have a (e.g. locally built) deb file installed and do try to install it again apt complained about this being a downgrade, but it wasn't as it is the very same version… it was just confused into not merging the versions together which looks like a downgrade then. The same size assumption is usually good, but given that volatile files are parsed last (even after the status file) the base assumption no longer holds, but is easy to adept without actually changing anything in practice.
* protect only the latest same-source providers from autoremoveDavid Kalnischkies2016-07-011-0/+36
| | | | | | | | | | | | | Traditionally all providers are protected providing something as apt can't know which of them is actually really providing the functionality for the user ensuring that we don't propose the removal of used stuff, but that is of course also keeping stuff around which could be removed. That can cause the collection of multiple old providers until the provided package is itself no longer needed (e.g. out-of-tree kernel modules). We combat this by marking providers only from the newest source package version so that old providers built by older versions of the same source package can be garbage collected.
* tests: deduplicate package creation framework codeDavid Kalnischkies2016-06-301-58/+38
| | | | Gbp-Dch: Ignore
* don't do atomic overrides with failed filesDavid Kalnischkies2016-06-291-0/+35
| | | | | | | | We deploy atomic renames for some files, but these renames also happen if something about the file failed which isn't really the point of the exercise… Closes: 828908
* eipp: let apt make a plan, not make stuff planeDavid Kalnischkies2016-06-293-20/+21
| | | | | | | | | | | | | | Julian noticed on IRC that I fall victim to a lovely false friend by calling referring to a 'planer' all the time even through these are machines to e.g. remove splinters from woodwork ("make stuff plane"). The term I meant is written in german in this way (= with a single n) but in english there are two, aka: 'planner'. As that is unreleased code switching all instances without any transitional provisions. Also the reason why its skipped in changelog. Thanks: Julian Andres Klode Gbp-Dch: Ignore
* eipp: enable xz-compressed scenario loggingDavid Kalnischkies2016-06-272-7/+52
| | | | | | | | | | | | In 385d9f2f23057bc5808b5e013e77ba16d1c94da4 I implemented the storage of scenario files based on enabling this by default for EIPP, but I implemented it first optionally for EDSP to have it independent. The reasons mentioned in the earlier commit (debugging and bugreports) obviously apply here, especially as EIPP solutions aren't user approved, nearly impossible to verify before starting the execution and at the time of error the scenario has changed already, so that reproducing the issue becomes hard(er).
* eipp: include global errors in reported errorDavid Kalnischkies2016-06-271-4/+4
| | | | Git-Dch: Ignore
* eipp: properly handle arch-specific providesDavid Kalnischkies2016-06-271-13/+13
| | | | | The generation of the EIPP request was a bit to strict not generation what would actually be needed to be part of the scenario.
* eipp: provide the internal planer as an external oneDavid Kalnischkies2016-06-273-1/+7
| | | | | | Testing the current implementation can benefit from being able to be feed an EIPP request and produce a fully compliant response. It is also a great test for EIPP in general.
* eipp: output at most two versions per packageDavid Kalnischkies2016-06-271-0/+28
| | | | | | | | | | | | | We can trim generation time and size of the EIPP scenario considerable if we we avoid telling the planers about "uninteresting" packages. This is one of the simpler but already very effective reductions: Do not tell planers about versions which are neither installed nor are to be installed as they have no effect on the plan we don't need to tell the planer about them. EDSP solvers need to know about all versions for better choice and error messages, but planers really don't. Git-Dch: Ignore
* eipp: implement version 0.1 of the protocolDavid Kalnischkies2016-06-271-1/+3
| | | | | | | | | | | | | | | | | | | | | | | The very first step in introducing the "external installation planer protocol" (short: EIPP) as part of my GSoC2016 project. The description reads: APT-based tools like apt-get, aptitude, synaptic, … work with the user to figure out how their system should look like after they are done installing/removing packages and their dependencies. The actual installation/removal of packages is done by dpkg with the constrain that dependencies must be fulfilled at any point in time (e.g. to run maintainer scripts). Historically APT has a super micro-management approach to this task which hasn't aged that well over the years mostly ignoring changes in dpkg and growing into an unmaintainable mess hardly anyone can debug and everyone fears to touch – especially as more and more requirements are tacked onto it like handling cycles and triggers, dealing with "important" packages first, package sources on removable media, touch minimal groups to be able to interrupt the process if needed (e.g. unattended-upgrades) which not only sky-rocket complexity but also can be mutually exclusive as you e.g. can't have minimal groups and minimal trigger executions at the same time.
* tests: add epoch-packages to try clean with epochsDavid Kalnischkies2016-06-271-7/+24
| | | | Git-Dch: Ignore
* add insecure (and weak) allow-options for sources.listDavid Kalnischkies2016-06-223-9/+35
| | | | | | | | Weak had no dedicated option before and Insecure and Downgrade were both global options, which given the effect they all have on security is rather bad. Setting them for individual repositories only isn't great but at least slightly better and also more consistent with other settings for repositories.
* add [weak] tag to hash errors to indicate insufficiencyDavid Kalnischkies2016-06-224-71/+71
| | | | | | | For "Hash Sum mismatch" that info doesn't make a whole lot of difference, but for the new insufficient info message an indicator that while this hashes are there and even match, they aren't enough from a security standpoint.
* better error message for insufficient hashsumsDavid Kalnischkies2016-06-221-3/+32
| | | | | | | | Downloading and saying "Hash Sum mismatch" isn't very friendly from a user POV, so with this change we try to detect such cases early on and report it, preferably before download even started. Closes: 827758
* generalize secure->insecure downgrade protectionDavid Kalnischkies2016-06-221-0/+26
| | | | | | | Handling the extra check (and force requirement) for downgrades in security in our AllowInsecureRepositories checker helps in having this check everywhere instead of just in the most common place and requiring a little extra force in such cases is always good.
* handle weak-security repositories as unauthenticatedDavid Kalnischkies2016-06-221-20/+138
| | | | | | | | | | | | | | | | APT can be forced to deal with repositories which have no security features whatsoever, so just giving up on repositories which "just" fail our current criteria of good security features is the wrong incentive. Of course, repositories are better of fixing their setup to provide the minimum of security features, but sometimes this isn't possible: Historic repositories for example which do not change (anymore). That also fixes problem with repositories which are marked as trusted, but are providing only weak security features which would fail the parsing of the Release file. Closes: 827364
* run update post-invokes even on (partial) failuresDavid Kalnischkies2016-06-221-3/+9
| | | | | | | Unsecure repositories result in error messages by default which causes the acquire run to fail hard, but non-failing repositories are still updated just like in the slightly less hard-failures which got this behaviour in 35664152e47a1d4d712fd52e0f0a2dc8ed359d32.
* implement and document DIRECT for auto-detect-proxyDavid Kalnischkies2016-06-201-28/+27
| | | | | | | There is a subtile difference between an empty setting and "DIRECT" in the configuration as the later overrides the generic settings while the earlier does not. Also, non-zero exitcodes should really be reported as an error rather than silently discarded.
* do not error if auto-detect-proxy cmd has no outputDavid Kalnischkies2016-06-201-1/+7
| | | | | | | | | | | Regression introduced in 8f858d560e3b7b475c623c4e242d1edce246025a. Commands are probably better of always having output through as the fall through to the generic proxy settings is likely not intended. As documenting and implementing this more consistently is kind of a regression through, it is split off into the next commit. Closes: 827713
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2024-11-05 14:45:35 +0000