Re: Short ID Collision
On Thu, Dec 29, 2011 at 2:18 AM, John Clizbe j...@enigmail.net 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=indexoptions=mrsearch=0x22AD5874F39D989Fexact=on vs. http://pgp.mit.edu:11371/pks/lookup?op=indexoptions=mrsearch=0xF39D989Fexact=on Public key lookup, both work: http://pgp.mit.edu:11371/pks/lookup?op=indexoptions=mrsearch=0x6D1A9E70E19DAA50exact=on vs. http://pgp.mit.edu:11371/pks/lookup?op=indexoptions=mrsearch=0xE19DAA50exact=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 w...@gnupg.org 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
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 w...@gnupg.org 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
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: Creating a quickly expiring signature
On Thu, Jul 28, 2011 at 5:04 PM, David Shaw ds...@jabberwocky.com 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
Re: Generate digest and signature seperately
On Sun, Jun 12, 2011 at 7:54 PM, Jerome Baum jer...@jeromebaum.com 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 w...@gnupg.org 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 dpmc...@gmail.com gpg: aka Dan McGee (Developer) d...@archlinux.org gpg: aka Dan McGee (Jabber) toofis...@toofishes.net 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 dpmc...@gmail.com gpg: aka Dan McGee (Developer) d...@archlinux.org gpg: aka Dan McGee (Jabber) toofis...@toofishes.net 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
