apt/apt-pkg/acquire-item.cc, branch 1.3_pre2Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=1.3_pre22016-07-02T10:01:17Zuse +0000 instead of UTC by default as timezone in output2016-07-02T10:01:17ZDavid Kalnischkiesdavid@kalnischkies.de2016-07-02T09:28:42Zurn:sha1:0b45b6e5de1ba4224ced67a9952e009d0f4139a0
All apt versions support numeric as well as 3-character timezones just
fine and its actually hard to write code which doesn't "accidently"
accepts it. So why change? Documenting the Date/Valid-Until fields in
the Release file is easy to do in terms of referencing the
datetime format used e.g. in the Debian changelogs (policy ยง4.4). This
format specifies only the numeric timezones through, not the nowadays
obsolete 3-character ones, so in the interest of least surprise we should
use the same format even through it carries a small risk of regression
in other clients (which encounter repositories created with
apt-ftparchive).
In case it is really regressing in practice, the hidden option
-o APT::FTPArchive::Release::NumericTimezone=0
can be used to go back to good old UTC as timezone.
The EDSP and EIPP protocols use this 'new' format, the text interface
used to communicate with the acquire methods does not for compatibility
reasons even if none of our methods would be effected and I doubt any
other would (in these instances the timezone is 'GMT' as that is what
HTTP/1.1 requires). Note that this is only true for apt talking to
methods, (libapt-based) methods talking to apt will respond with the
'new' format. It is therefore strongly adviced to support both also in
method input.
imbue .diff/Index parsing with C.UTF-8 as well2016-06-27T09:43:09ZDavid Kalnischkiesdavid@kalnischkies.de2016-06-25T08:20:35Zurn:sha1:1136a707b7792394ea4b1d039dda4f321fec9da4
In 3bdff17c894d0c3d0f813d358fc45d7a263f3552 we did it for the datetime
parsing, but we use the same style in the parsing for pdiff (where the
size of the file is in the middle of the three fields) so imbueing here
as well is a good idea.
add insecure (and weak) allow-options for sources.list2016-06-22T12:05:01ZDavid Kalnischkiesdavid@kalnischkies.de2016-06-20T18:50:43Zurn:sha1:d03b947b0ce4f87d7d5cc48d4d274ab3bd0b289a
Weak had no dedicated option before and Insecure and Downgrade were both
global options, which given the effect they all have on security is
rather bad. Setting them for individual repositories only isn't great
but at least slightly better and also more consistent with other
settings for repositories.
add [weak] tag to hash errors to indicate insufficiency2016-06-22T12:05:01ZDavid Kalnischkiesdavid@kalnischkies.de2016-06-18T13:15:27Zurn:sha1:d30036922c6963846db4ab633b13fb87c1b5b462
For "Hash Sum mismatch" that info doesn't make a whole lot of
difference, but for the new insufficient info message an indicator that
while this hashes are there and even match, they aren't enough from a
security standpoint.
better error message for insufficient hashsums2016-06-22T12:05:01ZDavid Kalnischkiesdavid@kalnischkies.de2016-06-18T11:55:39Zurn:sha1:562f0774f8f04d978c7cea69a29c131a0e0ec75f
Downloading and saying "Hash Sum mismatch" isn't very friendly from a
user POV, so with this change we try to detect such cases early on and
report it, preferably before download even started.
Closes: 827758
generalize secure->insecure downgrade protection2016-06-22T12:05:01ZDavid Kalnischkiesdavid@kalnischkies.de2016-03-18T11:50:02Zurn:sha1:b1bdfe682054ea6fc202416968c5342d59b403b1
Handling the extra check (and force requirement) for downgrades in
security in our AllowInsecureRepositories checker helps in having this
check everywhere instead of just in the most common place and requiring
a little extra force in such cases is always good.
handle weak-security repositories as unauthenticated2016-06-22T12:05:01ZDavid Kalnischkiesdavid@kalnischkies.de2016-03-17T15:36:14Zurn:sha1:ab94dcece2465f824bea80fc9158bf9a028b2e87
APT can be forced to deal with repositories which have no security
features whatsoever, so just giving up on repositories which "just" fail
our current criteria of good security features is the wrong incentive.
Of course, repositories are better of fixing their setup to provide the
minimum of security features, but sometimes this isn't possible:
Historic repositories for example which do not change (anymore).
That also fixes problem with repositories which are marked as trusted,
but are providing only weak security features which would fail the
parsing of the Release file.
Closes: 827364
fix two typos in untranslated errors of libapt-pkg2016-05-24T08:46:48ZDavid Kalnischkiesdavid@kalnischkies.de2016-05-24T08:40:22Zurn:sha1:cbe5f09846e7efafd36efa81f0ec788c55b5baf5
Reported-By: lintian: spelling-error-in-binary
Git-Dch: Ignore
implement Fallback-Of for IndexTargets2016-05-08T11:39:32ZDavid Kalnischkiesdavid@kalnischkies.de2016-05-08T09:58:36Zurn:sha1:7f2d1eef183dbebaaabe07a296d9a97e9cfd0f4a
Sometimes index files are in different locations in a repository as it
is currently the case for Contents files which are per-component in
Debian, but aren't in Ubuntu. This has historic reasons and is perhaps
changed soon, but such cases of transitions can always happen in the
future again, so we should prepare:
Introduced is a new field declaring that the current item should only be
downloaded if the mentioned item wasn't allowing for transitions without
a flagday in clients and archives.
This isn't implemented 'simpler' with multiple MetaKeys as items (could)
change their descriptions and perhaps also other configuration bits with
their location.
don't construct MetaIndex acquire items with IndexTargets2016-05-07T12:52:08ZDavid Kalnischkiesdavid@kalnischkies.de2016-05-07T12:52:08Zurn:sha1:a8f565d3f69e6dba59195469959106da3eb8f33f
We don't have to initialize the Release files with a set of IndexTargets
to acquire, but instead wait for the Release file to be acquired and
only then ask which IndexTargets to get.
Git-Dch: Ignore