summaryrefslogtreecommitdiff
path: root/test/libapt
Commit message (Collapse)AuthorAgeFilesLines
* Fix and avoid quoting in CommandLine::AsStringDavid Kalnischkies2017-03-191-1/+9
| | | | | | | | | | | | | | | | In the intended usecase where this serves as a hack there is no problem with double/single quotes being present as we write it to a log file only, but nowadays our calling of apt-key produces a temporary config file containing this "setting" as well and suddently quoting is important as the config file syntax is allergic to it. So the fix is to ignore all quoting whatsoever in the input and just quote (with singles) the option values with spaces. That gives us 99% of the time the correct result and the 1% where the quote is an integral element of the option … doesn't exist – or has bigger problems than a log file not containing the quote. Same goes for newlines in values. LP: #1672710
* CMake: Document that the globs are expanded during CMakeJulian Andres Klode2017-01-171-0/+3
| | | | | | | This will avoid people from thinking that they have to do nothing when they change the set of files. Gbp-Dch: ignore
* Read dpkg tables to handle architecture wildcardsJulian Andres Klode2017-01-171-22/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our implementation of wildcards was rudimentary. It worked for some common ones, but it was also broken: For example, armel matched any-armel, but should match any-arm. With this commit, we load the correct tables from dpkg. Supported are both triplets and quadruplet tables (the latter introduced in dpkg 1.18.11). There are some odd things we have to deal with in the cache filter for historical and API reasons: * The character "*" must be accepted as an alternative to any - in fact it may appear anywhere in the wildcard as we also allow fnmatch() style wildcard matching on the commandline. * The code might get passed an arch with a minus at the end, for example the cmdline "install apt:any-arm-" will first try to check if any-arm- is a valid architecture. We deal with this by rejecting any wildcard ending in a minus. * Triplets are actually implemented by extending them to faux quadruplets - by prepending a "base" component for the architecture tuple, and "any" if there is a wildcard component. Once we have constructed a wildcard, it is transformed into an fnmatch() expression for historical reasons. In the future, we should really get a tuple class and implement matching in a better, more explicit way. This does for now though - it passes all the test cases and accepts all things it should accept. Closes: #748936 Thanks: James Clarke <jrtc27@jrtc27.com> for the initial patch
* Run parsedepends_test for two different native archsJulian Andres Klode2017-01-021-40/+43
| | | | | | | Run the test for kfreebsd-i386 and amd64 and pass "amd64" as an additional argument to the function. This tests that the argument is used and thus ParseDepends returns the amd64 results even on a different architecture like i386.
* warn if clearsigned file has ignored content partsDavid Kalnischkies2016-12-313-0/+356
| | | | | | | | | | | | | Clearsigned files like InRelease, .dsc, .changes and co can potentially include unsigned or additional messages blocks ignored by gpg in verification, but a potential source of trouble in our own parsing attempts – and an unneeded risk as the usecases for the clearsigned files we deal with do not reasonably include unsigned parts (like emails or some such). This commit changes the silent ignoring to warnings for now to get an impression on how widespread unintended unsigned parts are, but eventually we want to turn these into hard errors.
* optional write aptwebserver log to client specific filesDavid Kalnischkies2016-11-251-0/+39
| | | | | | | | | | | | The test test-handle-redirect-as-used-mirror-change serves multiple clients at the same time, so the order of the output is undefined and once in a while the two clients will intermix their lines causing the grep we perform on it later to fail making our tests fail. Solved by introducing client-specific logfiles which we all grep and sort the result to have the results more stable. Git-Dch: Ignore
* follow the googletest merge in build-dependsDavid Kalnischkies2016-11-251-2/+4
|
* Do not read stderr from proxy autodetection scriptsJulian Andres Klode2016-10-042-0/+35
| | | | | | | | | | | | | This fixes a regression introduced in commit 8f858d560e3b7b475c623c4e242d1edce246025a don't leak FD in AutoProxyDetect command return parsing which accidentally made the proxy autodetection code also read the scripts output on stderr, not only on stdout when it switched the code from popen() to Popen(). Reported-By: Tim Small <tim@seoss.co.uk>
* CMake: test/libapt: Use a prebuilt GTest library if availableJulian Andres Klode2016-09-021-15/+26
| | | | | | | If a non-existing source directory is specified, try finding the system gtest library. Debian derived distributions are a bit strange because they only ship the source code and not the library...
* tests: silence -Wmissing-declarationsDavid Kalnischkies2016-09-013-7/+3
| | | | | Gbp-Dch: Ignore Reported-By: gcc -Wmissing-declarations
* tests: don't do boundless string compares with data()David Kalnischkies2016-08-121-9/+11
| | | | Git-Dch: Ignore
* ensure a good clock() value for usage and testsDavid Kalnischkies2016-08-121-1/+9
| | | | | | | | | | | We use clock() as a very cheap way of getting a "random" value, but the manpage warns that this could return -1, so we should be dealing with this. Additionally, e.g. on hurd-i386 the value increases only slowly – to slow for our fast running tests for randomness hence producing the same range in both samples, so we introduce a simple busy-wait loop (as clock is counting processor time used by the program) in the test which delays the second sample just enough making our randomness a bit more predictable.
* don't perform int<float in progress bar drawingDavid Kalnischkies2016-08-121-1/+6
| | | | | | | | Comparing floating numbers is always fun and in this instance a 9 < 9.0 is "somehow" true on hurd-i386 letting the tests fail by reporting that too much progress achieved. A bit mysterious, but with some rework we can use code which avoids dealing with the floats in this way entirely and make our testcases happy.
* allow user@host (aka: no password) in URI parsingDavid Kalnischkies2016-08-101-0/+12
| | | | If the URI had no password the username was ignored
* Get rid of the old buildsystemJulian Andres Klode2016-08-101-84/+0
| | | | Bye, bye, old friend.
* CMake: Add unit testsJulian Andres Klode2016-08-103-8/+30
| | | | | | | | 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
* 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.
* 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
* avoid std::get_time usage to sidestep libstdc++6 bugDavid Kalnischkies2016-06-171-0/+35
| | | | | | | | | | | | | | | | As reported upstream in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71556 the implementation of std::get_time is currently not as accepting as strptime is, especially in how hours should be formatted. Just reverting 9febc2b238e1e322dce1f94ecbed46d595893b52 would be possible, but then we would reopen the problems fixed by it, so instead I opted here for a rewrite of the parsing logic which makes this method a lot longer, but at least it provides the same benefits as the rewrite in std::get_time was intended to give us and decouples us from the fix of the issue in the standard library implementation of GCC. LP: 1593583
* don't leak an FD in lz4 (de)compressionDavid Kalnischkies2016-06-101-1/+1
| | | | | Seen first in #826783, but as this buglog also shows leaked uncompressed files as well we don't close it just yet.
* accept only the expected UTC timezones in date parsingDavid Kalnischkies2016-05-281-0/+38
| | | | | | | | | | | | | | | | | | HTTP/1.1 hardcodes GMT (RFC 7231 §7.1.1.1) and what is good enough for the internet must be good enough for us™ as we reuse the implementation internally to parse (most) dates we encounter in various places like the Release files with their Date and Valid-Until header fields. Implementing a fully timezone aware parser just feels too hard for no effective benefit as it would take 5+ years (= until LTS's are out of fashion) until a repository could use non-UTC dates and expect it to work. Not counting non-apt implementations which might or might not only want to encounter UTC here as well. As a bonus, this eliminates the use of an instance of setlocale in libapt. Closes: 819697
* fix and document on the fly compressor configDavid Kalnischkies2016-05-271-12/+22
| | | | | | | libapt allows to configure compressors to be used by its system via configuration implemented in 03bef78461c6f443187b60799402624326843396, but that was never really documented and also only partly working, which also explains why the tests weren't using it…
* properly format multiline error messagesDavid Kalnischkies2016-04-251-0/+34
|
* tests: reenable basic auth test and add @ in usernameDavid Kalnischkies2016-03-191-1/+9
| | | | | | | | | | On launchpad #1558484 a user reports that @ in the authentication tokens parsing of sources.list isn't working in an older (precise) version. It isn't the recommended way of specifying passwords and co (auth.conf is), but we can at least test for regressions (and in this case test at all… who was that "clever" boy disabling a test with exit……… oh, nevermind. Git-Dch: Ignore
* Do not consider SHA1 usableJulian Andres Klode2016-03-131-1/+8
| | | | | SHA1 is not reasonably secure anymore, so we should not consider it usable anymore. The test suite is adjusted to account for this.
* test that seeking to a position earlier in the file worksJulian Andres Klode2016-02-101-0/+12
| | | | | | This tests the fix for #812994, #813000 Gbp-Dch: ignore
* support <libc>-<kernel>-<cpu> in architecture specsDavid Kalnischkies2016-01-312-0/+88
| | | | | | | | | | | | | | | | | | | APT has a different understanding than dpkg (#748936) what matches and what doesn't match an architecture specification as it isn't converting back (and forward) to Debian triplets. That has to eventually be solved some way or the other, but until that happens we change the matching in apt so that porters can continue their work on non-gnu libc-ports even if policy doesn't specify that yet (and dpkg just supporting it "by accident" via triplets). The initial patch was reformatted, fixed in terms of patterns containing "any-any", dealing with expanding an arch without libc to gnu while a pattern expands libc to any, the parsedepends test was fixed (the new if's were inserted one step too early) and another test just for the specifications added. Closes: #812212 Thanks: Bálint Réczey for initial patch
* stablize gtest testcase environmentDavid Kalnischkies2016-01-263-4/+26
| | | | | | | | | Avoid the dependency on a specific current path for the tar test and ensure that _system is correctly initialized (gcc-6 runs into a segfault otherwise and with it fixed starts to depend on the multi-arch configuration of the running system… not good). Git-Dch: Ignore
* string_view: Drop constexpr constructor for standard compatibilityJulian Andres Klode2016-01-151-8/+8
| | | | | | | | | | | | | APT::StringView is supposed to be a temporary measure, until support for the standardized string_view is widely available. Introducing additional unstandardized features just makes porting to the standard version harder. The constexpr constructor also won't have any real effect on most systems, as the compiler will happily optimise the strlen() call away for constant strings. Gbp-Dch: ignore
* provide a constexpr char[] overload for APT::StringViewDavid Kalnischkies2016-01-151-0/+88
| | | | | | The commit also adds a few trivial tests Git-Dch: Ignore
* add optional support for comments in pkgTagFileDavid Kalnischkies2016-01-021-0/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | APT usually deals with perfectly formatted files generated automatically be other programs – and as it has to parse multiple MBs of such files it tries to be fast rather than forgiving. This was always a problem if we reused this parser for files with a deb822 syntax which are mostly written by hand however, like apt_preferences or the deb822-style sources as these can include stray newlines and more importantly comments all over the place. As a stopgap we had pkgUserTagSection which deals at least with comments before and after a given stanza, but comments in between weren't really supported and now that we support parsing debian/control for e.g. build-dep we face the full comment problem e.g. with comments inbetween multi-line fields (like Build-Depends). We can't easily deal with this on the pkgTagSection level as the interface gives access to 'raw' char-pointers for performance reasons so we would need to optionally add a buffer here on which we could remove comments to hand out pointers into this buffer instead. The interface is quite large already and supports writing stanzas as well, which does not support comments at all either. So while in future it might make sense to have a parser setup which deals with and keeps comments in this commit we opt for the simpler solution for now: We officially declare that pkgTagSection does not support comments and instead expect the caller to deal with them, which in our case is pkgTagFile: pkgTagFile is extended with an additional mode which can deal with comments by dropping them from the buffer which will later form the input of pkgTagSection. The actual implementation is slightly more complex than this sentence suggests at first on one hand to have good performance and on the other to allow jumping directly to stanzas with offsets collected in a previous run (like our cache generation does it for example).
* deal with empty values properly in deb822 parserDavid Kalnischkies2015-12-271-1/+4
| | | | | | | | Regression introduced in 8710a36a01c0cb1648926792c2ad05185535558e, but such fields are unlikely in practice as it is just as simple to not have a field at all with the same result of not having a value. Closes: 808102
* Fix FileUtlTest.GetTempDir failure when run as rootPino Toscano2015-12-191-3/+7
| | | | | | | | | | | Testing /usr as TMPDIR assumes that GetTempDir() cannot use it because it cannot write to it; this is true for non-root users, but not so much for root. Since root can access everything, perform this particular test case only when not running as root. Closes: #808383
* Do not swap required and important in pkgCache::Priority()Julian Andres Klode2015-12-101-0/+16
| | | | | | | | required and important were swapped, leading to wrong output. Closes: #807523 Thanks: Manuel A. Fernandez Montecelo for discovering this
* outsmart gcc -O3 over-optimization in pkgCdrom::FindPackagesDavid Kalnischkies2015-11-271-0/+2
| | | | | | | | Seems like a simpler workaround than forcing a lower optimization level just for this for all of apt. See also: https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1473674
* support setting empty values (sanely) & removing support forDavid Kalnischkies2015-11-191-0/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | space-gapping: '-o option= value' That is a very old feature (straight from 1998), but it is super surprising if you try setting empty values and instead get error messages or a non-empty value as the next parameter is treated as the value – which could have been empty, so if for some reason you need a compatible way of setting an empty value try: '-o option="" ""'. I can only guess that the idea was to support '-o option value', but we survived 17 years without it, we will do fine in the future I guess. Similar is the case for '-t= testing' even through '-t testing' existed before and the code even tried to detect mistakes like '-t= -b' … all gone now. Technically that is as its removing a feature replacing it with another a major interface break. In practice I really hope for my and their sanity that nobody was using this; but if for some reaon you do: Remove the space and be done. I found the patch and the bugreport actually only after the fact, but its reassuring that others are puzzled by this as well and hence a thanks is in perfect order here as the patch is practical identical [expect that this one here adds tests and other bonus items]. Thanks: Daniel Hartwig for initial patch. Closes: 693092
* do not use _apt for file/copy sources if it isn't world-accessibleDavid Kalnischkies2015-11-191-0/+6
| | | | | | | | | | | | | | | | | | | | | | In 0940230d we started dropping privileges for file (and a bit later for copy, too) with the intend of uniforming this for all methods. The commit message says that the source will likely fail based on the compressors already – and there isn't much secret in the repository content. After all, after apt has run the update everyone can access the content via apt anyway… There are sources through which worked before which are mostly single-deb (and those with the uncompressed files available). The first one being especially surprising for users maybe, so instead of failing, we make it so that apt detects that it can't access a source as _apt and if so doesn't drop (for all sources!) privileges – but we limit this to file/copy, so the uncompress which might be needed will still fail – but that failed before this regression. We display a notice about this, mostly so that if it still fails (e.g. compressed) the user has some idea what is wrong. Closes: 805069
* encode UTF-8 characters correctly in QuoteStringDavid Kalnischkies2015-11-051-0/+11
| | | | | | | Limit the field length to a char to avoid bogus FF for utf-8 characters with the default length. Closes: 799123
* apply various suggestions made by cppcheckDavid Kalnischkies2015-11-051-1/+1
| | | | | Reported-By: cppcheck Git-Dch: Ignore
* ensure FileFd doesn't try to open /dev/null as atomic and coDavid Kalnischkies2015-11-041-0/+30
| | | | | | | | | | The wrapping will fail in the best case and actually end up deleting /dev/null in the worst case. Given that there is no point in trying to write atomically to /dev/null as you can't read from it again just ignore these flags if higher level code ends up trying to use them on /dev/null. Git-Dch: Ignore
* support arch:all data e.g. in separate Packages fileDavid Kalnischkies2015-11-041-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on a discussion with Niels Thykier who asked for Contents-all this implements apt trying for all architecture dependent files to get a file for the architecture all, which is treated internally now as an official architecture which is always around (like native). This way arch:all data can be shared instead of duplicated for each architecture requiring the user to download the same information again and again. There is one problem however: In Debian there is already a binary-all/ Packages file, but the binary-any files still include arch:all packages, so that downloading this file now would be a waste of time, bandwidth and diskspace. We therefore need a way to decide if it makes sense to download the all file for Packages in Debian or not. The obvious answer would be a special flag in the Release file indicating this, which would need to default to 'no' and every reasonable repository would override it to 'yes' in a few years time, but the flag would be there "forever". Looking closer at a Release file we see the field "Architectures", which doesn't include 'all' at the moment. With the idea outlined above that 'all' is a "proper" architecture now, we interpret this field as being authoritative in declaring which architectures are supported by this repository. If it says 'all', apt will try to get all, if not it will be skipped. This gives us another interesting feature: If I configure a source to download armel and mips, but it declares it supports only armel apt will now print a notice saying as much. Previously this was a very cryptic failure. If on the other hand the repository supports mips, too, but for some reason doesn't ship mips packages at the moment, this 'missing' file is silently ignored (= that is the same as the repository including an empty file). The Architectures field isn't mandatory through, so if it isn't there, we assume that every architecture is supported by this repository, which skips the arch:all if not listed in the release file.
* revamp all tools help messagesDavid Kalnischkies2015-11-041-1/+1
| | | | | | | | | | | | | | | | The general idea is: A small paragraph on the tool itself as a description, a list of the most used (!= all) commands available in the tool, a remark where to find more information on the tool and its commands (aka: in the manpage) and finally a common block referring to even more manpages. In exchange options are completely omitted from the output as well as deprecated or obscure commands. (Better) Information about them is available in the manpages anyway and the few options which were listed before were also the least interesting ones (-o -c -q and co are hardly of interest for someone totally new looking to find info by asking for help and anyone with a bit of experience doesn't need this short list. Those would need a list of options applying to the command they call, but they are too numerous and command specific to list them sanely in this context.
* move apts cmdline helper type into -privateDavid Kalnischkies2015-11-042-9/+9
| | | | | | | | Its not as simple as I initially thought to abstract this enough to make it globally usable, so lets not pollute global namespace with this for now. Git-Dch: Ignore
* generate commands array after config is loadedDavid Kalnischkies2015-11-042-4/+10
| | | | | | | This ensures that location strings loaded from a location specified via configuration (Dir::Locale) effect the help messages for commands. Git-Dch: Ignore
* add binary-specific options via Binary scopeDavid Kalnischkies2015-11-041-0/+17
| | | | | | Especially with apt now, it can be useful to set an option only for apt and not for apt-get. Using a binary-specific subtree which is merged into the root seems like a simple enough trick to achieve this.
* srv test: do 100 pulls twice and compare listDavid Kalnischkies2015-09-141-27/+61
| | | | | | | The previous implementation was still a bit unstable in terms of failing at times. Lets try if we have more luck with this one. Git-Dch: Ignore
* use clock() as source for SRV randomnessDavid Kalnischkies2015-09-011-8/+16
| | | | | | | | | | | | | | | Initializing a random number generator with the time since epoch could be good enough, but reaches its limits in test code as the 100 iterations might very well happen in the same second and hence the seed number is always the same… clock() has a way lower resolution so it changes more often and not unimportant: If many users start the update at the same time it isn't to unlikely the SRV record will be ordered in the same second choosing the same for them all, but it seems less likely that the exact same clock() time has passed for them. And if I have to touch this, lets change a few other things as well to make me and/or compilers a bit happier (clang complained about the usage of a GNU extension in the testcase for example).
* use unusable-for-security hashes for integrity checksDavid Kalnischkies2015-09-011-0/+14
| | | | | | | We want to declare some hashes as not enough for security, so that a user will need --allow-unauthenticated or similar to get data secured only by those hashes, but we can still us these hashes for integrity checks if we got them.
* Add test for using ExtractTar on compressed filesJulian Andres Klode2015-08-272-2/+43
| | | | Git-Dch: ignore
* Add basic (non weight adjusted) shuffling for SrvRecords selectionMichael Vogt2015-08-201-0/+33
| | | | | Also add "Debug::Acquire::SrvRecs" debug option and the option "Acquire::EnableSrvRecods" to allow disabling this lookup.