Failing key verification during installation

[Huge]

Seems there is a problem with the line
validpgpkeys=('6DD601691023247FB4FE63A3498FCFAD9FE6855B') # Jon Frisby <[e-mail]>
yay fails with

 -> 6DD601691023247FB4FE63A3498FCFAD9FE6855B, required by: ssss
==> Import? [Y/n]
:: Importing keys with gpg...
gpg: keyserver receive failed: General error

When I tried with makepkg -si, failed in similar vain:

    ssss git repo ... FAILED (unknown public key 7F7CFB137DCB12A7)
==> ERROR: One or more PGP signatures could not be verified!

[Jon Frisby]

I'm not familiar with yay. Some Googling (and context) tells me it's an interface on top of the pacman package manager. Unfortunately, I have no involvement with any packaging/distribution of this so I don't even know where to start looking. I tried bringing up an Arch userland in a Docker container to see if I could reproduce the problem, but I can't find any package referencing ssss (pacman -Ss ssss turns up nothing).

I'm not sure what package sources you're using, and when I look I find a bunch of different packages of ssss for various package management systems -- but none of them seem to be packaging up my fork.

That said, perhaps you can make some progress by manually importing the pertinent key to your keyring? The necessary hostname has changed as a result of the shenanigans that SKS got hit by last year:

gpg --keyserver ipv4.pool.sks-keyservers.net --recv-key 7DCB12A7

[Huge]

Cool, I didn't know about the shenanigans and adding it from the location you recommended helped to get the package installed by yay. I seems someone must notify the https://aur.archlinux.org/packages/ssss/ admins to modify for the new URL of the key.

[Jon Frisby]

I'm glad to hear you got it up and running! And thank you for notifying the package maintainer for me!

[Jon Frisby]

(I still need to update my own docs, so I'm leaving this ticket open for now.)

[Jon Frisby]

Looks like a (relatively) new GCC warning spotted a legitimate issue with memset! I've pushed a fix for that, and updates to the docs.

Nope. I'm just jumbled about where I am in history. >.<

[Feraidoon Mehri]

@MrJoy I get a bad signature after cloning:

❯ gpg --keyserver ipv4.pool.sks-keyservers.net --recv-key 7DCB12A7
gpg: key 498FCFAD9FE6855B: public key "Jon Frisby <[e-mail]>" imported
gpg: Total number processed: 1
gpg:               imported: 1

❯ git tag -v releases/v0.5.7                
object 056546fe8e8c6d51b97caaabcdcdf81c7ea50b8b
type commit
tag releases/v0.5.7
tagger Jon Frisby <[e-mail]> 1607379205 -0800

* Update README to reflect changes to SKS keyserver.
* Improve consistency of styling in README and installation guide.
* Make README reference correct tag names.
gpg: Signature made Tue Dec  8 01:43:31 2020 +0330
gpg:                using RSA key 7CF4A19F848BDD8EA8B2E1247F7CFB137DCB12A7
gpg: Good signature from "Jon Frisby <[e-mail]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 6DD6 0169 1023 247F B4FE  63A3 498F CFAD 9FE6 855B
     Subkey fingerprint: 7CF4 A19F 848B DD8E A8B2  E124 7F7C FB13 7DCB 12A7

[Jon Frisby]

(Sorry if this is a bit rambly/disjointed, but I was unable to fall asleep last night so I'm a bit sleep-deprived.)

Ok, I think my documentation has misled you a bit by not calling out the trust issue explicitly.

If I'm understanding the warning properly, it basically just means that you haven't marked the key as "trusted" (signed it with your own key) in your keyring. And you shouldn't sign my key. At least, not without taking steps to ensure that I am, in fact, the real owner of that key and that I really do have the email jfrisby at mrjoy dot com.

https://www.gnupg.org/gph/en/manual/x334.html

If you want a degree of trust that, say, would prove handy in pursuing me if I turned out to be a bad actor, you're not gonna be able to achieve that without without some interaction involving real-life/meat-space. I don't think that would be a particularly valuable use of either of our time in this scenario anyway: I'm not the original/primary/at-all-significant developer of this code. I put it on Github to make it a bit more convenient for people to get at it and utilize it, but I do not claim to understand how it works or to be able to make guarantees about the robustness of the tool. No warranties/claims implied or otherwise, blah blah blah. I am not attesting that the signed code is secure/safe/trustworthy. I'm not actively developing this project, either.

All I am, to you, is some rando on the Internet who apparently has control of key 7DCB12A7, and claims to be named Jon Frisby with the afore-mentioned email address. For all you know, I could be lying about both my name and email -- and this mechanism gives you no way to determine if that's the case.

All that the signature and associated check can possibly tell you is:

1. That someone with control of key 7DCB12A7 attests that any given tag contains only the code that said individual is aware of.
2. An early warning if someone other than the owner of key 7DCB12A7 adds commits / changes code / re-tags a release / tags a new release, after you have already cloned the repo and imported key 7DCB12A7.
   • (There can be cases where this can happen despite no bad actors being involved, and you'd be stuck trying to figure out whether it was a bad actor or the owner of key 7DCB12A7 simply changing keys in a very clumsy and unfriendly way. But. You will know that such an investigation is needed.)

In short: The most the signature can tell you is offer some reasonable (but not absolute) assurance that what you're getting is what I intended to give you.

It cannot tell you if I am who I say I am. It cannot tell you whether or not I'm trustworthy/well-intentioned/etc. It also can't tell you if a bad actor changed the code/docs, and re-tagged things using a different key they control and then somehow figured out how to push those changes to this repo without me noticing it prior to you discovering those instructions. (Although this last one is maybe mitigated by me showing up to have this conversation. So either Github user MrJoy owns that key, or I am someone who has taken over MrJoy's Github account, acquired access to the key, etc.)

Basically: Don't infer from these signatures more than they can guarantee under the circumstances. If you're comfortable with this tool as-is, have at it! The output is telling you that what you got is what I intended for you to get. Just proceed with all the skepticism and caution you would otherwise have for a random tool provided second-hand by a random, wholly insignificant and unknown stranger on the Internet. (And, y'know, try not to think too hard about what Homebrew/NPM/Yarn/Bundler/PyPi/insert-package-manager-here's signature checking does/doesn't guarantee, or what their human processes are to ensure those signatures are likely to be meaningful...)

P.S. For the love of Root, if you're going to use it for anything actually important/sensitive, track down the original author, pay him to audit my changes and offer you guidance on the best implementation strategy (and associated requisite human processes) for your situation.