How to use GPG to verify ASC signature of PgAdmin binary? - postgresql

How do I use GPG to verify the ASC signature of a PgAdmin binary?
This is the binary I am verifying: https://ftp.postgresql.org/pub/pgadmin/pgadmin4/v3.3/macos/pgadmin4-3.3.dmg
This is the signature I am using:
https://ftp.postgresql.org/pub/pgadmin/pgadmin4/v3.3/macos/pgadmin4-3.3.dmg.asc
Steps I followed from this serverfault answer:
Download binary to ~/Downloads
Import signature
$ gpg --import pgadmin4-3.3.dmg.asc
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
That didn't work so I tried to verify using the ASC
gpg --verify pgadmin4-3.3.dmg.asc pgadmin4-3.3.dmg
gpg: Signature made Mon Sep 3 03:27:56 2018 MDT
gpg: using RSA key E8697E2EEF76C02D3A6332778881B2A8210976F2
gpg: Can't check signature: No public key
That didn't work either. Do I need an additional file?

After emailing the mailing list (should have started there) I was sent the following URL: https://pgp.mit.edu/pks/lookup?op=get&search=0x8881B2A8210976F2
This contained the following text, which imported successfully:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: SKS 1.1.6
Comment: Hostname: pgp.mit.edu
mQINBFtyz58BEACgKbtY59R0mxs8rWJNAn1BWNXwhuTvELNCV6gZkMRGFP14tMopd9VcUx5U
WiulT5wysji63xhkNljmE90jJdlxZwZ+XtnmLzIqp6i29EkAIUt1AoxMw2ipMhfuwE6WA6VY
xQihu5z2IDOR1PdDUHF5cX/GZgBon/2A33rG5IKTcaNZzL0Oc3rS5VzOzwnp1FHPlR7PY7BR
DNe8q1MrQq14tlgMTaYziNg2t2YwjuhNV6G33qGEh390aUnO/eMWIPJzKoi4mE5mhEbh4L/7
sFlcRUC6Vs1xa5Ab+L5y2xoDe2grraKDu+XpGJaDPLunlhDSTUsp0HsoLVU4ne/HNbCAm2b2
5tKFcFTUwDH4Ekge1/bQLCvxkB63MMLa/FgsJ0XAr8zKEQFrc89qJU4JuvadL4hAIqZ1ywFl
wTOBaNfZHbW2Pt5fprktIL5d5jIHAdQrFPvLqhhjhM03de6O6dS5lDeP8dTdqzMcqBkwFMmj
ZMeRAcoJvs0jJNc0fYwL3h2JSWQnIhsvcSe6gk8GFVRbCCy9UplK1K/5TWw+y3mtfWwUCUSW
nBIuUTV+5iG21o3rdZgfEjXJtBAWW/hKoVwBTe5Ir9yIqaomG5ul0Sn2EgOravnsAWe2nk4l
9cno5CPhGunEtiOD8YQJHskk7/NMtnPegB5j4tprXGS/cK/5hQARAQABtDxQYWNrYWdlIE1h
bmFnZXIgKFBhY2thZ2UgU2lnbmluZyBLZXkpIDxwYWNrYWdlc0BwZ2FkbWluLm9yZz6JAk4E
EwEKADgWIQToaX4u73bALTpjMneIgbKoIQl28gUCW3LPnwIbAwULCQgHAgYVCgkICwIEFgID
AQIeAQIXgAAKCRCIgbKoIQl28ukfD/4y3gGysVSJU1964mpi/4NtSTruQ+fx8rN1vY/cctdQ
Vr1ltuJsDRyPgGpXIh9zeK0/bkCreCcuGezm2WOUFR6Kf54zMWWbIrAPpbib7rYi8n50jz7S
kCfSyJZgqO2bAPBUMP6Y09mdLaB4jib9Y6nDhFgm2V0rO64yX/bznVjBzNXFjCTgbPoABU0G
uy4yHGUFHkQ7Hdg1QLhupMWlphlMJbeSxZJx0T6ApNvr2Qg+uFykSXbXjP2e/tXGb9NeHveT
tw/hD2yMPzXJZ4uQbk8mJWDfD87fHY4ZUVqLJtKiS3omePJ5FWMPnLl0PLICkvmhmhoxyKFG
jB+62/PpYwclZLR8iB7wn9tIA/q6BqP/BBhgmzpuh7ZOAU/zUZ5D+tHuQ9X0e29iFs4nxewm
SM1uCq++l+gGMFRMn0FPH8nyQS/EcB/qXXRc0J3Ja7VVfH5BdjmVvqTeJmwY+xGdLZAh/WZ9
raWd/qbRGNIcYOyhHnvp719EQxYSiiJbIQcRLDbcIBiUG322ubSiR4+saYfx4ixrHvx8QYbt
agien0kkXtoouhhIuLxq/EADRb979ZvQ1hnlUkSGHRN6mDNyLztRqy/iibZrSgX+iKR9lQYI
5MnhchihgoN7jyFUiGTV/VSG6oH2KHiTgUQawli9OirnBB1oekf2+QZfZUvnM+b+SokCMwQQ
AQoAHRYhBODEzuuCax/aT7Ro4CSt+q9pjxUZBQJbcs/+AAoJECSt+q9pjxUZ4fAP/iQpwcrU
ZrPp3WI3hi3wHAe+L6E6LiWlhMEMlqfy/2/xOpDEniwy6IEbMV7+H8WSbFYnTBM6EJAWPCMK
ZAfkduuB6xqHllEuPuFY9O13+fV5bJMrW/ej3MbX2yz+wfa6LLORRBB/e4R34suzmlSzQzRt
tPHejmpNicn0S2kA07kqdl/2I3KcsWM1a5GeRZAukDSMLI6orZAGR+r4xKpdEiEMHfoxYYxu
jmQR9+jqYYPsuViHc3LtIwaKMjTiWBx7wUDF+qIl7bNkT7P94VudNU9hhzCcYSAt4qiDykTo
jbSlXSx/ltqoTRhVQlk1kFk2g1O1zHyVpuAkolje5ZmRGa/ZFQWuSOd01n1QqiRLrQDXHKDB
h+sUOqaF4Hby/pwZwcsXGLEzSI9uC5HeWAn/yomDJInpyYwGmT9FyD9YSd9QjpM1y2/w2+KM
j1KRq7GvmZUONYaWp1+A0eCLyhdsZ+bqdS6DVnh0qKT/8ulWUKe+sxiRyAaKBF0QacuuRiRF
AfgWbQbsrEQGcDqLq7lmtmOKa0GrBQJAvTMUkxrpMG6SIe+HsJJ3/u+pmTWg77oiQqTByQPP
JF0/EgMVg/JzstHdI+FA7Q/4DKJZ5NrPBpUUQC0h+Iex426C7gBtnGXQHYB2Nx6xCtwmpPZv
w5THrRb07Y59nZEZLEdcL8bbH/CZuQINBFtyz58BEACt0Hcb8t24ZXsGcOlVnElocMMo17Id
yDvs1j2jJxrNTT6jkxlgwG+ojStsRvllRrG85Wq/FNI6LuBY3Ux+YmdaNm+p8CJiEDE/Gql4
GPSNZ7fCiiopRyyFXg61VM72lWokAT9o9GaSU0/sM5WDeXvMA5QIlAg6+jQ7+R0MMLHeH0GT
MnF58KAFmE7T72+H1zPtvH3qeQlOt+PBMJVNhjiO2MwU7NlUIKVz4Vn1JmxA1kCWEIxZyFS8
2XXKc9BXgPqwnk27lqBxdZzDWFki8SBnDdvwTT/s0chtwekWN4t2RofK0w33TF7+MSQLxpWL
r8igrQQvBq6LBfMqm8tQWHL2VDORDg5kKIpZv4pNxxIFmu1VX+W01Oj2GV6AOJgX6jadMiRl
Hptkz7D/dmnqsCyfDRCmLcwB3y2/behbV1+iW2bViUaFoQIt/XXm2Jo1YtskxZ7LDngDin88
pU6jId1NdxjP2rKUjm/dyH5jMn1engv71w16TH+GVr42ho+yOwOTYo8qKDAvQgI8I8e+MlkM
LRLpgmFiECmWCovJOQ2JHizqFOmr+eSbeg7o5VpWA+cb0sCdbGUX8Kv6i8zP/ayhVnWg1oU5
Q0HTgH9gQ0rzkR+Re2O5xSKuNYnqVOJv4eRzt1NPFgZZOw+PFMJlvEz4ujGwA/OsdJNLQK/H
EK75GwARAQABiQI2BBgBCgAgFiEE6Gl+Lu92wC06YzJ3iIGyqCEJdvIFAltyz58CGwwACgkQ
iIGyqCEJdvKPUg//f2YJGHX9FaNkCpoEk51QW5svpqITO24Ig65mEVVyx1GPOR9BQnCJoXZr
nhEv2d/BpijFE/cR/fHv9bmqc434waeZPyDyflWTn6+MQYMJJfszKdJFaaY4qPeaCcoh7GC2
qw4I5MINfNVTcinOU52XZzt6F+ENm4h8u6vbS+55sKXjRRxNMHbBlNMr0yylukdGrs3PTGEY
tXEPBhms4Plz5uHjwkvf+rti84z2qqdX6y0YWxtRBy0cGeo15NYA8kHJLIQeUYbkV20PC7Uo
oj29DpIsRxDv7F2qZ3KIse8oiJTIubdM+O7zNhzMo+XSUY2HM6aWDLCjV5SuJVJUsPxA3aEK
ijn/PjmGkr4DKhiant0nIB/pzyKelNQJHO5fgCFuV72R9GIR7yBRG2AU5OwgHQdy5F0/4/6L
tNVWZMKy2lEYuyW8fm0rbC7G5Qbz0KhYZWxp3F20rO6679ViMuNQTwQfHI9akdtFqFEFPuoH
yT3VAMxzeUAcMXwBaPcHw1EOlX1kibaM5dbDVOfKEr6JNj4VN00CeuM++rHJSTeM/gcxO+BW
pzaNFF9MMrCBL74wiY+WJ7rogRf5Du7H2e0+w/XOpuIx3rGSO9VhVrVcoTHimJPuWH7j56wy
bLS/TCh6HI8soMjYLzxWbqvSyV0b4xfbczb/7fY4Fah80eE59/M=
=E6/L
-----END PGP PUBLIC KEY BLOCK-----
I then executed the following commands (showing output) to import the key and verify the signature:
$ gpg --import postgres-pub-key.txt
gpg: key 8881B2A8210976F2: 1 signature not checked due to a missing key
gpg: key 8881B2A8210976F2: public key "Package Manager (Package Signing Key) <packages#pgadmin.org>" imported
gpg: Total number processed: 1
gpg: imported: 1
gpg: no ultimately trusted keys found
$ gpg --verify pgadmin4-3.3.dmg.asc pgadmin4-3.3.dmg
gpg: Signature made Mon Sep 3 03:27:56 2018 MDT
gpg: using RSA key E8697E2EEF76C02D3A6332778881B2A8210976F2
gpg: Good signature from "Package Manager (Package Signing Key) <packages#pgadmin.org>" [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: E869 7E2E EF76 C02D 3A63 3277 8881 B2A8 2109 76F2

Related

Cannot commit error: Load key "path": invalid format?

When I tried to commit my work I've this message :
error: Load key "/var/folders/97/8chxzhxs3n79g9b95510jwwr0000gn/T//.git_signing_key_tmp2JvaYk": invalid format?
fatal: failed to write commit object
Please can help me, I can't commit anything.
I see many topics about this with ssh-add and ss-agent but none works for my case...
I've tried to regenerate my ssh key with ssh-keygen. I've remove my id_rsa and id_rsa.pub to regenerate them.
Question : the message is -> error: Load key "/var/folders/97/8chxzhxs3n79g9b95510jwwr0000gn/T//.git_signing_key_tmp2JvaYk": invalid format?
But my key are located in ~/.ssh/id_rsa... I don't understand.
If your private key is passphrase-protected (meaning, encrypted), you would need to add your SSH key to an SSH agent.
Check also "Signing Git Commits with Your SSH Key" from Caleb Hearth.
Only then a git commit -S (signing the commit) would work.
Or you might have told Git about your SSH key:
git config --global gpg.format ssh
git config --global user.signingkey 'key::ssh-ed25519 AAAAC3(...) user#example.com'
Note that, with Git 2.40 (Q1 2023), the error message is improved when private key is not loaded in the SSH agent in the codepath to sign with an SSH key.
See commit dce7b31 (25 Jan 2023) by Adam Szkoda (adaszko).
(Merged by Junio C Hamano -- gitster -- in commit c7757b2, 03 Feb 2023)
ssh signing: better error message when key not in agent
Signed-off-by: Adam Szkoda
When signing a commit with a SSH key, with the private key missing from ssh-agent, a confusing error message is produced:
error: Load key
"/var/folders/t5/cscwwl_n3n1_8_5j_00x_3t40000gn/T//.git_signing_key_tmpkArSj7":
invalid format? fatal: failed to write commit object
The temporary file .git_signing_key_tmpkArSj7 created by Git contains a valid public key.
The error message comes from ssh-keygen -Y sign' and is caused by a fallback mechanism in ssh-keygenwhereby it tries to interpret.git_signing_key_tmpkArSj7` as a private key if it can't find in the agent.
A fix is scheduled to be released in OpenSSH 9.1.
All that needs to be done is to pass an additional backward-compatible option -U to 'ssh-keygen -Y sign' call.
With '-U', ssh-keygen always interprets the file as public key and expects to find the private key in the agent.
As a result, when the private key is missing from the agent, a more accurate error message gets produced:
error: Couldn't find key in agent

GPG Check fails on CentOS Stream 9, but not on Fedora 35

I am having an issue with a lab server I am running using CentOS 9, when I'm trying to install Grafana, the GPG check fails. This is the output I get:
Importing GPG key 0x24098CB6:
Userid : "Grafana <info#grafana.com>"
Fingerprint: 4E40 DDF6 D76E 284A 4A67 80E4 8C8C 34C5 2409 8CB6
From : https://packages.grafana.com/gpg.key
Is this ok [y/N]: y
Key import failed (code 2). Failing package is: grafana-8.5.5-1.x86_64
GPG Keys are configured as: https://packages.grafana.com/gpg.key
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED
When I try the same on my local Fedora 35 machine, I get this:
Importing GPG key 0x24098CB6:
Userid : "Grafana <info#grafana.com>"
Fingerprint: 4E40 DDF6 D76E 284A 4A67 80E4 8C8C 34C5 2409 8CB6
From : https://packages.grafana.com/gpg.key
Is this ok [y/N]: y
Key imported successfully
Running transaction check
The packages being downloaded are the same grafana-8.5.5-1.x86_64.rpm, I am using dnf for both installations, and the grafana.repo files are both the same:
[grafana]
name=grafana
baseurl=https://packages.grafana.com/oss/rpm
repo_gpgcheck=1
enabled=1
gpgcheck=1
gpgkey=https://packages.grafana.com/gpg.key
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
I know I could just turn off the gpg checking, but I am not comfortable with a solution like that.
Any help resolving this would be greatly appreciated! Let me know if I should supply any more information.
I've quite recently swapped over to CentOS and Fedora, so I apologize if this has been resolved before, but I was unable to find it.
There has been some change with the default crypto policies in CentOS streams 9.
update-crypto-policies --set DEFAULT:SHA1
The packages need to be re-signed with a SHA256 or SHA521 key instead of SHA1.
Ref: https://access.redhat.com/articles/6846411

GPG Key generation failed: End of file

I'm trying to generate a GPG Key following this tutorial: https://docs.github.com/en/authentication/managing-commit-signature-verification/generating-a-new-gpg-key but I'm getting the following End of file error:
% gpg --full-generate-key
gpg (GnuPG) 2.3.6; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Please select what kind of key you want:
(1) RSA and RSA
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
(9) ECC (sign and encrypt) *default*
(10) ECC (sign only)
(14) Existing key from card
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (3072) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 0
Key does not expire at all
Is this correct? (y/N) y
GnuPG needs to construct a user ID to identify your key.
Real name: name
Email address: email
Comment: comment
You selected this USER-ID:
"name (comment) <email>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: agent_genkey failed: End of file
Key generation failed: End of file
Versions:
gpg (GnuPG) 2.3.6
libgcrypt 1.10.1
Do you know how can I solve this End of file issue?
Thank you in advance!
Are you using MacOS? I've had the same problem with the currently latest GnuPG OSX version (2.3.6) which didn't work for me either. Try using LTS version (2.2.35). It worked fine for me.
Link: https://sourceforge.net/p/gpgosx/docu/Download/

Error installing sbt on Ubuntu 18.04: `gpg: keyserver receive failed: Invalid argument` [closed]

Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 3 years ago.
Improve this question
I'm following the official sbt install instructions.
$ sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 2EE0EA64E40A89B84B2DF73499E82A75642AC823
Executing: /tmp/apt-key-gpghome.uRI0yiusG0/gpg.1.sh --keyserver hkp://keyserver.ubuntu.com:80 --recv 2EE0EA64E40A89B84B2DF73499E82A75642AC823
gpg: keyserver receive failed: Invalid argument
Edit:
I've tried digging into the gpg.1.sh script that it executes. Here is the final call to gpg.
$ sudo cat /tmp/apt-key-gpghome.IRnmlx6hfX/gpg.0.sh
#!/bin/sh
exec 'gpg' --ignore-time-conflict --no-options --no-default-keyring \
--homedir '/tmp/apt-key-gpghome.IRnmlx6hfX' --no-auto-check-trustdb --trust-model always "$#"
Edit 2:
I've tried to directly query for the key from the keyserver with no luck. See http://keyserver.ubuntu.com/pks/lookup?search=2EE0EA64E40A89B84B2DF73499E82A75642AC823&op=vindex . Is it possible the key is missing?
Edit 3:
I retried again on Feb 24th and it now works!
giving the command
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 2EE0EA64E40A89B84B2DF73499E82A75642AC823
I got the error
Executing: /tmp/apt-key-gpghome.DKOlZn67Q0/gpg.1.sh --keyserver hkp://keyserver.ubuntu.com:80 --recv 2EE0EA64E40A89B84B2DF73499E82A75642AC823
gpg: ricezione dal server di chiavi non riuscita: Dati assenti
(no data)
I solved in this way (laptop with Ubuntu 18.04.1, behind a corporate proxy without authentication):
got the key with gpg: gpg --receive-keys 99E82A75642AC823
gpg showed me that the key belongs to scalasbt#gmail.com
searched that key on http://keyserver.ubuntu.com/ using the email address
saved the key in local file (sbt-key) and then imported with sudo apt-key add sbt-key
Had same problem. Two ubuntu 18.04.1 boxes. One recently installed, the other was recently upgraded from 16.04.5. In the first one I could import keys to install Scala & R without problems. In the second one the import process failed with the same error as you.
It seems that gpg imports keys launching a dirmng daemon. This process is the one that communicates through the network with keyserver.ubuntu.com.
To solve the problem, I launched dirmng prior to gpg this way:
sudo -i
dirmngr --daemon --homedir /root/key --debug-level guru --log-file dirmng.log
gpg -vv --debug-level 9 --ignore-time-conflict --no-options --no-default-keyring --homedir '/root/key' --no-auto-check-trustdb --trust-model always --keyserver hkp://keyserver.ubuntu.com:80 --recv 2EE0EA64E40A89B84B2DF73499E82A75642AC823
Then gpg shows the dialog with dirmngr:
gpg: DBG: chan_3 -> KEYSERVER --clear hkp://keyserver.ubuntu.com:80
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_GET -- 0x2EE0EA64E40A89B84B2DF73499E82A75642AC823
gpg: DBG: chan_3 <- ERR 167804976 Invalid argument <Dirmngr>
gpg: keyserver receive failed: Invalid argument
gpg: DBG: chan_3 -> BYE
And dirmngr log file shows errors resolving keyserver.ubuntu.com:
2018-09-07 11:44:34 dirmngr[16174.6] DBG: chan_6 <- KS_GET -- 0x2EE0EA64E40A89B84B2DF73499E82A75642AC823
2018-09-07 11:44:39 dirmngr[16174.6] resolving 'keyserver.ubuntu.com' failed: Invalid argument
2018-09-07 11:44:39 dirmngr[16174.6] number of system provided CAs: 133
2018-09-07 11:44:44 dirmngr[16174.6] resolving 'keyserver.ubuntu.com' failed: Invalid argument
2018-09-07 11:44:44 dirmngr[16174.6] can't connect to 'keyserver.ubuntu.com': host not found
2018-09-07 11:44:44 dirmngr[16174.6] error connecting to 'http://keyserver.ubuntu.com:80': Invalid argument
2018-09-07 11:44:44 dirmngr[16174.6] command 'KS_GET' failed: Invalid argument
Why one box connected to the same network fails to resolve keyserver.ubuntu.com from dirmngr and the newer one succeeds? Why in the older box I could resolve keyserver.ubuntu.com with nslookup but dirmngr couldn't? I don't know. But the difference between the two boxes was in /etc/resolv.conf. I had added google DNS servers. Removing them from resolv.conf made dirmngr work.
nameserver 127.0.0.53
#nameserver 8.8.8.8
#nameserver 8.8.4.4
After this change, apt-key works. Hope this helps.
In official SBT documentation there is this note:
Note: There’s been reports about SSL error using Ubuntu: Server access Error: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty url=https://repo1.maven.org/maven2/org/scala-sbt/sbt/1.1.0/sbt-1.1.0.pom, which apparently stems from OpenJDK 9 using PKCS12 format for /etc/ssl/certs/java/cacerts cert-bug. According to https://stackoverflow.com/a/50103533/3827 it is fixed in Ubuntu Cosmic (18.10), but Ubuntu Bionic LTS (18.04) is still waiting for a release. See the answer for a woraround.
According to this the problem has been fixed in Ubuntu 18.04.1.

Digital signature with iText and beID (using 2048 RSA key) on JDK8

When used under JKD8, the signature of PDF files using iText and beID (with RSA key 2048 bits) will throws an exception: RSA key must be at most 1024 bits
26/09/2014 10:48:36 [exitApplication] [SEVERE] - exitApplication with status 1
java.security.InvalidKeyException: RSA key must be at most 1024 bits
at sun.security.pkcs11.P11Signature.checkKeySize(P11Signature.java:363) at sun...
at sun.security.pkcs11.P11Signature.engineInitSign(P11Signature.java::427)
at java.security.Signature$Delegate.engineInitSign (Signature.java:1129)
at java.security.Signature.initSign (Signature;java:512)
at com.itextpdf.pdf.security.PrivateKeySignature.sign(PrivateKeySignature.java:115)
at com.itextpdf.pdf.security.MakeSignature.signDetached(MakeSignature.java:152)
Use an updated version of the middleware that fixes this bug:
Reported Issue
This issue should be fixed in the future release build (v410), which you can find on http://eid.belgium.be/en/using_your_eid/installing_the_eid_software/windows/