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: auto refresh-keys
On 06/04/2010 01:35 PM, Micah Anderson wrote: > It seems like the best solution would be to build into gnupg the functionality > that is similar to the automatic trust database operation: have gpg > auto-refresh > from the configured keyserver periodically. I think something like this would be a good idea. I've found that many users (even sophisticated users) of GnuPG never refresh their keyrings manually, which means that they use a good strong tool to (for example) encrypt messages to known-revoked keys (in a recent case, to a key whose revocation certificate was published over 2½ years ago). This is bad security for those users. GnuPG should help those users to Do The Right Thing as automatically as possible. > There are some considerations that > should be made here, such as how frequent should this refresh operation > happen? > Should it happen on every use, before the key is used? Should it happen just > on > the key(s) that the current operation is going to act on? here's a proposal: gpg could keep track of the last time it refreshed any given key from a public keyserver. when the user tries to use that key, if the last-refreshed time is more than X days ago, the key is refreshed (and the associated part of the trustdb updated?) before use. Upon succes, the last-refreshed time associated with that key should be updated. > What about network > problems, such as no network at all, keyserver down, or slow? There should > probably be a low timeout to not cause user annoyance, but also some sort of > indication/warning that when a keyserver update could not be performed that > the > key is potentially out of date. 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? > Users should have the capability to configure in > their gpg.conf a 'no-auto-refresh-keys' variable if they do not want this > functionality. Sounds good to me. i could even imagine this being a per-key setting, but that might be more complexity cost than is worth incurring for the (minimal) gain. > Perhaps even some sanity checking on the data that is coming in > would be good to guard against gigabytes of data coming down. for signature data coming from keyservers during an auto-refresh, i could see doing the following triage to avoid storing gigabytes of unnecessary stuff: * discard all certifications made by keys which we do not have a local copy of (since they are meaningless for computing calculated validity of a key). * discard all certifications which are not cryptographically valid, or are executed with cryptographic algorithms we do not support, or which rely on known-weak cryptographic algorithms. * discard all certifications which are larger than some Certifications fetched are either over: 0) a User ID and a primary Key, or 1) a primary key and an associated subkey (these are usually self-sigs or revocations), or 2) a primary key itself (also usually self-sigs or revocations) For each thing being certified: * for cryptographically-valid certifications (or revocations) from any given public key (or its associated subkeys): only store the certifications with the most-recent certification date. This prevents fetching, say, 1000 certifications from an abusive certifier. What do other folks think about this? The more we can make gpg do the right thing automatically (and this includes picking up revocations and updates), the more useful it will be in terms of providing real secured communications for its users. --dkg signature.asc Description: OpenPGP digital 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 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. --dkg signature.asc Description: OpenPGP digital signature ___ 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 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 , 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 , 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 > , 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
Re: Test mail to aldo...@gmail.com
2010/6/11 Werner Koch > Sorry for the inconvenience, > No problem. -- Aldo Latino OpenPGP key: 4096R/0xA18E41E8 | bit.ly/keyDSA 84E2 2BC8 ABE3 DCC0 9F15 E511 4357 7ECD 4397 C730 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
