Re: Working with a system-shared keyring
On Thu, 18 Aug 2011 10:41, sat...@pgpru.com said: > Same here. Maybe i'm missing something, but it seems without the ability > to have multiple keyrings in GPG configuration one will lose an ability > to use detached subkeys (or actually any private keys) stored on a I am using offline key parts for a long time and iirc, I even implemeented that. With 2.1 it is even much easier - there is no more secring.gpg. All secret keys are stored as separate files in .gnupg/private-key-v1.d. If you want to take a key offline, you only need to remove that. It is way easier than what we have now. 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: Working with a system-shared keyring
Doug Barton: > On 08/09/2011 02:38, Werner Koch wrote: >> On Fri, 10 Jun 2011 20:43, do...@dougbarton.us said: >> But fixes a lot of problems. The keyring is a database and if we distribute this database to several files without a way to sync them; this leads to problems. You may have not been affected by such problems but only due to the way you use gpg. >>> >>> Can you elaborate on those problems? I can think of several examples >>> of databases whose contents are stored in multiple files without any >>> difficulty, so I'm curious. >> >> But in those cases the files are either under the control of the >> database or partitioned using a well defined scheme. With the --keyring >> option this is different: You may add several keyrings to GnuPG and >> remove them later. There is no way GPG can tell whether there are >> duplicates or which instances of a duplicated entry it needs to update. >> Sure, we could make this working but I it will get really complex. Thus >> it is far easier to have one file or set of files which are under the >> sole control of GPG. > > Easier to code maybe. But I still maintain that losing the ability to > have multiple keyrings will be a significant loss of functionality for > the user. Significant enough for me that I would likely go back to the > 1.4 branch (with regrets, since I like some of the functionality that is > provided in 2.x now). Same here. Maybe i'm missing something, but it seems without the ability to have multiple keyrings in GPG configuration one will lose an ability to use detached subkeys (or actually any private keys) stored on a removable USB drive for example. Does smartcards become the only approved and *supported* way for non-local storage of private keys? -- Vlad "SATtva" Miller 3d viz | security & privacy consulting www.vladmiller.info | www.pgpru.com ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Working with a system-shared keyring
On 08/09/2011 02:38, Werner Koch wrote: > On Fri, 10 Jun 2011 20:43, do...@dougbarton.us said: > >>> But fixes a lot of problems. The keyring is a database and if we >>> distribute this database to several files without a way to sync them; >>> this leads to problems. You may have not been affected by such problems >>> but only due to the way you use gpg. >> >> Can you elaborate on those problems? I can think of several examples >> of databases whose contents are stored in multiple files without any >> difficulty, so I'm curious. > > But in those cases the files are either under the control of the > database or partitioned using a well defined scheme. With the --keyring > option this is different: You may add several keyrings to GnuPG and > remove them later. There is no way GPG can tell whether there are > duplicates or which instances of a duplicated entry it needs to update. > Sure, we could make this working but I it will get really complex. Thus > it is far easier to have one file or set of files which are under the > sole control of GPG. Easier to code maybe. But I still maintain that losing the ability to have multiple keyrings will be a significant loss of functionality for the user. Significant enough for me that I would likely go back to the 1.4 branch (with regrets, since I like some of the functionality that is provided in 2.x now). Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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, 10 Jun 2011 20:43, do...@dougbarton.us said: >> But fixes a lot of problems. The keyring is a database and if we >> distribute this database to several files without a way to sync them; >> this leads to problems. You may have not been affected by such problems >> but only due to the way you use gpg. > > Can you elaborate on those problems? I can think of several examples > of databases whose contents are stored in multiple files without any > difficulty, so I'm curious. But in those cases the files are either under the control of the database or partitioned using a well defined scheme. With the --keyring option this is different: You may add several keyrings to GnuPG and remove them later. There is no way GPG can tell whether there are duplicates or which instances of a duplicated entry it needs to update. Sure, we could make this working but I it will get really complex. Thus it is far easier to have one file or set of files which are under the sole control of GPG. Salam-Shalom, 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: Working with a system-shared keyring
On 06/10/2011 02:43 PM, Doug Barton wrote: > Actually I'm very careful to avoid doing just that. :) I have various > command-line aliases to move keys between rings depending on their > status, de-duplicate on import, and cross-check to make sure that I > haven't missed something. Could you share these tools? They sound useful to me. regards, --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Working with a system-shared keyring
On 6/9/2011 11:56 PM, Werner Koch wrote: On Thu, 9 Jun 2011 22:38, do...@dougbarton.us said: IMO that would be a serious regression. I have several different But fixes a lot of problems. The keyring is a database and if we distribute this database to several files without a way to sync them; this leads to problems. You may have not been affected by such problems but only due to the way you use gpg. Can you elaborate on those problems? I can think of several examples of databases whose contents are stored in multiple files without any difficulty, so I'm curious. it easy to keep things up to date. I also use keyrings to keep the keys that have signed my key, keys that I've signed, etc. That's easy to figure out. Your approach keeps duplicates of the keys; duplicating data is something which should not been done. Actually I'm very careful to avoid doing just that. :) I have various command-line aliases to move keys between rings depending on their status, de-duplicate on import, and cross-check to make sure that I haven't missed something. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Working with a system-shared keyring
On Thu, 9 Jun 2011 22:38, do...@dougbarton.us said: > IMO that would be a serious regression. I have several different But fixes a lot of problems. The keyring is a database and if we distribute this database to several files without a way to sync them; this leads to problems. You may have not been affected by such problems but only due to the way you use gpg. > it easy to keep things up to date. I also use keyrings to keep the > keys that have signed my key, keys that I've signed, etc. That's easy to figure out. Your approach keeps duplicates of the keys; duplicating data is something which should not been done. Salam-Shalom, 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: Working with a system-shared keyring
On 06/03/2011 00:19, Werner Koch wrote: Be warned that future gpg versions may not support the use of multiple keyrings. IMO that would be a serious regression. I have several different spheres where I use PGP, and I use various different keyrings to make it easy to keep things up to date. I also use keyrings to keep the keys that have signed my key, keys that I've signed, etc. I realize that my use is exceptional, and that the average gnupg user isn't going to have nearly as many separate keyrings as I do, but I'd hate to lose that capability. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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
Re: Working with a system-shared keyring
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. What we currently do is to write changes to the first writable keyring. This may lead to a situation were we have 2 copies of the keys; one updated and one not updated. > 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. 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. 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 (gpgme_protocol_t PROTO, const char *FILE_NAME, const char *HOME_DIR) The function `gpgme_set_engine_info' changes the default configuration of the crypto engine implementing the protocol PROTO. FILE_NAME is the file name of the executable program implementing this protocol, and HOME_DIR is the directory name of the configuration directory for this crypto engine. If HOME_DIR is `NULL', the engine's default will be used. The new defaults are not applied to already created GPGME contexts. This function returns the error code `GPG_ERR_NO_ERROR' if successful, or an eror code on failure. The functions `gpgme_ctx_get_engine_info' and `gpgme_ctx_set_engine_info' can be used to change the engine configuration per context. *Note Crypto Engine::. 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: Working with a system-shared keyring
Am 02.06.2011 00:41, schrieb Dan McGee: > 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? > I'd try not relocating the homedir, but only the keyring location. If you have a means of distributing a gpg.conf to everyone's home directory, you could insert no-default-keyring keyring /etc/pacman.d/gnupg Not sure about the secret keyring, though. It should not try to use ~/.gnupg/secring.gpg, so trying to import a secret key or generate a new one should give an error. I assume that's what you intend. A home directory with wrong permissions and/or read-only is granted to give problems with various applications. Bye, Andreas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
