| 1 |
On Tue, 2019-04-02 at 08:02 -0600, Rich Freeman wrote: |
| 2 |
> On Sun, Feb 24, 2019 at 3:35 AM Michał Górny <mgorny@g.o> wrote: |
| 3 |
> > Following the recent mailing list discussion indicating that developers |
| 4 |
> > are taking GLEP 63 as only source of truth about OpenPGP keys, and can |
| 5 |
> > make assumption that if encryption key is not listed there they should |
| 6 |
> > not have one. Amend the specification to extend it beyond the previous |
| 7 |
> > limited scope of commit signing, and require an encryption key |
| 8 |
> > appropriately. This matches the GnuPG defaults. |
| 9 |
> |
| 10 |
> Does GLEP 63 actually match the gpg defaults? That is, if you |
| 11 |
> generate a gpg key and accept every default value will the key be |
| 12 |
> acceptable? |
| 13 |
> |
| 14 |
> If not, could we get some updated documentation as to how to generate |
| 15 |
> a minimally compliant key, similar to: |
| 16 |
> https://www.gentoo.org/glep/glep-0063.html#bare-minimum-requirements |
| 17 |
> |
| 18 |
|
| 19 |
There's: |
| 20 |
|
| 21 |
https://wiki.gentoo.org/wiki/Project:Gentoo-keys/Generating_GLEP_63_based_OpenPGP_keys |
| 22 |
|
| 23 |
It doesn't follow the best practices but is good enough to pass minimal |
| 24 |
GLEP 63 requirements. |
| 25 |
|
| 26 |
-- |
| 27 |
Best regards, |
| 28 |
Michał Górny |
Archives