Re: (bug?) Revoked keys and past signatures
On Tue 2015-02-10 08:37:38 -0500, Hugo Osvaldo Barrera wrote: Also, I see no reason why I should not be able to assign a trust to a revoked key - I might trust it even if the author revoked it as superseded: $ gpg --edit 1BFBED44 [... info on revoked key ...] gpg lsign Key is revoked. Unable to sign. fwiw, you said assign trust above, but then in your example, tried to do lsign, which is an entirely different operation from assigning trust. I believe the reason matters. I can even sit down with the owner of the key and verify his ID and fingerprint and sign it, meaning this key belongs to this person, but was superseeded a week ago. If actually influences the validity of anything he signed up to a week ago. your certifications (whether local or exportable) themselves have a timestamp in them. It would be silly to certify a key and its user ID after it was revoked by the owner; you'd be claiming i believe that right now this is the correct key, which is not the case. I understand the semantics of what you're trying to do, but i'm not sure that OpenPGP has syntax to represent it. The closest OpenPGP comes would be to forge a certification yourself from *before* the revocation. e.g. gpg --faked-system-time 20100105T153023 --lsign 1BFBED44 This isn't exactly the same semantics (it says on January 5 2010 i thought that this key was correct) but it's close. --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Revoked keys and past signatures
On 2015-02-10 12:28, Peter Lebbing wrote: On 09/02/15 20:34, Daniel Kahn Gillmor wrote: the *date* of your key was superceded revocation is relevant, though. Any certifications that claim to have happened after the date of the revocation *should* be considered invalid, whereas revocations that happen before that date (but after the key creation date) should retain their validity. (By the way, I'm going to treat data signatures, not certifications, since I believe that was what Hugo reported) I started to think you were right and I was mistaken, but I can reproduce Hugo's scenario: $ gpg2 --verify test.gpg gpg: Signature made Tue 10 Feb 2015 11:53:47 CET using RSA key ID B2F1C0D8 gpg: Good signature from Testkey 3 [full] Note how verify-options show-uid-validity notes it is fully valid. It is signed by an ultimately trusted key. Now I revoke it: $ gpg2 --edit-key B2F1C0D8 gpg (GnuPG) 2.0.26; Copyright (C) 2013 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. Secret key is available. pub 1024R/B2F1C0D8 created: 2014-02-24 expires: 2015-02-17 usage: SC trust: never validity: full sub 1024R/98AC4DFA created: 2014-02-24 expired: 2014-03-03 usage: E [ full ] (1). Testkey 3 gpg revkey Do you really want to revoke the entire key? (y/N) y Please select the reason for the revocation: 0 = No reason specified 1 = Key has been compromised 2 = Key is superseded 3 = Key is no longer used Q = Cancel Your decision? 2 Enter an optional description; end it with an empty line: Test revocation Reason for revocation: Key is superseded Test revocation Is this okay? (y/N) y The following key was revoked on 2015-02-10 by RSA key B2F1C0D8 Testkey 3 pub 1024R/B2F1C0D8 created: 2014-02-24 revoked: 2015-02-10 usage: SC trust: never validity: revoked The following key was revoked on 2015-02-10 by RSA key B2F1C0D8 Testkey 3 sub 1024R/98AC4DFA created: 2014-02-24 revoked: 2015-02-10 usage: E [ revoked] (1). Testkey 3 gpg save $ Now let's check that signature again: $ gpg2 --verify test.gpg gpg: Signature made Tue 10 Feb 2015 11:53:47 CET using RSA key ID B2F1C0D8 gpg: Good signature from Testkey 3 [unknown] gpg: WARNING: This key has been revoked by its owner! gpg: This could mean that the signature is forged. gpg: reason for revocation: Key is superseded gpg: revocation comment: Test revocation 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: EFF1 596F 1A68 F708 8699 579D 0815 4E55 B2F1 C0D8 $ The dates for signature and revocation are the same, but the times are reasonably far apart: $ gpg2 --export B2F1C0D8|gpg2 --list-packets :public key packet: version 4, algo 1, created 1393271747, expires 0 pkey[0]: [1024 bits] pkey[1]: [17 bits] keyid: 08154E55B2F1C0D8 :signature packet: algo 1, keyid 08154E55B2F1C0D8 version 4, created 1423566838, md5len 0, sigclass 0x20 digest algo 8, begin of digest 9c c5 hashed subpkt 2 len 4 (sig created 2015-02-10) hashed subpkt 29 len 16 (revocation reason 0x01 (Test revocation)) subpkt 16 len 8 (issuer key ID 08154E55B2F1C0D8) data: [1024 bits] [...] $ date -d 1970-01-01 +1423566838 secs UTC Tue 10 Feb 12:13:58 CET 2015 $ That's twenty minutes later. I don't see a reason for GnuPG to round to full days when it has resolution down to the second for the times the signatures (data, revocation) are made... is there? The RFC clearly states key superseded doesn't invalidate old signatures: However, if it was merely superseded or retired, old signatures are still valid. But using GnuPG 2.0.26 on Debian jessie/testing, package 2.0.26-4, I can reproduce signatures becoming invalid... what's going on? Does GnuPG not implement the RFC here or is it a bug? HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter I haven't read the RFC, so I don't know if something is define in this exact scenario, but it does sound like a bug. I imagine that recipients of all my emails for the past four years now looking at their archives will find that my messages have no valid signature, and that must be slightly disturbing. I'll read the RFC if I have time and see if something specific is defined. Thanks for testing this thuroughly. Also, thanks Daniel for confirming that the reason *is* stored. Cheers, -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text?
Re: Revoked keys and past signatures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/10/2015 12:28 PM, Peter Lebbing wrote: On 09/02/15 20:34, Daniel Kahn Gillmor wrote: the *date* of your key was superceded revocation is relevant, though. Any certifications that claim to have happened after the date of the revocation *should* be considered invalid, whereas revocations that happen before that date (but after the key creation date) should retain their validity. ... That's twenty minutes later. I don't see a reason for GnuPG to round to full days when it has resolution down to the second for the times the signatures (data, revocation) are made... is there? No The RFC clearly states key superseded doesn't invalidate old signatures: And it doesn't However, if it was merely superseded or retired, old signatures are still valid. But using GnuPG 2.0.26 on Debian jessie/testing, package 2.0.26-4, I can reproduce signatures becoming invalid... what's going on? Does GnuPG not implement the RFC here or is it a bug? No, the signature is still valid: $ gpg2 --verify test.gpg gpg: Signature made Tue 10 Feb 2015 11:53:47 CET using RSA key ID B2F1C0D8 gpg: Good signature from Testkey 3 [unknown] ^^ gpg: WARNING: This key has been revoked by its owner! gpg: This could mean that the signature is forged. gpg: reason for revocation: Key is superseded gpg: revocation comment: Test revocation 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: EFF1 596F 1A68 F708 8699 579D 0815 4E55 B2F1 C0D8 ... However you have an unknown situation wrt the validity of the key having issued the signature, you get the additional information and you need to make your own considerations as to the validity of the key at the present stage - -- - Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - Credo quia absurdum I believe it because it is absurd -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJU2fECAAoJEP7VAChXwav6ou8IAK9zhGomCj7qmpBgo2DOn0BM fLTJXb3iUvDQgzuzYi+UIrj5L+2CaCllSQlFdDkcZfaH0FbT184j39VAhhc73liR VhLqn2kSByi8OQTMjR0A7OdMCKDExgcI98jr5GF4v4KsSnwk61BYnrTtGVb7/h0L kqQwIFxwVSrbxxFouv5nG5dQeAWW26YyDpPmUDTyaF3ANuCeDEtpfE1UrI9NBRMH T6xUoHW45OxkZkodDIbTwT8FpUZpM24d5oYqO+Fmyy7JcNUW8Z+iHhFhtv+6Xvpy dPISOnkXI8hstPrFDmKB8nYleU4vhlf5LEqCcaqcnxNvbczGUPIV+1rjAcJ5+TA= =MCEY -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: HKPS issue with static build of gnupg 2.0.26: checking whether curl is usable: no
Not a gnupg problem. If the root cause for this behaviour is the failure to link against libcurl, it's either the openssl ebuild or openssl's own build system. I suspect the latter ... # equery u openssl [ Legend : U - final flag setting for installation] [: I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for dev-libs/openssl-1.0.1k: U I - - bindist : Disable EC/RC5 algorithms (as they seem to be patented) -- note: changes the ABI - - gmp : Add support for dev-libs/gmp (GNU MP library) - - kerberos : Add kerberos support - - rfc3779 : Enable support for RFC 3779 (X.509 Extensions for IP Addresses and AS Identifiers) + + static-libs : Build static versions of dynamic libraries as well - - test : Workaround to pull in packages needed to run with FEATURES=test. Portage-2.1.2 handles this internally, so don't set it in make.conf/package.use anymore + + tls-heartbeat : Enable the Heartbeat Extension in TLS and DTLS - - vanilla : Do not add extra patches which change default behaviour; DO NOT USE THIS ON A GLOBAL SCALE as the severity of the meaning changes drastically + + zlib : Add support for zlib (de)compression # gnupg ebuild config.log: ... configure:9593: x86_64-pc-linux-gnu-gcc -o conftest -O2 -march=native -pipe -fomit-frame-pointer -Wl,-O1 -Wl,--as-needed -static conftest.c -lcurl -lssl -lcrypto -lssl -lcrypto -lz 5 /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcurl.a(libcurl_la-netrc.o): In function `Curl_parsenetrc': (.text+0x3b1): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcurl.a(libcurl_la-curl_addrinfo.o): In function `Curl_getaddrinfo_ex': (.text+0x6e): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup': (.text+0x11): undefined reference to `dlopen' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup': (.text+0x24): undefined reference to `dlsym' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup': (.text+0x2f): undefined reference to `dlclose' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func': (.text+0x334): undefined reference to `dlsym' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func': (.text+0x3f2): undefined reference to `dlerror' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var': (.text+0x464): undefined reference to `dlsym' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var': (.text+0x522): undefined reference to `dlerror' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load': (.text+0x589): undefined reference to `dlopen' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load': (.text+0x5ed): undefined reference to `dlclose' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load': (.text+0x625): undefined reference to `dlerror' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_pathbyaddr': (.text+0x6b1): undefined reference to `dladdr' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_pathbyaddr': (.text+0x711): undefined reference to `dlerror' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libcrypto.a(dso_dlfcn.o): In function `dlfcn_unload': (.text+0x772): undefined reference to `dlclose' collect2: error: ld returned 1 exit status ... ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Revoked keys and past signatures
On 09/02/15 20:34, Daniel Kahn Gillmor wrote: the *date* of your key was superceded revocation is relevant, though. Any certifications that claim to have happened after the date of the revocation *should* be considered invalid, whereas revocations that happen before that date (but after the key creation date) should retain their validity. (By the way, I'm going to treat data signatures, not certifications, since I believe that was what Hugo reported) I started to think you were right and I was mistaken, but I can reproduce Hugo's scenario: $ gpg2 --verify test.gpg gpg: Signature made Tue 10 Feb 2015 11:53:47 CET using RSA key ID B2F1C0D8 gpg: Good signature from Testkey 3 [full] Note how verify-options show-uid-validity notes it is fully valid. It is signed by an ultimately trusted key. Now I revoke it: $ gpg2 --edit-key B2F1C0D8 gpg (GnuPG) 2.0.26; Copyright (C) 2013 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. Secret key is available. pub 1024R/B2F1C0D8 created: 2014-02-24 expires: 2015-02-17 usage: SC trust: never validity: full sub 1024R/98AC4DFA created: 2014-02-24 expired: 2014-03-03 usage: E [ full ] (1). Testkey 3 gpg revkey Do you really want to revoke the entire key? (y/N) y Please select the reason for the revocation: 0 = No reason specified 1 = Key has been compromised 2 = Key is superseded 3 = Key is no longer used Q = Cancel Your decision? 2 Enter an optional description; end it with an empty line: Test revocation Reason for revocation: Key is superseded Test revocation Is this okay? (y/N) y The following key was revoked on 2015-02-10 by RSA key B2F1C0D8 Testkey 3 pub 1024R/B2F1C0D8 created: 2014-02-24 revoked: 2015-02-10 usage: SC trust: never validity: revoked The following key was revoked on 2015-02-10 by RSA key B2F1C0D8 Testkey 3 sub 1024R/98AC4DFA created: 2014-02-24 revoked: 2015-02-10 usage: E [ revoked] (1). Testkey 3 gpg save $ Now let's check that signature again: $ gpg2 --verify test.gpg gpg: Signature made Tue 10 Feb 2015 11:53:47 CET using RSA key ID B2F1C0D8 gpg: Good signature from Testkey 3 [unknown] gpg: WARNING: This key has been revoked by its owner! gpg: This could mean that the signature is forged. gpg: reason for revocation: Key is superseded gpg: revocation comment: Test revocation 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: EFF1 596F 1A68 F708 8699 579D 0815 4E55 B2F1 C0D8 $ The dates for signature and revocation are the same, but the times are reasonably far apart: $ gpg2 --export B2F1C0D8|gpg2 --list-packets :public key packet: version 4, algo 1, created 1393271747, expires 0 pkey[0]: [1024 bits] pkey[1]: [17 bits] keyid: 08154E55B2F1C0D8 :signature packet: algo 1, keyid 08154E55B2F1C0D8 version 4, created 1423566838, md5len 0, sigclass 0x20 digest algo 8, begin of digest 9c c5 hashed subpkt 2 len 4 (sig created 2015-02-10) hashed subpkt 29 len 16 (revocation reason 0x01 (Test revocation)) subpkt 16 len 8 (issuer key ID 08154E55B2F1C0D8) data: [1024 bits] [...] $ date -d 1970-01-01 +1423566838 secs UTC Tue 10 Feb 12:13:58 CET 2015 $ That's twenty minutes later. I don't see a reason for GnuPG to round to full days when it has resolution down to the second for the times the signatures (data, revocation) are made... is there? The RFC clearly states key superseded doesn't invalidate old signatures: However, if it was merely superseded or retired, old signatures are still valid. But using GnuPG 2.0.26 on Debian jessie/testing, package 2.0.26-4, I can reproduce signatures becoming invalid... what's going on? Does GnuPG not implement the RFC here or is it a bug? HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: (bug?) Revoked keys and past signatures
On 2015-02-10 13:30, Kristian Fiskerstrand wrote: On 02/10/2015 01:24 PM, Peter Lebbing wrote: On 10/02/15 12:52, Kristian Fiskerstrand wrote: No, the signature is still valid: Why? The key was revoked because it was superseded or has been retired, not because it was stolen or compromised. Unless you rely on a trusted third party to provide signature stamps, signature dates can be forged. A key revocation should result in immediate questioning of all aspects of the key, as it currently does. There is no reason to assume that the signature has been forged if the key has not been compromised. Also, I see no reason why I should not be able to assign a trust to a revoked key - I might trust it even if the author revoked it as superseded: $ gpg --edit 1BFBED44 [... info on revoked key ...] gpg lsign Key is revoked. Unable to sign. I believe the reason matters. I can even sit down with the owner of the key and verify his ID and fingerprint and sign it, meaning this key belongs to this person, but was superseeded a week ago. If actually influences the validity of anything he signed up to a week ago. -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? pgp575kuUABHQ.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
moving up from 2.0.26 to 2.1.1
I've been a linux user for less than a year and the only configure/make/install I've done is for 2.0.26 and its dependencies (when I couldn't get the distro supplied package 2.0.22 to work). Now when I look at the dependencies for gnupg 2.1.1, I see that I need to upgrade libassuan to 2.2.0, libgpg-error to 1.17 and gpgme to 1.5.3. The first question I have is whether it is necessary to remove the versions I already have prior to installing the later versions ? I suppose simply installing the later version will not automatically replace the previous version ? Up to present, all updates to software have been done by the distro's 'Software updater' and this has not made me any the wiser on the procedure for manual updating. Is there a risk of having a sedimentary layer of unwanted an outdated versions accumulate on disk when updating manually ? Any and all advice will be gratefully accepted, thank you. Philip signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
status of ed25519 draft
Is there any way to see the progress of the IETF working group on the draft Werner has submitted? I noticed that the draft expires in May. In particular, I would like to know if 22 is going to be the IANA standardized Public-Key Algorithm number. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: (bug?) Revoked keys and past signatures
On Tuesday 10 February 2015 10:37:38 Hugo Osvaldo Barrera wrote: On 2015-02-10 13:30, Kristian Fiskerstrand wrote: On 02/10/2015 01:24 PM, Peter Lebbing wrote: On 10/02/15 12:52, Kristian Fiskerstrand wrote: No, the signature is still valid: Why? The key was revoked because it was superseded or has been retired, not because it was stolen or compromised. Unless you rely on a trusted third party to provide signature stamps, signature dates can be forged. A key revocation should result in immediate questioning of all aspects of the key, as it currently does. There is no reason to assume that the signature has been forged if the key has not been compromised. Also, I see no reason why I should not be able to assign a trust to a revoked key - I might trust it even if the author revoked it as superseded: $ gpg --edit 1BFBED44 [... info on revoked key ...] gpg lsign Key is revoked. Unable to sign. I believe the reason matters. I can even sit down with the owner of the key and verify his ID and fingerprint and sign it, meaning this key belongs to this person, but was superseeded a week ago. If actually influences the validity of anything he signed up to a week ago. Use gpg --lsign --expert 1BFBED44 to sign the key despite the revocation. But this won't change the validity of the key. The validity of a revoked key is (and remains for all times) revoked (as far as gpg is concerned). Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: (bug?) Revoked keys and past signatures
Am Di 10.02.2015, 13:01:17 schrieb Daniel Kahn Gillmor: I can even sit down with the owner of the key and verify his ID and fingerprint and sign it, meaning this key belongs to this person, but was superseeded a week ago. If actually influences the validity of anything he signed up to a week ago. I support this attitude. your certifications (whether local or exportable) themselves have a timestamp in them. It would be silly to certify a key and its user ID after it was revoked by the owner; you'd be claiming i believe that right now this is the correct key, which is not the case. And who says that this is the statement? The RfC? I think that faking cannot be a good idea in a crypto context. What if the signing key was created after the revocation? What would that look like? It must be possible for people who have only newer keys to make a the owner of this key is X statement. I understand the semantics of what you're trying to do, but i'm not sure that OpenPGP has syntax to represent it. I don't see any problem with the syntax. The problem is the lack of semantic definition. The next OpenPGP version should address that at any rate. Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Sign key with externalized master key
Hello,
May I ask how one would sign public keys when a master key is
stored onto an USB stick ?
I followed instructions from [1]. Now I am in the process of
announcing my key transition to all old signers *but*, as a last
test, I just tested public signature with my master key and this is
where troubles occur:
LANG=C gpg --home /Volumes/FSF/.gnupg --recv-keys A KEYID
gpg: WARNING: unsafe permissions on homedir `/Volumes/FSF/.gnupg'
gpg: external program calls are disabled due to unsafe options file permissions
gpg: keyserver communications error: General error
gpg: keyserver receive failed: General error
So what ? My USB stick is formated using extFat so permissions are
something unknown.
Do you have any way to workaround that ? Or better, USB stick storage
best practice ? My environment is very hetereogenous but I may only
sign from my OS X machine so there can be a better choice than extFat
I presume.
I did something odd as a very short temporary workaround:
umask 077; mkdir /tmp/_gpg-to-sign
gpg --home /tmp/_gnupg-to-sign --import
/Volumes/FSF/2015-02-09/{public+private}.gpg
then did my keysigning.
Thank you very much.
Footnotes:
[1] https://alexcabal.com/creating-the-perfect-gpg-keypair/
--
Sent with my mu4e
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: moving up from 2.0.26 to 2.1.1
On Tue 2015-02-10 14:09:59 -0500, Philip Jackson wrote: I've been a linux user for less than a year and the only configure/make/install I've done is for 2.0.26 and its dependencies (when I couldn't get the distro supplied package 2.0.22 to work). Now when I look at the dependencies for gnupg 2.1.1, I see that I need to upgrade libassuan to 2.2.0, libgpg-error to 1.17 and gpgme to 1.5.3. The first question I have is whether it is necessary to remove the versions I already have prior to installing the later versions ? I suppose simply installing the later version will not automatically replace the previous version ? Up to present, all updates to software have been done by the distro's 'Software updater' and this has not made me any the wiser on the procedure for manual updating. Is there a risk of having a sedimentary layer of unwanted an outdated versions accumulate on disk when updating manually ? The questions you're asking are very much the sort of thing that distributions are designed to address. What distro are you using? what version? 2.1.1 has been packaged for some distros already (as have some of these dependencies), and you might be able to save yourself a lot of pain by choosing a path with a maintainer familiar with your system :) --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: (bug?) Revoked keys and past signatures
On 10/02/15 12:52, Kristian Fiskerstrand wrote: No, the signature is still valid: $ gpg2 --verify test.gpg gpg: Signature made Tue 10 Feb 2015 11:53:47 CET using RSA key ID B2F1C0D8 gpg: Good signature from Testkey 3 [unknown] ^^ In my opinion, the signature might be /good/, but it is not /valid/. A /good/ signature is just as good as any signature from a key you downloaded off the internet. Here's the status-fd output: $ gpg2 --status-fd 1 --verify test.gpg 2/dev/null [GNUPG:] SIG_ID mIjaz0UJC1cgEmJHXntwKHhdiuI 2015-02-10 1423565627 [GNUPG:] REVKEYSIG 08154E55B2F1C0D8 Testkey 3 [GNUPG:] VALIDSIG EFF1596F1A68F7088699579D08154E55B2F1C0D8 2015-02-10 1423565627 0 4 0 1 8 00 EFF1596F1A68F7088699579D08154E55B2F1C0D8 [GNUPG:] KEYREVOKED [GNUPG:] TRUST_UNDEFINED $ Note that unfortunately 'good' and 'valid' are slightly mixed up, perhaps that's where the confusion comes from. VALIDSIGfingerprint in hex sig_creation_date sig-timestamp expire-timestamp sig-version reserved pubkey-algo hash-algo sig-class [ primary-key-fpr ] The signature with the keyid is good. This is the same as GOODSIG but has the fingerprint as the argument. Both status lines are emitted for a good signature. [...] What you'd like to see, though, is TRUST_FULLY or better: TRUST_UNDEFINED error token TRUST_NEVER error token TRUST_MARGINAL [0 [validation_model]] TRUST_FULLY [0 [validation_model]] TRUST_ULTIMATE [0 [validation_model]] For good signatures one of these status lines are emitted to indicate the validity of the key used to create the signature. Note how it says /validity of the key/. It's not ownertrust it is talking about![1] gpg: WARNING: This key has been revoked by its owner! gpg: This could mean that the signature is forged. gpg: reason for revocation: Key is superseded gpg: revocation comment: Test revocation gpg: WARNING: This key is not certified with a trusted signature! This is exactly what a superseded or retired revocation is /not/. It has not been stolen; the signature could not have been forged. The key /is/ certified with a trusted signature as I've indicated in my previous post. It's just that the key has since been revoked. The RFC clearly says this doesn't invalidate past signatures, but this message is the message you get for an invalid data signature. gpg: There is no indication that the signature belongs to the owner. No indication that the signature belongs to the owner... the exact same message you get for any invalid key you just got from somewhere. ... However you have an unknown situation wrt the validity of the key having issued the signature Why? The key was revoked because it was superseded or has been retired, not because it was stolen or compromised. If you're convinced you're not mistaken, could you please take the time to show me where this data signature from a revoked key is any different than a signature from any random invalid key? Peter. PS: I've tagged the subject line so it stands out more, since it seems like a bug to me. [1] For certifications the terminology trust makes sense, for data signatures not so much, in my opinion. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: (bug?) Revoked keys and past signatures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/02/15 13:30, Kristian Fiskerstrand wrote: Unless you rely on a trusted third party to provide signature stamps, signature dates can be forged. A key revocation should result in immediate questioning of all aspects of the key, as it currently does. Does GnuPG consciously not follow the RFC here then? Otherwise, what does this mean (RFC 4880 section 5.2.23, Reason for Revocation subpacket): An implementation SHOULD implement this subpacket, include it in all revocation signatures, and interpret revocations appropriately. There are important semantic differences between the reasons, and there are thus important reasons for revoking signatures. If a key has been revoked because of a compromise, all signatures created by that key are suspect. However, if it was merely superseded or retired, old signatures are still valid. What is the important semantic difference between Key is superseded and Key material has been compromised, if past signatures are immediately questioned? Peter. PS: Odd turn of the sentence, there are thus important reasons for revoking signatures. I wonder if they intended there are thus important reasons for handling the cases differently. - -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: (bug?) Revoked keys and past signatures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/10/2015 01:24 PM, Peter Lebbing wrote: On 10/02/15 12:52, Kristian Fiskerstrand wrote: No, the signature is still valid: Why? The key was revoked because it was superseded or has been retired, not because it was stolen or compromised. Unless you rely on a trusted third party to provide signature stamps, signature dates can be forged. A key revocation should result in immediate questioning of all aspects of the key, as it currently does. - -- - Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - Dura necessitas Necessity is harsh -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJU2fndAAoJEP7VAChXwav6LSwH/ihbdKxXt7NneEjwvSnu/HtP DJE1ihJB6z+AGe2Z8LR/YkEuvDKcxPbskmjbkVA7+7f4AX+R4pPeZBdgcpt/9SsL 06GzOeHyjkPS3tvKaJ9jHFJWXg3Vkd2++Q8+Awguh0zp+MrN/Np8b/esDsUHOLs7 qPHt0NCc7NveX8HgcS81dZkV1W6Ke1u4HijVw2TkgNuP7qRDlbTMHbrkcp96FxOq bGzVhwjHpQTEuTMnuBq1KL7hl1iATihfeMg/DtLcRXPiMvYGGSomdj9U1RcfbVCL exVNnwBkNzMXy9NGqtTzmZCXuUbtoP65oHmgz0wFzWftA/N8j2/E2yofcMoDJQQ= =F1PH -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: (bug?) Revoked keys and past signatures
On 10/02/15 13:24, Peter Lebbing wrote: If you're convinced you're not mistaken, could you please take the time to show me where this data signature from a revoked key is any different than a signature from any random invalid key? Quick correction: If you're convinced you're not mistaken, could you please take the time to show me where this data signature from a revoked, but certified key is any different than a signature from any random revoked invalid key? The key difference (heh...) is that the key has been certified with a trusted signature. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: (bug?) Revoked keys and past signatures
On Tue 2015-02-10 13:20:03 -0500, Hauke Laging wrote: your certifications (whether local or exportable) themselves have a timestamp in them. It would be silly to certify a key and its user ID after it was revoked by the owner; you'd be claiming i believe that right now this is the correct key, which is not the case. And who says that this is the statement? The RfC? I think that faking cannot be a good idea in a crypto context. What if the signing key was created after the revocation? What would that look like? It must be possible for people who have only newer keys to make a the owner of this key is X statement. I suspect this is widely held to be the semantics of the signature created on timestamp, based on the following two sections of RFC 4880 5.2.3.4. Signature Creation Time (4-octet time field) The time the signature was made. MUST be present in the hashed area. 5.2.3.10. Signature Expiration Time (4-octet time field) The validity period of the signature. This is the number of seconds after the signature creation time that the signature expires. If this is not present or has a value of zero, it never expires. The implication here is that the time of signature creation is the start of the signature validity period. I understand the semantics of what you're trying to do, but i'm not sure that OpenPGP has syntax to represent it. I don't see any problem with the syntax. The problem is the lack of semantic definition. The next OpenPGP version should address that at any rate. It sounds to me like you're asking for the standard to separate out signature creation time from signature validity start time. This is an interesting proposal, and i can see why it would make sense for this scenario. I can also see it introducing a lot of subtle bugs in what is already a very nuanced and subtle area (certificate timestamp checking; not just in OpenPGP either -- the ongoing x.509 discussions about overlapping windows of certificate validity). I'm not sure about the tradeoffs here. --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
