On Wed 2021-07-07 19:57:14 +0200, Werner Koch wrote:
> You need to check for the canonical form anway and thus it is easier to
> directly sort it. In case of signature subpackets (if that is one of
> your concerns), this if of course not possible and thus this would
> require that the specs
On Wed, 7 Jul 2021 08:30, Daniel Kahn Gillmor said:
> Without a canonical form, we simply can't make such a proposal.
You need to check for the canonical form anway and thus it is easier to
directly sort it. In case of signature subpackets (if that is one of
your concerns), this if of course
On Tue 2021-07-06 23:20:23 +0100, Andrew Gallagher wrote:
> That's an interesting idea, and it has merit in itself, but from a
> keyserver point of view I think a more general solution is to explode
> TPKs into atomic components, sync them separately, and reconstruct the
> TPK on demand at
On Tue, 6 Jul 2021 15:59, Daniel Kahn Gillmor said:
> There are no published specifications for how to canonically order
> OpenPGP packets, but i sketched a proposal here:
There has never been a need for such an ordering except for what the
specs require. Introducing a specific order will make
On 06/07/2021 20:59, Daniel Kahn Gillmor wrote:
On Mon 2021-06-28 18:42:02 +0100, Andrew Gallagher via Gnupg-users wrote:
It’s not clear, but it may be due to a lack of canonical ordering of
packets.
There are no published specifications for how to canonically order
OpenPGP packets, but i
On Mon 2021-06-28 18:42:02 +0100, Andrew Gallagher via Gnupg-users wrote:
> It’s not clear, but it may be due to a lack of canonical ordering of
> packets.
There are no published specifications for how to canonically order
OpenPGP packets, but i sketched a proposal here:
*keyserver of course.
Please excuse my html, typos and use of soft keyboards.
On Mon, Jun 28, 2021, 16:33 C.J. Collier wrote:
> I was thinking of build a keystone out of perl and bigquery, but I haven't
> gotten around to it yet. At least not the bigquery part. I'll share the
> perl http
I was thinking of build a keystone out of perl and bigquery, but I haven't
gotten around to it yet. At least not the bigquery part. I'll share the
perl http listener and dispatch server if anyone's interested.
On Sun, Jun 27, 2021, 18:04 Jason Harris via Gnupg-users <
gnupg-users@gnupg.org>
"Hell is paved with good intention."
GDPR came from the laudable intention of limiting the power of GAFAMs
and other data brokers, inside our private lives.
But the text maintains a confusion between personal data and private
data. Some personal data is not and should not be private. Email
Andrew Gallagher wrote:
On 28 Jun 2021, at 18:02, Стефан Васильев via Gnupg-users
wrote:
When looking at the stats, why are there IMHO such high numbers
(daily) on updated pub keys, compared to submitted ones?
It’s not clear, but it may be due to a lack of canonical ordering of
packets.
> On 28 Jun 2021, at 18:02, Стефан Васильев via Gnupg-users
> wrote:
>
> When looking at the stats, why are there IMHO such high numbers
> (daily) on updated pub keys, compared to submitted ones?
It’s not clear, but it may be due to a lack of canonical ordering of packets.
Say Alice and Bob
Jason Harris wrote:
There are still SKS servers running, but several are unsynchronized,
including, apparently, pgp.mit.edu. Of course, they have the same key
import/poisoning problems already mentioned on these lists…
Here are the hockeypuck servers I could find, all synchronizing
properly
There are still SKS servers running, but several are unsynchronized, including,
apparently, pgp.mit.edu. Of course, they have the same key import/poisoning
problems already mentioned on these lists…
Here are the hockeypuck servers I could find, all synchronizing properly and
apparently
13 matches
Mail list logo
