Im trying to setup my gnupg configuration on MAC OS 11.2.1
So far I have setup my SSH, I have generated my GPG key and added it into GPG agent.
Now, if I run this command:
echo "test" | gpg --clearsign
I am getting this result:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
test
gpg: signing failed: No pinentry
gpg: [stdin]: clear-sign failed: No pinentry
The problem is, that the pinetry is installed:
pinentry-curses (pinentry) 1.1.1
Copyright (C) 2016 g10 Code GmbH
License GPLv2+: GNU GPL version 2 or later <https://www.gnu.org/licenses/>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
In my gpg-agent.conf file, I have this line:
pinentry-program /usr/local/bin/pinentry-mac
In my gpg.conf I have this line:
no-tty
gpg version:
gpg (GnuPG) 2.2.27
libgcrypt 1.9.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: /Users/usr/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
I have tried to kill gpg agent and reinstall gnupg several times, reinstal pinentry. Nothing helped.
Update
I have tried
unset DISPLAY
Still no help
Related
The following is a copy of a simple terminal session on Mac OS Big Sur 11.4:
1 ~> date
Fri Jul 2 20:16:45 EDT 2021
2 ~> which gmake
3 ~> ll /usr/local/bin/gmake
ls: /usr/local/bin/gmake: No such file or directory
4 ~> /usr/bin/gnumake --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i386-apple-darwin11.3.0
5 ~> sudo ln -s /usr/bin/gnumake /usr/local/bin/gmake
Password:
6 ~> ll /usr/local/bin/gmake
lrwxr-xr-x 1 root admin 16 Jul 2 20:17 /usr/local/bin/gmake -> /usr/bin/gnumake
7 ~> /usr/bin/gnumake --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i386-apple-darwin11.3.0
8 ~> /usr/local/bin/gmake --version
gmake: error: Failed to locate 'gmake'.
xcode-select: Failed to locate 'gmake', requesting installation of command line developer tools.
And a little window pops up, giving me the choice to install or cancel. (In this session I cancelled. When I choose install it will succeed after several minutes, but if I invoke usr/local/bin/gmake again, the same thing will happen again.)
How is this even possible?
FWIW, the command line tools are already installed:
9 ~> xcode-select --install
xcode-select: error: command line tools are already installed, use "Software Update" to install updates
Any explanation of this phenomenon would be greatly appreciated.
I tried to solve this Geocache:
https://www.geocaching.com/geocache/GC67EXW_signaturbruch
And it gave me a password prompt, when I tried to solve gpg message.asc, but I didn't know the correct password back then.
Now I know it, but it just wouldn't give me the password prompt again, no matter how I tried it.
The output is as follows:
Martinas-Air:gpg martl$ gpg message.asc
gpg: WARNING: Kein Kommando angegeben. Versuche zu raten was gemeint ist ...
gpg: CAST5 verschlüsselte Daten
gpg: Verschlüsselt mit einer Passphrase
gpg: Entschlüsselung fehlgeschlagen: Bad session key
(I am on a German MacOs Mojave, 10.14.6 and my gpg --version gives me this:
Martinas-Air:gpg martl$ gpg --version
gpg (GnuPG/MacGPG2) 2.2.17
libgcrypt 1.8.4
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: /Users/martl/.gnupg
Unterstützte Verfahren:
Öff. Schlüssel: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Verschlü.: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2)
Can somebody tell me, how can I get back to getting asked for the password again??? I searched whole Internet for solutions like "restart your computer", reinstall all gpg tools, delete all .gpg files and so on, but nothing would make it better.
Thanks in advance.
After having had the same issue, I was able to get the password prompt back using the following steps:
In file ~/.gnupg/gpg.conf, append:
use-agent
pinentry-mode loopback
In file ~/.gnupg/gpg-agent.conf, append:
pinentry-program /usr/bin/pinentry-gtk-2
allow-loopback-pinentry
Then restart your gpg agent with echo RELOADAGENT | gpg-connect-agent.
I have downloaded a GNU tar archive (emacs-26.1.tar.xz) and now want to verify it against its signature file. gpg returns with the verify option the following output:
gpg: no valid OpenPGP data found.
gpg: the signature could not be verified.
Obviously the download could not be verified. But what does this mean? Is the tar archive probably corrupt? Or had I not imported the correct keys?
Here is step-by-step what I did:
I downloaded the archive file and its .sig file:
$ wget https://ftp.gnu.org/gnu/emacs/emacs-26.1.tar.xz
$ wget https://ftp.gnu.org/gnu/emacs/emacs-26.1.tar.xz.sig
I downloaded the GNU keyring (the Emacs download page gave me the link):
$ wget https://ftp.gnu.org/gnu/gnu-keyring.gpg
With gpg I imported the GNU keyring:
$ gpg --import gnu-keyring.gpg
Note that this returned:
.
.
.
gpg: Total number processed: 525
gpg: imported: 525 (RSA: 187)
gpg: no ultimately trusted keys found
Finally I verified the tar archive:
gpg --verify emacs-26.1.tar.xz.sig emacs-26.1.tar.xz
This then returned (as stated at the top):
gpg: no valid OpenPGP data found.
gpg: the signature could not be verified.
Please remember that the signature file (.sig or .asc)
should be the first file given on the command line.
So, is the tar archive corrupt or had I not imported the correct keys? If the latter is the case, what are the correct keys for this GNU download?
I am trying to use productsign to sign a XAR archive containing 2 pkg files created using productbuild . The xar tool is creating the file correctly, but I think the signing is corrupting the content, even though the file obtained is signed.
Some relevant command outputs below (I replaced the sensitive information with INFO):
$ ls .
file1.pkg file2.pkg
$
$ xar -cf '../_file.xar' .
$
$ cd ..
$ /usr/bin/productsign --sign 'Developer ID Installer: INFO' '_file.xar' 'file.xar'
productsign: using timestamp authority for signature
productsign: signing product with identity "Developer ID Installer: INFO" from keychain /Users/INFO/Library/Keychains/login.keychain
productsign: adding certificate "Developer ID Certification Authority"
productsign: adding certificate "Apple Root CA"
productsign: Wrote signed product archive to file.xar
$
$ /usr/sbin/pkgutil --check-signature 'file.xar'
Package "file.xar":
Status: signed by a certificate trusted by Mac OS X
Certificate Chain:
1. Developer ID Installer: INFO
SHA1 fingerprint: INFO
-----------------------------------------------------------------------------
2. Developer ID Certification Authority
SHA1 fingerprint: INFO
-----------------------------------------------------------------------------
3. Apple Root CA
SHA1 fingerprint: INFO
$ file file.xar
file.xar: xar archive - version 1
$
$ xar -xf file.xar -D /tmp
Error while extracting archive:(file1.pkg): Error decompressing file
$
Is the productsign command intended to work in some other way? I don't understand what is wrong with my approach.
After some testing, I found out xar is using relative paths inside the archive, so in my case there was a problem because I used "../" inside a path name.
So we have a certificate that allows us to sign kexts,
but when we run > sudo kextload friendly.kext, it fails
and we sign the kext we want, and to prove it's signed, here's some diagnostic output:
👉 codesign --verify -vvvv friendly.kext
friendly.kext: valid on disk
friendly.kext: satisfies its Designated Requirement
👉 spctl -a -vvvv friendly.kext
friendly.kext: accepted
source=Developer ID
origin=Developer ID Application: Friendly Corporation
/Library/Extensions
👉 codesign -dvvv friendly.kext
Executable=/Library/Extensions/friendly.kext/Contents/MacOS/friendly
Identifier=com.friendly.friendly
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=502 flags=0x0(none) hashes=18+3 location=embedded
Hash type=sha1 size=20
CDHash=a1e2bf8d53ea67c6cfe9fc3d6d2001fe56c838a7
Signature size=8528
Authority=Developer ID Application: Friendly Corporation
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Oct 9, 2014, 11:49:02 AM
Info.plist entries=21
TeamIdentifier=1234567890
Sealed Resources version=2 rules=12 files=1
Internal requirements count=1 size=180
👉 codesign --verify -vvvv friendly.kext
friendly.kext: valid on disk
friendly.kext: satisfies its Designated Requirement
It looks like it's signed properly;
However, when I run > sudo kextutil -v friendly.kext :
Defaulting to kernel file '/System/Library/Kernels/kernel'
Diagnostics for /Library/Extensions/friendly.kext:
Code Signing Failure: code signature is invalid
/Library/Extensions/friendly.kext appears to be loadable (not including linkage for on-disk libraries).
ERROR: invalid signature for com.techsmith.friendly, will not load
I'm thinking either I downloaded the certificate wrong (we definitely got approved for kext signing), although I tried redownloading the certificate once before so that may not be the problem.
Otherwise, it's the way that I'm signing. I'm thinking maybe it has something to do with the permissions I set on the kext before I sign them?
Has anybody seen this problem before?
Thanks in advance!
The kext signing certificate must have the extension "( 1.2.840.113635.100.6.1.18 )" listed - this is what designates it as a kext-enabled certificate. You can easily verify this by viewing it in Keychain Access.app. (it's listed near the bottom, below extension "( 1.2.840.113635.100.6.1.13 )" which I think is used for apps and thus present in all Developer ID certificates)