Re: OpenPGP card not available
On Tue, Apr 09, 2024 at 12:11:31PM +0200, Werner Koch wrote: > By default we are not using PC/SC on Linux but direct access to the > reader via USB. Now if pcscd is already running and has access to the > reader scdaemon won't be able to access the reader via USB. > > 2.2 falls back to PC/SC if it can't use the reader via USB. That explains the difference it nicely. > Either shutdown pcscd or add > > disable-ccid-driver > > to ~/.gnupg/scdaemon.conf Shutting down pcscd fixed it! But I have other software that needs pcscd to access the card, so I added "disable-ccid" to scdaemon.conf and gpg now works even though pcscd is running. Thanks for the help. Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
OpenPGP card not available
Running "gpg --card-status" with a configured Yubikey plugged in on an x86_64 Linux machine just gives me these errors when running 2.4.5: gpg: selecting card failed: No such device gpg: OpenPGP card not available: No such device However, leaving everything else the same and just running 2.2.42 (& earlier 2.2.x) gives me the output I'd expect with that command. I've tried some of the advice I've found of adding "reader-port Yubico Yubi" and "pcsc-shared" to scdaemon.conf didn't make a difference. Enabling some scdaemon logging shows this interesting bit in the log file: 2024-04-08 16:45:28 scdaemon[62168] DBG: chan_7 <- SERIALNO 2024-04-08 16:45:28 scdaemon[62168] DBG: apdu_open_reader: BAI=70202 2024-04-08 16:45:28 scdaemon[62168] DBG: apdu_open_reader: new device=70202 2024-04-08 16:45:28 scdaemon[62168] ccid open error: skip 2024-04-08 16:45:28 scdaemon[62168] DBG: chan_7 -> ERR 100696144 No such device With 2.2.42, I see this (with an actual serial number) and all works well: 2024-04-08 16:38:43 scdaemon[36563] DBG: chan_7 <- SERIALNO 2024-04-08 16:38:43 scdaemon[36563] DBG: apdu_open_reader: BAI=70202 2024-04-08 16:38:43 scdaemon[36563] DBG: apdu_open_reader: new device=70202 2024-04-08 16:38:43 scdaemon[36563] ccid open error: skip 2024-04-08 16:38:43 scdaemon[36563] DBG: chan_7 -> S SERIALNO D000 2024-04-08 16:38:43 scdaemon[36563] DBG: chan_7 -> OK ... Running "echo SERIALNO | scd/scdaemon --server" is enough. I've tried both pcsc-lite 1.9.9 and 2.0.3 without a difference. I'm not sure how to drill down to figure out further to figure out what else could be causing the failure. One obvious difference is that the working version is linked against libpthread.so.0 but the failing one is linked against libnpth.so.0, but that seems to have to do with locking which I wouldn't expect to make difference with a simple local test. I was hoping to bisect to the problem except that the 2.3 and 2.4 branches fail at their .0 versions. Does someone have a suggestion to debug further? Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
OpenPGP card not available
Running "gpg --card-status" with a configured Yubikey plugged in on an x86_64 Linux machine just gives me these errors when running 2.4.5: gpg: selecting card failed: No such device gpg: OpenPGP card not available: No such device However, leaving everything else the same and just running 2.2.42 (& earlier 2.2.x) gives me the output I'd expect with that command. I've tried some of the advice I've found of adding "reader-port Yubico Yubi" and "pcsc-shared" to scdaemon.conf didn't make a difference. Enabling some scdaemon logging shows this interesting bit in the log file: 2024-04-08 16:45:28 scdaemon[62168] DBG: chan_7 <- SERIALNO 2024-04-08 16:45:28 scdaemon[62168] DBG: apdu_open_reader: BAI=70202 2024-04-08 16:45:28 scdaemon[62168] DBG: apdu_open_reader: new device=70202 2024-04-08 16:45:28 scdaemon[62168] ccid open error: skip 2024-04-08 16:45:28 scdaemon[62168] DBG: chan_7 -> ERR 100696144 No such device With 2.2.42, I see this (with an actual serial number) and all works well: 2024-04-08 16:38:43 scdaemon[36563] DBG: chan_7 <- SERIALNO 2024-04-08 16:38:43 scdaemon[36563] DBG: apdu_open_reader: BAI=70202 2024-04-08 16:38:43 scdaemon[36563] DBG: apdu_open_reader: new device=70202 2024-04-08 16:38:43 scdaemon[36563] ccid open error: skip 2024-04-08 16:38:43 scdaemon[36563] DBG: chan_7 -> S SERIALNO D000 2024-04-08 16:38:43 scdaemon[36563] DBG: chan_7 -> OK ... Running "echo SERIALNO | scd/scdaemon --server" is enough. I've tried both pcsc-lite 1.9.9 and 2.0.3 without a difference. I'm not sure how to drill down to figure out further to figure out what else could be causing the failure. One obvious difference is that the working version is linked against libpthread.so.0 but the failing one is linked against libnpth.so.0, but that seems to have to do with locking which I wouldn't expect to make difference with a simple local test. I was hoping to bisect to the problem except that the 2.3 and 2.4 branches fail at their .0 versions. Does someone have a suggestion to debug further? Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Questions re auto-key-locate
> On Feb 15, 2022, at 2:45 PM, Andrew Gallagher wrote: > > >> On 15 Feb 2022, at 21:46, Dan Mahoney (Gushi) via Gnupg-users >> wrote: >> >> Since the debacle a few years ago with the SKS keyserver denial-of-service >> attack, the keyservers are kind of a non-starter. > > Why so? Keyservers are still around, and the ones that survived the > apocalypse are generally the ones that are better maintained. The only glitch > from a user POV is that you have to publish to both a synchronising server > and keys.openpgp.org to make sure everyone sees your updates… That's a decision I leave up to the people who *make* the key (and the software that it's signing). If they've decided not to push the key out there (and it's no longer the case that you can publish just anyone's key) I need to respect that. Right now, the decision is that our key (signed with our prior-year key) is on our website and FTP (also via https) site, and we do not assert that it's available on the keyservers. -Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Questions re auto-key-locate
Hey all, A long time ago I wrote a doc on a blog about putting PGP keys in the DNS, which has been linked to quite a bit. I also recoded make-dns-cert as a shell script so that people who want to do this but don't have access to the make-dns-cert tool (which is not built by default on some OS packages) had an option to do this. At the day job, we have a script that we use to push gpg-signed releases to our FTP server, and as part of that job, it verifies the signatures on the tarball, and will try to auto-key-locate those keys if it can't find them. Since the debacle a few years ago with the SKS keyserver denial-of-service attack, the keyservers are kind of a non-starter. And because GPG searches for keys on a tarball by keyid, not by user@domain, a keyserver is the only real retrieval method available to look up a key by keyid, which is now a non-starter. Worse still, if you know a key exists via something like DANE (dayjob makes DNS software, we like the idea of it being available via DANE), there's no way to do gpg --search via DANE, only via a keyserver. Thus, using that as a prefetch method to grab the current version of our codesign@ key into our keyring is not helpful either, unless we "faked it" by attempting to encrypt a message to that address, then discarded it. Is there another way forward? The normal things for auto-key-locate don't seem to help here. I'm open to ideas. -Dan (PS: on gnupg.org, the documentation for auto-key-locate dane says "Locate a key using DANE, as specified in draft-ietf-dane-openpgpkey-05.txt." It should probably say RFC7929 rather than referring to an I-D.) -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC FB: fb.com/DanielMahoneyIV LI: linkedin.com/in/gushi Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Ideas on raising donations for GnuPG, Gpg4win, and g10 code
I was on Amazon Smile today and noticed quite a few FOSS projects were available to select as the source of my amazon shopping proceeds. Also thought that registering gnupg.org, gpg4win.org and g10code.com in the Brave Rewards program might be an interesting way to allow GnuPG to accept small concurrency donations. There may be some legal reasons, or non profit status constraints that might prevent these organizations from accepting donations through Smile or Brave, but I thought I would go ahead and make the suggestion on the chance that it simply hadn't been considered yet. AmazonSmile: https://org.amazon.com/ BraveRewards: https://publishers.basicattentiontoken.org/ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Can I use my Microsoft Outlook S/MIME certificate with gpgsm.exe ?
Thanks, I checked the following per your advice 1. Are any of the certs ECC? No, they all appear to be RSA keys. 2. Has the org root cert been imported? I believe so, yes. There are three certs in the chain. My s/MIME cert, it's parent, and its "grandparent". Both gpgsm and the Windows Cert Manager show only three certs in the chain. The same three certs that show up in Windows Cert Manager show up in gpgsm. When I listed the cert chain with validation I got a lot of CRL errors. I tried to import the CRLs listed in the certs, but it appeared to fail. I will also not that I have not added any LDAP servers. I would prefer to be able to do the signing "offline" when I'm not on my corporate network. I also don't think my company will allow me to store password data in cleartext in the dirmngr_ldapservers.conf file. If there is anyway to encrypt this data with a master password, that would be prefered. Here's a list of commands I tried to hopefully shed some light on my config $ gpgsm --verbose --with-validation --list-chain 0x64208E9A [REDACTED]\AppData\Roaming\gnupg\pubring.kbx --- ID: 0x64208E9A Certified by ID: 0x2731A14E Certified by ID: 0x0B9BC7C1 wc -l "[REDACTED]\AppData\Roaming\gnupg\dirmngr_ldapservers.conf" 0 [REDACTED]\AppData\Roaming\gnupg\dirmngr_ldapservers.conf $ gpgsm -a --export 0x64208E9A | openssl x509 -text | grep -i http URI:[REDACTED-0x64208E9A-CRL] OCSP - URI:[REDACTED-0x64208E9A-OCSP] CPS: [REDACTED-0x64208E9A-CPS] $ gpgsm -a --export 0x2731A14E | openssl x509 -text | grep -i http $ gpgsm -a --export 0x0B9BC7C1 | openssl x509 -text | grep -i http OCSP - URI:[REDACTED-0x0B9BC7C1-OCSP] CPS: [REDACTED-0x0B9BC7C1-CSP] Explicit Text: [REDACTED-0x0B9BC7C1-ETXT] URI:[REDACTED-0x0B9BC7C1-CRL] $ dirmgr --verbose --fetch-crl [REDACTED-0x0B9BC7C1-CRL] dirmngr[76084]: permanently loaded certificates: 253 dirmngr[76084]: runtime cached certificates: 0 dirmngr[76084]:trusted certificates: 253 (252,0,0,1) dirmngr[76084]: update times of this CRL: this=20190226T00 next=20190324T235959 dirmngr[76084]: locating CRL issuer certificate by authorityKeyIdentifier dirmngr[76084]: error checking validity of CRL issuer certificate: No value dirmngr[76084]: crl_parse_insert failed: No value dirmngr[76084]: processing CRL from '[REDACTED-0x0B9BC7C1-CRL]' failed: No value $ dirmgr --verbose --fetch-crl [REDACTED-0x64208E9A-CRL] dirmngr[75900]: permanently loaded certificates: 253 dirmngr[75900]: runtime cached certificates: 0 dirmngr[75900]:trusted certificates: 253 (252,0,0,1) dirmngr[75900]: update times of this CRL: this=20190314T170848 next=20190317T170848 dirmngr[75900]: locating CRL issuer certificate by authorityKeyIdentifier dirmngr[75900]: Note: non-critical certificate policy not allowed dirmngr[75900]: error checking validity of CRL issuer certificate: No value dirmngr[75900]: crl_parse_insert failed: No value dirmngr[75900]: processing CRL from '[REDACTED-0x64208E9A-CRL]' failed: No value $ gpgsm --verbose --with-validation --list-chain 0x64208E9A [REDACTED]\AppData\Roaming\gnupg\pubring.kbx --- ID: 0x64208E9A S/N: [REDACTED] Issuer: [REDACTED] Subject: [REDACTED] aka: [REDACTED] validity: [REDACTED] key type: 2048 bit RSA key usage: digitalSignature keyEncipherment ext key usage: emailProtection policies: 2.16.840.1.113733.1.7.23.2:N: fingerprint: [REDACTED] [Note: non-critical certificate policy not allowed] [checking the CRL failed: No value] [certificate is bad: No value] Certified by ID: 0x2731A14E S/N: [REDACTED] Issuer: [REDACTED] Subject: [REDACTED] validity: [REDACTED] key type: 2048 bit RSA key usage: certSign crlSign policies: 2.16.840.1.113733.1.7.23.2:N: chain length: 0 fingerprint: [REDACTED] [Note: non-critical certificate policy not allowed] [certificate is bad: No value] Certified by ID: 0x0B9BC7C1 S/N: [REDACTED] Issuer: [REDACTED] Subject: [REDACTED] validity: [REDACTED] key type: 2048 bit RSA chain length: none fingerprint: [REDACTED] [certificate is bad: No value] $ echo hi | gpgsm --sign --armor --default-key 0x64208E9A \ > --disable-crl-checks --disable-policy-checks --verbose \ > --audit-log alog.txt gpgsm: certificate is good gpgsm: validation model used: shell gpgsm: error creating signature: No value $ cat alog.txt * Data signing succeeded: No * Data available: No * Gpg-Agent usable: Yes On Thu, Mar 14, 2019 at 8:20 AM Werner Koch wrote: > > On Wed, 13 Mar 2019 03:03, dkbry...@gmail.com said: > > > $ echo hi | gpgsm --sign -
Can I use my Microsoft Outlook S/MIME certificate with gpgsm.exe ?
So I work for a large company that has their own internal CA and maintains their own set of S/MIME certificates. We periodically have to re-enroll in S/MIME and import the certificate into Microsoft Outlook to have encrypt / sign functionality. This time when I enrolled for my recent certificate, I went ahead and added my S/MIME to gpgsm. Import looked good (I guess), but I'm unable to sign. I've looked at the public and private keys and it looks like the whole chain is imported. Kleopatra also has them showing up in the right hierarchical order. I apologize for clipping some of my command output but our company is rather paranoid about publicly publishing internal key data, even public key data. $ gpgsm --version --verbose gpgsm (GnuPG) 2.2.11 libgcrypt 1.8.4 libksba 1.3.5 $ gpgsm --import sMIME.pfx gpgsm: total number processed: 4 gpgsm: unchanged: 3 gpgsm: secret keys read: 1 gpgsm: secret keys unchanged: 1 $ echo hi | gpgsm --sign --armor --default-key 0x64208E9A --disable-crl-checks --disable-policy-checks gpgsm: error creating signature: No value ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking changes
On Tue, May 22, 2018 at 10:24 PM, Fiedler Roman wrote: >> https://en.wikipedia.org/wiki/GNU_Privacy_Guard >> already give an end-of-life date for 2.0, but none for 1.4. >> And since Ubuntu 16.04 includes 1.4, there are likely >> to still be a few vocal 1.4 users out there. >> >> How about announcing an end-of-life date for 1.4 that >> is in the future (say, by 3 to 6 months)? > > In my opinion, just "announcing" EOL (especially with such a short notice) is > quite bad practice for products aiming to be used in production setups also. > This quite negatively affects trust into the product as your costs may change > quite rapidly. You might argue, that companies should be used to paying for > things. They are, but they want to have some planning when they are expected > to pay. Would you like your car manufacturer announce, that your car is not > secure any more in 6 month and that you have to pay for non-standard > maintenance, if you still want to operate it securely? > > Apart from that: some companies using open source software are non-profit > companies, like mine in research business. If our software strategy is bad - > e.g. because upstream forces us suddenly to switch/pay, where we did not > expect it - research funding money (mostly from the society) has to be used > to keep the projects running. > > So when talking about EOL, gpg community should consider writing down a > consistent EOL strategy, similar to those of Ubuntu, Linux kernel or others > or something like I tried to argue for in the middle of > https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060539.html Yes, exactly! And taking a look at https://www.ubuntu.com/info/release-end-of-life, one sees that Ubuntu 12.04 and 14.04 have a final end of life in about February 2019; 16.04 lives until Feb 2021. To be kind to enterprise customers, GnuPG could pick one of those two dates as the EOL for 1.4. Matching 16.04's EOL would strand the fewest users, but even just matching 14.04's would make sense to a lot of people. Also, gnupg.org should add a web page like https://www.gnupg.org/release-end-of-life that lays out the EOL for all released versions; the only one with a clear EOL is 2.0.x, and that's a bit buried in text on the front page. - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking changes
Lessee... https://en.wikipedia.org/wiki/GNU_Privacy_Guard already give an end-of-life date for 2.0, but none for 1.4. And since Ubuntu 16.04 includes 1.4, there are likely to still be a few vocal 1.4 users out there. How about announcing an end-of-life date for 1.4 that is in the future (say, by 3 to 6 months)? That would avoid poking classic users in the eye too hard, and give time for them to get used to the idea. - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Don't Panic.
Thanks for the heads up! (The eff alert only suggests disabling tools that *automatically* decrypt messages, Stumbling around a bit on the net, this sounds like a rehash of https://sourceforge.net/p/enigmail/bugs/226/ Anyway, if you have a checkbox for 'automatically decrypt', you might consider unticking it.) - Dan On Mon, May 14, 2018 at 12:27 AM, Robert J. Hansen wrote: > [taps the mike] > > Hi. I maintain the official GnuPG FAQ. So let me start off by > answering a question that is certainly about to be asked a lot: "Should > we be worried about OpenPGP, GnuPG, or Enigmail? The EFF's advising us > to uninstall it!" > > https://www.eff.org/deeplinks/2018/05/attention-pgp-users-new-vulnerabilities-require-you-take-action-now > > Werner saw a preprint of this paper some time ago. I saw it recently. > Patrick Brunschwig of Enigmail saw it. None of us are worried. Out of > respect for the paper authors I will skip further comment until such > time as the paper is published. > > It would've been nice if EFF had reached out to us for comment, rather > than apparently only talking to the paper authors. We hope they'll > reach out next time. > > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How can we utilize latest GPG from RPM repository?
On Wed, Feb 21, 2018 at 10:22 PM, Ben McGinnes wrote: >> And when you're on those certified, curated systems, you have >> access to tools like >> https://www.open-scap.org/resources/documentation/make-a-rhel7-server-compliant-with-pci-dss/ >> to help make sure you're in compliance, I think. > > open-scap.org is a RedHat service > and most likely only supplied to RHEL customers seeking PCI-DSS > compliance along with direct support via their service contract. https://www.open-scap.org/download/ shows they provide an open source tool which is in repositories for four redhat-ish distros and two debian-ish distros; on Ubuntu, I was able to walk down the path of using it a bit, looks a bit rusty, but see https://github.com/OpenSCAP/scap-security-guide So it doesn't seem to be RHEL-only. (They have a value-added tool that is, of course.) - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How can we utilize latest GPG from RPM repository?
On Tue, Feb 20, 2018 at 10:16 PM, Ben McGinnes wrote: > On Sat, Feb 17, 2018 at 05:06:54PM -0600, helices wrote: >> I will probably never understand why wanting to run the most current >> version of gnupg on a plethora of servers is controversial. >> >> Nevertheless, the two (2) greatest reasons are: >> >>1. PCI DSS v3.2 >>2. PCI DSS compliance audits > > Ah, now *this* is a pertinent fact that would've helped at the > beginning of the thread and the fact that it wasn't is a clear > demonstration of a tangential point I made further along about getting > people to step back from their drilled in focus so we can identify the > actual needs. > > Because these two lines explain *precisely* why you need something like > RHEL or CentOS (certified systems to go with the auditing) *and* > updated crypto. And when you're on those certified, curated systems, you have access to tools like https://www.open-scap.org/resources/documentation/make-a-rhel7-server-compliant-with-pci-dss/ to help make sure you're in compliance, I think. I suspect that kind of approach would make passing audits a lot easier than building the latest gnupg release yourself... and is less likely to break things. - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Using GnuPG when switching users
I'd love to have gone to 2.2 but getting GnuPG to work on Solaris is extremely difficult. We tried compiling from source, but hit several roadblocks. Looking online, several others have reported the same issues, but have had no resolution. I messaged this group, but unfortunately, none of the suggestions worked. In the end, our admins found an old packaged version of v2 on an open source for Solaris repository. The workaround was to make the virtual device terminal of the original user accessible to the su user who was creating the keys. This is a security hole that we're not happy with, but it was only temporary as we don't require an interactive passphrase following key creation. On 1 February 2018 at 05:00, Daniel Kahn Gillmor wrote: > On Mon 2018-01-29 15:44:56 +1300, Dan Horne wrote: > > Has someone got a workaround? I need to be able to use "su" as we are not > > allowed to log into the user directly. I'm also stuck with Solaris and > the > > specified version of GnuPG > > the problem you're running into is that pinentry is unable to prompt you > for a password. > > as a workaround, you could create your own pinentry that provides a > password, or that can prompt you in some other way. You might be > interested in some dummy pinentry implementations: > >https://dev.gnupg.org/source/gnupg/browse/master/tests/fake-pinentries/ > > For an actual fix, you've got quite a set of constraints here, and they > might just mean that you cannot solve the problem without a workaround. > > Please note that the 2.0.x branch of GnuPG is no longer supported by the > project. > > I *strongly* recommend that you try to get the 2.2.* branch installed > and then you'll be able to use the loopback pinentry-mode. And you'll > be running supported software. > > --dkg > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
[no subject]
Hi I'm using GnuPG 2.0.29 on Solaris. This specific version is being used because it's the only one we could get installed and working. I'm trying to generate keys from a user I have su'd to, but I get the following error: gpg-agent[23024]: command get_passphrase failed: Permission denied gpg: problem with the agent: Permission denied gpg: Key generation canceled. I believe that thus occurs because when pinentry-curses is invoked by gpg-agent, the tty is owned by the original user I logged into via SSH, not the user I switched to via su. I've seen various workarounds online, but most are relevant to GNU/Linux, not Solaris (e.g. run the "script" command with the -c option, which doesn't exist on Solaris). Others have suggested using the loopback pinentry-mode, which doesn't seem to exist in version 2.0.29 of gpg-agent , as far as I can tell. Has someone got a workaround? I need to be able to use "su" as we are not allowed to log into the user directly. I'm also stuck with Solaris and the specified version of GnuPG Thanks ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Using GnuPG when switching users
Hi I'm using GnuPG 2.0.29 on Solaris. This specific version is being used because it's the only one we could get installed and working. I'm trying to generate keys from a user I have su'd to, but I get the following error: gpg-agent[23024]: command get_passphrase failed: Permission denied gpg: problem with the agent: Permission denied gpg: Key generation canceled. I believe that thus occurs because when pinentry-curses is invoked by gpg-agent, the tty is owned by the original user I logged into via SSH, not the user I switched to via su. I've seen various workarounds online, but most are relevant to GNU/Linux, not Solaris (e.g. run the "script" command with the -c option, which doesn't exist on Solaris). Others have suggested using the loopback pinentry-mode, which doesn't seem to exist in version 2.0.29 of gpg-agent , as far as I can tell. Has someone got a workaround? I need to be able to use "su" as we are not allowed to log into the user directly. I'm also stuck with Solaris and the specified version of GnuPG ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
On Sat, Jan 20, 2018 at 4:08 PM, Todd Zullinger wrote: > I think that's https://dev.gnupg.org/T2290 Thanks. Say, anyone know how to get bug tracker problems resolved? Somehow my email address there lacks a dot before .com, so I can't get confirmation emails. - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
On Thu, Jan 18, 2018 at 7:58 PM, Dan Kegel wrote: >> The keys referred to via signed-by are the only acceptable keys for the >> associated apt repo. >> >> does that make sense? > > That'd be great if it worked. Since it's hard to explain what's broken > without a simple script showing exactly what I'm doing, let's just > hold that thought until I post one. I spent a little while cleaning up my script and found the problem, whew! Here's part of the log: + gpg2 -q --pinentry-mode loopback --passphrase --personal-digest-preferences SHA256 --gen-key gpg.in.tmp + gpg2 --armor --export temp-r...@example.com ... + sudo GNUPGHOME=/tmp/obs_localbuild_gpghome_dank.tmp APT_CONFIG=/home/dank/src/obs/foo.tmp/etc/apt.conf apt-get update ... Preparing to exec: /usr/bin/apt-key --quiet --readonly --keyring /tmp/obs_localbuild_keyrings_dank.tmp/keyrings/localhost.gpg verify --status-fd 3 /tmp/apt.sig.nD3tum /tmp/apt.data.OVJLiX Read: [GNUPG:] ERRSIG 505A301EE37484C6 1 8 01 1516484740 9 Got ERRSIG Read: [GNUPG:] NO_PUBKEY 505A301EE37484C6 Even with apt debug logging on, that wasn't enough to make the problem obvious. I had to add exec 2> /tmp/apt-key.log.$$ set -x to the top of /usr/bin/apt-key. Grepping for that key in /tmp/apt-key*, I found + gpgv --homedir /tmp/tmp.oM7RZ707db --keyring /tmp/obs_localbuild_keyrings_dank.tmp/keyrings/localhost.gpg --ignore-time-conflict --status-fd 3 /tmp/apt.sig.nD3tum /tmp/apt.data.OVJLiX gpgv: Signature made Sat Jan 20 13:45:40 2018 PST using RSA key ID E37484C6 gpgv: [don't know]: invalid packet (ctb=2d) gpgv: keydb_search failed: invalid packet gpgv: Can't check signature: public key not found Well, well. That 'invalid packet' appears to be a telltale sign of using --armor where one shouldn't, and looking at my first log, you can see a --armor. Removing it made everything happy. So this was a case of a) dumb user and b) poor diagnostics from apt. Also, now that I've ripped out all gpg1 support from my script, I realize that gpg-agent is nearly well behaved. Only possible rough spots I ran into were: - having to enable pinentry (ubuntu 16.04's gpg is old) - not knowing a clean way to tidy up an old gnupghome and its agent without hanging if the agent is missing - the gpg man page says --dearmor isn't very useful. I beg to differ :-) - might save time and anguish if apt-key (and thus gpg[v]?) accepted armored keyrings even if filename ends in .gpg Thanks for the encouragement. All's well that ends well. I'm sure I'll trip over my shoelaces again soon enough! - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
On Thu, Jan 18, 2018 at 7:52 PM, Daniel Kahn Gillmor wrote: > if this is the only thing happening, apt will indeed fail, because it > has never heard of the "new key" that was just created -- why should it > accept signatures from that new key? > > how are you configuring the target system to point to the repo? how are > you telling it where to find the key? By installing my package, which drops the key into /usr/share/keyrings and creates the lists.d entries with signed-by. That ought to suffice, I gather, but I'm tripping over shoelaces somewhere. > this looks strange to me -- you seem to be using a --keyring that is > *inside* the GNUPGHOME that you've set > (/tmp/obs_localbuild_gnupghome_dank.tmp/). > > that GnuPG homedir is really not part of the GnuPG API contract -- and > anything you put in that homedir could potentially be overwritten by > GnuPG itself. How is > /tmp/obs_localbuild_gpghome_dank.tmp/keyrings/localhost.gpg being > generated? It's just a regression test script. I'm cleaning it up and will post it once it's legible and avoids sins like that. > The keys referred to via signed-by are the only acceptable keys for the > associated apt repo. > > does that make sense? That'd be great if it worked. Since it's hard to explain what's broken without a simple script showing exactly what I'm doing, let's just hold that thought until I post one. - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
On Wed, Jan 17, 2018 at 8:58 PM, Dan Kegel wrote: > Here's the bit where it explodes, > > + sudo GNUPGHOME=/tmp/obs_localbuild_gpghome_dank.tmp > APT_CONFIG=/home/dank/src/obs/foo.tmp/etc/apt.conf apt-get -q -q > update > inside VerifyGetSigners > Preparing to exec: /usr/bin/apt-key --quiet --readonly --keyring > /tmp/obs_localbuild_gpghome_dank.tmp/keyrings/localhost.gpg verify > --status-fd 3 /tmp/apt.sig.UbNAaM /tmp/apt.data.5w6fyj > Read: [GNUPG:] ERRSIG 77D1F0D4EC3422C4 1 8 01 1516232802 9 > Got ERRSIG > Read: [GNUPG:] NO_PUBKEY 77D1F0D4EC3422C4 > Got NO_PUBKEY One little clue: apt evidently runs apt-key as user _apt, and /tmp/obs_localbuild_gpghome_dank.tmp/ is owned by me, with permissions 700. So apt-key can't read it. Whee! And if I try creating it with permissions 755, gpg complains about unsafe permissions. I'm still stuck in a twisty maze of little passages, all different. I probably should boil down my test to a simple linear script so I can ask for help properly... - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
On Wed, Jan 17, 2018 at 5:20 PM, Daniel Kahn Gillmor wrote: > > - The package depends on debian-archive-keyring (to leverage > > the web of trust as suggested in 'man secure-apt') > > (itym 'man apt-secure', right?) right. > if you're expecting ubuntu (or any other non-debian) users to install > this, then you're actually increasing their attack surface Correct. Glad to hear it's a crazy idea, happy to drop it, just need to understand how trust is established, and how to use the tools. > what i'm not hearing is an explicit example of how you are using gpg -- > as the archive maintainer, surely you manage the archive itself on a > system of your choice. for me, that would be a debian stable system, > with reprepro or something like that, which should already know how to > call out to gpg. > > as the developer of the foobar-archive package, you shouldn't need to > invoke gpg at all in your package build scripts other than just --import > and --export, which should be pretty standard across all versions of > gpg. Does one even need --import and --export while building foobar-archive; aren't the thing being imported and the thing being exported the same format? Just ferry active-keys/foobar-archive.gpg straight into /usr/share/keyrings/foobar-archive.gpg? (I saw a note about stripping off trust packets, since they're less portable. Wonder if that's related.) > You may also be interested in https://bugs.debian.org/861695, fwiw. Yes, I read that earlier with interest. Happy to be chatting with a grandmaster, as it were. What I am missing is how dropping a key into /usr/share/keyrings, and then pointing to it with signed-by=, actually establishes trust. I mean, it makes sense and all, but when I write a regression test script that : - sets GNUPGHOME to an empty directory - generates a key - creates a repo using reprepro signed by that key - creates a dummy package - adds it to the repo - tries to access the repo with 'apt-get update' it says the repo key is bad. Such a script is long enough than a secure apt beginner like me is unlikely to be able to get it right quickly. Here's the bit where it explodes, with debugging prints enabled: + sudo GNUPGHOME=/tmp/obs_localbuild_gpghome_dank.tmp APT_CONFIG=/home/dank/src/obs/foo.tmp/etc/apt.conf apt-get -q -q update inside VerifyGetSigners Preparing to exec: /usr/bin/apt-key --quiet --readonly --keyring /tmp/obs_localbuild_gpghome_dank.tmp/keyrings/localhost.gpg verify --status-fd 3 /tmp/apt.sig.UbNAaM /tmp/apt.data.5w6fyj Read: [GNUPG:] ERRSIG 77D1F0D4EC3422C4 1 8 01 1516232802 9 Got ERRSIG Read: [GNUPG:] NO_PUBKEY 77D1F0D4EC3422C4 Got NO_PUBKEY So I'm forgetting something important, like avoiding breaking things when I set up an isolated GNUPGHOME or apt config, or forgetting to mark the key I just generated as trusted, or not understanding how apt-key works, or just plain being dumb. My next move is probably reading apt-key and trying to understand it. Alternately, I could try ripping out all the gpg1 support in my scripts. That probably won't help, but would be satisfying :-) - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
On Tue, Jan 16, 2018 at 8:31 PM, Daniel Kahn Gillmor wrote: > On Tue 2018-01-16 20:10:38 -0800, Dan Kegel wrote: > > When I try to use gpg to manipulate secure apt repositories in the > > real world, my head explodes. > > hi there! what kind of manipulation are you doing of secure apt > repositories with gpg? > > are you talking about signing the repo as an author? or about > configuring for a client? or distributing public keys for the repo? or > about verifying signatures as a client? Yes to all four questions. Here's the user story. - I maintain a secure apt repository at pkgs.foobar.com following best practices in https://wiki.debian.org/DebianRepository/UseThirdParty - the key that signs my repository is trusted by debian developers in the pgp web of trust - To my users, I send via a trusted offline mechanism a copy of a package foobar-archive.deb - When they install that package, it installs the files /usr/share/keyrings/foobar-archive.gpg, and /etc/apt/sources.list.d/foobar-archive.list - The latter file's entries say signed-by=/usr/share/keyrings/foobar-archive.gpg - The package depends on debian-archive-keyring (to leverage the web of trust as suggested in 'man secure-apt') - My users are happy that simply installing one package establishes trust and lets them apt-get from my repo with no pesky errors from ubuntu 17.10 about my server having an invalid or untrusted signature - Updates to foobar-archive are delivered via secure apt. So much magic. It took me a while to figure that path out, and I'm still not quite sure I've got it right, still working on getting my regression tests to pass. There don't seem to be a wealth of accurate examples that are both kosher and up to date. Most of my angst comes from having to come up two learning curves simultaneously with tools that are used by fairly small communities and thus have some rough edges still (debian packaging and gpg commandline tools), and have lots of stale stories out on the web about how to work around problems that no longer exist. I also have to support a range of versions of gpg, can't insist on the latest. Happily, in preparation for supporting Ubuntu 17.10, I verified that I can drop support for versions of gpg and apt older than the ones in Ubuntu 16.04. While my foobar-archive.deb may seem superficially similar to debian-archive-keyring.deb, the latter does things in its postinstall step that establish trust at the system level in a way that doesn't seem like a good example for third party apt repositories to use as an example. That package is not to be confused with the similarly named debian-keyring package, which is completely kosher and just installs key(ring)s into /usr/share/keyrings, but does not of itself establish trust. - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Will gpg 1.x remain supported for the foreseeable future?
On Tue, Jan 16, 2018 at 7:37 PM, Robert J. Hansen wrote: > * it's not going away in the near future > * we know people like to use it for servers > * it's a lot of work to keep two codebases going > * new crypto, like ECC, will not be backported to 1.4 > * new features will probably not be backported > * if you need 1.4 support, contact g10 Code GmbH Thanks. When I try to use gpg to manipulate secure apt repositories in the real world, my head explodes. I'm sure it will all seem reasonable after I figure things out. I've only been at it off and on for a couple years. - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Will gpg 1.x remain supported for the foreseeable future?
Hey all, I'm starting to suspect that using version 2.x of gnupg is simply not a good idea when writing shell scripts that have to run unattended and not touch system keychains or agents. I worked hard to jump through hoops to use version 2 in such an environment, but then I ran into the fact that even the latest apt from debian does not support version 2's keybox format, so I had to drop back to gpg version 1 anyway. Is version 1 going to remain available, I hope? Version 2 simply seems a poor fit for scripting. Thanks, Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPGv2 & 'pinentry' on Linux w/ remote access
On Tue, Nov 7, 2017 at 5:45 AM, Sander Smeenk via Gnupg-users wrote: > Could you elaborate on the 'why' part of this enforced pinentry usage > with GnuPG? It wasn't mandatory in 1.x, now it's forced on us. > > Where did that come from? > What problem did it solve? I'm curious, too. It sure makes scripting hard. - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Verify that the file is from who I expect it to be from
Thanks. I exported my keys to ~/.gnupg/trustedkeys.gpg. I tried gpgv2 but got the following bash-3.2$ gpgv2 declaration.pgp gpgv: verify signatures failed: Unexpected error Adding --verbose did not affect this (Note this is a OpenCSW install) However, if I simply decrypt the file I get confirmation of the signature bash-3.2$ gpg2 --output declaration.txt --decrypt declaration.pgp gpg: encrypted with 2048-bit RSA key, ID C0F7C32A, created 2017-10-26 "" gpg: Signature made Mon Oct 30 13:04:26 2017 NZDT using RSA key ID 0A5F3B0F gpg: Good signature from "" [ultimate] On 28 October 2017 at 00:20, Werner Koch wrote: > On Fri, 27 Oct 2017 06:01, dan.ho...@redbone.co.nz said: > > > gpg2 --verify-sign > > Verification against a set of known keys is done using gpgv > > gpgv FILE > > which uses ~/.gnupg/trustedkeys.gpg. To specifiy another file with keys > you use > > gpgv --keyring KEYRING FILE > > here is how we do this when building GnUPG using the Speedo scripts: > > if ! $GPGV --keyring "$distsigkey" swdb.lst.sig swdb.lst; then > echo "list of software versions is not valid!" >&2 > exit 1 > fi > > This is from gnupg/build-aux/getswdb.sh. To create the file with the > keys you can do this: > > gpg --export --export-options export-minimal FPR1 FPR2 FPR2 > >trustedkeys.gpg > > Do _not_ use --armor. --export-options is not really required but > strips down the size of the key. > > > @Rob: Shouldn't we mention gpgv in the FAQ? > > > Shalom-Salam, > >Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Verify that the file is from who I expect it to be from
Yes - that's what my OP meant - Verifying the key. But I'm hoping to avoid greping the output. What I'd love to do is provide the key I want verified and for GnuPG to confirm e.g. something like the following would be fab: gpg2 --verify-sign On 27 October 2017 at 15:08, Antony Prince wrote: > You need to verify the key that signed it. A valid signature means > nothing. A malicious actor could sign any message or days with a valid, > verifiable key and send it to you. The heart of the matter is the key that > signed it. Gnupg tells you which key signed the data, usually by long key > ID IIRC. You have to make sure the key that signed the data is the key that > you expect, basically. If you need something more in-depth, there are many > more qualified individuals to assist on the list. > > On October 26, 2017 7:52:33 PM EDT, Dan Horne > wrote: >> >> Hi all >> >> maybe I'm missing something, but how do I verify not only that an >> encrypted file is signed, but that it is signed by the party I expect to >> have signed it? In other words, if two parties can supply a file with the >> same name I want to make sure that when I think I'm dealing with a file >> from party A, it is actually signed by party A. At the the moment, when I >> decrypt the file, it seems to simply be checking that the signature is >> valid. >> >> >> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Verify that the file is from who I expect it to be from
Thanks - I get the line saying "good signature" i n my message, but are you saying that I have to grep the output for the message and the email address of the encryptor? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Verify that the file is from who I expect it to be from
Hi all maybe I'm missing something, but how do I verify not only that an encrypted file is signed, but that it is signed by the party I expect to have signed it? In other words, if two parties can supply a file with the same name I want to make sure that when I think I'm dealing with a file from party A, it is actually signed by party A. At the the moment, when I decrypt the file, it seems to simply be checking that the signature is valid. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Automating and integrating GPG
On Mon, Sep 18, 2017 at 11:45 AM, Grzegorz Kulewski wrote: > I am working on a project (in Python and bash) that requires me to use GPG in > "headless mode" to generate keys and edit OpenPGP smartcard (to set some > properties and transfer some of the generated keys). This includes > transfering any passwords and PINs from my program to GPG, instead of > requiring user to enter them using pinentry. > > I wonder what method of integration of GPG with such project is best, most > future-proof and recommended and are there any other advices you may give me? Good question. I wrote a bit about doing that in shell scripts, see https://lists.gnupg.org/pipermail/gnupg-users/2017-April/058158.html It's challenging to make it both future- and past- proof, as gpg keeps changing. What range of Linux distributions / versions of gpg do you need to support? The new requirement for the agent is very challenging, and should not be taken lightly. You may need to expose the agent concept to your program; a transparent wrapper may not be possible. I keep running into problems with this. https://github.com/Oblong/obs/ has my ugly code, and an automated test that sometimes fails on slow systems like raspberry pi because of my poor transparent wrapper around the gpg agent. It is somewhat obscured by site-specific stuff (e.g. it uses gpg via apt). I could try to do a clean demo without apt sometime if that would be helpful. - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Automating and integrating GPG
On Mon, Sep 18, 2017 at 2:45 PM, Daniel Kahn Gillmor wrote: > GnuPG upstream developers tend to recommend the use of GPGME for system > integration projects that require a stable interface. dpkg does that, but it doesn't help people trying to automate dpkg :-) - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
"Insecure memory" (yes setuid set) and "get_passphrase failed"
Hi. I'm trying to get GnuPG working on Solaris 10 Our Unix administrator installed the CSW package. I'm trying to create my key: $ gpg2 --gen-key However at the time it comes to generate the secret key I get: You need a Passphrase to protect your secret key. Warning: using insecure memory! gpg-agent[10073]: command get_passphrase failed: End of file gpg: problem with the agent: End of file gpg: Key generation canceled. Regarding the warning, the recommended response I found via Internet search was: # chmod u+s /path/to/gpg This was done, but didn't affect the warning: $ ls -l /opt/csw/bin/gpg2 -r-sr-xr-x 25 root bin12252 Jul 25 2016 /opt/csw/bin/gpg2 Regarding the passphrase, I've made sure that pinentry is in my path: $ which pinentry /opt/csw/bin/pinentry Which is a symbolic link to pinentry-curses $ ls -l /opt/csw/bin/pinentry-curses -rwxr-xr-x 1 root bin58004 Jul 11 2011 /opt/csw/bin/pinentry-curses It still doesn't work After a bit more Googling, I tried adding the following to my gpg.conf file, but it caused a syntax error: pinentry-program /opt/csw/bin/pinentry-curses Any advice appreciated Thanks Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Newbie can't get --passphrase option to work
On Tue, May 16, 2017 at 12:31 AM, Peter Lebbing wrote: > You should also ask yourself what the purpose of the passphrase is other > than to make your life difficult > You should probably just remove the passphrase from the key. That way > any decryption or signature will just succeed without jumping through > hoops to pass the passphrase to GnuPG. That wasn't my experience. I used keys with no passphrase, and *still* had to use loopback (and jump through other hoops) to get gpg to work unattended. https://lists.gnupg.org/pipermail/gnupg-users/2017-April/058158.html https://lists.gnupg.org/pipermail/gnupg-users/2017-April/058162.html describe my travails. It was several days of learning curve. In fairness, I needed a solution that worked with all versions of gpg that shipped with any LTS version of ubuntu, not just the current release, which made things a bit harder. - Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Newbie can't get --passphrase option to work
Did you see my walkthrough of all the problems I ran into while getting gpg to not prompt? https://lists.gnupg.org/pipermail/gnupg-users/2017-April/058158.html https://lists.gnupg.org/pipermail/gnupg-users/2017-April/058162.html That's for Linux, but it might still have a trick you're missing. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Unattended use of gpg across a wide range of gpg versions, Ubuntu edition. --debug-quick-random taking evasive action.
addendum: demo of how to delete a key unattended with gpg2
Documented in earlier thread,
http://marc.info/?l=gnupg-users&m=146287358008663&w=2
-- snip --
#!/bin/sh
# Script to demonstrate unattended creation, export, and deletion of a
secret key with gpg 2.x
set -ex
cat > test-script.sh << "_EOF_"
set -e
set -x
passphrase=""
gpg --batch --passphrase "$passphrase" --quick-gen-key 'test user
'
gpg --batch --passphrase "$passphrase" --pinentry-mode loopback
--export-secret-key --armor 'test user ' > key.dat
# 1st fingerprint is for the primary, 2nd is for the secondary?
fingerprint=$(gpg -k --with-colons t...@example.org | awk -F: '/^fpr:/
{print $10}' | head -n 1)
gpg --batch --passphrase "$passphrase" --pinentry-mode loopback --yes
--delete-secret-and-public-key $fingerprint
_EOF_
chmod +x test-script.sh
rm -rf /tmp/gpgtest-*
export GNUPGHOME=$(mktemp -d /tmp/gpgtest-XXX.tmp)
echo "allow-loopback-pinentry" > $GNUPGHOME/gpg-agent.conf
gpg-agent --daemon ./test-script.sh
rm -rf $GNUPGHOME
-- snip --
On Sat, Apr 29, 2017 at 9:14 PM, Dan Kegel wrote:
> tl;dr: anyone know what's up with --debug-quick-random? Also, handy
> script for unattended key generation across many versions of gpg.
>
> Hi all. This topic has been beaten to death on many forums and in many
> bug reports, but here's a user report from the field that sums up what
> works. It's mostly just stitching together known workarounds, plus
> one little mystery
> with --debug-quick-random in gpg 2.1.15 (the one on Ubuntu 17.04).
> I'll list the problems, then at the bottom show the full solution I'm using.
>
> I'm writing a test script that uses gpg, so I reviewed
> https://www.gnupg.org/documentation/manuals/gnupg/Unattended-Usage-of-GPG.html
> but it doesn't quite handle all the situations I ran into.
> This kind of test script has to satisfy requirements like:
> - work on current OS as well as last few LTS releases
> - use the OS's default gpg
> - work in both interactive and headless situations
> - leave the user's normal environment unchanged
> - work even in deeply nested directories
> That means I can't follow some of the advice in the manual (e.g. "use
> GPGME" or "use --quick-addkey").
>
> For the purposes of testing, let's say I want to generate a key with the
> command
>gpg --gen-key
> for use with apt on an Ubuntu 17.04 desktop, as well as in freshly
> installed headless older systems.
> (For instance, containers created with the commands
> lxc-create -n ubu1204 -t download -- --dist ubuntu --release precise
> --arch amd64
> lxc-create -n ubu1404 -t download -- --dist ubuntu --release trusty
> --arch amd64
> lxc-create -n ubu1604 -t download -- --dist ubuntu --release xenial
> --arch amd64
> lxc-create -n ubu1704 -t download -- --dist ubuntu --release zesty
> --arch amd64 )
> Easy, right?
>
> Challenges and solutions I ran into, rearranged in a less embarassing
> order than I ran into them:
>
> 0. Googling for solutions to problems finds stale or incomplete info
> from random people
> Solution: RTFM. Really. Go find *the manual* for gpg and read it.
>
> 1. Running a test script that creates keys affects user's keyring
> Solution: follow
> https://www.gnupg.org/documentation/manuals/gnupg/Ephemeral-home-directories.html
> i.e. create a directory for the test, and set GNUPGHOME to the
> absolute path to that dir
> Works on all systems
>
> 2. 'gpg --gen-key' prompts user for key parameters, and aborts if
> /dev/tty can't be opened (e.g. with noninteractive ssh )
> Solution: follow
> https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html
> i.e. create a file foo.dat containing the responses, e.g.
> Key-Type: 1
> Key-Length: 2048
> Subkey-Type: 1
> Subkey-Length: 2048
> Name-Real: My Real Name
> Name-Email: f...@example.com
> Expire-Date: 30
> and change the command to 'gpg --batch --gen-key foo.dat'
> Works on ubuntu 16.04 and below
>
> 3. On ubuntu 16.04, which straddles gpg and gpg2, the command
> 'gpg --export | gpg2 --import -'
> appears to be required to get apt to notice a key you've generated
> with gpg, but 'gpg2 --import' aborts with
> gpg: can't connect to the agent: Invalid value passed to IPC
> gpg: error getting the KEK: No agent running
>
> Solution: 'sudo apt-get install gnupg-agent', then
> use "gpg-agent --daemon -- gpgcommand..." to create a transient
> gpg-agent just for the duration of the gpg command.
> This works on Ubuntu 12.04 through 16.04.
>
> 4. also on ubun
Unattended use of gpg across a wide range of gpg versions, Ubuntu edition. --debug-quick-random taking evasive action.
tl;dr: anyone know what's up with --debug-quick-random? Also, handy script for unattended key generation across many versions of gpg. Hi all. This topic has been beaten to death on many forums and in many bug reports, but here's a user report from the field that sums up what works. It's mostly just stitching together known workarounds, plus one little mystery with --debug-quick-random in gpg 2.1.15 (the one on Ubuntu 17.04). I'll list the problems, then at the bottom show the full solution I'm using. I'm writing a test script that uses gpg, so I reviewed https://www.gnupg.org/documentation/manuals/gnupg/Unattended-Usage-of-GPG.html but it doesn't quite handle all the situations I ran into. This kind of test script has to satisfy requirements like: - work on current OS as well as last few LTS releases - use the OS's default gpg - work in both interactive and headless situations - leave the user's normal environment unchanged - work even in deeply nested directories That means I can't follow some of the advice in the manual (e.g. "use GPGME" or "use --quick-addkey"). For the purposes of testing, let's say I want to generate a key with the command gpg --gen-key for use with apt on an Ubuntu 17.04 desktop, as well as in freshly installed headless older systems. (For instance, containers created with the commands lxc-create -n ubu1204 -t download -- --dist ubuntu --release precise --arch amd64 lxc-create -n ubu1404 -t download -- --dist ubuntu --release trusty --arch amd64 lxc-create -n ubu1604 -t download -- --dist ubuntu --release xenial --arch amd64 lxc-create -n ubu1704 -t download -- --dist ubuntu --release zesty --arch amd64 ) Easy, right? Challenges and solutions I ran into, rearranged in a less embarassing order than I ran into them: 0. Googling for solutions to problems finds stale or incomplete info from random people Solution: RTFM. Really. Go find *the manual* for gpg and read it. 1. Running a test script that creates keys affects user's keyring Solution: follow https://www.gnupg.org/documentation/manuals/gnupg/Ephemeral-home-directories.html i.e. create a directory for the test, and set GNUPGHOME to the absolute path to that dir Works on all systems 2. 'gpg --gen-key' prompts user for key parameters, and aborts if /dev/tty can't be opened (e.g. with noninteractive ssh ) Solution: follow https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html i.e. create a file foo.dat containing the responses, e.g. Key-Type: 1 Key-Length: 2048 Subkey-Type: 1 Subkey-Length: 2048 Name-Real: My Real Name Name-Email: f...@example.com Expire-Date: 30 and change the command to 'gpg --batch --gen-key foo.dat' Works on ubuntu 16.04 and below 3. On ubuntu 16.04, which straddles gpg and gpg2, the command 'gpg --export | gpg2 --import -' appears to be required to get apt to notice a key you've generated with gpg, but 'gpg2 --import' aborts with gpg: can't connect to the agent: Invalid value passed to IPC gpg: error getting the KEK: No agent running Solution: 'sudo apt-get install gnupg-agent', then use "gpg-agent --daemon -- gpgcommand..." to create a transient gpg-agent just for the duration of the gpg command. This works on Ubuntu 12.04 through 16.04. 4. also on ubuntu 17.04, the previous fix isn't quite enough. gpg-agent fails with gpg-agent[1631]: command 'GENKEY' failed: Inappropriate ioctl for device gpg: agent_genkey failed: Inappropriate ioctl for device which sounds like https://dev.gnupg.org/T2680 Evidently it wants a tty, which isn't going to be possible. Solution: echo allow-loopback-pinentry > $GNUPGHOME/gpg-agent.conf and add --pinentry-mode loopback to the gpg command. This requires ubuntu 17.04 and up; you can't use it with ubuntu 12.04 through 16.04. 5. gpg hangs with message Not enough random bytes available. Please do some other work... Solutions: a) stuff the system rng somewhat securely; e.g. on Ubuntu, 'sudo apt-get install haveged' b) tell gpg to use an insecure RNG, e.g. if gpg --quick-random --version >/dev/null 2>&1 ; then echo quick-random >> "$GNUPGHOME"/gpg.conf elif gpg --debug-quick-random --version >/dev/null 2>&1 ; then echo debug-quick-random >> "$GNUPGHOME"/gpg.conf fi Either works on all tested ubuntu versions up to ubuntu 16.04. 6. On Ubuntu 17.04, gpg (2.1.15) takes several minutes to run, complaining gpg-agent[6385]: can't connect my own socket: IPC connect call failed gpg-agent[6385]: this process is useless - shutting down even with --debug-quick-random in gpg.conf (or gpg-agent.conf). Oddly, the same two workarounds fix this, more or less: a) stuff the system rng somewhat securely; e.g. on Ubuntu, 'sudo apt-get install haveged' b) tell gpg-agent to use an insecure RNG; only way is to pass --debug-quick-random option on gpg-agent's commandline! Neither conf file will do anymore. That socket error is very odd, and so is the fact that tweaking the rng in these two ways makes it go away. Bug? Feature? 7. When running
Re: OSX: How to install gpg without Admin password
COMPLETE SUCCESS.
I had to add the *-program argument to both the gpg and gpg-agent
config files. Below is very very crude shell script to show others
how it was done. The script wasn't tested as is, but rather was a
notepad I had open to try to record the steps as I did them. It is
almost guaranteed to have one or two bus in it.
--
cd ~
gpgosx=http://downloads.sourceforge.net/project/gpgosx
curl -LO ${gpgosx}/GnuPG-2.1.7.dmg
curl -LO ${gpgosx}/GnuPG-2.1.7.dmg.sig
mkdir GnuPG
mkdir GnuPG/tmp
cd ~/GnuPG/tmp
7z x ../../GnuPG-2.1.7.dmg
7z x 4.hfs
tar -xf Install.pkg
cd ..
cat ./tmp/GnuPG.pkg/Payload | gunzip -dc |cpio -i
export PATH=${PATH}:`pwd`/bin
export DYLD_FALLBACK_LIBRARY_PATH=`pwd`/lib
export GNUPGHOME=${HOME}/.gnupg
echo "agent-program" \
"`pwd`/bin/gpg-agent" \
> ${GNUPGHOME}/gpg.conf
echo "pinentry-program" \
"`pwd`/bin/pinentry-mac.app/Contents/MacOS/pinentry-mac" \
> ${GNUPGHOME}/gpg-agent.conf
# this will start a gpg capable shell
bash
--
So if anyone is stumbles upon this thread later who is also trying to
get GPG on a Admin controlled Mac, hopefully this will guide the way.
Another path you could take would be to install Chrome and Mailvelope.
I know that Chrome allows "drag-and-drop" install of the browser
without Admin rights. Once in chrome you can install the Mailvelope
extension which will give you a graphical interface for GPG
operations. You can also export your Mailvelope key to GPG so you can
do finer manipulation of it through the shell.
Many thanks to Mr. Brunschwig for the tips along the way.
On Sun, Aug 30, 2015 at 9:19 AM, Patrick Brunschwig
wrote:
> You'll need to set the path to pinentry in gpg-agent.conf Something like:
> pinentry-program /home/xyz/pinentry-mac.app/Contents/MacOS/pinentry-mac
>
> -Patrick
>
> On 29.08.15 19:13, Dan Bryant wrote:
>> OK, this worked in getting the binaries extracted and by setting PATH
>> and DYNLD_LIBRARY_PATH I can get the bins to load and dump version
>> information... SUCCESS...
>>
>> Now my biggest problem is getting the agent and pinentry (I assume) to
>> talk to gpg.
>>
>> I was hoping I could set bindir, libdir, libexecdir with gpgconf
>> (gpgconf.conf) but I can't seem to figure out how to convice gpg to
>> look in nonstandard paths for binaries and libraries. Seems to be
>> ignoring PATH environment.
>>
>> Suggestions?
>>
>> On Thu, Aug 27, 2015 at 1:31 AM, Patrick Brunschwig
>> wrote:
>>> On 26.08.15 17:16, Dan Bryant wrote:
>>>> I have a monitored OS X laptop that I would like to put GNU Privacy
>>>> Guard (gpg) on. Of course I can't because I don't have Admin rights,
>>>> but I was hoping there is a way to install it in user space through a
>>>> virtual environment or chroot, or some other wizardry, or by exacting
>>>> the package files.
>>>>
>>>> Obviously I only need console access to the app.
>>>
>>>
>>> Just download a DMG file, open (=mount) it, and copy the PKG file to
>>> some temporary location. Then use pkgutil in a terminal to unpack the
>>> PKG file to some temp directory. Then copy whatever you need to your
>>> home directory.
>>>
>>> man pkgutil will tell you how to use it.
>>>
>>> -Patrick
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OSX: How to install gpg without Admin password
OK, this worked in getting the binaries extracted and by setting PATH and DYNLD_LIBRARY_PATH I can get the bins to load and dump version information... SUCCESS... Now my biggest problem is getting the agent and pinentry (I assume) to talk to gpg. I was hoping I could set bindir, libdir, libexecdir with gpgconf (gpgconf.conf) but I can't seem to figure out how to convice gpg to look in nonstandard paths for binaries and libraries. Seems to be ignoring PATH environment. Suggestions? On Thu, Aug 27, 2015 at 1:31 AM, Patrick Brunschwig wrote: > On 26.08.15 17:16, Dan Bryant wrote: >> I have a monitored OS X laptop that I would like to put GNU Privacy >> Guard (gpg) on. Of course I can't because I don't have Admin rights, >> but I was hoping there is a way to install it in user space through a >> virtual environment or chroot, or some other wizardry, or by exacting >> the package files. >> >> Obviously I only need console access to the app. > > > Just download a DMG file, open (=mount) it, and copy the PKG file to > some temporary location. Then use pkgutil in a terminal to unpack the > PKG file to some temp directory. Then copy whatever you need to your > home directory. > > man pkgutil will tell you how to use it. > > -Patrick ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: OSX: How to install gpg without Admin password
I went ahead and made a very very very light OpenSSL set of scripts to encrypt / decrypt. Not nearly versatile enough, but at least I can lock some files and send to my friends (if they run my scripts too). https://gist.github.com/brianddk/a22febdca28f79ad58b0 On Wed, Aug 26, 2015 at 10:16 AM, Dan Bryant wrote: > I have a monitored OS X laptop that I would like to put GNU Privacy > Guard (gpg) on. Of course I can't because I don't have Admin rights, > but I was hoping there is a way to install it in user space through a > virtual environment or chroot, or some other wizardry, or by exacting > the package files. > > Obviously I only need console access to the app. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
OSX: How to install gpg without Admin password
I have a monitored OS X laptop that I would like to put GNU Privacy Guard (gpg) on. Of course I can't because I don't have Admin rights, but I was hoping there is a way to install it in user space through a virtual environment or chroot, or some other wizardry, or by exacting the package files. Obviously I only need console access to the app. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Generating GnuPG S/MINE key pair
*SOLVED*
On Tue, Apr 28, 2015 at 11:12 AM, Dan Bryant wrote:
> OK... I'm apparently suffering from a bad gpgsm setup. According to
> the 2011 post
> (https://lists.gnupg.org/pipermail/gnupg-devel/2011-March/025989.html)
> the following command, should just work:
>gpgsm --gen-key | gpgsm --import
>
> Not for me... I get
> gpgsm: problem looking for existing certificate: Invalid argument
> gpgsm: error storing certificate
>
I found the problem. I had a corrupt install. I was
trying to work around problems in the 2.1.3 installer, and went about
it poorly. I copied pinentry from gpg4win 2.2.4 (bad idea).
The better way to do it was as follows:
1) Download gnupg-w32-2.1.1_20141216.exe
2) Install {1} to %ProgramFiles(x86)%\GNU\GnuPG
3) Copy files out of {2} into %UserProfile%\GnuPG.Combined
4) Uninstall {1}
6) Stop any processes running from {2}
7) Remove directory {2}
8) Download gnupg-w32-2.1.3_20150413.exe
9) Install {8} to %ProgramFiles(x86)%\GNU\GnuPG
10) Copy files out of {9} into %UserProfile%\GnuPG.Combined
11) Stop any processes running from {9}
12) Copy %UserProfile%\GnuPG.Combined to %UserProfile%\GnuPG as Admin
13) Remove %UserProfile%\GnuPG.Combined
This will get GPA.exe and PinEntry.exe working (I hope) on a 2.1.3 baseline.
You may be able to simply install 2.1.1 then install 2.1.3 over it, I
leave others to speculate on that. This worked for me.
The GPGSM self-sign cert now imports without error.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Generating GnuPG S/MINE key pair
OK... I'm apparently suffering from a bad gpgsm setup. According to the 2011 post (https://lists.gnupg.org/pipermail/gnupg-devel/2011-March/025989.html) the following command, should just work: gpgsm --gen-key | gpgsm --import Not for me... I get gpgsm: problem looking for existing certificate: Invalid argument gpgsm: error storing certificate Moreover just trying to dump my keystore with "gpgsm -k" gives errors gpgsm: keydb_search failed: Invalid argument Here's a dump of my failed import attempt. C:\Program Files (x86)\GNU\GnuPG>gpgsm --gen-key | gpgsm --import gpgsm (GnuPG) 2.1.3; Copyright (C) 2015 Free Software Foundation, 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 (2) Existing key (3) Existing key from card Your selection? 1 What keysize do you want? (2048) Requested keysize is 2048 bits Possible actions for a RSA key: (1) sign, encrypt (2) sign (3) encrypt Your selection? 1 Enter the X.509 subject name: CN=test cert Enter email addresses (end with an empty line): > Enter DNS names (optional; end with an empty line): > Enter URIs (optional; end with an empty line): > Create self-signed certificate? (y/N) y These parameters are used: Key-Type: RSA Key-Length: 2048 Key-Usage: sign, encrypt Serial: random Name-DN: CN=test cert Proceed with creation? (y/N) y Now creating self-signed certificate. This may take a while ... gpgsm: about to sign the certificate for key: &77C68CE5AC362254D7 gpgsm: certificate created Ready. gpgsm: problem looking for existing certificate: Invalid argument gpgsm: error storing certificate gpgsm: total number processed: 1 gpgsm: not imported: 1 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Generating GnuPG S/MINE key pair
Getting closer... The DirMngr stuff is totally required. Got that out
of the way (added rootCA to the right dirmgr stuff).
Now I'm scrubbing the logs and it looks like DirMgr is complaining
because I didn't timestamp any of my custom certs. Any "--ignore_ts"
or similar option to bypass this message?
dirmngr[7276] command 'VALIDATE' failed: No value
On to
http://stackoverflow.com/questions/21297139/how-do-you-sign-certificate-signing-request-with-your-certification-authority
although I might have to shelve this for a few days at this point.
Call / Text: 281.760.4296
On Mon, Apr 27, 2015 at 9:22 PM, Dan Bryant wrote:
> OK... I found some very old posts about this... don't know how much still
> holds.
> -- https://lists.gnupg.org/pipermail/gnupg-devel/2011-June/026126.html
>
> This guide says:
> 1. Convert rootCA.pem to rootCA.der
> 2. Place rootCA.der in dirmngr\trusted-certs
> 3. Ensure rootCA.der has revocation URL (??can disable??)
> 4. Add rootCA.der fingerprint to trustlist.txt
> 5. Restart dirmngr service and gpg-agent
>
> Don't know... you think that will work?
>
> BTW.. Here's the versions of the previously mentioned utilities:
> - OpenSSL 1.0.2a 19 Mar 2015
> - gpg-protect-tool (GnuPG) 2.0.27 (Gpg4win 2.2.4)
> - gpgsm (GnuPG) 2.1.3
>
> On Mon, Apr 27, 2015 at 3:07 PM, Dan Bryant wrote:
>> TL;DR: gpgsm import fails with "no issuer found in certificate"
>>
>> I'm trying to generate a key-pair for GnuPG S/MINE strictly for
>> instructional reasons. I'll concede that I'm using a weak CA, but I'm
>> trying to image how the CA maintainers do this task as well. So, for my
>> instruction, I'm trying to do the following:
>>
>> I started off just wanting to create a GnuPG S/MINE key-pair. I soon found
>> out that gpgsm requires key-pars to be externally signed by a CA. So now
>> I'm trying to do the whole process, make-key, sign-key, import-key
>>
>> 1. Create a CA with a new RSA key-pair (openSSL)
>> 2. Generate a new GnuPG S/MINE key-pair (gpgsm)
>> 3. Sign the GnuPG S/MINE key-pair with my fictitious CA above (openssl)
>> 4. Import the now signed GnuPG S/MINE key-pair into my gpgsm key-ring.
>>
>> So I theory I thought this should work, but I've botched it somewhere along
>> the way. Again... this is for INSTRUCTIONAL purposes. I realize a self
>> signed CA is about as secure as a post-it on a monitor. Trying to learn...
>>
>> Here's what I tried (for those unfamiliar with Windows, the '^' is a line
>> continuation).
>>
>> -- gpgsm
>> openssl genrsa -out rootCA.key 2048
>> openssl req -x509 -new -nodes -key rootCA.key -days 1024 -out rootCA.pem
>> gpgsm --gen-key > unsigned.pem
>> gpg-protect-tool --p12-export ^
>>%appdata%\gnupg\private-keys-v1.d\{keygrip_from_prev_gen_key_cmd}.key ^
>>> kgfpgkc.p12
>> openssl pkcs12 -in kgfpgkc.p12 -nocerts -out kgfpgkc.pem
>> openssl x509 -x509toreq -signkey kgfpgkc.pem ^
>>-in unsigned.pem -out unsigned.csr
>> openssl x509 -req -CA rootCA.pem -CAkey rootCA.key -CAcreateserial ^
>> -in unsigned.csr -out signed.pem -days 500
>> gpgsm --import signed.pem
>> --Output
>> gpgsm: no issuer found in certificate
>> gpgsm: basic certificate checks failed - not imported
>> gpgsm: no issuer found in certificate
>> gpgsm: basic certificate checks failed - not imported
>> gpgsm: ksba_cert_hash failed: No value
>> gpgsm: total number processed: 2
>> gpgsm: not imported: 2
>>
>>
>> So... Why did the issuer check fail? Do I need to import my fake CA (tried
>> that). If so, how? Is there an option to provide a PEM to serve as the
>> root CA (like Python)? Also tried coping rootCA.pem to com-certs.pem, but
>> no luck
>>
>>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Generating GnuPG S/MINE key pair
OK... I found some very old posts about this... don't know how much still holds.
-- https://lists.gnupg.org/pipermail/gnupg-devel/2011-June/026126.html
This guide says:
1. Convert rootCA.pem to rootCA.der
2. Place rootCA.der in dirmngr\trusted-certs
3. Ensure rootCA.der has revocation URL (??can disable??)
4. Add rootCA.der fingerprint to trustlist.txt
5. Restart dirmngr service and gpg-agent
Don't know... you think that will work?
BTW.. Here's the versions of the previously mentioned utilities:
- OpenSSL 1.0.2a 19 Mar 2015
- gpg-protect-tool (GnuPG) 2.0.27 (Gpg4win 2.2.4)
- gpgsm (GnuPG) 2.1.3
On Mon, Apr 27, 2015 at 3:07 PM, Dan Bryant wrote:
> TL;DR: gpgsm import fails with "no issuer found in certificate"
>
> I'm trying to generate a key-pair for GnuPG S/MINE strictly for
> instructional reasons. I'll concede that I'm using a weak CA, but I'm
> trying to image how the CA maintainers do this task as well. So, for my
> instruction, I'm trying to do the following:
>
> I started off just wanting to create a GnuPG S/MINE key-pair. I soon found
> out that gpgsm requires key-pars to be externally signed by a CA. So now
> I'm trying to do the whole process, make-key, sign-key, import-key
>
> 1. Create a CA with a new RSA key-pair (openSSL)
> 2. Generate a new GnuPG S/MINE key-pair (gpgsm)
> 3. Sign the GnuPG S/MINE key-pair with my fictitious CA above (openssl)
> 4. Import the now signed GnuPG S/MINE key-pair into my gpgsm key-ring.
>
> So I theory I thought this should work, but I've botched it somewhere along
> the way. Again... this is for INSTRUCTIONAL purposes. I realize a self
> signed CA is about as secure as a post-it on a monitor. Trying to learn...
>
> Here's what I tried (for those unfamiliar with Windows, the '^' is a line
> continuation).
>
> -- gpgsm
> openssl genrsa -out rootCA.key 2048
> openssl req -x509 -new -nodes -key rootCA.key -days 1024 -out rootCA.pem
> gpgsm --gen-key > unsigned.pem
> gpg-protect-tool --p12-export ^
>%appdata%\gnupg\private-keys-v1.d\{keygrip_from_prev_gen_key_cmd}.key ^
>> kgfpgkc.p12
> openssl pkcs12 -in kgfpgkc.p12 -nocerts -out kgfpgkc.pem
> openssl x509 -x509toreq -signkey kgfpgkc.pem ^
>-in unsigned.pem -out unsigned.csr
> openssl x509 -req -CA rootCA.pem -CAkey rootCA.key -CAcreateserial ^
> -in unsigned.csr -out signed.pem -days 500
> gpgsm --import signed.pem
> --Output
> gpgsm: no issuer found in certificate
> gpgsm: basic certificate checks failed - not imported
> gpgsm: no issuer found in certificate
> gpgsm: basic certificate checks failed - not imported
> gpgsm: ksba_cert_hash failed: No value
> gpgsm: total number processed: 2
> gpgsm: not imported: 2
>
>
> So... Why did the issuer check fail? Do I need to import my fake CA (tried
> that). If so, how? Is there an option to provide a PEM to serve as the
> root CA (like Python)? Also tried coping rootCA.pem to com-certs.pem, but
> no luck
>
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Generating GnuPG S/MINE key pair
TL;DR: gpgsm import fails with "no issuer found in certificate"
I'm trying to generate a key-pair for GnuPG S/MINE strictly for
instructional reasons. I'll concede that I'm using a weak CA, but I'm
trying to image how the CA maintainers do this task as well. So, for my
instruction, I'm trying to do the following:
I started off just wanting to create a GnuPG S/MINE key-pair. I soon found
out that gpgsm requires key-pars to be externally signed by a CA. So now
I'm trying to do the whole process, make-key, sign-key, import-key
1. Create a CA with a new RSA key-pair (openSSL)
2. Generate a new GnuPG S/MINE key-pair (gpgsm)
3. Sign the GnuPG S/MINE key-pair with my fictitious CA above (openssl)
4. Import the now signed GnuPG S/MINE key-pair into my gpgsm key-ring.
So I theory I thought this should work, but I've botched it somewhere along
the way. Again... this is for INSTRUCTIONAL purposes. I realize a self
signed CA is about as secure as a post-it on a monitor. Trying to learn...
Here's what I tried (for those unfamiliar with Windows, the '^' is a line
continuation).
-- gpgsm
openssl genrsa -out rootCA.key 2048
openssl req -x509 -new -nodes -key rootCA.key -days 1024 -out rootCA.pem
gpgsm --gen-key > unsigned.pem
gpg-protect-tool --p12-export ^
%appdata%\gnupg\private-keys-v1.d\{keygrip_from_prev_gen_key_cmd}.key ^
> kgfpgkc.p12
openssl pkcs12 -in kgfpgkc.p12 -nocerts -out kgfpgkc.pem
openssl x509 -x509toreq -signkey kgfpgkc.pem ^
-in unsigned.pem -out unsigned.csr
openssl x509 -req -CA rootCA.pem -CAkey rootCA.key -CAcreateserial ^
-in unsigned.csr -out signed.pem -days 500
gpgsm --import signed.pem
--Output
gpgsm: no issuer found in certificate
gpgsm: basic certificate checks failed - not imported
gpgsm: no issuer found in certificate
gpgsm: basic certificate checks failed - not imported
gpgsm: ksba_cert_hash failed: No value
gpgsm: total number processed: 2
gpgsm: not imported: 2
So... Why did the issuer check fail? Do I need to import my fake CA (tried
that). If so, how? Is there an option to provide a PEM to serve as the
root CA (like Python)? Also tried coping rootCA.pem to com-certs.pem, but
no luck
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Fwd: GNU hackers discover HACIENDA government surveillance and give us a way to fight back
| > Is this not the core of the question? In a world of social media | > and sensor-driven everything, does not the very concept of private | > information fade, per se? I believe it does. | | No. Taking part in social networks and other media is a choice. One can | a) choose not to take part at all, or b) choose how one takes part and | what information one shares. | | In short, privacy of information is still real, still relevant, and | still (largely) within the control of the individual. Tools such as | encryption help retain the reality of privacy of information. | | The question of privacy of information is of critical importance to | liberty. By choosing to believe that privacy (or specifically privacy of | information) is a concept that has "fade"ed you are playing into the | hands of those who would wish to forcefully strip us all of privacy, | whether we like or or not. That would be a mistake, I think. I fully agree with you, which means that I see few ways to preserve the liberty that privacy represents than to withdraw from much of civil society while it shares ever more -- sharing ever more on the "I've got nothing to hide" premise. Technology makes what is observable by others daily grow wider; lip reading robots, electric grids that know the noise signature of every device you own, smart cameras on every street corner, MIT's "visual microphone," electronic health records that are and must be shared amongst providers plus the providers' paymasters, and on and on. That these are possible is worrisome; that they are widely built into services which promise "convenience" is the Pied Piper institutionalized. As I wrote elsewhere(*), we are becoming a society of informants -- I have nowhere to hide from you. --dan (*) We Are All Intelligence Officers Now http://geer.tinho.net/geer.rsa.28ii14.txt ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Fwd: GNU hackers discover HACIENDA government surveillance and give us a way to fight back
| On 2014-08-23 at 12:16, d...@geer.org wrote: | >> On 2014-08-22 at 21:13, Rejo Zenger wrote: | >> Open data and transparency should only be about what concerns everybody, | >> like government actions, trains schedule, etc. not private information. | > | > Is this not the core of the question? In a world of social media | > and sensor-driven everything, does not the very concept of private | > information fade, per se? I believe it does. | | It will be when any kind of authority (thus hierarchy) or intolerance | (thus ignorance/inconsciousness) would have *perfectly disappeared*. | Whenever it's possible or not, we can still see that today it isn't so, | therefore privacy still has importance. Given that Philosophical and legal analysis has often identified privacy as a precondition for the development of a coherent self. -- Phil Agre, "The Architecture of Identity," 1998 one must conclude that it is a mortal peril to give up privacy, at least before, as you said, evil has disappeared from the face of the Earth. My point was and is simply that nearly everything is now observable IN PUBLIC. Technology makes this possible but it social media and sensor networks through which that technology brings observability of the heretofore unobservable to the attention of whomever wants it. That trend cannot be undone, ergo, I said in the speech, [W]e are becoming a society of informants. In short, I have nowhere to hide from you. This being the gnupg list, we are likely now in a rat hole, but if we are not yet there, then let me ask a question: Many's the member of this list who posts under a pseudonym. Is pseudonymous posting a privacy-preserving tactic or something else? --dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Fwd: GNU hackers discover HACIENDA government surveillance and give us a way to fight back
> On 2014-08-22 at 21:13, Rejo Zenger wrote: > > Open data and transparency should only be about what concerns everybody, > like government actions, trains schedule, etc. not private information. Is this not the core of the question? In a world of social media and sensor-driven everything, does not the very concept of private information fade, per se? I believe it does. We Are All Intelligence Officers Now http://geer.tinho.net/geer.rsa.28ii14.txt --dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: It's 2014. Are we there yet?
I employ quite a few young people on my farm. Text messages are almost entirely what they do. Two (that I know of) are *never* without their phones but at the time *never* use them for voice comms. The only way to reach them is text. One of those claims that he has never answered a call on a mobile phone. Small sample,... --dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: It's 2014. Are we there yet?
> One possible answer: https://www.mailpile.is/faq/ * Where does Mailpile store my mail? With Mailpile, your e-mail is downloaded from the Internet (via an email server POP3 / IMAP), and stored locally on the computer where Mailpile is running. * Then how do I access it when my computer is turned off? You don't! Exactly so. Putting aside, for the moment, outright attacks, the individual or the enterprise that outsources its e-mail to a third party thereby creates by itself and for itself the risk of silent subpoenas delivered to their outsourcer. If, instead, the individual or the enterprise insources its e-mail then at the very least it knows when its data assets are being sought because the subpoena comes to them. Maybe insourcing your e-mail is too much work, but need I remind anyone that plaintext e-mail cannot be web-bugged, so why would anyone ever render HTML e-mail at all? Apologies, --dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to do pinentry in same screen as gpg
On Fri, 3 Jan 2014, Hauke Laging wrote: Am Fr 03.01.2014, 01:14:22 schrieb Dan Mahoney, System Admin: It basically works perfectly with gpg1, where I can get an inline prompt for a password, but gpg2 falls short where it tries to set up some kind of a unix-socket connection to a pinentry dialog, and this all falls apart within the simple exec() alpine is doing to launch the filter. GPG hangs up and I wind up needing to kill the whole window. Do you start gpg-agent before gpg2? I would expect the behaviour to be the same like gpg if gpg-agent is not running. It might also be nice if I could basically start a pinentry program in a dedicated window, You can write a wrapper around pinentry. This wrapper could start pinentry in a different console. See: http://lists.gnupg.org/pipermail/gnupg-users/2013-July/047168.html http://lists.gnupg.org/pipermail/gnupg-users/2013-December/048362.html I assume this is much more a screen problem. Some time ago I tried to create a pipeline between two processes running in different screen windows. I didn't manage to do that. But maybe there are tricks unknown to me. Maybe that can be done with redirecting stdin and stdout to a socket with socat or something like that. Actually -- it *looks like* loopback-pinentry is pretty much exactly what I'm looking for here, if I understand the feature. Hopefully recent fundraising activity can get 2.1 out the door soon. (I'm going to donate!) -Dan -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to do pinentry in same screen as gpg
On Fri, 3 Jan 2014, Hauke Laging wrote: Am Fr 03.01.2014, 01:14:22 schrieb Dan Mahoney, System Admin: It basically works perfectly with gpg1, where I can get an inline prompt for a password, but gpg2 falls short where it tries to set up some kind of a unix-socket connection to a pinentry dialog, and this all falls apart within the simple exec() alpine is doing to launch the filter. GPG hangs up and I wind up needing to kill the whole window. Do you start gpg-agent before gpg2? I would expect the behaviour to be the same like gpg if gpg-agent is not running. No, the agent "is required", per the manpage. If GPG doesn't find an agent, it starts one: I just fired up a gpg --gen-key on my system where 2.x is installed. danm 74860 0.0 0.1 13728 2120 ?? Ss1:18PM 0:00.02 gpg-agent --daemon --use-standard-socket danm 74853 0.0 0.1 17408 3136 3 I+1:18PM 0:00.02 gpg --gen-key (gpg2) danm 74861 0.0 0.0 9264 1972 ?? I 1:18PM 0:00.01 pinentry (pinentry-curses) It leaves this agent running after you exit GPG, which feels sloppy -- ssh doesn't leave ssh-agent running after I connect, if I use it at all. It might also be nice if I could basically start a pinentry program in a dedicated window, You can write a wrapper around pinentry. This wrapper could start pinentry in a different console. See: http://lists.gnupg.org/pipermail/gnupg-users/2013-July/047168.html http://lists.gnupg.org/pipermail/gnupg-users/2013-December/048362.html I assume this is much more a screen problem. Some time ago I tried to create a pipeline between two processes running in different screen windows. I didn't manage to do that. But maybe there are tricks unknown to me. Maybe that can be done with redirecting stdin and stdout to a socket with socat or something like that. I seem to recall that I was able to do it by messing heavily with environment variables. As I want to get back into playing with smartcards, the agent become more necessary. (Or keeping v1 and v2 installed in parallel, which seems nonoptimal). Hauke, in your posts, you mention that the pinentry protocol isn't on the GPG website. Could that please be fixed by the people who maintain the project? I notice it also missing from http://www.gnupg.org/documentation/manuals/ If I come up with a good method for doing so, I'll post a howto/blog here. I do wonder how difficult it would be to write a pinentry-getline which doesn't try to do any fancy display tricks -- I just want enough magic to turn echoing off. (I think the ncurses are part of what mess alpine up). I may try this as well. Thanks all, -Dan -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
How to do pinentry in same screen as gpg
All, I have a script that I use to send mail (as part of pine/alpine) that needs to prompt for my key passphrase. I run alpine on a private unix server, within a screen session. It basically works perfectly with gpg1, where I can get an inline prompt for a password, but gpg2 falls short where it tries to set up some kind of a unix-socket connection to a pinentry dialog, and this all falls apart within the simple exec() alpine is doing to launch the filter. GPG hangs up and I wind up needing to kill the whole window. Here's where I've gotten on a possible solution: I could possibly have every window within my screen session have my .cshrc check for a running gpg-agent, and start one if it's not (this seems wasteful considering how infrequently I sign). Along these lines, I'd probably have to have every single screen process update the running TTY, so that my most recently-opened screen would contain the dialog. It seems that the pinentry command is invoked behind the scenes by the agent, and then directly writes to and reads/from the tty specified (so it could in theory interfere with whatever else I'm running on that screen), for example, if I were doing something while su'd to root. -or- It would also be nice if pinentry could cause the spawning of a new screen window via "screen -X", but as I have a password-protected screen, this isn't possible either. -or- It might also be nice if I could basically start a pinentry program in a dedicated window, and simply choose to use it when needed (similar in analog to how I might use a hardware pinpad, or a fingerprint reader). I don't know if this is possible. I could also start up some "dummy" program in a screen where the agent will spawn. I think that last one is the plan of attack I'll likely pursue. However, it would be really, really nice if, instead of gpg--agent--assuan--pinentry, GPG could just fall back to prompting for a password on the same tty where GPG is running. It would also be nice if GPG had some method of simply saying "hey, I can't find a place to spawn this pinentry, and could exit cleanly." Thoughts are welcome. -Dan -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: UK Guardian newspaper publishes USA NSA papers
> "You don't need to be talking to a terror suspect to have your > communications data analysed by the NSA. The agency is allowed to > travel "three hops" from its targets." Barnett, "Facebook Cuts Six Degrees of Separation to Four," 22 November 2011 http://www.telegraph.co.uk/technology/facebook/8906693/Facebook-cuts-six-degrees-of-separation-to-four.html average distance on Twitter is 4.67, as found in "Six Degrees of Separation, Twitter Style," 30 April 2010 http://www.sysomos.com/insidetwitter/sixdegrees/ or maybe it is only 3.43, as found in Bakhshandeh, Samadi, Azimifar & Schaeffer, "Degrees of Separation in Social Networks," 2011 http://www.aaai.org/ocs/index.php/SOCS/SOCS11/paper/view/4031 "Allowed three hops" is closer to a grand mal seizure than a twitch. For a sideline, look up "percolation theory." --dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [tor-talk] BitMail.sf.net v 0.6 - Secure Encrypting Email Client
| ... Further, getting two | computers to generate the exact same binary code from the exact same | source code is a surprisingly difficult challenge. It requires a | perfect match of everything from compiler versions to C library | versions right down to identical *clocks* -- because often, compilers | will incorporate timestamps into the output. | | Doing checksum validation of source code is feasible. Of binary code, | not really. Well said. Two binaries can be execution identical except for their use of registers -- their use of registers being an artefact of the compiler. --dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: RNG: is it possible to spoil /dev/random by seeding it from (evil) TRNGs (was: howto secure older keys after the recent attacks)
I consulted a non-list-reading colleague who knows rather a lot about randomness. He writes: > here's my reply; i dunno whether it counts > as an example of evil per se: > > the bigger problem with manufactured > entropy sources is that rigorous unit testing > at the factory usually is just impossible. > it just takes too long to gather a few hours > of bits from every unit, then do the exhaustive > statistical testing, again for every unit. > > indeed, it seems likely to me that when > a CPU vendor sells CPU chips with integrated > TRNG circuits, some of the chips will surely > come off the fabrication line with defective > TRNGs, just as some CPU chips get made with > defective ALUs, memory, etc. the bad logic > circuits get caught by exhaustive pre-ship > testing, and those chips don't get sold. but > given that rigorous testing of the TRNG circuit > is so expensive, it's my guess that the CPU > vendor surely must just unwittingly ship the > CPUs that happen to have obscurely bad TRNGs. --dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [gnupg-users] Re: Future of GnuPG 1.x.x?
On Sat, 4 Aug 2012, Robert J. Hansen wrote: On 08/04/2012 03:26 PM, Sin Trenton wrote: Is the plan to retire 1.x sometime in a not too distant future (I'm not saying that I assume an actual time plan being set)? I am not a GnuPG developer. My information is not definitive. Take it with a grain of salt. That said, my understanding is the GnuPG developers wish to end 1.4 support as soon as possible. This is reasonable, given that 2.0 has been out for a decade. When 2.0 first came out I was not a big fan, but it's become much more stable and useful over the past few years. However, ending GnuPG 1.4 support 'as soon as possible' is not the same as 'ending it now.' They want to minimize impact on end-users as much as possible. The 1.4 model still works better for certain things. I've never successfully managed to make pinentry work in a shell/screen session using my mailer, and I've never heard back from the GPG developers about allowing the main gnupg process to prompt for a pin directly, without needing the socket/window of pinentry. Both myself and Doug Barton have commented on this list to this effect. I consider this a blocking factor for moving to 2.0. When 1.4 support ends, expect an EOL date to be announced far in advance and a lot of help given to people who need to migrate to 2.0. See above. -Dan -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Reply-to netiquette (was [META] please start To: with gnupg-users@gnupg.org...)
> Here here! Be liberal in what you accept, and conservative in > what you send. Folks, at the risk of starting a new thread or steering this thread into an eddy, Postel's Law is now officially a problem. I strongly (and I mean it) urge ya'll to take a look at the one or two principal papers at langsec.org I believe they are game changing. As I said earlier on, I read my mail in a text-only legacy reader because it cannot interpret. Ditto not allowing Javascript, etc. Why? Because I refuse to honor a remote procedure call from parties I know not written in a Turing-Complete language which characteristic, if I need to say it, means that security, a variant of the halting problem, is formally undecideable. --dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [META] please start To: with gnupg-users@gnupg.org, i.e.: To: gnupg-users@gnupg.org
I read my mail in plaintext (RAND MH) from the command line, so things like quoted-printable, base64, UNICODE, HTML, etc., are all a fuss and bother. My "ask" is thus for plaintext with line breaks, trimming the quoted material down to the relevant parts, and no top-posting. I'd also vote for the list having a "reply-to" header. The above applies to all mailing lists, including here. I can cope; this is just my ask. Please and thank you, --dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Short ID Collision
On Thu, Dec 29, 2011 at 2:18 AM, John Clizbe wrote: > Jerry wrote: >> >> It would seem, and this is strictly my own opinion, that if the "old >> pksd" servers are dead then there is no logical reason to continue to >> support them. Just my 2¢. > > If only all software support decisions were that cut and dried. Oh well... > > David Shaw committed patches to the 1.4, 2.0, & 2.1 branches of GnuPG > yesterday > afternoon (28-Dec). The change will be in the next release of each branch. Just discovered keyservers are still totally crappy on this front. Check this out when using a subkey ID to try to fetch a key; the following is a request produced by GPGME gpgme_get_key() that returns no matches (note that this is a subkey ID): Subkey lookup, broken in first URL: http://pgp.mit.edu:11371/pks/lookup?op=index&options=mr&search=0x22AD5874F39D989F&exact=on vs. http://pgp.mit.edu:11371/pks/lookup?op=index&options=mr&search=0xF39D989F&exact=on Public key lookup, both work: http://pgp.mit.edu:11371/pks/lookup?op=index&options=mr&search=0x6D1A9E70E19DAA50&exact=on vs. http://pgp.mit.edu:11371/pks/lookup?op=index&options=mr&search=0xE19DAA50&exact=on This is totally unacceptable in my opinion, why do we have such broken infrastructure that it cannot support a simple lookup like this? -Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Gnupg file formats
On Thu, Dec 1, 2011 at 11:25 AM, Werner Koch wrote: > On Thu, Â 1 Dec 2011 10:02, tosk...@gmail.com said: > >> ciphertext encrypted with a 1024 bit RSA key start \x848C03? Why is it >> \x85010C03 for 2048 bit RSA? Is this explained in the RFC somewhere >> I've missed or is it documented elsewhere? > > Read section 4.2 of RFC-4880. Â The length header encoding is a bit > complicate. The pgpdump source code may be a bit more easy to grasp if you just want to understand the file format. http://www.mew.org/~kazu/proj/pgpdump/en/ -Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: STEED - Usable end-to-end encryption
> > With respect to your question: what we offer is privacy, but most people > do not understand privacy, do not care about privacy, and would not care > about privacy even if they understood it. > > During graduate school the politically-active members of the Computer > Science department were up in arms over government surveillance. > Flyers, bulletin board notices, EFF fundraising campaigns, and the like. > Yet, when the Department required all TAs sign up for Facebook, in the > interests of "being accessible to the undergraduates," there wasn't any > outcry. I was serving as the Area Steward for the graduate student > labor union and tried to drum up some outrage that we were being > *required* to sign up for a privacy-annihilating 'service.' Nobody was > interested -- not even the people who had flyers on their doors > condemning Total Information Awareness and EFF stickers on their laptops. > You got that right, Brother. To be more pointed, how many folks on this list carry a cell phone? --dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Marking a key as "don't export"?
Is there any way to mark a key as local-only, similar to an lsign-created local signature? I'm asking because I plan on generating a master key to be used by a piece of software where ultimate trust can be rooted, and there is really no need to have even the public half of this key ever leave the machine. The only operation it will ever be used in is lsigning various other public keys. -Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Which release should we be using?
On Mon, Aug 22, 2011 at 7:01 AM, Werner Koch wrote: > On Mon, 22 Aug 2011 10:29, papill...@gmail.com said: > >> because I don't like having to use pinentry since it doesn't support cut >> and paste. My questions are these: > > That is on purpose. Â If you have your passphrase on file for c+p you may > as well use no passphrase at all. Â gpg-agent caches your passphrase; set > the caching time to whatever you l; this is far safer than to use c+p. So you're enforcing policy via disabling copy and paste? This is extremely shortsighted. Any password management program like Keepass makes transfer via the clipboard easy and relatively safe (clearing it after 10 seconds), so that doesn't sound like the safety of "no passphrase at all". -Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Creating a quickly expiring signature
On Thu, Jul 28, 2011 at 5:04 PM, David Shaw wrote: > On Jul 28, 2011, at 4:49 PM, Dan McGee wrote: > >> I wanted to test behavior of an application with an expired signature, >> but using `--ask-sig-expire` don't seem to be granular enough. The >> minimum I can specify is either 1 day, or an absolute date (e.g. >> 2011-07-29), which is still 8+ hours away for me right now. Am I >> missing something? Decimal values are not accepted, nor seconds, >> minutes, or hours. > > When GPG asks you for the value, enter "seconds=X". Â You can go down to as > low as a single second. Thanks! This worked. Now why isn't this documented anywhere to be found? What other secret helpful options does gpg not advertise? @Robert: while I appreciate your suggestion, I do not find setting my system clock (controlled by NTP) to an invalid time to be even remarkably a valid solution to this problem, especially if I am writing an automated test suite that generates signatures and keys, for example... -Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Creating a quickly expiring signature
I wanted to test behavior of an application with an expired signature, but using `--ask-sig-expire` don't seem to be granular enough. The minimum I can specify is either 1 day, or an absolute date (e.g. 2011-07-29), which is still 8+ hours away for me right now. Am I missing something? Decimal values are not accepted, nor seconds, minutes, or hours. -Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Generate digest and signature seperately
On Sun, Jun 12, 2011 at 7:54 PM, Jerome Baum wrote:
>> The databases (lists) are not very large, as far as I understand, but
>> it wasn't my call ("repositories" in the 4th line is a typo; I meant
>> "databases"). I'm not an Arch Linux developer; I'm just contributing
>> to their effort to implement package signing.
>
>> Individual packages will be signed, but for complete security, the
>> databases must themselves also be signed; otherwise, an attacker could
>> use DNS spoofing to deliver a database listing outdated packages with
>> known vulnerabilities, and it would happily be accepted by end-users'
>> systems. The vulnerable packages would not be updated, but the users
>> would most likely not notice, since other packages would be updated.
>
> All makes sense. Just don't get why it's so expensive to download a
> small package list?
I'll speak up as a developer here. I was the same one that asked about
a system-shared keyring last week if that helps bring it into context.
The actual issue isn't with package databases at all; those are, as
several people indicated, small enough to be copied, signed, and
uploaded as necessary. We're talking 50-500 KB or so here.
Our real issue revolves around signing very large packages. Take for
example, sage-mathematics [1]. This package clocks in at 306.3 MB
compressed. If this was built remotely on some build server and the
packager wanted to sign it, the current GPG signing workflow would
require to copy it locally where his secure keyring is located, sign
it, and then upload the signature file. The package itself could be
uploaded from either location.
With all that said, does anyone see a reasonable and secure workflow
for this? I did suggest [2] signing package hashes as one possible
option, after looking into agent forwarding and discovering that
doesn't seem to be a workable option at this point.
-Dan
[1] http://www.archlinux.org/packages/community/i686/sage-mathematics/
[2] http://mailman.archlinux.org/pipermail/pacman-dev/2011-June/01.html
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Working with a system-shared keyring
On Fri, Jun 3, 2011 at 2:19 AM, Werner Koch wrote: > On Thu, Â 2 Jun 2011 00:41, dpmc...@gmail.com said: > >> 1. Does anyone else have experience with a shared among users keyring? > > Be warned that future gpg versions may not support the use of multiple > keyrings. Â It is not easy to define the semantics for this as it is > similar to a translucent filesystem. Perhaps I phrased this bad- I more meant "accessible to multiple users". When using this keyring, no other keyring will ever come into play, as $GNUPGHOME is set to this shared directory (/etc/pacman.d/gnupg/). >> 2. What is best/secure practice when it comes to this? Outside of >> --lock-never, yum does something that seems silly, but works- make a >> user-owned copy of the entire keyring directory and then uses that. > > Importing all the keys is the safest strategy. Importing to where, and trust levels as well? The idea here is we are using this keyring for one purpose only- the system-defined keyring and trust levels used to verify downloaded and to-be-installed packages and metadata. Having user-specific keyrings/trustdbs for this stuff doesn't seem to make much sense unless I'm overlooking something. > Disable locking for a shared resource requires at least to check that no > write bits are set for the file. Â I am not sure whetehr such checks are > justified given the above mentioned problems with shared keyrings. > > >> 3. gpgme doesn't allow us to bypass the trustdb.gpg locking; is there >> any possibility of allowing gpgme to run with --lock-never in a >> read-only mode? > > You may specify a different home directory with gpgme and in that > home directory you put the option lock-never into gpg.conf. Aha, didn't think about this, but it makes sense- thanks. Of course if the user that does have write permissions on these files (root) runs gpg, then the --lock-never would be unwanted but maybe we have to live with that. > Â You can change the configuration of a backend engine, and thus change > Â the executable program and configuration directory to be used. Â You can > Â make these changes the default or set them for some contexts > Â individually. > > Â -- Function: gpgme_error_t gpgme_set_engine_info Yes, we are doing this already and are setting the home directory to /etc/pacman.d/gnupg/. -Dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Working with a system-shared keyring
We're trying to get a full implementation of package and database signing going for Arch Linux using gpgme/gpg, and have run into a few small hiccups. The goal was to actually use the web of trust features rather than relying on gpgv and trusting everything in a given keyring, as it seems every other distro using singing has done. However, gpg is very particular about permissions, locking, and ownership, and when layering gpgme on top of this, it becomes even harder to work within the bounds of what is available. A quick console session is shown below. Basically the idea is the system GPG homedir used by the package manager is located at /etc/pacman.d/gnupg/, and is world readable, as are all the files within. There will never be private key information in this location. So my questions are: 1. Does anyone else have experience with a shared among users keyring? 2. What is best/secure practice when it comes to this? Outside of --lock-never, yum does something that seems silly, but works- make a user-owned copy of the entire keyring directory and then uses that. 3. gpgme doesn't allow us to bypass the trustdb.gpg locking; is there any possibility of allowing gpgme to run with --lock-never in a read-only mode? Any feedback is welcome, thanks in advance! -Dan $ sudo gpg --homedir /etc/pacman.d/gnupg --verify /home/makepkg/packages/libmysqlclient-5.5.12-1-x86_64.pkg.tar.xz.sig gpg: WARNING: unsafe permissions on homedir `/etc/pacman.d/gnupg' gpg: Signature made Tue 17 May 2011 09:13:06 AM CDT using DSA key ID F53A76ED gpg: Good signature from "Dan McGee " gpg: aka "Dan McGee (Developer) " gpg: aka "Dan McGee (Jabber) " 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: A5CA 9D55 15DC 2CA7 3DF7 48CA 5C2E 46A0 F53A 76ED $ gpg --homedir /etc/pacman.d/gnupg --verify /home/makepkg/packages/libmysqlclient-5.5.12-1-x86_64.pkg.tar.xz.sig gpg: WARNING: unsafe ownership on homedir `/etc/pacman.d/gnupg' gpg: Signature made Tue 17 May 2011 09:13:06 AM CDT using DSA key ID F53A76ED gpg: failed to create temporary file `/etc/pacman.d/gnupg/.#lk0x149f680.galway.5260': Permission denied gpg: fatal: can't create lock for `/etc/pacman.d/gnupg/trustdb.gpg' secmem usage: 1408/1408 bytes in 2/2 blocks of pool 1408/32768 $ gpg --lock-never --homedir /etc/pacman.d/gnupg --verify /home/makepkg/packages/libmysqlclient-5.5.12-1-x86_64.pkg.tar.xz.sig gpg: WARNING: unsafe ownership on homedir `/etc/pacman.d/gnupg' gpg: Signature made Tue 17 May 2011 09:13:06 AM CDT using DSA key ID F53A76ED gpg: NOTE: trustdb not writable gpg: Good signature from "Dan McGee " gpg: aka "Dan McGee (Developer) " gpg: aka "Dan McGee (Jabber) " 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: A5CA 9D55 15DC 2CA7 3DF7 48CA 5C2E 46A0 F53A 76ED ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Slightly OFF TOPIC - Traffic analysis...in reverse?
| | in the avalanche of news about the [recently] late Osama Bin Laden, I | noticed a small item: the area where he was caught had been *also* | defined/pinpointed by the lack of cellular phone communications. | I do not send CallerID (well, you know that I do but you also know what I mean). As it happens, everyone I call assumes it is me as I am the only one who chooses that. --dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Deniability
> For example, I do genealogy as a hobby, and figuring out how person A was re > lated to person B 100 years ago would involve trips to the town in question > , and poring over a hand-kept records book in the town hall. These days, t > here are a number of websites that have brought that sort of information on > line. The information from old town record book is essentially unchanged, > but the ability to access it is dramatically easier. Such easy access enab > les all sorts of cross-referencing and data mining across multiple database > s that were (strictly speaking) possible a hundred years ago, but also extr > emely unrealistic. The "23andme.com" folks claim that their genetic screening thing is liberating people by connecting them to relatives that they did not know they had. I, for one, have a lot of relatives that I don't want to know. --dan This message is certified orthogonal to the topic of gnupg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Deniability
| > Perhaps you are correct. | | Unlikely, but you're kind to say so. I'll be happy if my mistakes | can just be interesting. :) I'm with you on that. | > My own definition of privacy evolves, but as of now is this: | | This is very good: I need to think on this. May I borrow this and | present it to others (with attribution)? Yes, of course. --dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Deniability
> If I'm right, then the only way to restore privacy is to raise the price > of information transfer in some way. OpenPGP can be thought of as this: > to recover a message the attacker has to undertake actions that involve > at least some measure of expense. Perhaps you are correct. My own definition of privacy evolves, but as of now is this: Privacy is the effective capacity to misrepresent oneself. and, semi-orthogonally, Security is the absence of unmitigatable surprise. YMMV, --dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Deniability
> Err, this is not the kind of direction I wanted this to take.
Even as a 99.44% pure lurker, me neither.
Might I suggest to those who want to argue what the plusses
and minuses are of hiding that it might be good to read Daniel
Solove's (new) Yale Press book, _Nothing to Hide_, or the paper
of the same name which preceded it?
Personally, I do think privacy and security are a zero sum
game in the main, i.e., I agree with Ed Giorgio's commentary
in the New Yorker ("The Spymaster," January 21, 2008) to that
effect. I don't like it, but what I like is irrelevant. If
zero-summed-ness is an actual fact of nature, then I'll choose
more privacy and less security as the Internet-of-Things approaches.
--dan
A conservative is a socialist who worships order.
A liberal is a socialist who worships safety.
-- Victor Milan', 1999
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Deniability
I don't think anyone was suggesting that adroit use of PGP/GPG is a talisman against those who wield lead pipes and want what they want. Not that there isn't a movie script in that line of thought... --dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: deniability
| | 2. Randomly send messages that can't be decrypted to random recipients |to obscure matters. The adversary would have to cope with the fact |that I have stuff to hide. :) | Ah. Spam as a covert channel. Tell me that this isn't already done? --dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: What is the benefit of signing an encrypted email
If one is a purist, then one wants sign>encrypt>sign See http://world.std.com/~dtd/#sign_encrypt --dan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Security considerations: CAST-128
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I understand that there are *some* security considerations when using CAST-128 (CAST5, as used in GnuPG), but this is typical of many ciphers in use today. In particular, a paper[1] on the linear cryptanalysis of reduced round versions of CAST-128 (used in GPG) and CAST-256 have produced successful known-plaintext and ciphertext-only attacks, though I'm not sure how computationally feasible they are. According to the paper, successful attacks were conducted on a 4 and 6 round version of CAST-128. Given that resources on the subject appear to be quite scarce, I come to you, O list. If anyone can clarify or elaborate on the security considerations of CAST-128, it would be greatly appreciated. Thanks, Dan [1]http://www.springerlink.com/content/978-3-642-04158-7/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzAbTgACgkQiSdIUo/InI28+ACfVACyk61T5YC3BVQIIv6CwDJb N9kAnRm8qQH8JefFhmmsmW9hJgflOZvE =7+qZ -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Changing secret key encryption algorithms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I was inspired by a thread on a friend's mishap with his secret key to look into the various ways that a GnuPG secret key can be encrypted prior to its storage on disk. On 20/10/2010 1:24 PM, Faramir wrote: > > Well, then the private key was still protected by the passphrase, I > think it uses CAST5 algorithm. > I poked around the documentation a bit and confirmed that the default cipher is CAST5 (GnuPG seems to prefer it when it needs a symmetric key cipher). After further digging, I found a way to change the symmetric key cipher used on the secret key from the default CAST5. You can discover the algorithms included in your GnuPG version by using gpg - --version, of course. I endeavored to test this by generating a new keypair on a new user. I used the following command: $ gpg --s2k-cipher-algo CAMMELIA256 --gen-key If you've got a secret key and you want to change its cipher algo, you can use the following command: $ gpg --s2k-cipher-algo --edit-key After that, you enter the passwd command in the edit key shell and change your passphrase. I used the same passphrase as I used during key generation and this posed no problem. I wonder if it is a good idea from a cryptographic standpoint, however. If anyone can comment on this, it would be appreciated. Also, it should be noted that changing the cipher algorithm used to encrypt a secret key should in no way change or impair the ability of that secret key to decrypt or sign documents. It simply changes the way in which the key is stored on the disk. However, if you use several different GnuPG versions with your secret key, you should probably check gpg --version on all of them to make sure your preferred cipher is present. After making the changes, I began digging through the documentation to find a way to verify that the Cammelia algorithm was indeed being used to encrypt my secret key. I used the following command: $ gpg --list-packets .gnupg/secring.gpg And got this output: ... iter+salt S2K, algo: 13, SHA1 protection ... ... It seems the algorithms are mapped to algo ID's. I can confirm that the algorithm is different than than the one used on my real secret key, but I had not been able to find any resources that map the algo ID's to their respective names with any completeness. I was able to find an excellent (if dated) resource on secret keys in the process[1]. I looked at the source code for GnuPG next, poking around different header files until I found this: #define CIPHER_ALGO_IDEA 1 #define CIPHER_ALGO_3DES 2 #define CIPHER_ALGO_CAST53 #define CIPHER_ALGO_BLOWFISH 4 /* blowfish 128 bit key */ /* 5 & 6 are reserved */ #define CIPHER_ALGO_AES 7 #define CIPHER_ALGO_AES192 8 #define CIPHER_ALGO_AES256 9 #define CIPHER_ALGO_TWOFISH 10 /* twofish 256 bit */ #define CIPHER_ALGO_CAMELLIA128 11 #define CIPHER_ALGO_CAMELLIA192 12 #define CIPHER_ALGO_CAMELLIA256 13 ... #define PUBKEY_ALGO_RSA1 #define PUBKEY_ALGO_RSA_E 2 /* RSA encrypt only */ #define PUBKEY_ALGO_RSA_S 3 /* RSA sign only */ #define PUBKEY_ALGO_ELGAMAL_E 16 /* encrypt only ElGamal (but not for v3)*/ #define PUBKEY_ALGO_DSA 17 #define PUBKEY_ALGO_ELGAMAL 20 /* sign and encrypt elgamal */ You can use these ID values to determine what kind of cipher or public key algorithm is being used on any piece of GnuPG data using the - --list-packets option. This post is purely informative and is the result of an early morning problem solving mission. I don't know why anyone would want to change the secret key protection algorithm, aside from personal preference. However, it is my view that if I have to go to this much trouble to find information about something, I should probably make it public. If you have any further information, want to correct or otherwise comment on the above, feel free. Regards, Dan [1]http://www.spywarewarrior.com/uiuc/ss/sec-key/sec-key.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzAbOsACgkQiSdIUo/InI0VsQCfXE6NUoOIwW4oeykFwvLOGhuj 8X0AnjICeCYEudrKvo7oEnfeKwCLbWkl =5GKj -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On 13/10/2010 4:02 PM, MFPA wrote: > The user can type their password once per session into a text file and > paste it every time it is requested. This reduces the annoyance factor > and does not train the user to constantly re-type the passphrase. > I use a program called KeePass to keep track of my passwords. It has a linux port called KeePassX, as well. It stores the password in an encrypted database and when the user requests it, copies it to the clipboard. After 20 seconds, the clipboard is cleared. KeePass can also be configured to lock the workspace after a certain period of time idle. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Paranoid People's User Group?
Hi everyone, Almost-but-not-quite my first post to this list. I am very interested in encryption technologies, and PGP in particular. Of course, this is only a hobby and I don't have any trade secrets or international intrigues to protect, so that leaves me at a bit of a disadvantage when it comes to playing around with such a fascinating piece of technology. After some googling, I decided this would be the best place to start. What I'm after is a mailing list or user group that exchanges encrypted communications with each other. Or, if no such mailing list exists, I wonder if I might be able to pick up a pen-pal or two that wants to use PGP to communicate. Thanks signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: "No-Keyserver" (and other) flags on keys
On Mon, 28 Jun 2010, David Shaw wrote: I presently consider synchronization broken. If there were only one network of keyservers out there, and I didn't have to search multiple places when trying to sign or request a key, I might think otherwise, but this is not the case. See my alternate request about being able to use multiple urls in auto-key-locate, which I don't believe currently works. It does. auto-key-locate hkp://pgp.mit.edu hkp://subkeys.pgp.net hkp://some.other.server.etc ldap://even.a.ldap.server.works Aah, perhaps here is a problem. auto-key-locate may in fact do this, but --search does not. Is there a way to make that work? -- "Ca. Tas. Tro. Phy." -John Smedley, March 28th 1998, 3AM Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: "No-Keyserver" (and other) flags on keys
On Sun, 27 Jun 2010, David Shaw wrote: However, you raise another question: How does a keyserver know who is uploading the key? At the moment, it doesn't. That would need to be addressed if you want keyservers to be able to reject a no-ks-modify key. One way to do it is to only accept key updates that are signed by the key itself. But, of course, to do that, the keyserver needs to be able to verify a signature... That's one way. Another is to do it the keyserver.pgp.com way, and email the primary uid a cookie. No crypto required. RFC2440 doesn't at all require that the authenticity be verified cryptographically. Correct? Correct, but then, RFC-2440 or 4880 doesn't say much about keyservers at all. It's mainly a message format document. Semantics of keyservers are not specified beyond one or two minor things like the no-modify flag and the "preferred keyserver" field. The difficulty with mailing the primary user ID a cookie is that it pretty much means your server can't synchronize with any other server. Keyserver A updating keyserver B for key "foo" would in essence be someone other than the owner, even if they're in the same "pool", as keyservers can have multiple names. Assumably if I have enough sense to set my preferred keyserver url (either to a keyserver or to a private url), I know which keyservers are islands and which are pools. I presently consider synchronization broken. If there were only one network of keyservers out there, and I didn't have to search multiple places when trying to sign or request a key, I might think otherwise, but this is not the case. See my alternate request about being able to use multiple urls in auto-key-locate, which I don't believe currently works. I'm also not aware of how servers synchronize, but if it's a different protocol than the standard single-key-request protocol, then there's an easy metric to say "don't hand out keys with this flag via this protocol". Perhaps if I get deeply into this, I could define keyservers which were aware of which other ones did verification. Since your server would have an entrance restriction, and the other servers won't, that means that your server would have to either reject keys from other servers (i.e. not syncing) or apply the same restriction (email user IDs from keys that weren't uploaded directly to your server). keyserver.pgp.com solves this by simply not syncing to anyone else. That makes it a completely opt-in server. I wasn't against this plan. This was (as mentioned) for work on a private keyserver whose changes would be merged upstream. Consider it an initial step toward the whole. However, I think you're still missing my question: is it necessary for the keyserver to be crypto-aware if I just want a keyserver to reject those keys outright? Is there crypto involved in reading that flag, or is it just a simple parse? From reading RFC2440 it seems the latter, but I certainly respect you've been doing this longer than I :) There is crypto involved in showing that the flag is real - that the keyholder set the flag, and not someone just setting the flag for malicious reasons. For example, take the case of a key with the no-modify flag set (i.e. the keyholder doesn't want the key on a keyserver). The attacker takes this key, and removes the flag. He then sends the key to a keyserver without crypto. The keyserver sees the key has no flag, so accepts it. This allows an attacker to violate the keyholder's requirements. If the keyserver had crypto, it would know that the key had been tampered with and the flag removed. At present, no keyservers respect this flag, with or without crypto. So that's not much of a leap, anyway. This "attack vector" exists now. I'm sure more than a few people have been annoyed that their keys wound up on a server, as I had read in a previous (and very long) thread. Without at all getting into the "flag" argument, do you feel keyservers should be verifying selfsigs before publication, or do you think they should remain "dumb"? Both imply some problems, but your statement as to keyservers not doing crypto didn't seem to imply whether you're for or against it, and I'm curious. -Dan -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: "No-Keyserver" (and other) flags on keys
On Sun, 27 Jun 2010, David Shaw wrote: On Jun 27, 2010, at 7:50 PM, Dan Mahoney, System Admin wrote: It's effectively a no-op though, as no server supports it. I'm looking into making mods to at least one server type (we run one locally at work), and commit them upstream. If I'm going to wade into that muck, I might as well have multiple things to try to make work. The change in the key file format is the "hard" part :) Having keyservers support no-modify requires that they first support crypto at all. That's a really big step. The ones I've seen have enough awareness of what's in a key to pull a key apart and determine who's signed it, when, and when it's expired. Is there more than that to read these bits? Again:step zero may be to determine what the internal format is. Vastly more. Keyservers are basically databases with a front-end that understands the OpenPGP key format. They don't actually do any crypto math - just storing the key packets in the database and allowing people to search for them. However, you raise another question: How does a keyserver know who is uploading the key? At the moment, it doesn't. That would need to be addressed if you want keyservers to be able to reject a no-ks-modify key. One way to do it is to only accept key updates that are signed by the key itself. But, of course, to do that, the keyserver needs to be able to verify a signature... That's one way. Another is to do it the keyserver.pgp.com way, and email the primary uid a cookie. No crypto required. RFC2440 doesn't at all require that the authenticity be verified cryptographically. Correct? While we're at this, do the various keyserver client-implementations provide any option for passing a human-readable message back to gpg? I don't see anything in draft-shaw-openpgp-hkp-00, but that's long expired (but good reading). From what you're telling me, it also sounds like keyservers don't actually verify the signatures that are on a key, and that's left up to the client. However, I think you're still missing my question: is it necessary for the keyserver to be crypto-aware if I just want a keyserver to reject those keys outright? Is there crypto involved in reading that flag, or is it just a simple parse? From reading RFC2440 it seems the latter, but I certainly respect you've been doing this longer than I :) -Dan -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: "No-Keyserver" (and other) flags on keys
On Sun, 27 Jun 2010, David Shaw wrote: It's a flag that can be set on a key user ID, similar to cipher or compression preferences. Run "--edit-key" on a key, and enter "showpref" or "pref". You will probably see a mention of "Keyserver no-modify" (or "no-ks-modify"). You can turn it on and off with setpref, like any other preference: "ks-modify" allows keyserver modifications, and "no-ks-modify" disallows them. Note that the definition of no-modify is that only the keyholder (or the administrator of the keyserver) can override it. So the flag only applies to other people - the keyholder can choose to upload his key if he so desires. Also, is it possible for either the manpage or the interactive help to include the meaning of the various preferences that are not cipher types? Sure enough, it's not in the man page. I'll fix that. I'd love to see an "editpref" which more interactively presented you with options (and descriptions) you could toggle (but would still maintain backwards compatibility with apps that used showpref or setpref) It's effectively a no-op though, as no server supports it. I'm looking into making mods to at least one server type (we run one locally at work), and commit them upstream. If I'm going to wade into that muck, I might as well have multiple things to try to make work. The change in the key file format is the "hard" part :) Having keyservers support no-modify requires that they first support crypto at all. That's a really big step. The ones I've seen have enough awareness of what's in a key to pull a key apart and determine who's signed it, when, and when it's expired. Is there more than that to read these bits? Again:step zero may be to determine what the internal format is. However, you raise another question: How does a keyserver know who is uploading the key? (Note that this doesn't apply to my original question, since that was simply a "keyservers should throw this away" flag, where a user might choose to publish on his website, his .plan file, on his business cards, in DNS, or via LDAP or S/Mime autodiscovery.) -Dan -- "Hitler, Satan, those Hanson kids, anything. Just not the curious anteater." -Peter Scolari, as Wayne Szalinki in "Honey, I Shrunk The Kids--The Series" Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: "No-Keyserver" (and other) flags on keys
On Sun, 27 Jun 2010, David Shaw wrote: On Jun 27, 2010, at 3:58 PM, Dan Mahoney, System Admin wrote: All, How difficult would it be to propose some kind of extension flag to the PGP key format that in essence says "don't publish me to a keyserver". Note that I'm asking from a technical point of view, not a social (i.e. making servers support it) or IETF one (insert bikesheds here). My question is: Is it possible to do in such a way that keys would be backward-compatible? Not only is it possible, it already exists. GnuPG can even set it and unset it, as you like. Really? Where is it? Also, is it possible for either the manpage or the interactive help to include the meaning of the various preferences that are not cipher types? It's effectively a no-op though, as no server supports it. I'm looking into making mods to at least one server type (we run one locally at work), and commit them upstream. If I'm going to wade into that muck, I might as well have multiple things to try to make work. The change in the key file format is the "hard" part :) -Dan -- "She's been getting attacked by these leeches, they're leaving these marks all over her neck. You gotta keep her out of those woods. If one more leech gets her, she's gonna get a smack." -Someone's Mother, December 18th, 1998 Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
"No-Keyserver" (and other) flags on keys
All, How difficult would it be to propose some kind of extension flag to the PGP key format that in essence says "don't publish me to a keyserver". Note that I'm asking from a technical point of view, not a social (i.e. making servers support it) or IETF one (insert bikesheds here). My question is: Is it possible to do in such a way that keys would be backward-compatible? (I have no idea about the internal format of a PGP key, to me it's just bricktext...at least right now). -Dan -- "If you aren't going to try something, then we might as well just be friends." "We can't have that now, can we?" -SK & Dan Mahoney, December 9, 1998 Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Using gpg2 without pinentry?
Hey there, I currently use gnupg 1 from within Alpine (running under screen), and it works okay, but I had a bear of a time using gpg2 because of the pinentry stuff. Specifically, gpg was launched within a mail filter, and had no idea how to spawn a third program (the pinentry window)) in a correct way. I've tried kludging it so it launches in a different screen by tweaking various environment variables, but this seems the wrong way to go about it. As does running with X-forwarding just to launch a tiny pinentry app (I can't guarantee I'll have an xserv everywhere I sit.) Is there some reasonable way that gpg can detect that it has a controlling termainal (or even, a config file option) and just ask me for my passphrase on stdin? I am my sysadmin. I trust me :) -Dan -- "Let me tell you something about regrowing your dead wife Lucy, Harry. It's probably illegal, potentially dangerous, and definitely crazy." -Harry nods- Vincent Spano, as Boris in "Creator". Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Searching multiple keyservers
On Wed, 23 Jun 2010, MFPA wrote: PGP Command Output Warning: using insecure memory! gpg: Signature made Wed Jun 23 12:59:05 2010 EDT using RSA key ID AD0C6E69 gpg: Good signature from "MFPA " 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: BA 23 9B 46 81 F1 EF 95 18 E6 BD 46 44 7E CA 03 --- Begin PGP Signed Message Verified 2010-06-23 13:25:55 -- Hi On Wednesday 23 June 2010 at 9:27:01 AM, in , Laurent Jumet wrote: Using GPGShell allows "Update from all keyservers". "all" being simply all the ones you have listed in your gpgshell config file. IIRC, you have a list for fetching/updating keys and another list for submitting keys - the latter may be useful to specify servers you know don't synchronise reliably, when posting revocations. Considering I'm running on a FreeBSD system, however... -Dan -- "It would be bad." -Egon Spengler, "Ghostbusters" Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Searching multiple keyservers
Hey all, Is there an easy syntax to chain multiple keyservers for searching? In theory it shouldn't be necessary, but there are distinct keyserver networks out there that don't share, as well as "private" hkp keyservers which might need to be searched first. -Dan -- "SOY BOMB!" -The Chest of the nameless streaker of the 1998 Grammy Awards' Bob Dylan Performance. Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Using the "clean" function (and the "PGP Global Directory")
On Tue, 22 Jun 2010, Dan Mahoney, System Admin wrote: On Tue, 22 Jun 2010, David Shaw wrote: On Jun 22, 2010, at 11:02 PM, Dan Mahoney, System Admin wrote: It seems there's two interesting problems which inter-relate. The first is PGP corporation's "global directory", which seems to operate orthogonally from every other keyserver I've seen. It's HTTP-only, not queryable by any of the open-source clients (in fact, it doesn't support wildcard searches at all, and returns a captcha before delivering results), and not SUBMITTABLE to from any of the open source clients. Not exactly. The GD speaks LDAP, so you can set your keyserver to ldap://keyserver.pgp.com and you can query and submit, etc. Interesting, I didn't see mention of that. I must try this (assuming I've built with LDAP support, that is, which under BSD is a bit obtuse). It's also the ONLY keyserver I've seen that supports photo IDs, and actually uses the web interface to show you the person. The SKS servers (i.e. pretty much everything that isn't the GD) do support photo IDs, but they do not use the web interface to show you the photo. That was what I meant to imply, perhaps I was unclear. Are you sure about that? "clean" strips off useless signatures (useless being defined as an invalid signature, a superseded signature, a revoked signature, and a signature from a key that isn't present on the keyring). Signatures from keys that are present, but have no trust value are not stripped off. Let me double check. I saw it earlier today when transferring my work sig to my personal one. But it might just have been that my coworkers did not have sigs present. It's entirely possible I mangled the windows. Yup, that's what happened. I had imported my work key to my personal machine, but didn't have the keys of all my coworkers on my personal box, so "clean" decided to be helpful. I pulled it off the keyserver again, and then pulled down the keys of all my coworkers, and was good. On a related subject, is there a way to say "pull down the keys of all keyids who have signed key X"? -Dan -- "Long live little fat girls!" -Recent Taco Bell Ad Slogan, Literally Translated. (Viva Gorditas) Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Using the "clean" function (and the "PGP Global Directory")
On Tue, 22 Jun 2010, David Shaw wrote: On Jun 22, 2010, at 11:02 PM, Dan Mahoney, System Admin wrote: It seems there's two interesting problems which inter-relate. The first is PGP corporation's "global directory", which seems to operate orthogonally from every other keyserver I've seen. It's HTTP-only, not queryable by any of the open-source clients (in fact, it doesn't support wildcard searches at all, and returns a captcha before delivering results), and not SUBMITTABLE to from any of the open source clients. Not exactly. The GD speaks LDAP, so you can set your keyserver to ldap://keyserver.pgp.com and you can query and submit, etc. Interesting, I didn't see mention of that. I must try this (assuming I've built with LDAP support, that is, which under BSD is a bit obtuse). It's also the ONLY keyserver I've seen that supports photo IDs, and actually uses the web interface to show you the person. The SKS servers (i.e. pretty much everything that isn't the GD) do support photo IDs, but they do not use the web interface to show you the photo. That was what I meant to imply, perhaps I was unclear. Are you sure about that? "clean" strips off useless signatures (useless being defined as an invalid signature, a superseded signature, a revoked signature, and a signature from a key that isn't present on the keyring). Signatures from keys that are present, but have no trust value are not stripped off. Let me double check. I saw it earlier today when transferring my work sig to my personal one. But it might just have been that my coworkers did not have sigs present. It's entirely possible I mangled the windows. -Dan -- "GO HOME AND COOK!!!" Donielle Cocossa, Taco Bell, 2:30 AM Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Using the "clean" function (and the "PGP Global Directory")
It seems there's two interesting problems which inter-relate. The first is PGP corporation's "global directory", which seems to operate orthogonally from every other keyserver I've seen. It's HTTP-only, not queryable by any of the open-source clients (in fact, it doesn't support wildcard searches at all, and returns a captcha before delivering results), and not SUBMITTABLE to from any of the open source clients. It's also the ONLY keyserver I've seen that supports photo IDs, and actually uses the web interface to show you the person. Finally, it will sign your non-photo-uids. With a very short signature time, and pollute them so they look like this: uid Dan Mahoney sig 3E919EC51 2008-11-22 Dan Mahoney sig 3E8048D08 2009-10-15 Peter Losher sig 68D482E2 2009-08-31 Guy Sisalli sig CF9890F8 2009-07-01 Mark Andrews sig 08F13AD2 2009-10-14 Evan Hunt sig 3294EC062 2009-06-30 Paul Vlaar sig 2DC6FF82 2009-10-14 Rob Austein sig 8FA50232 2010-06-13 Emma Smith sig X CA57AD7C 2009-12-16 PGP Global Directory Verification Key sig X CA57AD7C 2009-12-29 PGP Global Directory Verification Key sig X CA57AD7C 2010-01-12 PGP Global Directory Verification Key sig X CA57AD7C 2010-01-25 PGP Global Directory Verification Key sig X CA57AD7C 2010-02-07 PGP Global Directory Verification Key sig X CA57AD7C 2010-02-20 PGP Global Directory Verification Key sig B38DB1BE 2010-06-13 Francisco Obispo (ISC) uid Dan Mahoney Yes, I'm sure I need a signature added to my key EVERY TWO WEEKS. From the same ENTITY. So, to correct this, gpg has the "clean" function, except that it seems to be broken. I can then re-upload my key. "clean" kills off any local signature and uid that is expired, but it also removes keys I have no trust value for. This might make sense on someone ELSE'S key in my homedir. But I want EVERY nonexpired signature to stay on my public key, even if I don't have an explicit trust value for the person. A workaround is to assign some trust value to every other person who's signed my key, then run --clean, but this seems broken. So, all that said, two questions. 1) Is there some option I'm missing that will just remove expired signatures, and not other things? Assume I'm still interested in the social networking aspect of who-knows-who and who-trusts-who, but not interested in this automated "I figured out a web url three years ago" noise. 2) If I find the magic way to do #1, and upload it to a keyserver, will they accept it, or will they just re-merge the expired sigs in? (For most common keyservers). -Dan -- "Ca. Tas. Tro. Phy." -John Smedley, March 28th 1998, 3AM Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: IDEA Status?
On Tue, 22 Jun 2010, Robert J. Hansen wrote: On 6/22/10 10:09 PM, Dan Mahoney, System Admin wrote: Is this very old and it's now supported? Or is it still not in for some other reason (either oversight, legal, or other). By modern standards, IDEA is not considered a promising cipher. There are some very good theoretical attacks against it. Between the varying patent expiration dates (2011 or so in some countries, IIRC) and the thin safety margin, the GnuPG community has generally decided IDEA is not a priority for inclusion. Could the FAQ be updated then, assuming you speak with some authority? -Dan -- "Ca. Tas. Tro. Phy." -John Smedley, March 28th 1998, 3AM Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
IDEA Status?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey there, The FAQ for IDEA states that "The official GnuPG distribution does not contain IDEA due to a patent restriction. The patent does not expire before 2007 so don't expect official support before then." (http://gnupg.org/documentation/faqs.en.html#q3.3) Is this very old and it's now supported? Or is it still not in for some other reason (either oversight, legal, or other). - -Dan - -- - Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org - --- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkwhbOIACgkQ+75aMGJLskl+HwCgxUxctq090JveZu+QZmRi+Ziy GeUAoMiqGgZZp+Rs+5eQfXomssnaqf0k =GTdI -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ...key belongs to ...
On Sun, 30 May 2010, Michael D. Berger wrote: On a Linux box, in encrypting a file with gpg, I get this query: It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. Use this key anyway? (y/N) n Now in the context in which this is being used, there is no uncertainty regarding key ownership, and the encryption is part of a bash script. The query stops the script. Therefore, how can I prevent this query? Edit the trust of the key, and or sign it with a trust signature. -Dan -- "Don't be so depressed dear." "I have no endorphins, what am I supposed to do?" -DM and SK, February 10th, 1999 Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: new Installation... configure issues
On Mon, 24 May 2010, raviraj kondraguntla wrote: Hi, I am trying to install the gnupg 1.4.10 on solaris 10 server, I have received the below error configure:3550: /opt/SUNWspro/bin/cc --version >&5 ./configure: line 3551: /opt/SUNWspro/bin/cc: No such file or directory configure:3553: $? = 127 configure:3560: /opt/SUNWspro/bin/cc -v >&5 ./configure: line 3561: /opt/SUNWspro/bin/cc: No such file or directory configure:3563: $? = 127 configure:3570: /opt/SUNWspro/bin/cc -V >&5 ./configure: line 3571: /opt/SUNWspro/bin/cc: No such file or directory configure:3573: $? = 127 configure:3596: checking for C compiler default output file name It seems, I need to install C compiler by installing SPROcc 9(unbundled SPARCworks Professional C compiler) Please advise on this. Thanks, Raj You could just install gcc. -Dan -- "Blargy Frap!" -mtreal, efnet #macintosh channel, 8.10.98, Approx 3AM Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Symantec buys PGP and Guardian Edge
By Jeremy Kirk, IDG News Service http://www.pcworld.com/businesscenter/article/195217/symantec_buys_encryption_specialist_pgp_for_300m.html Symantec will acquire encryption specialist PGP and endpoint security vendor GuardianEdge Technologies for US$300 million and $70 million respectively, the company said on Thursday. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Implications Of The Recent RSA Vulnerability
On Thu, 11 Mar 2010, erythrocyte wrote: With the recent news of researchers being able to crack 1024-bit RSA keys using power fluctuations, I was wondering if it would be a good idea to switch the RSA keys I have to some other algorithm. Both my signing and encryption keys are 4096-bit keys. Am I vulnerable to this security hole? Is it possible to generate a new keypair and retain/transfer the old signatures from my email buddies? Ref: http://www.engadget.com/2010/03/09/1024-bit-rsa-encryption-cracked-by-carefully-starving-cpu-of-ele/ Okay, let me sum up this article for you: Researchers who had physical enough access to be able to rewire the private-key-holder's system's power supply were able to compromise that system. If you're at that point, I don't think key length is your problem. -Dan Mahoney -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Continued PKA problems on Windows
On Wed, 3 Mar 2010, Grant Olson wrote: On 3/3/2010 5:26 PM, Sean Rima wrote: Folks I downloaded and installed gpg4win-2.0.2rc1. I then tested my pka setup using: echo "foo" | gpg2 --no-default-keyring --keyring c:\temp\gpg --encrypt --armor --auto-key-locate pka -r s...@srima.eu -v 2> test.txt ... The only thing I can think is that the site is on Google apps or am I missing something else. I can post my gpg.conf if that helps Sean I noticed two things that may or may not matter... If I open "http://prime.gushi.org/danm.pubkey.txt"; in firefox, it opens right in the browser. If I open yours, it opens a "Save As..." window. So they have different content types. Also, the url listed in the firefox "Save as" window is some crazy computer generated url, not www.srima.eu. Just doing a quick test with curl, it takes like 4 302 redirects before you actually get to the file. It wouldn't be totally unsurprising to me if a series of redirects caused problems. So, if you're interested in comparing apples to apples, for curiosity I just uploaded your pubkey (sean.pubkey.txt) to the same url as danm.pubkey.txt). See if that fixes it, at least for testing. -Dan -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
