Re: FYI: About my test mails
On Fri, 11 Jun 2010 23:57, benja...@py-soft.co.uk said: Did alava...@gmail.com ever get removed? See http://lists.gnupg.org/pipermail/gnupg-users/2010-May/038724.html I can see no evidence that this address is abusing this ML. 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: libassuan dependency mismatch with gnupg 2.0.15 and dirmngr
On Mon, 14 Jun 2010 07:06, do...@dougbarton.us said: Working on updating gnupg in FreeBSD and ran into a problem. GnuPG 2.0.15 requires libassuan 2.0.0, but to build the gpgsm module it requires dirmngr, which requires libassuan 1.x. My understanding is Oppps. I though I released a new dirmngr version - hmmm that was only a release candidate. I try to get it out today. 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: libassuan dependency mismatch with gnupg 2.0.15 and dirmngr
Hi, I just released dirmngr 1.1.0 which requires libassuan 2.0. Let me know if you have any problems, 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: libassuan dependency mismatch with gnupg 2.0.15 and dirmngr
On 06/14/10 01:00, Werner Koch wrote: Hi, I just released dirmngr 1.1.0 which requires libassuan 2.0. Let me know if you have any problems, Looks good so far, thanks so much for the quick response! :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Test mail to mijiaail...@gmail.com
It's not me. No problem. Le vendredi 11 juin 2010 à 09:38 +0200, Werner Koch a écrit : Hi! One of the subscribers to this list created a mail forward to an automated ticketing system which responds to the the poster. The owner of the ticketing system at secure.mpcustomer.com does not respond to any of our queries to send us more information on the mails triggering the posting. Thus we need to send these test mails in the hope to figure out the culprit. Sorry for the inconvenience, Werner ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Test mail to lord.icervan...@gmail.com
not me. On Fri, Jun 11, 2010 at 2:38 AM, Werner Koch w...@gnupg.org wrote: Hi! One of the subscribers to this list created a mail forward to an automated ticketing system which responds to the the poster. The owner of the ticketing system at secure.mpcustomer.com does not respond to any of our queries to send us more information on the mails triggering the posting. Thus we need to send these test mails in the hope to figure out the culprit. Sorry for the inconvenience, Werner -- M. en C. Iván Cervantes ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: auto refresh-keys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Monday 14 June 2010 at 6:19:58 PM, in mid:4c1664be.1080...@fifthhorseman.net, Daniel Kahn Gillmor wrote: On 06/14/2010 12:50 PM, Daniel Kahn Gillmor wrote: * discard all certifications which are larger than some sorry, this thought didn't get finished. it should have said: * discard all certifications which are larger than some pre-defined value (e.g. do no not bother processing certifications that are 512KB in size, as there are currently no certifications that need to be anywhere near this size. The goal, again, is to avoid auto-refresh from chewing up too much space on the local disk. Although, of course, the certifications are all part of OxDECAFDAD.asc and therefore are still dowmloaded and consume bandwidth. With isks in excess of a terabyte, why bother expending the extra CPU cycles to conserve a little disk space? - -- Best regards MFPAmailto:expires2...@ymail.com When duty calls...hang up immediately -BEGIN PGP SIGNATURE- iQCVAwUBTBbBPaipC46tDG5pAQokmwQAxl9rG/x95kplr1NSETXDCtJmXLj3nImA fW3iUY3BBGdqVDJmcJRzM0l2W52j2Zrr60rYDpr0LlU9c34Q+XtzDXqluhjAaigU mehGxf80irIgI8ziZwRTVexHNl3aizSq+7Y2nsxLkhYSI/tF2wmGWyLwDZlGhvta be3CHUFAQY0= =3lAv -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: auto refresh-keys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Monday 14 June 2010 at 5:50:32 PM, in mid:4c165dd8.5020...@fifthhorseman.net, Daniel Kahn Gillmor wrote: Network or keyserver failures during an auto-refresh should be accepted and the rest of the operation should continue (though the last-refreshed time shouldn't be updated). What if the network and keyserver are both available, but the keyserver has never heard of the key in question? Same as Network or keyserver failure: there is no available auto-update, so warn and continue with the requested operations. - -- Best regards MFPAmailto:expires2...@ymail.com Was time invented by an Irishman named O'Clock? -BEGIN PGP SIGNATURE- iQCVAwUBTBbCQqipC46tDG5pAQrkfQQApS39GtHfr3BQU921e9jt7Zw3xqf5Iy5C r1YXdszWQfko9L3Rilup0vCwoLVf+t92S/XruzM0YaCpmi0zdJ2j+65Je0tLoq8c JAa9FCQ6YhXbxLLVzbo0uIKwZTgFBeaEjpkgJcIXiKx8w50snR2YFBrH+XUAczw+ /iN50W0cPYE= =SWv7 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: auto refresh-keys
On 06/14/2010 07:54 PM, MFPA wrote: On Monday 14 June 2010 at 6:19:58 PM, in mid:4c1664be.1080...@fifthhorseman.net, Daniel Kahn Gillmor wrote: The goal, again, is to avoid auto-refresh from chewing up too much space on the local disk. Although, of course, the certifications are all part of OxDECAFDAD.asc and therefore are still dowmloaded and consume bandwidth. With isks in excess of a terabyte, why bother expending the extra CPU cycles to conserve a little disk space? Your disks might be in excess of a terabyte. The large majority of mine aren't. Even if mine were, given that i'd like to see GnuPG easily available on mobile telephones and similar devices, i think disk space is a relevant metric. And even on the machines i use or administer that do have disks in excess of 1TB, disk I/O is a regular source of bottlenecks. Writing useless material to disks in any regular fashion is behavior to avoid. Plus, if we can demonstrate that GnuPG cares about minimizing costs to the user in terms of disk space, we also stand in a better rhetorical position to encourage development (or adoption) of alternate keyserver fetch requests that could apply similar minimization heuristics to bandwidth. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
