summaryrefslogtreecommitdiff
path: root/apt-pkg/deb/debmetaindex.cc
AgeCommit message (Collapse)Author
2019-06-17RFC1123StrToTime: Accept const std::string& as first argumentJulian Andres Klode
We are converting to std::string anyway by passing to istringstream, and this removes the need for .c_str() in callers.
2019-05-07debmetaindex: Use isspace_ascii() variant to normalize Signed-ByJulian Andres Klode
Using the locale-dependent isspace() function here opens us up to strange locale-dependent behavior.
2019-04-30Add 'explicit' to most single argument constructorsJulian Andres Klode
This prevents implicit conversions that we do not want, such as having a FileFd* being converted to a debListParser. Two cases are not yet handled because they require changes in code using them: 1. The classes in hashes.h 2. The URI class - this one is used quite a lot
2019-02-26metaindex: Remove deprecated checkSum::Hash (replaced by Hashes)Julian Andres Klode
2019-02-01Add a Packages-Require-Authorization Release file fieldJulian Andres Klode
This new field allows a repository to declare that access to packages requires authorization. The current implementation will set the pin to -32768 if no authorization has been provided in the auth.conf(.d) files. This implementation is suboptimal in two aspects: (1) A repository should behave more like NotSource repositories (2) We only have the host name for the repository, we cannot use paths yet. - We can fix those after an ABI break. The code also adds a check to acquire-item.cc to not use the specified repository as a download source, mimicking NotSource.
2018-09-11Support subkeys properly in Signed-By optionsDavid Kalnischkies
If we limit a file to be signed by a certain key it should usually accept also being signed by any of this keys subkeys instead of requiring each subkey to be listed explicitly. If the later is really wanted we support now also the same syntax as gpg does with appending an exclamation mark at the end of the fingerprint to force no mapping.
2018-08-29Don't use invalid iterator in Fallback-Of handlingDavid Kalnischkies
cppcheck reports: (error) Iterator 't' used after element has been erased. The loop is actually fashioned to deal with this (not in the most efficient way, but in simplest and speed isn't really a concern here) IF this codepath had a "break" at the end… so I added one. Note that the tests aren't failing before (and hopefully after) the change as the undefined behavior we encounter is too stable. Thanks: David Binderman for reporting
2018-02-19Check that Date of Release file is not in the futureJulian Andres Klode
By restricting the Date field to be in the past, an attacker cannot just create a repository from the future that would be accepted as a valid update for a repository. This check can be disabled by Acquire::Check-Date set to false. This will also disable Check-Valid-Until and any future date related checking, if any - the option means: "my computers date cannot be trusted." Modify the tests to allow repositories to be up to 10 hours in the future, so we can keep using hours there to simulate time changes.
2018-01-17Introduce inrelease-path option for sources.listJulian Andres Klode
Allow specifying an alternative path to the InRelease file, so you can have multiple versions of a repository, for example. Enabling this option disables fallback to Release and Release.gpg, so setting it to InRelease can be used to ensure that only that will be tried. We add two test cases: One for checking that it works, and another for checking that the fallback does not happen. Closes: #886745
2017-12-13give the methods more metadata about the files to acquireDavid Kalnischkies
We have quite a bit of metadata available for the files we acquire, but the methods weren't told about it and got just the URI. That is indeed fine for most, but to avoid methods trying to parse the metadata out of the provided URIs (and fail horribly in edgecases) we can just as well be nice and tell them stuff directly.
2017-12-13deprecate the single-line deprecation ignoring macroDavid Kalnischkies
gcc has problems understanding this construct and additionally thinks it would produce multiple lines and stuff, so to keep using it isn't really worth it for the few instances we have: We can just write the long form there which works better. Reported-By: gcc Gbp-Dch: Ignore
2017-09-13Fix translator comment location for legacy target warningJulian Andres Klode
In commit Do not warn about duplicate "legacy" targets, we we added an if, that changed the .po files...
2017-09-09Do not warn about duplicate "legacy" targetsJulian Andres Klode
If a source has a legacy Contents file, and two lines mention the same archive but different components, a warning would be issued that is confusing. So, as the field is named Contents-deb-legacy, let's just not print warnings for fields containing "legacy". LP: #1697120 Closes: #839259
2017-07-12Reformat and sort all includes with clang-formatJulian Andres Klode
This makes it easier to see which headers includes what. The changes were done by running git grep -l '#\s*include' \ | grep -E '.(cc|h)$' \ | xargs sed -i -E 's/(^\s*)#(\s*)include/\1#\2 include/' To modify all include lines by adding a space, and then running ./git-clang-format.sh.
2017-07-12Handle supported components with slashes in sources.listApollon Oikonomopoulos
Commit d7c92411dc1f4c6be098d1425f9c1c075e0c2154 parses the Components section of (In)Release and attempts to detect the distribution's supported components. While doing so, it handles component names with slashes in a special manner, assuming that the actual component is only the part after the final slash. This is done to handle security.debian.org, which usually appears in sources.list as follows: deb http://s.d.o/debian-security stretch/updates main contrib non-free while the actual release file has: Codename: stretch Components: updates/main updates/contrib updates/non-free While this special handing on APTs part indeed works for debian-security, it emits spurious warnings on repositories that actually use slashes in the component names *and* appear so in sources.list. We fix this by adding both component versions (whole and final part) to the SupportedComponents array. Closes: #868127
2017-06-28show a Release-Notes URI if infos were changedDavid Kalnischkies
This gives the repository owner a chance to explain why this change was needed – e.g. explaining the organisational changes or simply detailing the changes in the new release made. Note that this URI is also shown if the change is accepted, so it also draws attention to release notes of minor updates (if users watch apt output closely).
2017-06-28error in update on Release information changesDavid Kalnischkies
The value of Origin, Label, Codename and co can be used in user configuration from apts own pinning to unattended upgrades. A repository changing this values can therefore have serious effects on the behaviour of apt and other tools using these values. In a first step we will generate error messages for these changes now explaining the need for explicit confirmation and provide config options and commandline flags to accept them.
2017-06-26warn if an expected file can't be acquiredDavid Kalnischkies
If we couldn't find an entry for a Sources file we would generate an error while for a Packages file we would silently skip it due to assuming it is missing because it is empty. We can do better by checking if the repository declares that it supports a component we want to get the file from and if not say so and hint at the user making a typo. An example were this helps is mozilla.debian.net which dropped the firefox-aurora component (as upstream did) meaning no upgrades until the user notices manually that the repository doesn't provide packages anymore. With this commit warnings are raised hopefully causing the user to investigate what is wrong (sooner).
2016-12-31avoid producing invalid options if repo has no hostDavid Kalnischkies
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
2016-07-22allow arch=all to override No-Support-for-Architecture-allDavid Kalnischkies
If a user explicitly requests the download of arch:all apt shouldn't get in the way and perform its detection dance if arch:all packages are (also) in arch:any files or not. This e.g. allows setting arch=all on a source with such a field (or one which doesn't support all at all, but has the arch:all files like Debian itself ATM) to get only the arch:all packages from there instead of behaving like a no-op. Reported-By: Helmut Grohne on IRC
2016-07-19refactor plus/minus sources.list option handlingDavid Kalnischkies
Moving code around into some more dedicated methods, no effective code change itself. Gbp-Dch: Ignore
2016-06-22add insecure (and weak) allow-options for sources.listDavid Kalnischkies
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.
2016-06-22handle weak-security repositories as unauthenticatedDavid Kalnischkies
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
2016-06-17merge sources.list lines based on Release filenameDavid Kalnischkies
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
2016-05-15Normalize Signed-By values by removing trailing commas everywhereJulian Andres Klode
This fixes comparisons where either the stored or the input string have a trailing comma.
2016-05-15Add conflicting Signed-By values to error messageJulian Andres Klode
This hopefully makes debugging things easier.
2016-05-10Strip trailing commas for created signed-by fingerprint listsJulian Andres Klode
This prevented some sources.list entries from working, an example of which can be found in the test.
2016-05-08implement Identifier field for IndexTargetsDavid Kalnischkies
A frontend like apt-file is only interested in a specific set of files and selects those easily via "Created-By". If it supports two locations for those files through it would need to select both and a user would need to know that implementation detail for sources.list configuration. The "Identifier" field is hence introduced which by default has the same value as "Created-By", but can be freely configured – especially it can be used to give two indexes the same identifier.
2016-05-08implement Fallback-Of for IndexTargetsDavid Kalnischkies
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.
2016-05-07download arch:all also for NATIVE_ARCHITECTURE indextargetsDavid Kalnischkies
It looks a bit strange on the outside to have multiple "native architecture", but all is considered an implementation detail and e.g. packages of arch:all are in dependency resolution equal to native packages.
2016-05-07don't construct MetaIndex acquire items with IndexTargetsDavid Kalnischkies
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
2016-05-01support Signed-By in Release files as a sort of HPKPDavid Kalnischkies
Users have the option since apt >= 1.1 to enforce that a Release file is signed with specific key(s) either via keyring filename or fingerprints. This commit adds an entry with the same name and value (except that it doesn't accept filenames for obvious reasons) to the Release file so that the repository owner can set a default value for this setting effecting the *next* Release file, not the current one, which provides a functionality similar "HTTP Public Key Pinning". The pinning is in effect as long as the (then old) Release file is considered valid, but it is also ignored if the Release file has no Valid-Until at all.
2016-05-01support multiple fingerprints in signed-byDavid Kalnischkies
A keyring file can include multiple keys, so its only fair for transitions and such to support multiple fingerprints as well.
2016-03-25drop confusing comma from no strong hash messageDavid Kalnischkies
2016-01-27only warn about missing/invalid Date field for nowDavid Kalnischkies
The Date field in the Release file is useful to avoid allowing an attacker to 'downgrade' a user to earlier Release files (and hence to older states of the archieve with open security bugs). It is also needed to allow a user to define min/max values for the validation of a Release file (with or without the Release file providing a Valid-Until field). APT wasn't formally requiring this field before through and (agrueable not binding and still incomplete) online documentation declares it optional (until now), so we downgrade the error to a warning for now to give repository creators a bit more time to adapt – the bigger ones should have a Date field for years already, so the effected group should be small in any case. It should be noted that earlier apt versions had this as an error already, but only showed it if a Valid-Until field was present (or the user tried to used the configuration items for min/max valid-until). Closes: 809329
2016-01-08keep compressed indexes in a low-cost formatDavid Kalnischkies
Downloading and storing are two different operations were different compression types can be preferred. For downloading we provide the choice via Acquire::CompressionTypes::Order as there is a choice to be made between download size and speed – and limited by whats available in the repository. Storage on the other hand has all compressions currently supported by apt available and to reduce runtime of tools accessing these files the compression type should be a low-cost format in terms of decompression. apt traditionally stores its indexes uncompressed on disk, but has options to keep them compressed. Now that apt downloads additional files we also deal with files which simply can't be stored uncompressed as they are just too big (like Contents for apt-file). Traditionally they are downloaded in a low-cost format (gz) as repositories do not provide other formats, but there might be even lower-cost formats and for download we could introduce higher-cost in the repositories. Downloading an entire index potentially requires recompression to another format, so an update takes potentially longer – but big files are usually updated via pdiffs which has to de- and re-compress anyhow and does it on the fly anyhow, so there is no extra time needed and in general it seems to be benefitial to invest the time in update to save time later on file access.
2015-12-27allow repositories to forbid arch:all for specific index targetsDavid Kalnischkies
Debian has a Packages file for arch:all already, but the arch:any files contain arch:all packages as well, so downloading it would be a total waste of resources. Getting this solved is on the list of things to do, but it is also the hardest part – for index targets like Contents the situation is much easier and less server/client implementations are involved so we might not want to stall them. A repository can now declare via: No-Support-for-Architecture-all: Packages that even if an arch:all Packages exists, it shouldn't be downloaded, so that support for Contents files can be added now. See also 1dd20368486820efb6ef4476ad739e967174bec4 for the implementation of downloading arch:all index targets, which this is limiting. The field uses the name of the target from the apt configuration for simplicity and is negative by design as this field is intended to be supported/needed only for a "short" time (one or two Debian releases). While this commit theoretically supports any target, its expected to only see "Packages" as a value in reality.
2015-12-14show a more descriptive error for weak Release filesDavid Kalnischkies
If we can't work with the hashes we parsed from the Release file we display now an error message if the Release file includes only weak hashes instead of downloading the indexes and failing to verify them with "Hash Sum mismatch" even through the hashes didn't mismatch (they were just weak). If for some (unlikely) reason we have got weak hashes only for individual targets we will show a warning to this effect (again, befor downloading and failing the index itself). Closes: 806459
2015-11-21review of new/changed translatable program stringsJustin B Rye
Reference mail: https://lists.debian.org/debian-l10n-english/2015/11/msg00006.html
2015-11-04support arch:all data e.g. in separate Packages fileDavid Kalnischkies
Based on a discussion with Niels Thykier who asked for Contents-all this implements apt trying for all architecture dependent files to get a file for the architecture all, which is treated internally now as an official architecture which is always around (like native). This way arch:all data can be shared instead of duplicated for each architecture requiring the user to download the same information again and again. There is one problem however: In Debian there is already a binary-all/ Packages file, but the binary-any files still include arch:all packages, so that downloading this file now would be a waste of time, bandwidth and diskspace. We therefore need a way to decide if it makes sense to download the all file for Packages in Debian or not. The obvious answer would be a special flag in the Release file indicating this, which would need to default to 'no' and every reasonable repository would override it to 'yes' in a few years time, but the flag would be there "forever". Looking closer at a Release file we see the field "Architectures", which doesn't include 'all' at the moment. With the idea outlined above that 'all' is a "proper" architecture now, we interpret this field as being authoritative in declaring which architectures are supported by this repository. If it says 'all', apt will try to get all, if not it will be skipped. This gives us another interesting feature: If I configure a source to download armel and mips, but it declares it supports only armel apt will now print a notice saying as much. Previously this was a very cryptic failure. If on the other hand the repository supports mips, too, but for some reason doesn't ship mips packages at the moment, this 'missing' file is silently ignored (= that is the same as the repository including an empty file). The Architectures field isn't mandatory through, so if it isn't there, we assume that every architecture is supported by this repository, which skips the arch:all if not listed in the release file.
2015-09-14add by-hash sources.list option and document all of by-hashDavid Kalnischkies
This changes the semantics of the option (which is renamed too) to be a yes/no value with the special additional value "force" as this allows by-hash to be disabled even if the repository indicates it would be supported and is more in line with our other yes/no options like pdiff which disable themselves if no support can be detected. The feature wasn't documented so far and hasn't reached a (un)stable release yet, so changing it without trying too hard to keep compatibility seems okay.
2015-09-14avoid using global PendingError to avoid failing too often too soonDavid Kalnischkies
Our error reporting is historically grown into some kind of mess. A while ago I implemented stacking for the global error which is used in this commit now to wrap calls to functions which do not report (all) errors via return, so that only failures in those calls cause a failure to propergate down the chain rather than failing if anything (potentially totally unrelated) has failed at some point in the past. This way we can avoid stopping the entire acquire process just because a single source produced an error for example. It also means that after the acquire process the cache is generated – even if the acquire process had failures – as we still have the old good data around we can and should generate a cache for (again). There are probably more instances of this hiding, but all these looked like the easiest to work with and fix with reasonable (aka net-positive) effects.
2015-08-30detect and deal with indextarget duplicatesDavid Kalnischkies
Multiple targets downloading the same file is bad™ as it leads us to all sorts of problems like the acquire system breaking or simply a problem of which settings to use for them. Beside that this is most likely a mistake and silently ignoring it doesn't help the user realizing his mistake… On the other hand, we have 'duplicates' which are 'created' by how we create indextargets, so we have to prevent those from being created to but do not emit a warning for them as this is an implementation detail. And then, there is the absolute and most likely user mistake: Having the same target(s) activated in multiple entries.
2015-08-30implement $(NATIVE_ARCHITECTURE) substvar for indextargetsDavid Kalnischkies
2015-08-29implement indextargets option 'DefaultEnabled'David Kalnischkies
Some targets like Contents-udeb are special-needs targets. Shipping the configuration snippet for them is okay, but they shouldn't be downloaded by default. Forcing the user to enable targets by uncommenting targets is wrong and this would still not really solve the problem completely as even if you want to download some -udebs it will probably not be for all sources you have enabled, so having the possibility of disabling a target by default, but giving the user the option to enable it on a per-source entry basis is better.
2015-08-29use c++11 algorithms to avoid strange compiler warningsDavid Kalnischkies
Nobody knows what makes the 'unable to optimize loop' warning to appear in the sourceslist minus-options parsing, especially if we use a foreach loop, but we can replace it with some nice c++11 algorithm+lambda usage, which also helps in making even clearer what happens here. And as this would be a lonely change, lets do it for a few more loops as well where I might or might not have seen the warning at some point in time, too. Git-Dch: Ignore
2015-08-28implement PDiff patching for compressed filesDavid Kalnischkies
Some additional files like 'Contents' are very big and should therefore kept compressed on the disk, which apt-file did in the past. It also implemented pdiff patching of these files by un- and recompressing these files on-the-fly, with this commit we can do the same – but we can do this in both pdiff patching styles (client and server merging) and secured by hashes. Hashes are in so far slightly complicated as we can't compare the hashes of the compressed files as we might compress them differently than the server would (different compressor versions, options, …), so we must compare the hashes of the uncompressed content. While this commit has changes in public headers, the classes it changes are marked as hidden, so nobody can use them directly, which means the ABI break is internal only.
2015-08-27sources.list and indextargets option for pdiffsDavid Kalnischkies
Disabling pdiffs can be useful occasionally, like if you have a fast local mirror where the download doesn't matter, but still want to use it for non-local mirrors. Also, some users might prefer it to only use it for very big indextargets like Contents.
2015-08-27allow explicit dis/enable of IndexTargets in sources optionsDavid Kalnischkies
While Target{,-Add,-Remove} is available for configuring IndexTargets already, allow Targets to be mentioned explicitely as yes/no options as well, so that the Target 'Contents' can be disabled via 'Contents: no' as well as 'Target-Remove: Contents'.
2015-08-27not all targets are deb-src targetsDavid Kalnischkies
Sometimes too much refactoring can have bad effects. Thanks: Niels Thykier for reporting on IRC Git-Dch: Ignore