don't ask server if we have entire file in partial/

We have this situation in cases were parts of the transaction are
refused (e.g. in a hashsum mismatch) and rerun the update (e.g. in the
hope that we get a mirror which is synced this time).

Previously we would ask the server with an if-range and in the best case
recieve a 416 in response (less featureful server might end up giving us
the entire file again or we get the wrong file this time giving us a
hashsum mismatch…), which is a waste of time if we know already by
checking the hashsums that we got the complete and correct file.

add dep11 files to default Release patterns

make random acquire queues work less random

Queues feeding workers like rred are created in a random pattern to get
a few of them to run in parallel – but if we already have an idling queue
we don't need to assign it to a (potentially new) random queue as that
saves us the (agruably small) overhead of starting up a new queue,
avoids adding jobs to an already busy queue while others idle and as
a bonus reduces the size of debug logs a bit.

We also keep starting new queues now until we reach our limit before
we assign work at random to them, which should give us a more effective
utilisation overall compared to potentially adding work to busy queues
while we haven't reached our queue limit yet.

Release 1.2.11

ensure outdated files are dropped without lists-cleanup

Tested via (newly) empty index files, but effects also files dropped
from the repository or an otherwise changed repository config.

silently skip acquire of empty index files

There is just no point in taking the time to acquire empty files –
especially as it will be tiny non-empty compressed files usually.

allow uncompressed files to be empty in store again

With the previous fix for file applied we can again hit repositories
which contain uncompressed empty files, which since the introduction of
the central store: method wasn't accounted for anymore as we forbid
empty compressed files.

fix Alt-Filename handling of file method

A silly of-by-one error in the stripping of the extension to check for
the uncompressed filename broken in an attempt to support all
compressions in commit a09f6eb8fc67cd2d836019f448f18580396185e5.

Fixing this highlights also mistakes in the handling of the Alt-Filename
in libapt which would cause apt to remove the file from the repository
(if root has the needed rights – aka the disk isn't readonly or similar)

recheck Pre-Depends satisfaction in SmartConfigure

Regression introduced in commit 590f1923121815b36ef889033c1c416a23cbe9a2
(2011!) causing apt to not check if Pre-Depends are satisfied before
calling --configure. This managed to hide so perfectly well for years as
Pre-Depends aren't that common, apt prefers upgrading these packages
first and checks for satisfaction is already in SmartUnpack, so there
is only a small window of oppertunity to break a pre-dependency relation
(usually with an unpack).

Verified by logchecking with two provided status files in the buglog.
I would have liked to write a test, but I wasn't able to reach the needed
complexity to get apt to fail – but the change is small and reasonable,
so what could possible go wrong™, right?

LP: #1569099

detect compressed status files on extension again

It handy to be able to point apt at reading a compressed dpkg/status
file in debugging cases, which worked pre-1.1 but somewhere down the
line in the massive refactoring. Restoring this behavior in a central
place for all realfile index files instead of just for the status file.

(This has no effect on index files acquired from an archive – those are
handled by different classes and support compressed files just fine)

Hungarian program translation update

Closes: 820638

do not require non-broken systems in 'upgrade'

There is a good chance that the attempt will fail, but if a user
mentions certain packages explicitly on the commandline there is a
chance that this will consist of a broken system which is resolved
by upgrading more packages then just the mentioned.

This limitation was not effecting external resolvers.

webserver: 416 errors aren't closing connections

Breaking here lets our handler die which a client will fix by
reconnecting… but that eats time needlessly and is simple the wrong
handling, too.

Git-Dch: Ignore

stop handling items in doomed transactions

With the previous commit we track the state of transactions, so we can
now use our knowledge to avoid processing data for a transaction which
was already closed (via an abort in this case).

This is needed as multiple independent processes are interacting in the
process, so there isn't a simple immediate full-engine stop and it would
also be bad to teach each and every item how to check if its manager
has failed subordinate and what to do in that case.

In the pdiff case, which deals (potentially) with many items during its
lifetime e.g. a hashsum mismatch in another file can abort the
transaction the file we try to patch via pdiff belongs to. This causes
some of the items (which are already done) to be aborted with it, but
items still in the process of acquisition continue in the processing and
will later try to use all the items together failing in strange ways as
cleanup already happened.

The chosen solution is to dry up the communication channels instead by
ignoring new requests for data acquisition, canceling requests which are
not assigned to a queue and not calling Done/Failed on items anymore.
This means that e.g. already started or pending (e.g. pipelined)
downloads aren't stopped and continue as normal for now, but they remain
in partial/ and aren't processed further so the next update command will
pick them up and put them to good use while the current process fails
updating (for this transaction group) in an orderly fashion.

Closes: 817240
Thanks: Barr Detwix & Vincent Lefevre for log files

ensure transaction states are changed only once

We want to keep track of the state of a transaction overall to base
future decisions on it, but as a pre-requirement we have to make sure
that a transaction isn't commited twice (which happened if the download
of InRelease failed and Release takes over).

It also happened to create empty commits after a transaction was already
aborted in cases in which the Release files were rejected.

This isn't effecting security at the moment, but to ensure this isn't
happening again and can never be bad a bunch of fatal error messages are
added to make regressions on this front visible.

releasing package apt version 1.2.10

Fix `OnCalendar=*-*-* 6,18:00` instead of `OnCalendar=*-*-* 6:00,18:00`

See https://github.com/systemd/systemd/issues/2956 - it appears that
`OnCalendar=*-*-* 6,18:00` and `OnCalendar=*-*-* 6:00,18:00` are
quite different.

Git-Dch: ignore

Japanese program translation update

Closes: 819938

don't leak on error in listparser creation

Git-Dch: Ignore
Reported-By: gcc -fsanitize=address

use buffered writing for InRelease splitting

Hardly noticeable, but given that we have the option to easily enable
it, lets enable it as every newline in the message is written
individually by the code.

consistently add APT_OVERRIDE as method marker

Some methods had it missing, some used the keyword directly, which isn't
a problem as it is a cc file, but for consistency lets stick to our
macro for now.

Git-Dch: Ignore

Use systemd.timer instead of a cron job

The rational is that we need to spread the load on the mirrors
that apt update and unattended-upgrades cause. To do so, we
leverage the RandomizeDelay feature of systemd. The other advantage
is that the timer is not run at a fixed daily.daily time but
instead every 24h. This also fixes the problem that the randomized
deplay in the current apt.cron.daily causes other cron jobs to
be deplayed.

A compatibility cron job is also provided for systems that do not
use systemd.

Note that the time is fired two times a day, but the logic inside
of apt.systemd.daily will ensure (via stamp files) that the
servers are hit at most every 24h. Firing two times a day helps
with the worst case update time and it also helps with systems
that are not always on.

LP: #246381, #727685
Closes: #600262, #709675, #663290

Allow lowering trust level of a hash via config

Introduces APT::Hashes::<NAME> with entries Untrusted and Weak
which can be set to true to cause the hash to be treated as
untrusted and/or weak.

test-apt-update-reporting: Make more use of framework

Use msgtest and testsuccess with a function instead of failing
with a simple exit 1. This looks nicer.

Gbp-Dch: ignore

test-acquire-same-file-multiple-times: Delete files before retrying

This gets rid of byte-range requests and 416 responses.

Gbp-Dch: ignore

test-apt-download-progress: Use a larger file for testing

This should make the test less flaky, as with a small file,
we might have already received all the data before trying
to apply rate limits which is a constant source of failure
on the i386 Ubuntu autopkgtest.

zh_CN.po: update simplified Chinese translation. (100%)

Release 1.2.9

Do not mark packages for keep that we want to remove

If the package is marked for removal, keep it marked for
removal and do not mark it for keep. If we mark it for keep,
we some how later get to a different stage where it is marked
for unpack instead of removal.

In the example in the bug report, we would get a:

 SmartUnPack maas-region-controller-min:amd64 (replace version 2.0.0~alpha3+bzr4810-0ubuntu1 with Segmentation fault

maas-region-controller-min:amd64 was marked for removal, but
we changed it to keep and somehow it thinks that this is to
be replaced now instead of removed (probably because the
InstallVer != CandidateVer [with InstallVer = 0]).

This fixes a regression introduced in release 1.2.7, commit:
  0390edd5452b081f8efcf412f96d535a1d959457

Reported-by: LaMont Jones on IRC
LP: #1562402

drop confusing comma from no strong hash message

Release 1.2.8

Update symbols file

Set hidden visibility for StringView

This avoids templates using StringView to be exported, such as
std::vector<StringView*>::emplace_back().

Gbp-Dch: ignore

Japanese manpage translation update

Closes: 818950

handle gpgv's weak-digests ERRSIG

Our own gpgv method can declare a digest algorithm as untrusted and
handles these as worthless signatures. If gpgv comes with inbuilt
untrusted (which is called weak in official terminology) which it e.g.
does for MD5 in recent versions we should handle it in the same way.

To check this we use the most uncommon still fully trusted hash as a
configureable one via a hidden config option to toggle through all of
the three states a hash can be in.

properly check for "all good sigs are weak"

Using erase(pos) is invalid in our case here as pos must be a valid and
derefenceable iterator, which isn't the case for an end-iterator (like
if we had no good signature).
The problem runs deeper still through as VALIDSIG is a keyid while
GOODSIG is just a longid so comparing them will always fail.

Closes: 818910

refactor loading of previous release file

There is really no need to have the same code three times.

Git-Dch: Ignore

tests: reenable basic auth test and add @ in username

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

zh_CN.po: update simplified Chinese translation. (Closes: #818639)

100% translated.
Note: this commit contains a message from the future. #818639

cachefile: Only set members that were initialized successfully

Otherwise, things will just start failing later down the stack,
because (a) the lazy getters do not check if building was successful
and (b) any further getter call would return the invalid object
anyway.

Also initialize VS in pkgCache to nullptr by default.

Closes: #818628

zh_CN.po: update simplified chinese translation.

Note, 0 untran, 1 fuzzy, and the fuzzy string remains at Bug#818639.

test framework: Pass -n to lsof to speed up finding the https port

There is no point in resolving all addresses to their names, this
just seriously slows the setup phase down. So just pass -n to not
resolve names anymore.

Gbp-Dch: ignore

test-acquire-same-file-multiple-times: Run failing test up to 10 times

This should make the test less flaky and hopefully fix the failure
on Ubuntu's armhf CI nodes.

Gbp-Dch: ignore

Make test-apt-download-progress less flaky

The test is a bit flaky. In order to get it less flaky, reduce
the speed in each run. To compensate for issues, start with a
higher speed level. Also increase the number of runs to 10.

Furthermore, http get the same multiple-run loop, and the log
files are changed to indicate the protocol being tested, as it's
not obvious which one fails if it fails in quiet mode.

Gbp-Dch: ignore

do not strip epochs from state version strings

The epoch stripping in this code is done since day one, but in other
places we show a version epochs are not stripped. If epochs are present
in packages they tend to be an important information which we can't just
drop and especially can't drop "sometimes" as that confuses users and
tools alike – so even if removing code in use for (close to) 18 years
feels wrong, it is probably the right choice for consistency.

Closes: 818162

Make the weak signature message less ambigious

There was a complaint that, in the previous message,
the key fingerprint could be mistaken for a SHA1 digest
due to the (SHA1) after it.

Gbp-Dch: ignore

Use descriptive URIs in 104 Warning messages

This makes the new GPG related warnings much nicer to read,
for example, the second one here replaces the first one:

W: gpgv:/var/lib/apt/lists/example.com_dists_stable_InRelease: Weak ...
W: http://example.com/dists/stable/InRelease: Weak ...

methods/gpgv: Rewrite error handling and message

This should be easy to extend in the future and allow us to simplify
the error handling cases somewhat.

Thanks: Ron Lee for wording suggestions

Report non-transient errors as errors, not as warnings

This makes it easier to understand what really is an error
and what not.

Get accurate progress reporting in apt update again

For the non-pdiff case, we have can have accurate progress
reporting because after fetching the {,In}Release files we know
how many IndexFiles will be fetched and what size they have.

Therefore init the filesize early (in pkgAcqIndex::Init) and
ensure that in Acquire::Pulse() looks at already downloaded
bits when calculating the progress in Acquire::Pulse.

Also improve debug output of Debug::acquire::progress

tests: fix parallel execution to be working dir independent

Git-Dch: Ignore

Release 1.2.7

Fix bug where the problemresolve can put a pkg into a heisenstate

The problemresolver will set the candidate version for pkg P back
to the current version if it encounters an impossible to satisfy
critical dependency on P. However it did not set the State of
the package back as well which lead to a situation where P is
neither in Keep,Install,Upgrade,Delete state.

Note that this can not be tested via the traditional sh based
framework. I added a python-apt based test for this.

LP: #1550741

[jak@debian.org: Make the test not fail if apt_pkg cannot be
 imported]

methods/gpgv: Warn about SHA1 (and RIPEMD-160)

We will drop support for those in the future.

Also adjust the std::array to be a std::vector, as that's easier to
maintain.

apt-pkg/acquire-worker.cc: Introduce 104 Warning message

This can be used by workers to send warnings to the main
program. The messages will be passed to _error->Warning()
by APT with the URI prepended.

We are not going to make that really public now, as the
interface might change a bit.

methods/gpgv: Correctly handle weak signatures with multiple keys

We added weak signatures to BadSigners, meaning that a Release file
signed by both a weak signature and a strong signature would be
rejected; preventing people from migrating from DSA to RSA keys
in a sane way.

Instead of using BadSigners, treat weak signatures like expired
keys: They are no good signatures, and they are worthless.

Gbp-Dch: ignore

zh_CN.po: fix translation bug. (Closes: #818177)

methods/gpgv: Reject weak digest algorithms

This keeps a list of weak digest algorithms. For now, only MD5
is disabled, as SHA1 breaks to many repos.

Revert "Handle ERRSIG in the gpgv method like BADSIG"

This reverts commit 76a71a1237d22c1990efbc19ce0e02aacf572576.

That commit broke the test suite.

Gbp-Dch: ignore

Handle ERRSIG in the gpgv method like BADSIG

ERRSIG is created whenever a key uses an unknown/weak digest
algorithm, for example. This allows us to report a more useful
error than just "unknown apt-key error.":

The following signatures were invalid: ERRSIG 13B00F1FD2C19886 1 2 01 1457609403 5

While still not being the best reportable error message, it's
better than unknown apt-key error and hopefully redirects users
to complain to their repository owners.

test: Move --weak-digest initialization to the right place

This was wrong and caused some issues because apt-key invoked
host apt-config with our library.

Gbp-Dch: ignore

test: Use SHA512 digests for GPG, reject SHA1-based signatures

This makes the test suite safe if we ever need to reject SHA1
signatures in an update.

Spanish apt-mark translation fix

"%s can not be marked as it is not installed." was incorrectly
translated as "%s no se puede marcar como no instalado.\n",
which means "%s can not be marked as not installed."

Thanks to Marcos Del Sol Vives for reporting & to the spanish
translation team – and in particular Camaleón and Venturi –
for review and correction of this issue!

[commit message by commiter]

Closes: 817999

enforce verify of filesize in 'apt-get source'

The structure we parse the data into has a dedicated size field, but it
tends to be easier to handle it as a (very weak) checksum.

don't use Desc.URI to calculate .diff/Index filenames

The URI descibing an item can change via mirrors/redirectors which
causes the .diff/Index files to get the wrong names in storage.

Git-Dch: Ignore

streamline dpkgpm cleanup-handling

The (unlikely) waitpid failure case should fallthrough the code just
like the other failures (and successes) instead of taking a shortcut
avoiding all the cleanup (progress) and finishing touches (log, state).

This also delays the cleanup of the progress until apt is really done
with everything and "just" has the post-invokes left to do, so the
period of 'apt looks finished as it stopped the progress' and 'apt
really finished as I have the shell-prompt back' is shorter even if
there is no progress reported anymore, so the bar lingers at 100%…

Ideally even the post-invokes would be covered by progress, but they
can have their own output and dealing with that could be hard.

Git-Dch: Ignore

flush line-clearing on progress stop before post-invoke

All other interactions with std::cout are flushed directly, just in the
stop case we hadn't done it – no problem expect if there is still output
coming after apt is done like in the case of a post-invoke script
producing output.

Closes: 793672

aptwebserver: fix html validation issues

Iceweasel^WFirefox complains about the missing encoding in its console
which can be a bit annoying in interactive sessions, so fixing these
issues has no effect on apt itself, but on the testers.

Git-Dch: Ignore

require $(HASH)-Download field in .diff/Index files

Now that we ignore SHA1-only files it makes sense to require also the
provision of hashes for the compressed patches as this was introduced in
the same patchset as support for non-SHA1 hashes in the file itself in
dak and adding support in other archive creators (if they support pdiffs
at all) will likely be in the same batch.

The reason for the change itself is simple: If you are 'scared' enough
about the security of SHA1, you shouldn't uncompress a file you haven't
verified at all – after all, it could be exploiting a bug or a zip bomb.

test: remove SHA1 support testing as unsupported

Given that we refuse to use SHA1-only .diff/Indexes no point in shipping
and running code which pretends to check support for it which given that
all these tests are run 3 times eats a noticeable amount of time.

Git-Dch: Ignore

Test that SHA1-only .diff/Index files are not used

Ensure that .diff/Index files that only contain SHA1 values and no
SHA2 values are not used.

Do not consider SHA1 usable

SHA1 is not reasonably secure anymore, so we should not consider it
usable anymore. The test suite is adjusted to account for this.

Use native architecture instead of amd64 for build-dep-purge test

Using amd64 broke the test case on non-amd64 architectures. Query
the native architecture from dpkg and use that instead.

The definition of NATIVE is copied from the test
test-architecture-specification-parsing.

Dutch manpages translation update

Closes: 817062

Dutch program translation update

Closes: 817060

Release 1.2.6

apt-pkg/algorithms.cc: Avoid stack buffer overflow in KillList

Dynamically allocate KillList in order to avoid an overflow when
more than 100 elements would be written to it.

This happened while playing around with the status file from
Bug#701069 on a modern system.

Fix several typos

This effectively merges branch 'typofixes-vlajos-20150807' of github.com:vlajos/apt
with the following commit:

commit 13cacb3e2e2352ba701e769fc889e3344fabbf7e
Author: Veres Lajos <vlajos@gmail.com>
Date:   Sun Aug 9 00:12:53 2015 +0100

    typofix - https://github.com/vlajos/misspell_fixer

It has been rebased for a better commit message.

Release 1.2.5

debian/control: Set Standards-Version to 3.9.7

We do not follow the recommendation with regards to placement
of documentation in apt-doc, as we install in apt-doc, but
it's only a recommendation and I don't want think we should
move them.

get group again after potential remap in Source: parse

Mysteriously segfaults only on i386 for me, but at least one reporter
had the same behavior and it makes sense that this is the problem as the
parsing of Source: was fixed in 1.2.2 – before the not remapped group
was not used.

We don't use our usual Dynamic<> trick here as we don't have it in the
parser. Its a bit of a layer violation to do this parsing here, but its
how it is always was…

Until next time with this lovely kind of problem.

Closes: 812251
Thanks: Francesco Poli and Marc Haber for testdata.

Prevent double remapping of iterators and string views

If an iterator or a stringview has multiple dynamic objects
registered with it, it may be remapped twice. Prevent that
by noting which iterators/views we have seen and not remapping
one if we have already seen it.

We most likely do not have any instance of multiple dynamics
on a single object, but let's play safe - the overhead is not
high.

do not move not-failed pdiff-patches into CWD on failure

If a single pdiff fails, we have to fail the entire patching endeavour
and fall back to getting the complete file instead. That is easy in
serverside merged pdiffs as we get them one by one. For clientside we
get them all at once through, which means that a failure in one has to
stop the entire pipeline, which works as expected (as proven by the
bugreporters as they don't even notice it happening). The problem is
just that the first failing pdiff will do the cleanup, so another pdiff
which happens to be successfully acquired after we processed the failure
doesn't find the file it is supposed to use as a basename anymore, so
the patch is renamed to what should be the unique extension and moved
into the current working directory. Processing is then stopped as the
patch realizes that it isn't the last one which completed downloading.

On the plus side this means this is neither us using a bad temporary
location nor a security problem. It "just" overrides unconditionally
files in your current working directory (if you happen to have them
named like a pdiff patch – a bit unlikely perhaps) and so drops files
there which are never used again.

I guess this was introduced in 4e3c5633b1e74b4f58b95f339cfbbf4cbf21ab3e
for real as I made the need for the existence of the base file rather
explicit, but the potential lingers in the code for far longer.

Closes: #816837

Fix lzma write support to handle "try again" case

The liblzma-based write code needs the same tweaks that the read code
already has to cope with the situation where lzma_code returns zero the
first time through because avail_out is zero, but will do more work if
called again.

This ports the read tweaks to the write code as closely as possible
(including matching comments etc.).

Closes: #751688

add test for apt-key 0xKEY and use parameter expansion

Fixed in f7bd44bae0d7cb7f9838490b5eece075da83899e already, but the
commit misses the Closes tag and while we are at it we can add a simple
regression test and micro-optimize it a bit.

Thanks: James McCoy for the suggestion.
Closes: 816691

support APT::Get::Build-Dep-Automatic again in build-dep

In a249b3e6fd798935a02b769149c9791a6fa6ef16 I dropped with the manual
first resolver step also the support for installing build-deps as
automatic in such a way that it behaved like this option was enabled by
default.

Restoring support for it means that we go back to mark build-
dependencies as manually installed again by default and provide this
option to keep them as automatically installed.

tests: expect no output while compiling noopchroot

This way we hopefully notice (new) warnings in this little helper.

Git-Dch: Ignore

deal with partially downloaded changelogs

Changelogs are relatively small and we have no hashes for them, but we
had partial support for them before, so lets stick to it.

This also deletes the (partial) file before moving the downloaded file
into its place – rename(2) should be doing this by itself, but testing
on semaphoreci suggests that this isn't always the case (error is "Stale
file handle") and we don't need an atomic replace here, so be explicit.

Git-Dch: Ignore

apt-key del should correctly handle keyids prefixed with 0x

Release 1.2.4

Add missing numeric includes in files using std::accumulate()

Reported-By: Helmut Grohne on IRC

Fix crash with empty architecture list

If the architecture list is empty somehow, fail normally.

LP: #1549819

pass versioned provides to external solvers in EDSP

The EDSP output generated by apt didn't include the versioned provides
information so that every provides looked like an unversioned one in the
eyes of an external resolver.

Fix maintscript to properly remove 20changelog

Closes: #814754

always download changelogs into /tmp first

pkgAcqChangelog has the default behaviour of downloading a changelog to
a temporary directory (inside /tmp, not /tmp directly), which is cleaned
up on shutdown, but this can be overridden to store the changelog more
permanently – but that caries a permission problem.

For changelog we can 'easily' solve this by always downloading to a
temporary directory and only move it out of there on done.

use local changelog from /usr/share/doc if possible

If pkgAcqChangelog is told to acquire the changelog for a version it
will check first if this version is installed on the disk and if so will
use the local changelog in /usr/share/doc (possibily/likely gz
compressed) instead of downloading the file from the web.

An option is provided to disable this, which is enabled by default for
the Ubuntu vendor as they truncate the local changelogs – and for apts
--print-uris action.

Release 1.2.3

Build system messed up the 1.2.2 commit by not updating the
.po files properly, so they are now.

test: use our special downloaded dir for 'source' result

Otherwise the test run as root fails seeing the
W: Can't drop privileges for downloading as file 'foo_1.tar.gz' couldn't be
accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
warning in a command which isn't supposed to warn.

One trivial test, two fixups and still counting…

Git-Dch: Ignore

accept any tarball compression in 814139 testcase

Travis still uses a dpkg version which defaults to gz and as which
compression is picked isn't all to important as long as one is just
accept any.

Git-Dch: Ignore

test that seeking to a position earlier in the file works

This tests the fix for #812994, #813000

Gbp-Dch: ignore