aboutsummaryrefslogtreecommitdiff
path: root/t/conflicts.t
Commit message (Collapse)AuthorAge
* t: Consistently remove temp directory before testing, not afterSimon McVittie2019-02-03
| | | | | | When a test fails, it's useful to be able to inspect the output. Signed-off-by: Simon McVittie <smcv@debian.org>
* Exclude working directory from library path (CVE-2016-1238)Simon McVittie2016-07-28
| | | | | | | | | | | | | | | | | | | | | Current Perl versions put '.' at the end of the library search path @INC, although this will be fixed in a future Perl release. This means that when software loads an optionally-present module, it will be looked for in the current working directory before giving up. An attacker could use this to execute arbitrary Perl code from ikiwiki's current working directory. Removing '.' from the library search path in Perl is the correct fix for this vulnerability, but is not trivial to do due to backwards-compatibility concerns. Mitigate this (even if ikiwiki is run with a vulnerable Perl version) by explicitly removing '.' from the search path, and instead looking for ikiwiki's own modules relative to the absolute path of the executable when run from the source directory. In tests that specifically want to use the current working directory, use "-I".getcwd instead of "-I." so we use its absolute path, which is immune to the removal of ".".
* Run autopkgtest tests using autodep8 and the pkg-perl team's infrastructureSimon McVittie2015-11-30
|
* Standardize on --long-option instead of -long-optionSimon McVittie2015-03-01
| | | | | | | | | | [[forum/refresh_and_setup]] indicates some confusion between --setup and -setup. Both work, but it's clearer if we stick to one in documentation and code. A 2012 commit to [[plugins/theme]] claims that "-setup" is required and "--setup" won't work, but I cannot find any evidence in ikiwiki's source code that this has ever been the case.
* another class of conflicts: subdir/file conflictsJoey Hess2010-07-18
|
* 2 more casesJoey Hess2010-07-18
|
* avoid error if two source files render the same destination fileJoey Hess2010-07-18
| | | | | | | There are two sub-caces. If both source files still exist, the winner that renders the destination file is undefined. If one source file is deleted and the other added, in a refresh, the new file will take over the destination file.
* some other (similar) failure casesJoey Hess2010-07-18
|
* updateJoey Hess2010-07-17
|
* turning into complete source file conflict test suiteJoey Hess2010-07-17