On 07/08/2018 02:59 PM, Zac Medico wrote:
> On 07/08/2018 02:50 PM, Aaron W. Swenson wrote:
>> On July 8, 2018 5:38:48 PM EDT, Zac Medico wrote:
>>
>> On 07/08/2018 02:18 PM, Michał Górny wrote:
>>
>> W dniu nie, 08.07.2018 o godzinie 14∶11 -0700, użytkownik Zac Medico
>> napis
In v2 there's a suggestion to use git for better efficiency than rsync,
as requested by Michał Górny:
Title: Portage rsync hardlink support
Author: Zac Medico
Posted: 2018-07-11
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: sys-apps/portage
For users of the rsync tree, beginning with s
-sound/puddletag 20180708-10:31 billiee474f3fb4f1
Additions:
app-crypt/glep63-check20180704-20:57 mgorny9ba7015a40c
app-crypt/jitterentropy 20180706-19:24 gokturk 0c858706cfe
app-shells/loksh 20180702-07:54 gyakovlev
On Sun, Jul 8, 2018 at 5:50 PM Aaron W. Swenson wrote:
>
> Does Portage not call attention to critical updates?
>
> It used to make a special statement for a new stable Portage and strongly
> recommended that it be emerged first. It should probably do the same for
> openpgp-keys-gentoo-release.
On 07/08/2018 02:50 PM, Aaron W. Swenson wrote:
> On July 8, 2018 5:38:48 PM EDT, Zac Medico wrote:
>
> On 07/08/2018 02:18 PM, Michał Górny wrote:
>
> W dniu nie, 08.07.2018 o godzinie 14∶11 -0700, użytkownik Zac Medico
> napisał:
>
> On 07/08/2018 01:18 PM, Zac
On July 8, 2018 5:38:48 PM EDT, Zac Medico wrote:
>On 07/08/2018 02:18 PM, Michał Górny wrote:
>> W dniu nie, 08.07.2018 o godzinie 14∶11 -0700, użytkownik Zac Medico
>> napisał:
>>> On 07/08/2018 01:18 PM, Zac Medico wrote:
On 07/08/2018 01:08 PM, Michał Górny wrote:
> W dniu nie, 08.07.
On 07/08/2018 02:18 PM, Michał Górny wrote:
> W dniu nie, 08.07.2018 o godzinie 14∶11 -0700, użytkownik Zac Medico
> napisał:
>> On 07/08/2018 01:18 PM, Zac Medico wrote:
>>> On 07/08/2018 01:08 PM, Michał Górny wrote:
W dniu nie, 08.07.2018 o godzinie 11∶57 -0700, użytkownik Zac Medico
n
W dniu nie, 08.07.2018 o godzinie 14∶11 -0700, użytkownik Zac Medico
napisał:
> On 07/08/2018 01:18 PM, Zac Medico wrote:
> > On 07/08/2018 01:08 PM, Michał Górny wrote:
> > > W dniu nie, 08.07.2018 o godzinie 11∶57 -0700, użytkownik Zac Medico
> > > napisał:
> > > > On 07/08/2018 11:42 AM, Michał
On 07/08/2018 01:18 PM, Zac Medico wrote:
> On 07/08/2018 01:08 PM, Michał Górny wrote:
>> W dniu nie, 08.07.2018 o godzinie 11∶57 -0700, użytkownik Zac Medico
>> napisał:
>>> On 07/08/2018 11:42 AM, Michał Górny wrote:
W dniu nie, 08.07.2018 o godzinie 11∶04 -0700, użytkownik Zac Medico
On 07/08/2018 01:08 PM, Michał Górny wrote:
> W dniu nie, 08.07.2018 o godzinie 11∶57 -0700, użytkownik Zac Medico
> napisał:
>> On 07/08/2018 11:42 AM, Michał Górny wrote:
>>> W dniu nie, 08.07.2018 o godzinie 11∶04 -0700, użytkownik Zac Medico
>>> napisał:
On 07/08/2018 06:56 AM, Michał Górn
W dniu nie, 08.07.2018 o godzinie 11∶57 -0700, użytkownik Zac Medico
napisał:
> On 07/08/2018 11:42 AM, Michał Górny wrote:
> > W dniu nie, 08.07.2018 o godzinie 11∶04 -0700, użytkownik Zac Medico
> > napisał:
> > > On 07/08/2018 06:56 AM, Michał Górny wrote:
> > > > W dniu nie, 08.07.2018 o godzin
On Sun, Jul 8, 2018 at 2:31 PM Kristian Fiskerstrand wrote:
>
> On 07/08/2018 08:10 PM, Rich Freeman wrote:
> > Again, the current portage support for git verification doesn't check
> > any developer keys.
>
> right, so why would it be material for a news item improving the status
> quo for those
On 07/08/2018 11:42 AM, Michał Górny wrote:
> W dniu nie, 08.07.2018 o godzinie 11∶04 -0700, użytkownik Zac Medico
> napisał:
>> On 07/08/2018 06:56 AM, Michał Górny wrote:
>>> W dniu nie, 08.07.2018 o godzinie 15∶02 +0200, użytkownik Kristian
>>> Fiskerstrand napisał:
On 07/08/2018 08:53 AM,
W dniu nie, 08.07.2018 o godzinie 11∶04 -0700, użytkownik Zac Medico
napisał:
> On 07/08/2018 06:56 AM, Michał Górny wrote:
> > W dniu nie, 08.07.2018 o godzinie 15∶02 +0200, użytkownik Kristian
> > Fiskerstrand napisał:
> > > On 07/08/2018 08:53 AM, Michał Górny wrote:
> > > > Is safe git syncing
Requested-by: Ulrich Müller
---
glep-0063.rst | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/glep-0063.rst b/glep-0063.rst
index ae36d36..c02b89e 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -83,19 +83,19 @@ not be used to commit.
at least 25
---
glep-0063.rst | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/glep-0063.rst b/glep-0063.rst
index 84d87d2..ae36d36 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -45,6 +45,9 @@ v2
The ``gpg.conf`` contents have been removed as they were seriously
outdated and d
Remove the gpg.conf bits from recommended and minimal specification.
Apparently they are seriously obsolete and worse than the modern
defaults. While at it, editorial corrections to 'SHA2' bit.
Requested-by: Richard Yao
---
glep-0063.rst | 60 ---
Requested-by: Robin H. Johnson
---
glep-0063.rst | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/glep-0063.rst b/glep-0063.rst
index 300456b..37b1f4d 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -39,6 +39,9 @@ v2
The usage of DSA keys has been disallowed.
+
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
Replace the disjoint 'minimum' and 'recommendation' for expiration with
a single requirement. Make it 2.5 years with recommended annual renewal
to a fixed day of the year (2 years + some grace time for renewal).
Also, remove disjoint expiration recommendation for the primary key
and subkeys since
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 9ba778b..ca834a8 100644
--- a/glep-006
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
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
---
glep-0063.rst | 8
1 file changed, 8 insertions(+)
diff --git a/glep-0063.rst b/glep-0063.rst
index 14541d7..f4b49c2 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -41,6 +41,10 @@ Specifications for OpenPGP keys
Bare minimum requirements
-
+This section
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 +++
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 f02537d..8542031 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 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/glep-0063.rst b/glep-0063.r
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
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 | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
Hi,
Here's another updated version of GLEP 63, taking more feedback into
consideration. Changes since v4:
- removed all gpg.conf bits (which proved obsolete),
- added SHA-2 requirement on subkeys (this is in RISEUP and gnupg
default, and we require SHA-2 output anyway, so it makes sense
to
On 07/08/2018 08:10 PM, Rich Freeman wrote:
> Again, the current portage support for git verification doesn't check
> any developer keys.
right, so why would it be material for a news item improving the status
quo for those synching using the official rsync method?
--
Kristian Fiskerstrand
Open
On Sun, Jul 8, 2018 at 1:50 PM Kristian Fiskerstrand wrote:
>
> On 07/08/2018 07:34 PM, Rich Freeman wrote:
> > The patch is to do the verification before
> > checking it out so that if it fails the tree is left in a
> > last-known-good state (at least as seen by tools at the filesystem
> > level
On 07/08/2018 06:56 AM, Michał Górny wrote:
> W dniu nie, 08.07.2018 o godzinie 15∶02 +0200, użytkownik Kristian
> Fiskerstrand napisał:
>> On 07/08/2018 08:53 AM, Michał Górny wrote:
>>> Is safe git syncing implemented already? If not, maybe finish it first and
>>> cover both with a single news i
On 07/08/2018 07:34 PM, Rich Freeman wrote:
> The patch is to do the verification before
> checking it out so that if it fails the tree is left in a
> last-known-good state (at least as seen by tools at the filesystem
> level - the fetched bad commits would still be visible to git).
there is stil
On 08/07/18 18:34, Rich Freeman wrote:
> On Sun, Jul 8, 2018 at 9:02 AM Kristian Fiskerstrand wrote:
>> On 07/08/2018 08:53 AM, Michał Górny wrote:
>>> Is safe git syncing implemented already? If not, maybe finish it first and
>>> cover both with a single news item. Git is going to be more effi
On Sun, Jul 8, 2018 at 9:02 AM Kristian Fiskerstrand wrote:
>
> On 07/08/2018 08:53 AM, Michał Górny wrote:
> > Is safe git syncing implemented already? If not, maybe finish it first and
> > cover both with a single news item. Git is going to be more efficient here,
> > so people may want to lea
W dniu nie, 08.07.2018 o godzinie 15∶06 +0200, użytkownik Kristian
Fiskerstrand napisał:
> On 07/07/2018 03:11 PM, Michał Górny wrote:
> > > > 1. SHA2-series output digest (SHA1 digests internally permitted),
> > > >256bit or more::
> > > >personal-digest-preferences SHA256
> > >
> > >
W dniu nie, 08.07.2018 o godzinie 15∶02 +0200, użytkownik Kristian
Fiskerstrand napisał:
> On 07/08/2018 08:53 AM, Michał Górny wrote:
> > Is safe git syncing implemented already? If not, maybe finish it first and
> > cover both with a single news item. Git is going to be more efficient here,
> >
# Louis Sautier (8 July 2018)
# Superseded, respectively by dev-python/setuptools_scm
# and dev-python/jaraco-* + dev-python/tempora.
# Removal in a month. See https://bugs.gentoo.org/582728
dev-python/hgtools
dev-python/jaraco-utils
signature.asc
Description: OpenPGP digital signature
On 07/07/2018 03:11 PM, Michał Górny wrote:
>>> 1. SHA2-series output digest (SHA1 digests internally permitted),
>>>256bit or more::
>>>personal-digest-preferences SHA256
>> Is the config line still needed with current GnuPG versions?
> I'll let others answer that. In any case, the po
On 07/08/2018 08:53 AM, Michał Górny wrote:
> Is safe git syncing implemented already? If not, maybe finish it first and
> cover both with a single news item. Git is going to be more efficient here,
> so people may want to learn they have an alternative.
Why complicate things, and increase wait
On 07/08/2018 08:08 AM, Zac Medico wrote:
> For example, if signature verification fails during a
> sync operation, the new hardlink behavior will preserve the previous
> state of the repository.
This seems like a nice improvement, thank you for implementing it and
making it the new default.
--
On 07/08/2018 02:28 AM, Toralf Förster wrote:
> On 07/08/2018 08:08 AM, Zac Medico wrote:
>> Please review.
>>
>> Title: Portage rsync hardlink support
>> Author: Zac Medico
>> Posted: 2018-07-11
>> Revision: 1
>> News-Item-Format: 2.0
>> Display-If-Installed: sys-apps/portage
>> IMO there's anoth
On 08/07/18 10:21, Zac Medico wrote:
> On 07/08/2018 02:15 AM, Michał Górny wrote:
>>
>> Are you sure about that? That might have been the case so far but this
>> hardlink tree may actually tip the balance.
> Even if it takes twice a long (which it doesn't), the difference is
> negligible for mos
On 07/08/2018 08:08 AM, Zac Medico wrote:
> Please review.
>
> Title: Portage rsync hardlink support
> Author: Zac Medico
> Posted: 2018-07-11
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: sys-apps/portage
> IMO there's another heads-up for users having an unsual configuration:
So
On 07/08/2018 02:15 AM, Michał Górny wrote:
> Dnia 8 lipca 2018 09:14:06 CEST, Zac Medico napisał(a):
>> On 07/07/2018 11:53 PM, Michał Górny wrote:
>>> Dnia 8 lipca 2018 08:08:31 CEST, Zac Medico
>> napisał(a):
Please review.
Title: Portage rsync hardlink support
Author: Zac
Dnia 8 lipca 2018 09:14:06 CEST, Zac Medico napisał(a):
>On 07/07/2018 11:53 PM, Michał Górny wrote:
>> Dnia 8 lipca 2018 08:08:31 CEST, Zac Medico
>napisał(a):
>>> Please review.
>>>
>>> Title: Portage rsync hardlink support
>>> Author: Zac Medico
>>> Posted: 2018-07-11
>>> Revision: 1
>>> News
On 07/07/2018 11:53 PM, Michał Górny wrote:
> Dnia 8 lipca 2018 08:08:31 CEST, Zac Medico napisał(a):
>> Please review.
>>
>> Title: Portage rsync hardlink support
>> Author: Zac Medico
>> Posted: 2018-07-11
>> Revision: 1
>> News-Item-Format: 2.0
>> Display-If-Installed: sys-apps/portage
>>
>> F
49 matches
Mail list logo
