Re: [gentoo-dev] Packages up for grabs: sys-process/parallel

[M. J. Everitt]

On 28/10/17 22:02, Jonas Stein wrote:
> Dear all,
>
> The following packages are up for grabs:
>
> sys-process/parallel
>
> after retirement of the proxied maintainer.
> (https://bugs.gentoo.org/633090)
>
> https://packages.gentoo.org/packages/sys-process/parallel
>
> The ebuild was defacto maintained by several gentoo developers who kept
> the package up to date.
>
> The tool is very powerful and it would be great to have one or more
> interested developers who want to maintain it.
>
Possibly worth CC'ing to the proxy-maint ML too? fwiw...



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Packages up for grabs: sys-process/parallel

[Jonas Stein]

Dear all,

The following packages are up for grabs:

sys-process/parallel

after retirement of the proxied maintainer.
(https://bugs.gentoo.org/633090)

https://packages.gentoo.org/packages/sys-process/parallel

The ebuild was defacto maintained by several gentoo developers who kept
the package up to date.

The tool is very powerful and it would be great to have one or more
interested developers who want to maintain it.

-- 
Best,
Jonas



























signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] GLEP 74: Full-tree verification using Manifest files

[Michał Górny]

W dniu sob, 28.10.2017 o godzinie 15∶46 +0200, użytkownik Ulrich Mueller
napisał:
> > > > > > On Sat, 28 Oct 2017, Michał Górny wrote:
> > W dniu sob, 28.10.2017 o godzinie 14∶49 +0200, użytkownik Ulrich Mueller
> > napisał:
> > > Other tools like "find" don't special-case dot-prefixed files
> > > though (in fact, "ls" may well be the exception there).
> > > 
> > > Implicit ignores only create an unnecessary attack surface. Better
> > > make them explicit, even if this will require adding some entries
> > > for common cases (like .git in the top-level dir).
> > I dare say it's not an attack surface if tools are explicitly
> > directed not to use those files.
> 
> For example, an ebuild can apply all patches from a given directory.
> We certainly don't want any unaccounted dot-prefixed files being
> injected there. (And yes, globbing shouldn't normally match such
> files, but there's at least one eclass setting the dotglob option.)

I think that's a really poor argument.

Firstly, the mentioned eclass does it for one command call, and it
doesn't go anywhere near the repository. So no, that doesn't count.

Secondly, someone being able to theoretically cut himself with a spoon
if he only sharpened its edge is no reason to forbid people from having
spoons without explicitly written permission.

> > The problem is, you can't predict all possible dotfiles and even if
> > you do, you're effectively blocking the user from creating any files
> > for his own use.
> 
> Create files for their own use in random locations in the Gentoo
> repository? Why would anyone want to do that?

.DS_Store? ;-)

> > Say, if user wanted to use git on top of rsync for his own purposes,
> > why would you prevent him from doing that?
> 
> As I said before, top-level .git should have an explicit IGNORE entry.

Are we going to supply explicit IGNORE entries for any VCS anyone might
choose to use? Or backup software and any other weird thing?

> IMHO we should rather stay on the safe side there, unless someone will
> speak up who has a concrete workflow where such dot-prefixed files
> with unpredictable names are needed.

I've already mentioned two. The first one were cheap union filesystems
based on FUSE where I'm pretty sure I've seen random dotfiles.

-- 
Best regards,
Michał Górny

[gentoo-dev] Packages up for grabs: app-text/rnv

[Jonas Stein]

Dear all,

The following packages are up for grabs:

app-text/rnv

after retirement of the proxied maintainer.
(https://bugs.gentoo.org/632784)

https://packages.gentoo.org/packages/app-text/rnv

The ebuild makes repoman sad
  KEYWORDS.dropped  1
   app-text/rnv/rnv-1.7.11-r1.ebuild: ppc
  repo.eapi.deprecated  1
   app-text/rnv/rnv-1.7.11.ebuild: 4

The package seems to be easy to clean up and to maintain.

-- 
Best,
Jonas

























signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: dev-python/whirlpool

[Mike Gilbert]

# Mike Gilbert  (28 Oct 2017)
# Tests segfault, bug 635732.
# No updates upstream since 2013.
# Removal in 30 days.
dev-python/whirlpool

Re: [gentoo-dev] [RFC] GLEP 74: Full-tree verification using Manifest files

[Robin H. Johnson]

On Sat, Oct 28, 2017 at 01:50:46PM +0200, Michał Górny wrote:
> > A SVN or Git repo might also have dot-named directories.
> I like the implicit idea better as it is more consistent with normal
> tool behavior, like 'ls' not listing the files. Dotfiles can be created
> by many random tools or even the filesystem (especially in some cases
> of overlay filesystems).
> 
> That said, the case of 'lost+found' just occurred to me. I suppose this
> one we will want to always IGNORE.
Thought: make the package manager responsible for their own ignore list
in addition to the IGNORE values; and by default it can contain a
partial overlap with the IGNORE manifest entries.
**/.git
/lost+found # ignore at the top-level only
/distfiles # ignore at the top-level only
/packages # ignore at the top-level only
/local # ignore at the top-level only

If users need other values, it's a package-manager config knob.

> Let's try:
> 
> | 2. Start at the top-level Manifest file. Verify its OpenPGP signature.
> |Optionally verify the ``TIMESTAMP`` entry if present.
> |If the timestamp is significantly out of date compared to the local
> |clock or a trusted source, halt or require manual intervention
> |from the user. Remove the top-level Manifest from the *present* set.
> 
> Maybe it would look better if I split it into sub-points.
Yes, put 'Verifying TIMESTAMP' into a new section as you added below,
including the out-of-date part there; don't detail how to verify it in
this section.

> > GLEP61, for the transition period, required compressed & uncompressed 
> > Manifests
> > in the same directory to have identical content. Include mention of that 
> > here.
> Can do. But I'll do it in 'Backwards compatibility' section:
> | - if the Manifest files inside the package directory are compressed,
> |   a uncompressed file of identical content must coexist.
> > Saying that either can be used is a potential issue.
> Why? It also says that they must be identical, so it's of no difference
> to the implementation which one is used.
It's safe if the identical requirement is there, and potentially unsafe 
otherwise.

> > > Tree design
> > > ---
> > Add a minor header here, to say this is the end of the 'Tree design' 
> > section?
> It's not the end, it's description of the alternative. Both belong
> in one section. I could add additional section level but I'd rather
> not do that for a single use.
Hmm, just reads unclear if that should have been a different section.
Not sure if there is a nice way to fix it at all.

> > > Timestamp field
> | A malicious third-party may use the principles of exclusion and replay
> | to deny an update to clients, while at the same time recording
> | the identity of clients to attack. The timestamp field can be used
> | to detect that.
> |
> | In order to provide a more complete protection, the Gentoo
> | Infrastructure should provide an ability to obtain the timestamps
> | of all Manifests from a recent timeframe over a secure channel
> | for comparison.
> |
> | Strictly speaking, this is already provided by the various
> | ``metadata/timestamp.*`` files provided already by Gentoo which are also
> | covered by the Manifest. However, including the value in the Manifest
> | itself has a little cost and provides the ability to perform
> | the verification stand-alone.
Just add in the sentence re trusted source from before, otherwise good.
The rest of this thread devolved into specifics about implementing the
validation; which aren't relevant to this GLEP (yes, telling the package
manager that it's a known old tree, ignore the age only, is a valid use
case).


> > Could we please note here, for the transitional period, that the
> > file equivalence rule is applicable? 
> > During the transitional, the package Manifests may contain two entries for a
> > given file: (DATA, EBUILD) or (DATA, AUX). The MISC type remains the
> > same.
> Equivalence rule is applicable always. However, there's no point
> in duplicating the entry for the same file as that's only going
> to increase space use.
This means that new verification tools (beyond Gemato) need to handle
the legacy types for the moment, and can't just skip them (eg if both
entries existed).

> > > - the Manifest files inside the package directory can be signed
> > >   to provide authenticity verification.
> > Why do we need to specify this in backwards compat, it's still permitted 
> > above.
> But it makes no sense when top-level Manifest is signed. This points out
> that for tools not supporting full-tree verification smaller signatures
> need to be used (skipping the fact that Portage did not ever implement
> it).
The Manifests might not be signed by the same entity.
/metadata/glsa/Manifest might be signed by the security team, 
/sec-policy/Manifest might be signed by SELinux team, 
/Manifest should STILL be signed by Infra/tree-generation-process.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Asst. Treasurer
E-Mail   : 

Re: [gentoo-dev] [RFC] GLEP 74: Full-tree verification using Manifest files

[Ulrich Mueller]

> On Sat, 28 Oct 2017, Michał Górny wrote:

> W dniu sob, 28.10.2017 o godzinie 14∶49 +0200, użytkownik Ulrich Mueller
> napisał:
>> Other tools like "find" don't special-case dot-prefixed files
>> though (in fact, "ls" may well be the exception there).
>>
>> Implicit ignores only create an unnecessary attack surface. Better
>> make them explicit, even if this will require adding some entries
>> for common cases (like .git in the top-level dir).

> I dare say it's not an attack surface if tools are explicitly
> directed not to use those files.

For example, an ebuild can apply all patches from a given directory.
We certainly don't want any unaccounted dot-prefixed files being
injected there. (And yes, globbing shouldn't normally match such
files, but there's at least one eclass setting the dotglob option.)

> The problem is, you can't predict all possible dotfiles and even if
> you do, you're effectively blocking the user from creating any files
> for his own use.

Create files for their own use in random locations in the Gentoo
repository? Why would anyone want to do that?

> Say, if user wanted to use git on top of rsync for his own purposes,
> why would you prevent him from doing that?

As I said before, top-level .git should have an explicit IGNORE entry.

IMHO we should rather stay on the safe side there, unless someone will
speak up who has a concrete workflow where such dot-prefixed files
with unpredictable names are needed.

Ulrich


pgpnnc9QigXFT.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] GLEP 74: Full-tree verification using Manifest files

[Michał Górny]

W dniu sob, 28.10.2017 o godzinie 14∶49 +0200, użytkownik Ulrich Mueller
napisał:
> > > > > > On Sat, 28 Oct 2017, Michał Górny wrote:
> > > > The Manifest files can also specify ``IGNORE`` entries to skip
> > > > Manifest verification of subdirectories and/or files. Files and
> > > > directories starting with a dot are always implicitly ignored.
> > > > All files that are not ignored must be covered by at least one
> > > > of the Manifests.
> > > 
> > > Do we need to keep that implicit ignore rule? Rather, convert it
> > > to being always explicit.
> > > 
> > > There is only one such file in the rsync checkout presently:
> > > metadata/.checksum-test-marker (see bug #572168, it is used to
> > > detect mis-configured mirrors).
> > > 
> > > A SVN or Git repo might also have dot-named directories.
> > I like the implicit idea better as it is more consistent with normal
> > tool behavior, like 'ls' not listing the files. Dotfiles can be
> > created by many random tools or even the filesystem (especially in
> > some cases of overlay filesystems).
> 
> Other tools like "find" don't special-case dot-prefixed files though
> (in fact, "ls" may well be the exception there).
> 
> Implicit ignores only create an unnecessary attack surface. Better
> make them explicit, even if this will require adding some entries for
> common cases (like .git in the top-level dir).
> 

I dare say it's not an attack surface if tools are explicitly directed
not to use those files. The problem is, you can't predict all possible
dotfiles and even if you do, you're effectively blocking the user from
creating any files for his own use.

Say, if user wanted to use git on top of rsync for his own purposes, why
 would you prevent him from doing that?

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] GLEP 74: Full-tree verification using Manifest files

[Ulrich Mueller]

> On Sat, 28 Oct 2017, Michał Górny wrote:

>> > The Manifest files can also specify ``IGNORE`` entries to skip
>> > Manifest verification of subdirectories and/or files. Files and
>> > directories starting with a dot are always implicitly ignored.
>> > All files that are not ignored must be covered by at least one
>> > of the Manifests.
>>
>> Do we need to keep that implicit ignore rule? Rather, convert it
>> to being always explicit.
>>
>> There is only one such file in the rsync checkout presently:
>> metadata/.checksum-test-marker (see bug #572168, it is used to
>> detect mis-configured mirrors).
>>
>> A SVN or Git repo might also have dot-named directories.

> I like the implicit idea better as it is more consistent with normal
> tool behavior, like 'ls' not listing the files. Dotfiles can be
> created by many random tools or even the filesystem (especially in
> some cases of overlay filesystems).

Other tools like "find" don't special-case dot-prefixed files though
(in fact, "ls" may well be the exception there).

Implicit ignores only create an unnecessary attack surface. Better
make them explicit, even if this will require adding some entries for
common cases (like .git in the top-level dir).

Ulrich


pgpDLb36ye2cA.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] GLEP 74: Full-tree verification using Manifest files

[Michał Górny]

W dniu pią, 27.10.2017 o godzinie 21∶05 +, użytkownik Robin H.
Johnson napisał:
> On Thu, Oct 26, 2017 at 10:12:25PM +0200, Michał Górny wrote:
> > 2. Alike the original Manifest2, the files should be split into two
> >groups — files whose authenticity is critical, and those whose
> >mismatch may be accepted in non-strict mode. The same classification
> >should apply both to files listed in Manifests, and to stray files
> >present only in the repository.
> 
> nit: s/Alike/Like/, or rewrite the sentence.

Done.

> > Manifest file locations and nesting
> > ---
> > The ``Manifest`` file located in the root directory of the repository
> > is called top-level Manifest, and it is used to perform the full-tree
> > verification. In order to verify the authenticity, it must be signed
> > using OpenPGP, using the armored cleartext format.
> 
> Are detached signatures also permitted (for all levels of Manifest)?

I'd say no. Keeping it always contained in a single file is simpler.

> > The Manifest files can also specify ``IGNORE`` entries to skip Manifest
> > verification of subdirectories and/or files. Files and directories
> > starting with a dot are always implicitly ignored. All files that
> > are not ignored must be covered by at least one of the Manifests.
> 
> Do we need to keep that implicit ignore rule? Rather, convert it to being
> always explicit.
> 
> There is only one such file in the rsync checkout presently:
> metadata/.checksum-test-marker (see bug #572168, it is used to detect
> mis-configured mirrors).
> 
> A SVN or Git repo might also have dot-named directories.

I like the implicit idea better as it is more consistent with normal
tool behavior, like 'ls' not listing the files. Dotfiles can be created
by many random tools or even the filesystem (especially in some cases
of overlay filesystems).

That said, the case of 'lost+found' just occurred to me. I suppose this
one we will want to always IGNORE.

> > All the files covered by a Manifest tree must reside on the same
> > filesystem. It is an error to specify entries applying to files
> > on another filesystem. If subdirectories of the Manifest tree reside
> > on a different filesystem, they must be explicitly excluded
> > via ``IGNORE``.
> 
> Distfiles aren't required to be in the same filesystem.

I've updated the sentence to clearly indicate it's about «local (non-
``DIST``) files».

> 
> > New Manifest tags
> > -
> 
> ...
> > ``IGNORE ``
> >   Ignores a subdirectory or file from Manifest checks. If the specified
> >   path is present, it and its contents are omitted from the Manifest
> >   verification (always pass).
> 
> Should this be accepted even by strict-mode? Alternatively, should strict mode
> require that other content is kept outside of the tree?

Yes, it should. I'd really prefer if strict mode still worked out-of-
the-box for most of our users without requiring them to do major
reshuffling of their systems.

Plus, see 'lost+found' above.

> > Algorithm for full-tree verification
> > 
> 
> ...
> > 2. Start at the top-level Manifest file. Verify its OpenPGP signature.
> >Optionally verify the ``TIMESTAMP`` entry if present. Remove
> >the top-level Manifest from the *present* set.
> 
> This spec does not state how the timestamp should be verified. 
> Borrow from the original GLEP?

Let's try:

| 2. Start at the top-level Manifest file. Verify its OpenPGP signature.
|Optionally verify the ``TIMESTAMP`` entry if present.
|If the timestamp is significantly out of date compared to the local
|clock or a trusted source, halt or require manual intervention
|from the user. Remove the top-level Manifest from the *present* set.

Maybe it would look better if I split it into sub-points.

> 
> > 4. Process all ``IGNORE`` entries. Remove any paths matching them
> >from the *present* set.
> > 
> > 5. Collect all files covered by ``DATA``, ``MISC``, ``OPTIONAL``,
> >``EBUILD`` and ``AUX`` entries into the *covered* set.
> 
> Clarification request: point out again in this section, that IGNORE entries 
> are
> prohibited from also matching any other entry. It is mentioned further up, but
> a reminder is good.

I've added an extra step:

| 6. Verify the entries in *covered* set for incompatible duplicates
|and collisions with ignored files as explained in `Manifest file
|locations and nesting`_.

> 
> > Checksum algorithms
> > ---
> > This section is informational only. Specifying the exact set
> > of supported algorithms is outside the scope of this specification.
> 
> ...
> > The method of introducing new hashes is defined by GLEP 59 [#GLEP59]_.
> > It is recommended that any new hashes are named after the Python
> > ``hashlib`` module algorithm names, transformed into uppercase.
> 
> Would we ever consider algorithm parameters? Yes, outside of this spec, but 
> checking anyway.

I can't say