wget https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/cryptsetup-1.7.3.tar.xz
wget https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/cryptsetup-1.7.3.tar.sign
wget https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/sha256sums.asc
shasum verified: ok
gpg --verify cryptsetup-1.7.3.tar.sign cryptsetup-1.7.3.tar.xz
the output is bad :
gpg: Signature made Sun 30 Oct 2016 01:56:01 PM UTC using RSA key ID D93E98FC
gpg: BAD signature from "Milan Broz <gmazyland#gmail.com>"
then
wget https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.3-ReleaseNotes
wget https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.3-ReleaseNotes.sign
gpg --verify v1.7.3-ReleaseNotes.sign v1.7.3-ReleaseNotes
this is good (although the warning):
gpg: Signature made Sun 30 Oct 2016 01:56:09 PM UTC using RSA key ID D93E98FC
gpg: Good signature from "Milan Broz <gmazyland#gmail.com>"
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: 2A29 1824 3FDE 4664 8D06 86F9 D9B0 577B D93E 98FC
I make another test on another website:
wget https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.0.30.tar.bz2
wget https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.0.30.tar.bz2.sig
and everything is good as well.
Then I go to the author's blog (Milan Broz's blog), but the download link leads to the same website.
I tried some previous packages and had the same issue:
cryptsetup-1.7.1.tar.sign with cryptsetup-1.7.1.tar.gz & cryptsetup-1.7.1.tar.xz
cryptsetup-1.7.2.tar.sign with cryptsetup-1.7.2.tar.gz & cryptsetup-1.7.2.tar.xz
If I miss something here, plz tell me what.
otherwise, is there a place where I can have a correctly signed version of this software?
thanx folks.
is there a place where I can have a correctly signed version of this software?
Try from the official website: https://gitlab.com/cryptsetup/cryptsetup (now -- Nov. 2017, 9 months later, in 1.7.5 or 2.0-rc1)
this is good (although the warning):
The warning is expected. See "Check PGP Signature and Install Veracrypt 1.17":
The "WARNING: This key is not certified with a trusted signature! There is no indication that the signature belongs to the owner." means that the Veracrypt public key is not signed by you or by anybody whose key you have signed, so there is no direct line of trust between you and the Veracrypt developers.
This is as expected.
Related
I want to download and verify TortoiseGit-2.8.0.0-64bit.msi
I use gnupg2 (in Cygwin)
The TortoiseGit download page provides these files:
TortoiseGit-2.8.0.0-64bit.msi
TortoiseGit-2.8.0.0-64bit.msi.rsa.asc
I did the below to verify a download (but got: No public key):
$ gpg2 --auto-key-locate keyserver --keyserver-options auto-key-retrieve --
verify TortoiseGit-2.8.0.0-64bit.msi.rsa.asc TortoiseGit-2.8.0.0-64bit.msi
gpg: Signature made Thu, Feb 28, 2019 4:34:13 PM EST
gpg: using RSA key 74A21AE301B3CA5BD8072F5EF7F17B3F9DD9539E
gpg: requesting key F7F17B3F9DD9539E from hkp server keys.gnupg.net
gpg: Can't check signature: No public key
Since I don't have a .sig I tried and got:
$ gpg2 --import TortoiseGit-2.8.0.0-64bit.msi.rsa.asc
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
I can't understand how then to properly verify this download -- if anyone can show the correct method it would be greatly appreciated!
Thank you!
The key is available here: https://download.tortoisegit.org/keys.
As the MSI files are also signed using AuthentiCode, there is no real need for the GPG signatures for end users. - The GPG signatures are used by the auto-updater in order to verify the integrity of the update packages (despite the fact that those are also downloaded using HTTPs).
If you need another trust root, you can call TortoiseGitProc.exe /command:pgpfp in order to display the GPG fingerprint.
I've been fighting with this for quite some time and would be extremely grateful if anyone could help me understand what's happening here.
I have an install4j project that creates installer packages for Windows and OSX. I have a regular signing cert for Windows and this works without issue. I have an Apple developer certificate as well. I've exported the private key from my keychain to a p12 file. I've tested the resulting p12 file to make sure it works with the keystore password. The certificate is definitely valid, since I just created it (again) today. And, when I run the installer build via Maven, it even looks as though everything is going fine:
[INFO] Compressed media file 'Mac OS X Single Bundle':
[INFO] Compressing files
[INFO] Generating VM options file vmoptions.txt.
[INFO] Signing installer
[INFO] Signing DMG
[INFO] Moving media files to media directory /Users/....
[INFO] The name of the media file is my-app_macos_1_1_1.dmg.
[INFO] The size of the media file is 4.8 MB
Which seems good, except that the installer and dmg AREN'T signed, or at least not in a way that's useful:
$ spctl -a -v target/media/my-app_macos_1_1_1.dmg
target/media/my-app_macos_1_1_1.dmg: CSSMERR_TP_CERT_EXPIRED
$ spctl -a -v /Volumes/my-app/My\ Application\ Installer.app
/Volumes/my-app/My Application Installer.app: CSSMERR_TP_CERT_EXPIRED
The cert is NOT expired:
Alias name: mac developer: me myself (my company, inc.)
Creation date: Mar 6, 2017
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: C=US, O="Radiologics, Inc.", OU=K865L34KBQ, CN=Mac Developer: Me Myself (XXXX), UID=YYYY
Issuer: CN=Apple Worldwide Developer Relations Certification Authority, OU=Apple Worldwide Developer Relations, O=Apple Inc., C=US
Serial number: 30544da25ea67233
Valid from: Mon Mar 06 14:46:17 CST 2017 until: Tue Mar 06 14:46:17 CST 2018
But whether I build the dmg/installer directly from install4j or through the Maven plugin, the result is not valid. I always get something similar to this:
$ codesign -dvvv target/media/my-app_macos_1_1_0.dmg
Executable=.../target/media/my-app_macos_1_1_0.dmg
Identifier=my-app_macos_1_1_0
Format=disk image
CodeDirectory v=20100 size=173 flags=0x0(none) hashes=1+2 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=XXXXXX
Hash choices=sha256
CDHash=XXXXX
Signature size=8641
Authority=(unavailable)
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=1 size=36
In order for us to be able to distribute this app, we really need to get this to work, but I've spent literally days on this without making any progress at all. If anyone could shed any light on what's going on here, I'd greatly appreciate it.
There are two different kinds of certificates for distributing apps outside of the Mac App Store.
An application certificate and an installer cetificate.
Check your certs (which you can do via the "My Certificates" in the Keychain Access app hiding in /Application/Utilities) to make sure you're using an installer certificate (on my machine the name of it is "Developer ID Installer: Michael Dautermann". This is separate from the "Developer ID Application" certificate you use to codesign apps.
More information can be seen here.
As for DMG's, my original answer would have been "can't do that", but actually as of MacOS 10.11.5 you CAN sign dmg files. More information can be seen in the "Signing Disk Images" section of the "macOS code signing in depth" reference guide. You'd use your Developer ID Application certificate.
I am new to cryptography in general, I have a question about the primary key fingerprint:
I have downloaded Apache Maven and, as they say in the download page, have verified the signature of the public key, using gpg:
user$ gpg --verify apache-maven-3.2.3-bin.tar.gz.asc apache-maven-3.2.3-bin.tar.gz
gpg: Signature made Tue Aug 12 00:59:35 2014 MSK using DSA key ID BB617866
gpg: Good signature from "Someone <email#maven.org>"
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: FB11 D4BB 7B24 4678 337A AD8B C7BF 26D0 BB61 7866
Now, I read from http://www.apache.org/dev/release-signing#fingerprint that the primary key fingerprint is a digest of the key, easier to read and compare, but my question is:
How should I compare it? I mean, where should I found the counterpart against whom I should compare the fingerprint "FB11 D4BB 7B24 4678 337A AD8B C7BF 26D0 BB61 7866"?
The public keys of the Maven developers are linked on top of the download page.
It only contains the short IDs, which are not sufficient to verify keys, but help you at looking up which key was used. To do so, delete this key (it probably already was fetched from the key servers during verifying the signature):
gpg --delete-keys [keyid]
Now prepare importing this key, by copying the public key block matching to the key ID given above to a file of your choice. This file should afterwards contain:
-----BEGIN PGP PUBLIC KEY BLOCK-----
[snip]
-----END PGP PUBLIC KEY BLOCK-----
Now import using gpg --import [file]. Now run gpg --fingerprint [keyid], it should print the same fingerprint given in the output of the signature verification.
When I download GCC, it also has a .sig file, and I think it is provided to verify downloaded file.
(I downloaded GCC from here).
But I can't figure out how should I use it. I tried gpg, but it complains about public key.
[root#localhost src]# gpg --verify gcc-4.7.2.tar.gz.sig gcc-4.7.2.tar.gz
gpg: Signature made Thu 20 Sep 2012 07:30:44 PM KST using DSA key ID C3C45C06
gpg: Can't check signature: No public key
[root#localhost src]#
How can I verify downloaded file with .sig file?
You need to import public key: C3C45C06
Can be done in three steps.
find public key ID:
$ gpg gcc-4.7.2.tar.gz.sig
gpg: Signature made Čt 20. září 2012, 12:30:44 CEST using DSA key ID C3C45C06
gpg: Can't check signature: No public key
import the public key from key server. It's usually not needed to choose key server, but it can be done with --keyserver <server>. Keyserver examples.
$ gpg --recv-key C3C45C06
gpg: requesting key C3C45C06 from hkp server keys.gnupg.net
gpg: key C3C45C06: public key "Jakub Jelinek jakub#redhat.com" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1
If the command error's out with a timeout, you may be behind a firewall that is blocking the default gpg port. Try using the `--keyserver' option with port 80 (almost all firewalls allow port 80 b/c of web browsing):
$ gpg --keyserver hkp://${HOSTNAME}:80 --recv-keys ${KEY_ID}
verify signature:
$ gpg gcc-4.7.2.tar.gz.sig
gpg: Signature made Čt 20. září 2012, 12:30:44 CEST using DSA key ID C3C45C06
gpg: Good signature from "Jakub Jelinek jakub#redhat.com" [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: 33C2 35A3 4C46 AA3F FB29 3709 A328 C3A2 C3C4 5C06
The output should say "Good signature".
gpg: WARNING: This key is not certified with a trusted signature!
Is for another question ;)
This other avenue is particularly useful for verifying GNU projects (e.g. Octave) since the key requested by their signature may not be found in any key server.
From https://ftp.gnu.org/README
There are also .sig files, which contain detached GPG signatures of
the above files, automatically signed by the same script that
generates them.
You can verify the signatures for gnu project files with the keyring
file from:
https://ftp.gnu.org/gnu/gnu-keyring.gpg
In a directory with the keyring file, the source file to verify and
the signature file, the command to use is:
$ gpg --verify --keyring ./gnu-keyring.gpg foo.tar.xz.sig
You have to search the public keyservers for the given key id: in your case ID C3C45C06
Import the found key in your local keystore and after this the verification should be OK.
I use Ubuntu 12.04 and it comes with Seahorse key management software. Before the key import I was seeing this:
~/Downloads$ gpg --verify --keyring ./gnu-keyring.gpg icecat-31.5.0.en-US.linux-x86_64.tar.bz2.sig icecat-31.5.0.en-US.linux-x86_64.tar.bz2
gpg: Signature made 9.03.2015 (пн) 22,35,52 EET using RSA key ID D7E04784
gpg: Can't check signature: public key not found
After the key import I was seeing this:
~/Downloads$ gpg --verify --keyring ./gnu-keyring.gpg icecat-31.5.0.en-US.linux-x86_64.tar.bz2.sig icecat-31.5.0.en-US.linux-x86_64.tar.bz2
gpg: Signature made 9.03.2015 (пн) 22,35,52 EET using RSA key ID D7E04784
gpg: Good signature from "Ruben Rodriguez (GNU IceCat releases key) <ruben#gnu.org>"
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: A573 69A8 BABC 2542 B5A0 368C 3C76 EED7 D7E0 4784
according to this http://gcc.gnu.org/mirrors.html that should be Jakub Jelinek and valid. i don't know where you would get his public key though.
I've created a Firefox plugin, a Win32-native code DLL - using Firebreath. I'm working on Windows 7/x64, and targeting Windows only. The plugin itself is working well, but I'm really stuck getting a correctly signed XPI. If I don't sign my XPI, it's accepted and installed by FF 3.6 thru 10 (beta). Of course, during the install it lists the publisher as (Author not verified). So, I spent a week debugging the signing process... but FF 9 and 10 still say (Author not verified)! FF 3.6 rejects the signed XPI as invalid.
How do I troubleshoot this??
Just to repeat: I sign the xpi without error, and the resulting XPI installs successfully on FF 9 and 10, but FF still says (Author not verified).
Here's the batch code I use to sign the XPI:
echo * clean out old signing folder and xpi
if exist package rmdir /S /Q package
if exist %package%.xpi del %package%.xpi
echo * copy in files for package
md package
xcopy ..\*.rdf package
md package\plugins
xcopy ..\build\bin\Plugin\Debug\*.dll package\plugins
echo * clean out certificate database
del *.db
echo * import our signing certificate
pk12util -d . -i %keyfile% -K %pwd% -w keypass.txt
echo * adjust trust on base, intermediate and root cert
certutil -M -d . -n "VeriSign" -t "c,c,C"
certutil -M -d . -n "VeriSign Class 3 Code Signing 2010 CA - VeriSign, Inc." -t "TC,TC,TC"
certutil -M -d . -n "%certname%" -t "u,u,Cu"
certutil -L -d .
echo * create signed package
signtool -d . -X -Z %package%.xpi -k "%certname%" -p %pwd% package
I work for Mozilla, but this isn't an authoritative answer, just what I've gathered asking around:
So, essentially, each certificate authority has three trust bits Mozilla might grant it: they might trust it to sign websites, and/or mail, and/or code. Your certificate is from a certificate authority that Mozilla doesn't trust to sign code. (This is why going and manually setting the bit in your preferences makes it work—for you.)
I'm told so few people try to use binary code in xpi's that Mozilla doesn't really have an organized way to find out which authorities can be used for what. However, you can check out this list: look at the "Code Trust Bit":
https://spreadsheets.google.com/pub?key=ttwCVzDVuWzZYaDosdU6e3w&single=true&gid=0&output=html
For example (picked completely at random), ComSign Secured CA has the "Websites" and "Code" trust bits set.
I gather that Mozilla publicly discusses what rights to grant to each CA, and re-evaluates each CA periodically:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
Basically your signature needs to include full certificate chain up to the trusted VeriSign root certificate, bypassing the "VeriSign Class 3 Public Primary Certification Authority - G5" with unknown trust in mozilla (bug 602107), as by default the chain ends too soon.
Your XPI is currently signed with your certificate, with no further certificate chain included, relying that the user's browser will trust the issuer of your certificate immediately. You can examine this with Mozilla's jarsigner tool (see Mozilla NSS tools):
Tools\nss-3.11>jarsigner -verify -verbose -certs my-old.xpi
2057 Thu Sep 15 15:17:44 CEST 2011 META-INF/zigbert.rsa
sm 87 Thu Sep 15 15:17:44 CEST 2011 chrome.manifest
X.509, CN=Company Name inc., OU=General, OU=Digital ID Class 3 - Microsoft Software Validation v2, O=Company Name inc., L=City, ST=State, C=XX
[certificate will expire on 26.4.13 0:59]
(showing just the output for the 1st file)
You need to include a few more certificates to complete the chain to a certificate that is by default explicitly trusted in the end user's browser. In the end it should look like this:
jarsigner -verify -verbose -certs my-newly-signed.xpi
2057 Thu Sep 15 15:17:44 CEST 2011 META-INF/zigbert.rsa
sm 87 Thu Sep 15 15:17:44 CEST 2011 chrome.manifest
X.509, CN=Company Name inc., OU=General, OU=Digital ID Class 3 - Microsoft Software Validation v2, O=Company Name inc., L=City, ST=State, C=XX
[certificate will expire on 26.4.13 0:59]
X.509, CN=VeriSign Class 3 Code Signing 2010 CA, OU=Terms of use at https://www.verisign.com/rpa (c)10, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
[certificate is valid from 8.2.10 1:00 to 8.2.20 0:59]
[KeyUsage extension does not support code signing]
X.509, CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
[certificate is valid from 8.11.06 1:00 to 8.11.21 0:59]
[KeyUsage extension does not support code signing]
X.509, OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
[certificate is valid from 23.5.06 19:01 to 23.5.16 19:11]
To achieve this you need to:
remove the not-explicitly-trusted VeriSing's built-in certificates from the certificate database with Mozilla's certutil tool
Build the certificate trust chain of your certificate all the way up to Microsoft's "Class 3 Public Primary Certification Authority".
sign the xpi (this time full certificates chain will be included in the signature)
verify the xpi with jarsigner as described above
test the xpi in Firefox - you should not see "Author not verified" anymore.
Caveats:
Trust bits in the built-in Firefox certificate store are actually 3-state (trusted, untrusted and unknown), despite only being shown as 2-state checkbox in the FF GUI (checked=trusted, unchecked=untrusted OR unknown). By default trust is unknown, which enables you to bypass the VeriSign's certificate as described. If you ever enabled trust via FF's checkboxes it will still work, but if you uncheck the trust checkbox the trust will be set to untrusted, which will prevent bypassing that certificate in the chain. The easiest (only?) way to reset this back to initial unknown is to delete your firefox profile.
After Mozilla eventually enables the code-signing trust bit (see the bug above) you will still need to sign like this if you want to support older versions of Firefox.
Hope it helps!