summaryrefslogtreecommitdiff
path: root/methods/gpgv.cc
Commit message (Collapse)AuthorAgeFilesLines
* Temporarily downgrade key assertions to "soon worthless"Julian Andres Klode2024-02-281-8/+1
| | | | | This will only issue warnings instead of errors while we continue cleaning up our repositories.
* Rename 'weak digest algorithm' to 'weak algorithm'Julian Andres Klode2024-02-281-1/+1
| | | | This allows us to render public key algorithms as weak as well.
* Implement gpgv --assert-pubkey-algo=>=rsa2048,ed25519,ed448Julian Andres Klode2024-02-281-0/+20
| | | | | | | | | | | | The assertion can be overriden using apt::key::assert-pubkey-algo, the default is the most opinionated one. This will inform the user during apt-cdrom add as we do not pass --quiet to user, so adjust test case. Add a simple test case for it to test-method-gpgv. LP: #2055193
* gpgv: Add a reason to worthless signersJulian Andres Klode2024-02-281-6/+26
|
* gpgv: Surface [GNUPG:] ERROR and [GNUPG:] WARNING status messagesJulian Andres Klode2024-02-281-0/+9
|
* Modernize standard library includesJulian Andres Klode2024-02-201-6/+6
| | | | | | This was automated with sed and git-clang-format, and then I had to fix up the top of policy.cc by hand as git-clang-format accidentally indented it by two spaces.
* Actually delete temporary apt-key.*.asc helper filesJulian Andres Klode2022-10-311-1/+1
| | | | | | | During development there was an if (0) there for debugging purposes that unfortunately stayed in and caused files to accumulate. LP: #1995247
* gpgv: Use Valid instead of Good to determine fallbackJulian Andres Klode2022-03-071-2/+2
| | | | | | | | | | | | Change the logic to use "Valid" instead of "Good" to determine whether we need to fallback and if fallback was successful. That means that if you have an expired key in trusted.gpg.d, and a non-expired in trusted.gpg, verification will now fail directly with the expired key in trusted.gpg.d and not try to fallback. Likewise, if the key in trusted.gpg is expired, this will now also be reported correctly again, instead of producing an error message that the key could not be found.
* gpgv: Fix legacy fallback on unavailable keysJulian Andres Klode2022-03-071-4/+10
| | | | | | | | | | | | | | | | | | | | | If a repository is signed with multiple keys, apt 2.4.0 would ignore the fallback result if some keys were still missing, causing signature verification to fail. Rework the logic such that when checking if fallback was "succesful", missing keys are ignored - it only matters if we managed to verify one key now, whether good or bad. Likewise, simplify the logic when to do the fallback: If there was a bad signature in trusted.gpg.d, do NOT fallback at all - this is a minor security issue, as a key in trusted.gpg.d could fail silently with a bad signature, and then a key in trusted.gpg might allow the signature to succeed (as trusted.gpg.d key is then missing). Only fallback if we are missing a good signature, and there are keys we have not yet checked.
* Warn if the legacy trusted.gpg keyring is used for verificationJulian Andres Klode2022-02-221-1/+43
| | | | | With apt-key going away, people need to manage key files, rather than keys, so they need to know if any keys are in the legacy keyring.
* Add support for embedding PGP keys into Signed-By in deb822 sourcesJulian Andres Klode2021-10-181-5/+29
| | | | | | Extend the Signed-By field to handle embedded public key blocks, this allows shipping self-contained .sources files, making it substantially easier to provide third party repositories.
* Replace PrintStatus with SendMessage usageDavid Kalnischkies2021-02-041-2/+6
| | | | | | | varg API is a nightmare as the symbols seems different on ever other arch, but more importantly SendMessage does a few checks on the content of the message and it is all outputted via C++ iostreams and not mixed in FILE* which is handy for overriding the streams.
* Implement encoded URI handling in all methodsDavid Kalnischkies2020-12-181-2/+2
| | | | | | | | Every method opts in to getting the encoded URI passed along while keeping compat in case we are operated by an older acquire system. Effectively this is just a change for the http-based methods as the others just decode the URI as they work with files directly.
* gpgv: Rename master to primaryJulian Andres Klode2020-08-041-4/+4
|
* Rename _count() macro to APT_ARRAY_SIZE()Julian Andres Klode2020-01-071-1/+2
|
* Fix some style warnings from cppcheckDavid Kalnischkies2019-11-261-11/+9
| | | | | | | | Unused variable, std::algorithms instead of raw for-loops. There should be no observeable difference in behaviour. Reported-By: cppcheck Gbp-Dch: Ignore
* apt-pkg: URI: Add 'explicit' to single argument constructorJulian Andres Klode2019-04-301-1/+1
| | | | | This needs a fair amount of changes elsewhere in the code, hence this is separate from the previous commits.
* Communicate back which key(s) were used for signingDavid Kalnischkies2019-01-221-19/+60
| | | | | | | Telling the acquire system which keys caused the gpgv method to succeed allows us for now just a casual check if the gpgv method really executed catching bugs like CVE-2018-0501, but we will make use of the information for better features in the following commits.
* Refactor internal Signers information storage in gpgvDavid Kalnischkies2019-01-221-73/+67
| | | | | | | | | Having a method take a bunch of string vectors is bad style, so we change this to a wrapping struct and adapt the rest of the code brushing it up slightly in the process, which results even in a slightly "better" debug output, no practical change otherwise. Gbp-Dch: Ignore
* Support multiple keyrings in sources.list Signed-ByDavid Kalnischkies2018-09-111-11/+29
| | | | | | | A user can specify multiple fingerprints for a while now, so its seems counter-intuitive to support only one keyring, especially if this isn't really checked or enforced and while unlikely mixtures of both should work properly, too, instead of a kinda random behaviour.
* Support subkeys properly in Signed-By optionsDavid Kalnischkies2018-09-111-8/+36
| | | | | | | | 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.
* Report (soon) worthless keys if gpg uses fpr for GOODSIGDavid Kalnischkies2018-08-191-35/+24
| | | | | | | | | | gpgs DETAILS documentation file declares that GOODSIG could report keyid or fingerprint since gpg2, but for the time being it is still keyid only. Who knows if that will ever change as that feels like an interface break with dangerous security implications, but lets be better safe than sorry especially as the code dealing with signed-by keyids is prepared for this already. This code is rewritten still to have them all use the same code for this type of problem.
* Reformat and sort all includes with clang-formatJulian Andres Klode2017-07-121-5/+5
| | | | | | | | | | | | | 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.
* fix various typos reported by spellintianDavid Kalnischkies2017-01-191-1/+1
| | | | | | | | Most of them in (old) code comments. The two instances of user visible string changes the po files of the manpages are fixed up as well. Gbp-Dch: Ignore Reported-By: spellintian
* gpgv: Untrust SHA1, RIPE-MD/160, but allow downgrading to weakJulian Andres Klode2016-11-251-4/+4
| | | | | | | Change the trust level check to allow downgrading an Untrusted option to weak (APT::Hashes::SHA1::Weak "yes";), so it prints a warning instead of an error; and change the default values for SHA1 and RIPE-MD/160 from Weak to Untrusted.
* report apt-key errors via status-fd messagesDavid Kalnischkies2016-11-241-1/+6
| | | | | | | | | | | | | | | | | | | | We report warnings from apt-key this way already since 29c590951f812d9e9c4f17706e34f2c3315fb1f6, so reporting errors seems like a good addition. Most of those errors aren't really from apt-key through, but from the code setting up and actually calling it which used to just print to stderr which might or might not intermix them with (other) progress lines in update calls. Having them as proper error messages in the system means that the errors are actually collected later on for the list instead of ending up with our relatively generic but in those cases bogus hint regarding "is gpgv installed?". The effective difference is minimal as the errors apply mostly to systems which have far worse problems than a not as nice looking error message, which makes this pretty hard to test – but at least now the hint that your system is broken can be read in proper order (= there aren't many valid cases in which the permissions of /tmp are messed up…). LP: #1522988
* support long keyid and fingerprint in gpgv's GOODSIGDavid Kalnischkies2016-09-011-4/+20
| | | | | | | | | | | | | | In gpgv1 GOODSIG (and the other messages of status-fd) are documented as sending the long keyid. In gpgv2 it is documented to be either long keyid or the fingerprint. At the moment it is still the long keyid, but the documentation hints at the possibility of changing this. We care about this for Signed-By support as we detect this way if the right fingerprint has signed this file (or not). The check itself is done via VALIDSIG which always is a fingerprint, but there must also be a GOODSIG (as expired sigs are valid, too) found to be accepted which wouldn't be found in the fingerprint-case and the signature hence refused.
* show apt-key warnings in apt updateDavid Kalnischkies2016-08-251-0/+3
| | | | | | | | | | | | | | | | | | | | In 105503b4b470c124bc0c271bd8a50e25ecbe9133 we got a warning implemented for unreadable files which greatly improves the behavior of apt update already as everything will work as long as we don't need the keys included in these files. The behavior if they are needed is still strange through as update will fail claiming missing keys and a manual test (which the user will likely perform as root) will be successful. Passing the new warning generated by apt-key through to apt is a bit strange from an interface point of view, but basically duplicating the warning code in multiple places doesn't feel right either. That means we have no translation for the message through as apt-key has no i18n yet. It also means that if the user has a bunch of sources each of them will generate a warning for each unreadable file which could result in quite a few duplicated warnings, but "too many" is better than none. Closes: 834973
* implement generic config fallback for methodsDavid Kalnischkies2016-08-101-4/+2
| | | | | | | | | | The https method implemented for a long while now a hardcoded fallback to the same options in http, which, while it works, is rather inflexible if we want to allow the methods to use another name to change their behavior slightly, like apt-transport-tor does to https – most of the diff being s#https#tor#g which then fails to do the full circle fallthrough tor -> https -> http for https sources. With this config infrastructure this could be implemented now.
* use std::locale::global instead of setlocaleDavid Kalnischkies2016-05-281-6/+1
| | | | | | We use a wild mixture of C and C++ ways of generating output, so having a consistent world-view in both styles sounds like a good idea and should help in preventing regressions.
* gpgv: show always webportal error on NODATADavid Kalnischkies2016-05-081-12/+21
| | | | | | | | | | | | | | | | | gpg doesn't give use a UID on NODATA, which we were "expecting" (but not using for anything), but just an error number. Instead of collecting these as badsigners which will trigger a "invald signature" error with remarks like "NODATA 1" we instead adapt a message similar to the NODATA error of a clearsigned file (which is actually not reached anymore as we split them up, which fails with a NOSPLIT error, which uses the same general error message). In other words: Not a security relevant change, just a user experience improvement as we now point them to the most likely cause of the problem instead of saying "invalid signature" which would point them in the direction of the archive being broken (for everyone) instead. Closes: 823746
* support multiple fingerprints in signed-byDavid Kalnischkies2016-05-011-13/+17
| | | | | A keyring file can include multiple keys, so its only fair for transitions and such to support multiple fingerprints as well.
* gpgv: cleanup statusfd parsing a bitDavid Kalnischkies2016-05-011-57/+45
| | | | | | | | | | | We parse the messages we receive into two big categories: Most of the messages have a keyid as well as a userid and as they are errors we want to show the userids as well. The other category is also errors, but have no userid (like NO_PUBKEY). Explicitly expressing this in code should make it a bit easier to look at and it also help in dropping additional fields or just the newline at the end consistently. Git-Dch: Ignore
* don't show NO_PUBKEY warning if repo is signed by another keyDavid Kalnischkies2016-05-011-4/+4
| | | | | | | | | | | | | | | Daniel Kahn Gillmor highlights in the bugreport that security isn't improving by having the user import additional keys – especially as importing keys securely is hard. The bugreport was initially about dropping the warning to a notice, but in given the previously mentioned observation and the fact that we weren't printing a warning (or a notice) for expired or revoked keys providing a signature we drop it completely as the code to display a message if this was the only key is in another path – and is considered critical. Closes: 618445
* gpgv: handle expired sig as worthlessDavid Kalnischkies2016-05-011-0/+7
| | | | | | | Signatures on data can have an expiration date, too, which we hadn't handled previously explicitly (no problem – gpg still has a non-zero exit code so apt notices the invalid signature) so the error message wasn't as helpful as it could be (aka mentioning the key signing it).
* gpgv: use EXPKEYSIG instead of KEYEXPIREDDavid Kalnischkies2016-05-011-3/+3
| | | | | | The upstream documentation says about KEYEXPIRED: "This status line is not very useful". Indeed, it doesn't mention which key is expired, and suggests to use the other message which does.
* Allow lowering trust level of a hash via configJulian Andres Klode2016-03-281-12/+12
| | | | | | 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.
* handle gpgv's weak-digests ERRSIGDavid Kalnischkies2016-03-221-7/+50
| | | | | | | | | | | 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"David Kalnischkies2016-03-211-9/+14
| | | | | | | | | | 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
* Make the weak signature message less ambigiousJulian Andres Klode2016-03-161-1/+1
| | | | | | | | 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
* methods/gpgv: Rewrite error handling and messageJulian Andres Klode2016-03-161-19/+50
| | | | | | | 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
* methods/gpgv: Warn about SHA1 (and RIPEMD-160)Julian Andres Klode2016-03-151-3/+29
| | | | | | | 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.
* methods/gpgv: Correctly handle weak signatures with multiple keysJulian Andres Klode2016-03-151-1/+6
| | | | | | | | | | | | 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
* methods/gpgv: Reject weak digest algorithmsJulian Andres Klode2016-03-141-0/+16
| | | | | 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"Julian Andres Klode2016-03-141-7/+0
| | | | | | | | This reverts commit 76a71a1237d22c1990efbc19ce0e02aacf572576. That commit broke the test suite. Gbp-Dch: ignore
* Handle ERRSIG in the gpgv method like BADSIGJulian Andres Klode2016-03-141-0/+7
| | | | | | | | | | | | 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.
* allow acquire method specific options via Binary scopeDavid Kalnischkies2015-11-051-13/+3
| | | | | | | | Allows users who know what they are getting themselves into with this trick to e.g. disable privilege dropping for e.g. file:// until they can fix up the permissions on those repositories. It helps also the test framework and people with a similar setup (= me) to run in less modified environments.
* add c++11 override marker to overridden methodsDavid Kalnischkies2015-08-101-2/+2
| | | | | | | | | C++11 adds the 'override' specifier to mark that a method is overriding a base class method and error out if not. We hide it in the APT_OVERRIDE macro to ensure that we keep compiling in pre-c++11 standards. Reported-By: clang-modernize -add-override -override-macros Git-Dch: Ignore
* implement Signed-By without using gpg for verificationDavid Kalnischkies2015-08-101-9/+60
| | | | | | | | | | The previous commit returns to the possibility of using just gpgv for verification proposes. There is one problem through: We can't enforce a specific keyid without using gpg, but our acquire method can as it parses gpgv output anyway, so it can deal with good signatures from not expected signatures and treats them as unknown keys instead. Git-Dch: Ignore
* implement Signed-By option for sources.listDavid Kalnischkies2015-08-101-8/+10
| | | | | | | | | | Limits which key(s) can be used to sign a repository. Not immensely useful from a security perspective all by itself, but if the user has additional measures in place to confine a repository (like pinning) an attacker who gets the key for such a repository is limited to its potential and can't use the key to sign its attacks for an other (maybe less limited) repository… (yes, this is as weak as it sounds, but having the capability might come in handy for implementing other stuff later).
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2026-05-14 21:43:11 +0000