From bernhard at intevation.de Wed Nov 8 11:00:01 2006 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed Nov 8 22:00:10 2006 Subject: Wish: group support for Kmail and gnupg Message-ID: <200611081100.02441.bernhard@intevation.de> Hi Werner, Hi Marc, I like to bring up the support for groups (aka aliases of gnupg recipients) for KMail. (There probably is an issue for this as well, but I am currently offline.) My thoughts: Currently gnupg has the --group feature, I believe that keeping recipient alises on the gnupg level is good, as this is the place where recipients are checked anyway. The alternative: Associate several keys with one email adress oder identifier on client level. This seems more cumbersome to me. To improve the current situation is would be a good next step to have KMail make it possible to select a gnupg group from the interface when it is looking for a key for an email address. For this gnupg must somehow provide the list of groups on request. Werner: Do we have such a method in gpgme already? On KMail side it would involve adding code to retrieve this list and add it to the selection dialog. Bernhard -- Managing Director - Owner, www.intevation.net (Free Software Company) Germany Coordinator, fsfeurope.org (Non-Profit Org for Free Software) www.kolab-konsortium.com (Email/Groupware Solution, Professional Service) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20061108/701af969/attachment.pgp From jan at intevation.de Tue Nov 21 23:39:46 2006 From: jan at intevation.de (Jan-Oliver Wagner) Date: Wed Nov 22 01:23:58 2006 Subject: Separate mailing lists for gpa? Message-ID: <200611212339.46888.jan@intevation.de> Hi, since a while gpa has a nice new infrastructure at http://wald.intevation.org/projects/gpa/ . Wouldn't it make sense to create there the mailing lists "gpa-users" and "gpa-devel" for the respective discussion groups. This might be a chance to generate more noise, ie. to be more attractive to get in contact. gpa-dev@gnupg.org probably has too unclear objectives? Best Jan -- Jan-Oliver Wagner: www.intevation.de/~jan | GISpatcher: www.gispatcher.de Kolab Konsortium : www.kolab-konsortium.de | Thuban : thuban.intevation.org Intevation GmbH : www.intevation.de | Kolab : www.kolab.org FreeGIS : www.freegis.org | GAV : www.grass-verein.de From jan at intevation.de Tue Nov 21 23:40:01 2006 From: jan at intevation.de (Jan-Oliver Wagner) Date: Wed Nov 22 01:24:03 2006 Subject: Upgrade gpa from GTK+ 2.2 to 2.4? Message-ID: <200611212340.01633.jan@intevation.de> Hi gpa developers, I wonder whether there is any reason not to upgrade the minimum version of GTK+ 2.2 to 2.4. With 2.4 various new interesting methods have been introduced. Getting rid of any deprecated methods is also interesting, I guess. Or is even GTK+ 2.6 something we can assume to be everywhere where gpa aims for? Best Jan -- Jan-Oliver Wagner: www.intevation.de/~jan | GISpatcher: www.gispatcher.de Kolab Konsortium : www.kolab-konsortium.de | Thuban : thuban.intevation.org Intevation GmbH : www.intevation.de | Kolab : www.kolab.org FreeGIS : www.freegis.org | GAV : www.grass-verein.de From marcus.brinkmann at ruhr-uni-bochum.de Wed Nov 22 16:17:13 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed Nov 22 16:54:05 2006 Subject: Upgrade gpa from GTK+ 2.2 to 2.4? In-Reply-To: <200611212340.01633.jan@intevation.de> References: <200611212340.01633.jan@intevation.de> Message-ID: <87r6vvzf2e.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Tue, 21 Nov 2006 23:40:01 +0100, Jan-Oliver Wagner wrote: > > Hi gpa developers, > > I wonder whether there is any reason not to upgrade the minimum version > of GTK+ 2.2 to 2.4. With 2.4 various new interesting methods have been > introduced. I have no objection; however, such a bumb should be done when the new methods are actually used (ie, ideally, the minimum required version should reflect the minimum actually required version). > Getting rid of any deprecated methods is also interesting, I guess. > Or is even GTK+ 2.6 something we can assume to be everywhere where > gpa aims for? Again, the minimum required version should be motivated by actual changes in the code base. Currently, we build gpg4win against glib 2.9 and gtk 2.6. As such I have no objection to go up to there, assuming the windows port of that version is complete with respect to the features you want to use. Beyond that (say, 2.8), more testing would be required if the new version compiles and runs correctly on Windows. Gtk 2.8 was released over a year ago, so we can go even up to that. It seems to be the current stable version in use in distributions (Ubuntu Drapper for example). The limiting factor is the Windows port. Thanks, Marcus From wk at gnupg.org Wed Nov 29 17:54:15 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Nov 29 18:54:51 2006 Subject: Separate mailing lists for gpa? In-Reply-To: <200611212339.46888.jan@intevation.de> (Jan-Oliver Wagner's message of "Tue\, 21 Nov 2006 23\:39\:46 +0100") References: <200611212339.46888.jan@intevation.de> Message-ID: <87mz6ap51k.fsf@wheatstone.g10code.de> On Tue, 21 Nov 2006 23:39, jan@intevation.de said: > This might be a chance to generate more noise, ie. to be more > attractive to get in contact. gpa-dev@gnupg.org probably has > too unclear objectives? Agreed. I don't know for what gpa-dev should actually be used for. In the past we used it for Aegypten related stuff. Now that GnuPG 2.0 has been released the regular GnuPG mailing lists are better suited for this. Even the extra tools like dirmngr and pinentry have their place there because they are closely related to GnuPG. Thus we might even thinking of closing gpa-dev and moving existing users over to another lists. That list should then be used for GPA - in the sense of gpa-x.y.z.tar.bz2. I don't know whether a user and a developer list is justified. gpa-users@wald... is probably sufficient for now. Salam-Shalom, Werner From wk at gnupg.org Wed Nov 29 18:03:09 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Nov 29 18:56:16 2006 Subject: Wish: group support for Kmail and gnupg In-Reply-To: <200611081100.02441.bernhard@intevation.de> (Bernhard Reiter's message of "Wed\, 8 Nov 2006 11\:00\:01 +0100") References: <200611081100.02441.bernhard@intevation.de> Message-ID: <87irgyp4mq.fsf@wheatstone.g10code.de> On Wed, 8 Nov 2006 11:00, bernhard@intevation.de said: > The alternative: Associate several keys with one email adress oder identifier > on client level. This seems more cumbersome to me. That is in fact the only solid way to implement it. The --group sopport in gpg was a hack and I always feared the problems. > To improve the current situation is would be a good next step to have > KMail make it possible to select a gnupg group from the interface when > it is looking for a key for an email address. > For this gnupg must somehow provide the list of groups on request. > Werner: Do we have such a method in gpgme already? $ gpg --with-colons --list-config group Returns a listing of all defined groups. This does not use the configure interface, though. I am still not convinced that the group feature is a good idea. To implement it properly we need anotehr database to store these aliases - using the configure file is a hack which does not scale. I thinking of a gpgk daemon to manage keys - with such a new infrastructure we could easily add aliases. But it is all not a good solution: The receiving MUA does not know about this mapping and may want to complain about a mismatch in the addresses used in the mail and those used in the key to encrypt it. Shalom-Salam, Werner From bernhard at intevation.de Thu Nov 30 12:15:51 2006 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu Nov 30 12:13:49 2006 Subject: Wish: group support for Kmail and gnupg In-Reply-To: <87irgyp4mq.fsf@wheatstone.g10code.de> References: <200611081100.02441.bernhard@intevation.de> <87irgyp4mq.fsf@wheatstone.g10code.de> Message-ID: <200611301215.56153.bernhard@intevation.de> On Wednesday 29 November 2006 18:03, Werner Koch wrote: > On Wed, 8 Nov 2006 11:00, bernhard@intevation.de said: > > The alternative: Associate several keys with one email adress oder > > identifier on client level. This seems more cumbersome to me. > > That is in fact the only solid way to implement it. I am unsure about this. Actually the association from key to user id (including) email address happens on the gpg level already. So having several clients like KMail, mutt and other frontends that can make use of this information, this information is best maintained at the same level than the user ids. Doing this sort of associations in frontends will multiply the place where it would need to be configured. > The --group > sopport in gpg was a hack and I always feared the problems. It solves an important use case: I know that more than one person is behind one email address, having several keys. I want to send there. > > To improve the current situation is would be a good next step to have > > KMail make it possible to select a gnupg group from the interface when > > it is looking for a key for an email address. > > For this gnupg must somehow provide the list of groups on request. > > Werner: Do we have such a method in gpgme already? > > $ gpg --with-colons --list-config group > > Returns a listing of all defined groups. This does not use the > configure interface, though. As I can ask for user ids over gpgme, I would expect this to be available via gpgme and not via the configure interface. > I am still not convinced that the group > feature is a good idea. The use case described above is real and to promote encryption, it should be made easier to solve for frontends. > To implement it properly we need anotehr > database to store these aliases - using the configure file is a hack > which does not scale. I cannot say much about the implementation side. > I thinking of a gpgk daemon to manage keys - with such a new > infrastructure we could easily add aliases. But it is all not a good > solution: The receiving MUA does not know about this mapping and may > want to complain about a mismatch in the addresses used in the mail > and those used in the key to encrypt it. Bernhard -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1310 bytes Desc: not available Url : /pipermail/attachments/20061130/44b7c0ff/smime.bin From wk at gnupg.org Thu Nov 30 12:32:25 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Nov 30 12:37:03 2006 Subject: Wish: group support for Kmail and gnupg In-Reply-To: <200611301215.56153.bernhard@intevation.de> (Bernhard Reiter's message of "Thu\, 30 Nov 2006 12\:15\:51 +0100") References: <200611081100.02441.bernhard@intevation.de> <87irgyp4mq.fsf@wheatstone.g10code.de> <200611301215.56153.bernhard@intevation.de> Message-ID: <87mz69jhkm.fsf@wheatstone.g10code.de> On Thu, 30 Nov 2006 12:15, bernhard@intevation.de said: > Actually the association from key to user id (including) email address > happens on the gpg level already. So having several clients That is coincidence. A key does not need to have an email address. Well, most do but it is not a requirement of gnupg. > like KMail, mutt and other frontends that can make use of this information, > this information is best maintained at the same level than the user ids. Frontends have much more information about email adresses. They need to handle To, Cc and especailly Bcc - gpg does not know about this. MUAs can also keep track of communication patterns and assign trust to a key by looking at these patterns. I hope this will eventually be implemented. Adding this stuff to gpg will finally add knowledge about email to it which is not the Unix way. I even hesitated to add PKA to gpg but this is an exception because no other way to implement it exists. > It solves an important use case: I know that more than one person > is behind one email address, having several keys. I want to send there. For me it jutts works adding these addresses to a --group. It is more of a problem with some MUAs. Then again it should be fixed in the MUA. > As I can ask for user ids over gpgme, I would expect this to be available > via gpgme and not via the configure interface. No, it is not a key, it does not work. > The use case described above is real and to promote encryption, > it should be made easier to solve for frontends. So where is the actual problem you want to solve? It is Mutt, which checks each recipient's key validity instead of leaving this to gpg. Right? Shalom-Salam, Werner From kloecker at kde.org Thu Nov 30 20:31:35 2006 From: kloecker at kde.org (Ingo =?iso-8859-15?q?Kl=F6cker?=) Date: Fri Dec 1 00:25:50 2006 Subject: Wish: group support for Kmail and gnupg In-Reply-To: <200611081100.02441.bernhard@intevation.de> References: <200611081100.02441.bernhard@intevation.de> Message-ID: <200611302031.42526@erwin.ingo-kloecker.de> On Wednesday 08 November 2006 11:00, Bernhard Reiter wrote: > Hi Werner, Hi Marc, > I like to bring up the support for groups (aka aliases of gnupg > recipients) for KMail. (There probably is an issue for this as well, > but I am currently offline.) > > My thoughts: > Currently gnupg has the --group feature, I believe that keeping > recipient alises on the gnupg level is good, as this is the place > where recipients are checked anyway. > > The alternative: Associate several keys with one email adress oder > identifier on client level. This seems more cumbersome to me. FWIW, KMail supports associating several keys with one email adress since ages (even before ?gypten stopped being just a country on the African continent). Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20061130/f2ea155a/attachment.pgp