apt/apt-pkg, branch 1.4_beta3

ParseDepends: Support passing the desired architecture

2017-01-02T13:27:52Z

This is useful for e.g. Britney, where the Build-Depends would have to be parsed for multiple architectures. With this change, the call can choose the architecture without having to mess with the config. Signed-off-by: Niels Thykier Closes: #845969 (jak@d.o: made the code compile)

allow warning generation for non-whitelisted options

2016-12-31T17:24:12Z

The idea is simple: Each¹ Find*( call starts with a call check if the given option (with the requested type) exists in the whitelist. The whitelist is specified via our configure-index file so that we have a better chance at keeping it current. the whitelist is loaded via a special (undocumented for now) configuration stanza and if none is loaded the empty whitelist will make it so that no warnings are shown. Much needs to be done still, but that is as good a time as any to take a snapshot of the current state and release it into the wild given that it found some bugs already and has no practical effect on users. ¹ not all in this iteration, but many

fix minimum pkgs option for dpkg --recursive usage

2016-12-31T17:23:25Z

Interpreting a boolean as an int works just fine – it just hasn't the intended result – it isn't a serious problem through as the disabling of the usage of this dpkg calling style is just an "optimization"

use FindB instead of FindI for Debug::pkgAutoRemove

2016-12-31T01:29:21Z

Again no practical difference, but for consistency a boolean option should really be accessed via a boolean method rather than an int especially if you happen to try setting the option to "true" … Gbp-Dch: Ignore

avoid producing invalid options if repo has no host

2016-12-31T01:29:21Z

This can happen e.g. for file: repositories. There is no inherent problem with setting such values internally, but its bad style, forbidden in the manpage and could be annoying in the future. Gbp-Dch: Ignore

gets file location via FindFile instead of manual merge

2016-12-31T01:29:21Z

Unlikely to have any practical effect, but its more consistent to use the right methods instead of performing it slightly incorrect by hand. Gbp-Dch: Ignore

ensure generation of valid EDSP error stanzas

2016-12-31T01:29:20Z

The crude way of preparing a message to be a multiline value failed at generation valid deb822 in case the error message ended with a new line like the resolving errors from apt do. apt itself can parse these, but other tools like grep-dctrl choke on it, so be nice and print valid. Reported-By: Johannes 'josch' Schauer on IRC

do not generate Maximum-Size if we already have that field

2016-12-31T01:29:20Z

Any respective parser will do the right thing and grab the last value, but its better for style to generate that field only once. Gbp-Dch: Ignore

warn if clearsigned file has ignored content parts

2016-12-31T01:29:19Z

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.

reword "Can't drop priv" warning message

2016-12-16T12:50:00Z

Note: This is a warning about disabling a security feature. It is supposed to be scary as we are disabling a security feature and we can't just be silent about it! Downloads really shouldn't happen any longer as root to decrease the attack surface – but if a warning causes that much uproar, consider what an error would do… The old WARNING message: | W: Can't drop privileges for downloading as file 'foobar' couldn't be | accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied) is frequently (incorrectly) considered to be an error message indicating that the download didn't happen which isn't the case, it was performed, but without all the security features enabled we could have used if run from some other place… The word "unsandboxed" is chosen as the term 'sandbox(ed)' is a common encounter in feature lists/changelogs and more people are hopefully able to make the connection to 'security' than it is the case for 'privilege dropping' which is more correct, but far less known. Closes: #813786 LP: #1522675