apt/test, branch 1.3_exp3Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=1.3_exp32016-06-22T12:05:01Zadd 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
run update post-invokes even on (partial) failures2016-06-22T12:05:01ZDavid Kalnischkiesdavid@kalnischkies.de2016-06-16T21:13:26Zurn:sha1:57f7fb6511fcc7c55ee7a88475d15385093c048e
Unsecure repositories result in error messages by default which causes
the acquire run to fail hard, but non-failing repositories are still
updated just like in the slightly less hard-failures which got this
behaviour in 35664152e47a1d4d712fd52e0f0a2dc8ed359d32.
implement and document DIRECT for auto-detect-proxy2016-06-20T11:49:31ZDavid Kalnischkiesdavid@kalnischkies.de2016-06-20T11:49:31Zurn:sha1:9515ed7bcdb32c7985ca83d309beda7155d02136
There is a subtile difference between an empty setting and "DIRECT" in
the configuration as the later overrides the generic settings while the
earlier does not. Also, non-zero exitcodes should really be reported as
an error rather than silently discarded.
do not error if auto-detect-proxy cmd has no output2016-06-20T11:22:22ZDavid Kalnischkiesdavid@kalnischkies.de2016-06-20T09:23:09Zurn:sha1:cad1877559f3e1703c3fea4d081978e1b4bb4a0e
Regression introduced in 8f858d560e3b7b475c623c4e242d1edce246025a.
Commands are probably better of always having output through as the
fall through to the generic proxy settings is likely not intended. As
documenting and implementing this more consistently is kind of a
regression through, it is split off into the next commit.
Closes: 827713
avoid std::get_time usage to sidestep libstdc++6 bug2016-06-17T16:09:20ZDavid Kalnischkiesdavid@kalnischkies.de2016-06-17T15:56:45Zurn:sha1:1d742e01470bba27715a8191c50adde4b39c2f19
As reported upstream in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71556
the implementation of std::get_time is currently not as accepting as
strptime is, especially in how hours should be formatted.
Just reverting 9febc2b238e1e322dce1f94ecbed46d595893b52 would be
possible, but then we would reopen the problems fixed by it, so instead
I opted here for a rewrite of the parsing logic which makes this method
a lot longer, but at least it provides the same benefits as the rewrite
in std::get_time was intended to give us and decouples us from the fix
of the issue in the standard library implementation of GCC.
LP: 1593583
merge sources.list lines based on Release filename2016-06-17T16:09:15ZDavid Kalnischkiesdavid@kalnischkies.de2016-06-17T11:27:34Zurn:sha1:b90faf2486b977aef0183e38a7f9c535a8a61a34
Merging by URI means that having sources lines with different URI
methods results in 'strange' warning and error messages, which aren't
very friendly from a user point of view as not encoding the method in
the filename is effectivly an implementation detail.
Merging by filename removes these messages and makes everything "work"
even if it isn't working the way it is configured as the indexes aren't
acquired over the method given, but over the first method for this
release file (which argueably is an implementation detail stemming from
the filename encoding, too).
So either direction isn't perfectly "right", but personally I prefer
"magic" over strange error messages (and doing a full-circle detection
of this with its own messages which would need to be translated feels
like way too much effort for dubious gain).
Closes: 826944