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 requir
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 no
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 query
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 sket
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:
https://dev.gnupg.org
*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 list
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> wrot
"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 c
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. Say
> 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 h
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 a
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 exchan
13 matches
Mail list logo
