summaryrefslogtreecommitdiff
path: root/test/integration/test-sourceslist-trusted-options
Commit message (Collapse)AuthorAgeFilesLines
* let {dsc,tar,diff}-only implicitly enable download-onlyDavid Kalnischkies2016-12-161-2/+2
| | | | | | That was the case already for tar-only and diff-only, but in a more confusing way and without a message while dsc "worked" before resulting in a dpkg-source error shortly after as tar/diff files aren't available…
* tests: support spaces in path and TMPDIRDavid Kalnischkies2015-12-191-2/+2
| | | | | | | This doesn't allow all tests to run cleanly, but it at least allows to write tests which could run successfully in such environments. Git-Dch: Ignore
* review of new/changed translatable program stringsJustin B Rye2015-11-211-1/+1
| | | | | Reference mail: https://lists.debian.org/debian-l10n-english/2015/11/msg00006.html
* rework errors and warnings around insecure repositoriesDavid Kalnischkies2015-11-041-2/+2
| | | | | | | | | | | | | | | | Insecure (aka unsigned) repositories are bad, period. We want to get right of them finally and as a first step we are printing scary warnings. This is already done, this commit just changes the messages to be more consistent and prevents them from being displayed if authenticity is guaranteed some other way (as indicated with trusted=yes). The idea is to first print the pure fact like "repository isn't signed" as a warning (and later as an error), while giving an explaination in a immediately following notice (which is displayed only in quiet level 0: so in interactive use, not in scripts and alike). Closes: 796549
* detect and error out on conflicting Trusted settingsDavid Kalnischkies2015-08-101-0/+17
| | | | | | | A specific trust state can be enforced via a sources.list option, but it effects all entries handled by the same Release file, not just the entry it was given on so we enforce acknowledgement of this by requiring the same value to be (not) set on all such entries.
* test exitcode as well as string equalityDavid Kalnischkies2015-03-161-2/+2
| | | | | | | | We use test{success,failure} now all over the place in the framework, so its only consequencial to do this in the situations in which we test for a specific output as well. Git-Dch: Ignore
* chown finished partial files earlierDavid Kalnischkies2014-10-231-2/+8
| | | | | | | | | | | | | | | | | partial files are chowned by the Item baseclass to let the methods work with them. Now, this baseclass is also responsible for chowning the files back to root instead of having various deeper levels do this. The consequence is that all overloaded Failed() methods now call the Item::Failed base as their first step. The same is done for Done(). The effect is that even in partial files usually don't belong to _apt anymore, helping sneakernets and reducing possibilities of a bad method modifying files not belonging to them. The change is supported by the framework not only supporting being run as root, but with proper permission management, too, so that privilege dropping can be tested with them.
* testcases: do not allow warnings in testsuccessDavid Kalnischkies2014-10-201-6/+6
| | | | | | | | | | Adds a new testwarning which tests for zero exit and the presents of a warning in the output, failing if either is not the case or if an error is found, too. This allows us to change testsuccess to accept only totally successful executions (= without warnings) which should help finding regressions. Git-Dch: Ignore
* testcases runable as rootDavid Kalnischkies2014-10-151-1/+1
| | | | | | | Running the testcases is usually not a good idea, but it can be handy to check if the privilege dropping works. Git-Dch: Ignore
* fix compile and tests errorDavid Kalnischkies2014-10-131-0/+27
| | | | | | I am pretty sure I did that before committing broken stuff… Git-Dch: Ignore
* trusted=yes sources are secure, we just don't know whyDavid Kalnischkies2014-10-131-0/+168
Do not require a special flag to be present to update trusted=yes sources as this flag in the sources.list is obviously special enough. Note that this is just disabling the error message, the user will still be warned about all the (possible) failures the repository generated, it is just triggering the acceptance of the warnings on a source-by-source level. Similarily, the trusted=no flag doesn't require the user to pass additional flags to update, if the repository looks fine in the view of apt it will update just fine. The unauthenticated warnings will "just" be presented then the data is used. In case you wonder: Both was the behavior in previous versions, too.