dkg
fwiw, i recently spoke to some of the IANA folks, and they suggested to me that as long as any relevant registries were clearly identified as tables in the document,...
According to `homectl(1)`, `--drop-caches` defaults to `true` when `--storage=fscrypt`, so i would have expected the result to look the way that it does after a reboot: ``` 0 root@unstable-amd64:~# cat...
Any word on this? I'm reluctant to set up any users with `--storage=fscrypt` if i am not convinced that the files will actually be opaque after full logout.
Is there a schedule for this release?
https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-13.html#name-notes-on-signatures says: > The high 16 bits (first two octets) of the hash are included in the Signature packet to provide a way to reject some invalid signatures without performing...
See also [MR !213](https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/213) and [issue #143](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/143).
Every one of the samples that @paulwouters posted has the two digest prefix octets set to `0x0001`
I've just noted that some future `sop update-key` command might want to identify and correct this kind of flaw in any certificate it finds, over at https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/29. @ni4 i agree...
@kaie wrote: > I've looked at a collection of about 1000 public keys, and in 5 of them I see a signature with 0x0001 lbits. None of the signatures is...
you have a mean of 187 signatures on each certificate‽ that seems quite high to me.