W dniu pią, 06.07.2018 o godzinie 08∶40 +0200, użytkownik Ulrich Mueller
napisał:
> > > > > > On Fri, 06 Jul 2018, Michał Górny wrote:
> > Did you even read the text? It's 'at most 2 years'. If you renew it
> > every year, you can achieve the desired effect while keeping far
> > ahead of the requir
W dniu pią, 06.07.2018 o godzinie 06∶28 +, użytkownik Robin H.
Johnson napisał:
> On Fri, Jul 06, 2018 at 08:18:32AM +0200, Michał Górny wrote:
> > > option a)
> > > 2 years + N:
> > > 2 weeks <= N <= 3 months.
> > >
> > > option b)
> > > Change the wording to be 'at most 2 years' instead of '
> On Fri, 06 Jul 2018, Michał Górny wrote:
> Did you even read the text? It's 'at most 2 years'. If you renew it
> every year, you can achieve the desired effect while keeping far
> ahead of the required schedule.
So effectively we're down from 5 years to 1 year also for the main
key, as a ma
On Thu, Jul 05, 2018 at 10:53:51PM +0200, Michał Górny wrote:
> Here's third version of the patches. I've incorporated the feedback
> so far and reordered the patches (again) to restore their
> degree-of-compatibility order. The full text is included below.
...
> v2
> The distinct minimal and r
On Fri, Jul 06, 2018 at 08:18:32AM +0200, Michał Górny wrote:
> > option a)
> > 2 years + N:
> > 2 weeks <= N <= 3 months.
> >
> > option b)
> > Change the wording to be 'at most 2 years' instead of 'exactly 2 years'.
> That *is* the wording.
I apologize. I took ulm's post as canonical and didn't
> On Fri, 6 Jul 2018, Robin H Johnson wrote:
> On Fri, Jul 06, 2018 at 07:43:56AM +0200, Ulrich Mueller wrote:
>> Still NACK. If expiration is exactly 2 years and renewal must happen
>> 2 weeks before the expiry date, then it is not possible to keep the
>> same date.
>>
>> Example: The key wi
W dniu pią, 06.07.2018 o godzinie 06∶08 +, użytkownik Robin H.
Johnson napisał:
> On Fri, Jul 06, 2018 at 07:43:56AM +0200, Ulrich Mueller wrote:
> > > > > > > On Thu, 5 Jul 2018, Michał Górny wrote:
> > > Replace the disjoint 'minimum' and 'recommendation' for expiration
> > > with a single re
W dniu pią, 06.07.2018 o godzinie 07∶43 +0200, użytkownik Ulrich Mueller
napisał:
> > > > > > On Thu, 5 Jul 2018, Michał Górny wrote:
> > Replace the disjoint 'minimum' and 'recommendation' for expiration
> > with a single requirement. Make it 2 years. Also, remove disjoint
> > expiration recommend
On Fri, Jul 06, 2018 at 07:43:56AM +0200, Ulrich Mueller wrote:
> > On Thu, 5 Jul 2018, Michał Górny wrote:
>
> > Replace the disjoint 'minimum' and 'recommendation' for expiration
> > with a single requirement. Make it 2 years. Also, remove disjoint
> > expiration recommendation for the prima
> On Thu, 5 Jul 2018, Jonas Stein wrote:
>> b. RSA, >=2048 bits (OpenPGP v4 key format or later only)
>>
>> + c. ECC curve 25519
>> +
>> 4. Key expiry: 5 years maximum
>> 5. Upload your key to the SKS keyserver rotation before usage!
> I think we should ensure first that everything works f
> On Thu, 5 Jul 2018, Michał Górny wrote:
> Replace the disjoint 'minimum' and 'recommendation' for expiration
> with a single requirement. Make it 2 years. Also, remove disjoint
> expiration recommendation for the primary key and subkeys since many
> developers fail at implementing that anywa
On Thu, 5 Jul 2018 12:32:20 -0500
William Hubbs wrote:
> I looked at this first, and it is very hard on the server.
> Every pull or clone you do to update things works like an initial clone,
> so it takes pretty massive resources.
Surely, then the recommended approach involves:
1. Selecting pag
On Thu, 5 Jul 2018 12:44:42 -0500
William Hubbs wrote:
> Have you even looked at gollum for example? it can support mw markdown.
I've looked at it, but none of my reading of online material indicates
whether it supports more than the existing media-wiki *syntax*.
For instance, Gollum states sup
On Fri, 06 Jul 2018 01:55:32 +0200
Gerion Entrup wrote:
> Would it possible to take the bare repo (< 600 MB) and only mount the latest
> checkout (with fuse eg)?
That would incur performance problems, because packed objects are
stored as differences to other objects ( similar to how later piece
Am Donnerstag, 5. Juli 2018, 14:03:36 CEST schrieb Martin Vaeth:
> Matt Turner wrote:
> > The ebuild tree is 600MB with rsync and cannot fit on the partition
> > with git.
> >
> > I'd be happy to switch if the space requirements were similar.
>
> If one git repacks every few syncs one needs curre
> b. RSA, >=2048 bits (OpenPGP v4 key format or later only)
>
> + c. ECC curve 25519
> +
> 4. Key expiry: 5 years maximum
> 5. Upload your key to the SKS keyserver rotation before usage!
I think we should ensure first that everything works fine with ECC. Last
time I checked, ECC was a ni
There really is no technical reason to use DSA keys and people who are
still using old DSA keys should finally replace them, so remove them
from the minimal requirements.
---
glep-0063.rst | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/glep-0063.rst b/glep-0063.rst
ind
Add a rule requesting renewal of keys at least two weeks before their
expiration date, in order to give services time to refresh.
---
glep-0063.rst | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/glep-0063.rst b/glep-0063.rst
index 0fdf5ed..d41a2a0 100644
--- a/glep-006
Replace the disjoint 'minimum' and 'recommendation' for expiration with
a single requirement. Make it 2 years. Also, remove disjoint
expiration recommendation for the primary key and subkeys since many
developers fail at implementing that anyway.
---
glep-0063.rst | 15 ---
1 file ch
Optionally allow using ECC curve 25519 keys. We already have
developers using those keys, and given that they are supported
by GnuPG 2.2, there's probably no reason to ban them. However, they're
not recommended due to interoperability issues.
---
glep-0063.rst | 4
1 file changed, 4 inserti
There is really no technical reason to use DSA these days, and we should
focus on having a single recommendation. DSA keys are still permitted
via 'minimal' requirements.
---
glep-0063.rst | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/glep-0063.rst b/glep
Change the recommended key size recommendation for RSA from 4096 bits
to 2048 bits. Use of larger keys is unjustified due to negligible gain
in security, and recommending RSA-4096 unnecessarily resulted
in developers replacing their RSA-2048 keys for no good reason.
---
glep-0063.rst | 20 +++
---
glep-0063.rst | 8
1 file changed, 8 insertions(+)
diff --git a/glep-0063.rst b/glep-0063.rst
index 2d30f68..b995d8e 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -40,6 +40,10 @@ Specifications for OpenPGP keys
Bare minimum requirements
-
+This section
Reword the specification to express the requirement for separate signing
subkey more verbosely. Replace the ambiguous term 'dedicated' with
clear explanation that it needs to be different from the primary key
and not used for other purposes.
Suggested-by: Kristian Fiskerstrand
---
glep-0063.rst
Replace the custom term 'root key' with much more common 'primary key'.
This is also the term used in GnuPG output.
---
glep-0063.rst | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/glep-0063.rst b/glep-0063.rst
index a56ae65..318717a 100644
--- a/glep-0063.rst
+++ b/gl
Replace the 'Gentoo subkey' term that might wrongly suggest that
the developers are expected to create an additional, dedicated subkey
for Gentoo.
Suggested-by: Kristian Fiskerstrand
---
glep-0063.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/glep-0063.rst b/glep-00
Replace many of the incorrect uses of GPG/GnuPG [key] with OpenPGP.
G[nu]PG has been left where the text clearly refers to the specific
implementation of OpenPGP rather than the standard itself.
---
glep-0063.rst | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff
Replace the 'RSAv4' with 'OpenPGP v4 key format'. The RSA algorithm
does not really have versions, and the author most likely meant the v4
of OpenPGP key format as outlined in RFC 4880, section 12.1.
This was figured out and explained to me by Kristian Fiskerstrand.
---
glep-0063.rst | 4 ++--
1
Hi,
Here's third version of the patches. I've incorporated the feedback
so far and reordered the patches (again) to restore their
degree-of-compatibility order. The full text is included below.
Michał Górny (12):
glep-0063: Use 'OpenPGP' as appropriate
glep-0063: RSAv4 -> OpenPGP v4 key fo
On Thu, Jul 5, 2018, at 08:36 CDT, Michał Górny wrote:
> I don't really know the original rationale for this.
>
> The NIST standard says 1-3 years. If I were to guess, I'd say 1 year
> was chosen for subkey because subkey expiring is a 'smaller' issue than
> the whole key expiring, i.e. other
W dniu czw, 05.07.2018 o godzinie 13∶24 -0500, użytkownik William Hubbs
napisał:
> On Thu, Jul 05, 2018 at 03:36:09PM +0200, Michał Górny wrote:
> > W dniu śro, 04.07.2018 o godzinie 18∶48 -0400, użytkownik Joshua Kinard
> > napisał:
> > > On 7/4/2018 5:24 PM, Michał Górny wrote:
> > > > W dniu śro
W dniu czw, 05.07.2018 o godzinie 17∶37 +0200, użytkownik Marc
Schiffbauer napisał:
> * Matthias Maier schrieb am 05.07.18 um 15:51 Uhr:
> >
> > On Thu, Jul 5, 2018, at 08:36 CDT, Michał Górny wrote:
> >
> > > That said, I'm open to using a different recommendation, e.g. 2 years
> > > as in ris
On Thu, Jul 05, 2018 at 03:36:09PM +0200, Michał Górny wrote:
> W dniu śro, 04.07.2018 o godzinie 18∶48 -0400, użytkownik Joshua Kinard
> napisał:
> > On 7/4/2018 5:24 PM, Michał Górny wrote:
> > > W dniu śro, 04.07.2018 o godzinie 23∶05 +0200, użytkownik Ulrich Mueller
> > > napisał:
> > > > > > >
On Thu, Jul 05, 2018 at 01:26:51PM +1200, Kent Fredric wrote:
> On Wed, 4 Jul 2018 12:44:11 -0500
> William Hubbs wrote:
>
> > Yes I would benefit from this change, but it is not a case of optimizing
> > for one. It is a case of opening up the use of the wiki to the largest
> > audiance possible.
On Thu, Jul 05, 2018 at 11:08:10AM +0200, Nils Freydank wrote:
> Am Dienstag, 3. Juli 2018, 19:39:43 CEST schrieb William Hubbs:
> > All,
> >
> > some of us have talked about this on IRC off and on, but I want to bring
> > it up here as well.
> >
> > I don't care that we have a wiki, but can we p
* Matthias Maier schrieb am 05.07.18 um 15:51 Uhr:
>
> On Thu, Jul 5, 2018, at 08:36 CDT, Michał Górny wrote:
>
> > That said, I'm open to using a different recommendation, e.g. 2 years
> > as in riseup [1]. I suppose having the same time for both primary key
> > and subkeys would make the spe
On Thu, Jul 5, 2018, at 08:36 CDT, Michał Górny wrote:
> That said, I'm open to using a different recommendation, e.g. 2 years
> as in riseup [1]. I suppose having the same time for both primary key
> and subkeys would make the spec simpler, and many developers are
> mistaking expiration times
W dniu śro, 04.07.2018 o godzinie 18∶48 -0400, użytkownik Joshua Kinard
napisał:
> On 7/4/2018 5:24 PM, Michał Górny wrote:
> > W dniu śro, 04.07.2018 o godzinie 23∶05 +0200, użytkownik Ulrich Mueller
> > napisał:
> > > > > > > > On Wed, 4 Jul 2018, Michał Górny wrote:
> > > >
> > > > -3. Key expi
W dniu śro, 04.07.2018 o godzinie 23∶43 +0200, użytkownik Kristian
Fiskerstrand napisał:
> On 07/04/2018 11:28 PM, Michał Górny wrote:
> > W dniu śro, 04.07.2018 o godzinie 23∶12 +0200, użytkownik Ulrich Mueller
> > napisał:
> > > > > > > > On Wed, 04 Jul 2018, Michał Górny wrote:
> > > >
> > > >
Matt Turner wrote:
> The ebuild tree is 600MB with rsync and cannot fit on the partition
> with git.
>
> I'd be happy to switch if the space requirements were similar.
If one git repacks every few syncs one needs currently about 800 MB.
With additionally squashfs (zstd) (+ overlayfs) the full
ar
Am Dienstag, 3. Juli 2018, 19:39:43 CEST schrieb William Hubbs:
> All,
>
> some of us have talked about this on IRC off and on, but I want to bring
> it up here as well.
>
> I don't care that we have a wiki, but can we please look into killing
> mediawiki and look at something with a git backend?
41 matches
Mail list logo
