On Sun, 20 Jun 2010 02:50:41 +0100, MFPA wrote:
> > So in order to be safe you need additional CPU load
> > either for TLS or for signing. Signing is superior IMHO
> > because it allows reuse of the data (one crypto action
> > (covering less data) for several users vs. one for each
> > user with T
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Sunday 20 June 2010 at 1:14:59 AM, in
, Hauke Laging
wrote:
> So in order to be safe you need additional CPU load
> either for TLS or for signing. Signing is superior IMHO
> because it allows reuse of the data (one crypto action
> (covering
Am Samstag 19 Juni 2010 13:36:15 schrieb MFPA:
> > Sending to several keyservers does not help if the MitM
> > attack point is on your side.
>
> Even if you send the key over an encrypted connection to a server? For
> example https://pgp.webtru.st/
No. Thus I wrote: "If your keyservers don't sup
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Saturday 19 June 2010 at 12:36:15 PM, in
, I wrote:
> Hi
> On Friday 18 June 2010 at 8:13:52 AM, in
> ,
> Hauke Laging wrote:
>> but this is about the share of file URLs in the
>> keyring not the number of file URLs against the number
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Friday 18 June 2010 at 8:42:31 PM, in
, David Shaw
wrote:
> When I wrote the new keyserver stuff, I thought about
> this sort of thing, but the lack of a good way to store
> metadata was a problem (the keybox fixes this), as well
> as the co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Friday 18 June 2010 at 8:42:39 PM, in
, David Shaw
wrote:
> The danger here is that it might take a long time
> (minutes+) to realize that the keyserver and/or network
> wasn't going to cooperate. This could seriously slow
> down many GPG op
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Friday 18 June 2010 at 8:13:52 AM, in
, Hauke Laging
wrote:
> but this is about the share of file URLs in the keyring
> not the number of file URLs against the number of
> alternative key servers.
My guess would be maybe 1-2% of my keyring.
On 06/18/10 12:42, David Shaw wrote:
The danger here is that it might take a long time (minutes+) to realize that
the keyserver and/or network wasn't going to cooperate. This could seriously
slow down many GPG operations.
I've been following this discussion with interest as I've seen proble
On Jun 14, 2010, at 7:58 PM, MFPA wrote:
> 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
>> up
On Jun 14, 2010, at 12:50 PM, Daniel Kahn Gillmor wrote:
> 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 configu
Hello,
Am Freitag 18 Juni 2010 02:10:22 schrieb MFPA:
> I don't know how common or uncommon it might be. I just know that, of
> the keys in my keyring of about 400 keys, I have noticed more
> deviations away from my default keyserver to key.asc files than to
> alternate keyservers.
but this is a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Thursday 17 June 2010 at 9:14:55 PM, in
, Hauke Laging
wrote:
>> A key may be sitting on a non-synchronising server
>> that has not been modified at all recently but
>> contains certifications not on my local copy. The key
>> has not change
Am Donnerstag 17 Juni 2010 21:23:40 schrieb MFPA:
> > A different approach might save even more bandwidth:
> > Most keys do now change often. It is useless to
> > download a key that has not changed.
>
> A key may be sitting on a non-synchronising server that has not been
> modified at all recent
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Wednesday 16 June 2010 at 8:26:11 PM, in
, Hauke Laging
wrote:
> Am Mittwoch 16 Juni 2010 19:10:17 schrieb Daniel Kahn
> Gillmor:
>> Do you have other suggestions? We should consider
>> bringing a prioritized form of these to the sks-deve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Wednesday 16 June 2010 at 6:10:17 PM, in
, Daniel Kahn Gillmor wrote:
> On 06/16/2010 01:03 PM, MFPA wrote:
>> What sort of alternate fetch requests do you envision?
>> Fetch-minimal? Fetch-no-photos?
> I was considering the same heuristic
Am Mittwoch 16 Juni 2010 19:10:17 schrieb Daniel Kahn Gillmor:
> Do you have other suggestions? We should consider bringing a
> prioritized form of these to the sks-devel list.
A different approach might save even more bandwidth:
Most keys do now change often. It is useless to download a key tha
On 06/16/2010 01:03 PM, MFPA wrote:
>> 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 simi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Tuesday 15 June 2010 at 1:46:30 AM, in
, Daniel Kahn Gillmor wrote:
> 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
On Mon, 14 Jun 2010 18:50, d...@fifthhorseman.net said:
> 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
That is one of the reasons why we should move away from the pubring.gpg
format. The new keybox
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
-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
> up
-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
> hav
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 t
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-aut
On Fri, 4 Jun 2010 19:55:37 +0200, Benjamin Marwell
wrote:
> Sounds good to me. Another consideration would be to pass this task to
> gui frontends, like kleopatra or seahorse. A warning printed out by
> gpg would be a good idea, too. Also, there should be a severe warning
> if you sign a key, w
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. Users should have the ca
icah Anderson
Sent: Friday, June 04, 2010 12:35
To: gnupg-users@gnupg.org
Subject: auto refresh-keys
I filed this today at https://bugs.g10code.com/gnupg/issue1235 but I
wanted to send it to the list to get wider discussion about the idea.
If you do not regularly refresh your public keys from ke
ld not be performed that the
key is potentially out of date. Users should have the capability to configure in
their gpg.conf a 'no-auto-refresh-keys' variable if they do not want this
functionality. Perhaps even some sanity checking on the data that is coming in
would be good to guard
28 matches
Mail list logo
