Re: [gentoo-dev] [RFC] GLEP 74 post-Council review update [v2]

2017-11-20 Thread Ulrich Mueller
> On Mon, 20 Nov 2017, Ulrich Mueller wrote:

> On Mon, 20 Nov 2017, Michał Górny wrote:
>> All paths specified in the Manifest file must consist of characters
>> corresponding to valid UTF-8 code points excluding the NULL character
>> (``U+``) and characters classified as whitespace in the current
>> version of the Unicode standard [#UNICODE]_. It is an error to use
>> Manifest files in directories containing files whose names contain
>> the disallowed characters.

> See above. I believe that NUL and ASCII whitespace (i.e. characters
> 09 0a 0b 0c 0d 20) should be excluded, but excluding byte sequences
> like "e1 9a 80" (which is the UTF-8 encoding for U+1680 "OGHAM SPACE
> MARK") doesn't make sense.

Thinking about it, this still looks too complicated. So, exclude only
SPACE (0x20) which is used as separator between fields. (NUL can be
excluded too, but it won't occur anyway.)

In fact, all Manifest files in the tree are ASCII only.
So alternatively, filenames could be restricted to printable ASCII.
This is also what GLEP 31 [1] says:

| Suitable Characters for File and Directory Names
|
| Characters outside the ASCII 0..127 range cannot safely be used for
| file or directory names. (Of course, not all characters inside the
| ASCII 0..127 range can be used safely either.)

Ulrich


[1] Character Sets for Portage Tree Items
https://www.gentoo.org/glep/glep-0031.html


pgpBeq6WPQhpm.pgp
Description: PGP signature


Re: [gentoo-dev] NEWS item for games destabling

2017-11-20 Thread Daniel Campbell
On Mon, Nov 20, 2017 at 11:36:33AM +0100, Róbert Čerňanský wrote:
> On Mon, 20 Nov 2017 10:26:29 +0100
> David Seifert  wrote:
> 
> > Round 2 (with correct whitespace this time):
> > 
> > Title: No stable KEYWORDS for Gentoo Games
> > Author: David Seifert 
> > Content-Type: text/plain
> > Posted: 2017-11-20
> > Revision: 1
> > News-Item-Format: 1.0
> > Display-If-Keyword: amd64 x86
> > 
> > As the Games team does not have enough manpower to keep tabs on all
> > games packages, we have dropped all ebuilds maintained by the games
> > project to unstable KEYWORDS (without those required by other stable
> > packages). If you have any of these stable games packages installed,
> > you will have to add them to /etc/portage/package.accept_keywords/
> > manually. Failures related to missing stable KEYWORDS will show up as
> > 
> >   The following keyword changes are necessary to proceed:
> >(see "package.accept_keywords" in the portage(5) man page for more
> > details)
> >   # required by @selected
> >   # required by @world (argument)
> >   =games-action/0verkill-0.16-r4 ~amd64
> > 
> > While we accept that this will cause some irritation for the
> > community, pretending we have a well supported games collection by
> > having a wealth of stable games packages is misleading at best. We
> > welcome contributions from outsiders willing to polish up the games
> > landscape in Gentoo via the Proxy Maintainers.
> 
> What does it mean for the future?  Should not users bother to test &
> write stabilization request bugs for games anymore?  Or stabi
> requests will still be accepted?
> 
> Robert
> 
> 
> -- 
> Róbert Čerňanský
> E-mail: ope...@tightmail.com
> Jabber: h...@jabber.sk
> 

If I may take a stab at this (correct me if I'm wrong, soap):

It only means games are being dropped to ~arch (testing) until other
maintainers (proxy or otherwise) step up to make sure the games really
are stable. Packages that rarely get attention but are still marked
"stable" dilutes the meaning of "stable", especially if you get
installation or runtime problems that a proper testing of the package
would have caught.

This results in bugs that should've been caught in the testing phase,
confuses users (and developers), and redundant or obvious bugs being
reported.

This reads like a "fresh slate" for games, allowing them to start from
~arch and ensure that stabilization procedures are correctly followed by
those who step up. While this will create more stabilization bugs, it
should, in theory, result in better ebuilds (which makes Gentoo
maintenance better/easier) and games that have *actually* been tested.

I hope this explanation is both accurate and helpful.

~zlg
-- 
Daniel Campbell - Gentoo Developer, Trustee, Treasurer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


signature.asc
Description: Digital signature


Re: [gentoo-dev] Re: Prefix bootstrap script maintainability

2017-11-20 Thread Benda Xu
R0b0t1  writes:

> This is why I am surprised documentation is lacking for specific
> projects, or, I suppose, any software package that has ever been
> created.

No surprise.  There is always a gap between theory and practice.  

That said, I will prioritize myself to document the internals of Gentoo
Prefix.  Thank you for emphasizing this, you are acknowledged.

Benda



Re: [gentoo-dev] Manifest2 hashes: validation of single hash per MANIFESTx_REQUIRED_HASH

2017-11-20 Thread R0b0t1
On Mon, Nov 20, 2017 at 9:00 PM, R0b0t1  wrote:
> Hello friends!
>
> On Wed, Nov 15, 2017 at 3:02 PM, Robin H. Johnson  wrote:
>> Replying to your original question here, to repeat the answer I emphasised
>> before, along with significantly more detail in the history of Portage hashes
>> (pulled from my notes back to GLEP57 and some minor updates).
>>
>> On Wed, Nov 08, 2017 at 12:57:49PM -0600, R0b0t1 wrote:
>>> These posts are concerning because it looks like someone became stir
>>> crazy and invented a problem to solve. The changes proposed to date
>>> have remained poorly justified, and no one has addressed the concern
>>> that multiple hashes *is* actually more secure.
>>>
>>> If it was deemed necessary at one point, what justification was used?
>>> I.e. https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence.
>> On Wed, Nov 15, 2017 at 11:47:41AM -0600, R0b0t1 wrote:
>>> Does the existence of a decision mean I would need to contact the trustees
>>> if I feel the changes have not been adequately justified?
>>
>> In GLEP59, I referenced a paper by Joux [J04], in which it was shown that a
>> concatenation of multiple hashes is NOT much more secure against collisions
>> than the strongest of the individual hashes.
>>
>> That was cited as original logic in GLEP59 for the removal of SHA256 (that
>> removal was never implemented). WHIRLPOOL & SHA512 were kept out of an
>> abundance of caution at the time, mostly to implementation bugs in hashes 
>> (as I
>> have referenced in the related threads since).
>>
>> Your logic regarding removing something you think I don't understand is wrong
>> (Chesterton's Fence):
>>
>> If you dig in the history of Portage, you will see that it's always been 
>> valid,
>> to have just a SINGLE hash for each file in a Manifest.  Required hashes has
>> NEVER contained more than one hash.
>>
>> If multiple hashes are present, then Portage will validate all of them, but a
>> potential attacker can still modify the Manifest and have only a single hash
>> listed.  Exactly which hash MUST be present has changed over time.
>>
>> Manifest1 is very old, and was stored in $CAT/$PN/files/digest-$P
>> Manifest2 is the current $CAT/$PN/Manifest (and soon in more locations per 
>> MetaManifest).
>>
>> 1999/xx/xx: Portage starts with Manifest1 format, MD5-only (CVS)
>> 2004/08/25: Portage gets SHA1 support in Manifest1, but is problematic, SHA1 
>> generation manual only.
>> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/portage/pym/portage_checksum.py?revision=1.1=markup
>> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/portage/pym/portage.py?r1=1.485=1.486
>> 2005/12/19: Portage Manifest1 supports MD5,SHA1,SHA256,RMD160, but still 
>> requires only a single hash present. Generates MD5+SHA256+RMD160.
>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=cd3e3775966a9f58aebb91f58cbdb5903faad3de
>> 2006/03/24: Manifest2 introduced.
>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=f993747ca501e8a70d6f6174711149a172cfc3c2
>> 2007/01/20: MANIFEST2_REQUIRED_HASH introduced, SHA1, it must be present & 
>> pass
>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=e768571187d1655fbb558c23d61fa2983e48e411
>> 2007/12/18: MANIFEST1_REQUIRED_HASH introduced, MD5, it must be present & 
>> pass
>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=d9b10deaa03ce174d5ccc3b59c477549ad87e884
>> 2008/02/28: Manifest1 support dropped.
>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=66940e1f2f0549ee8f01dad59016e168105e193d
>> 2011/10/02: GLEP59 implemented, MANIFEST2_REQUIRED_HASH changes to SHA256
>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=c8cd3a985cc529299411d7343a11004b7d1330ef
>> 2017/06/15: MANIFEST2_REQUIRED_HASH changes to SHA512
>> https://gitweb.gentoo.org/proj/portage.git/commit/?id=e6abcc0b7cbdca481862a5c7cca946c01c471ffb
>>
>> [J04] Joux, Antoie. (2004). "Multicollisions in Iterated Hash Functions - 
>> Application to Cascaded Constructions;"
>> Proceedings of CRYPTO 2004, Franklin, M. (Ed); Lecture Notes in Computer 
>> Science 3152, pp. 306-316.
>> Available online from: 
>> http://web.cecs.pdx.edu/~teshrim/spring06/papers/general-attacks/multi-joux.pdf
>>
>
> This is the information I was looking for, thank you. I feel that the
> matter has been adequately explained. I apologize for missing your
> response.
>
> The paper gives a counter intuitive result, so I suspect I will have
> to spend more time with it.
>

I appreciate the thought that robbat2 gave to his response, but I
would like to clarify that it is beyond and above what I expected.

What I wanted to avoid was something I encountered on the GCC mailing
list: When I asked why GCJ was removed, I was told that it was hard to
maintain. When I asked for an example of past maintenance issues (and
made it clear I had no interest in disputing whether the issues were
valid or not) I received no reply from the maintainer except his
original answer, 

Re: [gentoo-dev] Manifest2 hashes: validation of single hash per MANIFESTx_REQUIRED_HASH

2017-11-20 Thread R0b0t1
Hello friends!

On Wed, Nov 15, 2017 at 3:02 PM, Robin H. Johnson  wrote:
> Replying to your original question here, to repeat the answer I emphasised
> before, along with significantly more detail in the history of Portage hashes
> (pulled from my notes back to GLEP57 and some minor updates).
>
> On Wed, Nov 08, 2017 at 12:57:49PM -0600, R0b0t1 wrote:
>> These posts are concerning because it looks like someone became stir
>> crazy and invented a problem to solve. The changes proposed to date
>> have remained poorly justified, and no one has addressed the concern
>> that multiple hashes *is* actually more secure.
>>
>> If it was deemed necessary at one point, what justification was used?
>> I.e. https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence.
> On Wed, Nov 15, 2017 at 11:47:41AM -0600, R0b0t1 wrote:
>> Does the existence of a decision mean I would need to contact the trustees
>> if I feel the changes have not been adequately justified?
>
> In GLEP59, I referenced a paper by Joux [J04], in which it was shown that a
> concatenation of multiple hashes is NOT much more secure against collisions
> than the strongest of the individual hashes.
>
> That was cited as original logic in GLEP59 for the removal of SHA256 (that
> removal was never implemented). WHIRLPOOL & SHA512 were kept out of an
> abundance of caution at the time, mostly to implementation bugs in hashes (as 
> I
> have referenced in the related threads since).
>
> Your logic regarding removing something you think I don't understand is wrong
> (Chesterton's Fence):
>
> If you dig in the history of Portage, you will see that it's always been 
> valid,
> to have just a SINGLE hash for each file in a Manifest.  Required hashes has
> NEVER contained more than one hash.
>
> If multiple hashes are present, then Portage will validate all of them, but a
> potential attacker can still modify the Manifest and have only a single hash
> listed.  Exactly which hash MUST be present has changed over time.
>
> Manifest1 is very old, and was stored in $CAT/$PN/files/digest-$P
> Manifest2 is the current $CAT/$PN/Manifest (and soon in more locations per 
> MetaManifest).
>
> 1999/xx/xx: Portage starts with Manifest1 format, MD5-only (CVS)
> 2004/08/25: Portage gets SHA1 support in Manifest1, but is problematic, SHA1 
> generation manual only.
> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/portage/pym/portage_checksum.py?revision=1.1=markup
> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/portage/pym/portage.py?r1=1.485=1.486
> 2005/12/19: Portage Manifest1 supports MD5,SHA1,SHA256,RMD160, but still 
> requires only a single hash present. Generates MD5+SHA256+RMD160.
> https://gitweb.gentoo.org/proj/portage.git/commit/?id=cd3e3775966a9f58aebb91f58cbdb5903faad3de
> 2006/03/24: Manifest2 introduced.
> https://gitweb.gentoo.org/proj/portage.git/commit/?id=f993747ca501e8a70d6f6174711149a172cfc3c2
> 2007/01/20: MANIFEST2_REQUIRED_HASH introduced, SHA1, it must be present & 
> pass
> https://gitweb.gentoo.org/proj/portage.git/commit/?id=e768571187d1655fbb558c23d61fa2983e48e411
> 2007/12/18: MANIFEST1_REQUIRED_HASH introduced, MD5, it must be present & pass
> https://gitweb.gentoo.org/proj/portage.git/commit/?id=d9b10deaa03ce174d5ccc3b59c477549ad87e884
> 2008/02/28: Manifest1 support dropped.
> https://gitweb.gentoo.org/proj/portage.git/commit/?id=66940e1f2f0549ee8f01dad59016e168105e193d
> 2011/10/02: GLEP59 implemented, MANIFEST2_REQUIRED_HASH changes to SHA256
> https://gitweb.gentoo.org/proj/portage.git/commit/?id=c8cd3a985cc529299411d7343a11004b7d1330ef
> 2017/06/15: MANIFEST2_REQUIRED_HASH changes to SHA512
> https://gitweb.gentoo.org/proj/portage.git/commit/?id=e6abcc0b7cbdca481862a5c7cca946c01c471ffb
>
> [J04] Joux, Antoie. (2004). "Multicollisions in Iterated Hash Functions - 
> Application to Cascaded Constructions;"
> Proceedings of CRYPTO 2004, Franklin, M. (Ed); Lecture Notes in Computer 
> Science 3152, pp. 306-316.
> Available online from: 
> http://web.cecs.pdx.edu/~teshrim/spring06/papers/general-attacks/multi-joux.pdf
>

This is the information I was looking for, thank you. I feel that the
matter has been adequately explained. I apologize for missing your
response.

The paper gives a counter intuitive result, so I suspect I will have
to spend more time with it.

Cheers,
 R0b0t1



Re: [gentoo-dev] Packages up for grabs

2017-11-20 Thread Robert K
Hi, I would like to pick up app-misc/figlet

On Mon, Nov 20, 2017 at 6:37 PM, Geaaru  wrote:

> > app-admin/syslog-ng
>
> Hi, I will try to add this ebuild to my list as proxy maintainer.
>
> G.
>
> On Nov 20, 2017 5:18 PM, "Amy Liffey"  wrote:
>
> Hello all,
> The following packages are up for grabs:
>
> app-cdr/cdw
> app-misc/figlet
> app-text/tree
> dev-lang/nasm
> dev-lang/blassic
> dev-lang/clojure
> app-admin/syslog-ng
> dev-libs/eventlog
>
> Cheers,
> Amy Liffey
>
>
>


-- 
Thank you,
   Robert Kowalski.

MadGizmo.com
http://studio.madgizmo.com/ - Studio and portfolio.
http://rgk.madgizmo.com/ - Personal site with my resume.


Re: [gentoo-dev] Packages up for grabs

2017-11-20 Thread Geaaru
> app-admin/syslog-ng

Hi, I will try to add this ebuild to my list as proxy maintainer.

G.

On Nov 20, 2017 5:18 PM, "Amy Liffey"  wrote:

Hello all,
The following packages are up for grabs:

app-cdr/cdw
app-misc/figlet
app-text/tree
dev-lang/nasm
dev-lang/blassic
dev-lang/clojure
app-admin/syslog-ng
dev-libs/eventlog

Cheers,
Amy Liffey


Re: [gentoo-dev] [RFC] GLEP 74 post-Council review update [v2]

2017-11-20 Thread Ulrich Mueller
> On Mon, 20 Nov 2017, Michał Górny wrote:

> New changes:

> 9d819c9 glep-0074: Disallow filenames containing whitespace
> 4124b2f glep-0074: Explicitly specify UTF-8 encoding
> 7f9bd9f glep-0074: Include suggestions from Daniel Campbell

Here are a few comments (quoting below only the parts of the text
referenced by them):

> The Manifest files use UTF-8 encoding.

I don't understand the purpose of that requirement. The only place
where bytes outside of the ASCII range can occur are names of
distfiles, and these should simply be passed transparently. Otherwise,
you would have to reject any sequence of non-ASCII bytes that doesn't
form a valid UTF-8 sequence, which looks like an arbitrary restriction
to me.

> It is an error for a single file to be matched by multiple entries
> of different semantics, file size or checksum values. It is an error
> to specify another entry for a file matching ``IGNORE``, or one of its
> subdirectories.

What about regular files in a directory (or subdirectory) matched by
IGNORE? Looks like this case is not covered (?).

> All paths specified in the Manifest file must consist of characters
> corresponding to valid UTF-8 code points excluding the NULL character
> (``U+``) and characters classified as whitespace in the current
> version of the Unicode standard [#UNICODE]_. It is an error to use
> Manifest files in directories containing files whose names contain
> the disallowed characters.

See above. I believe that NUL and ASCII whitespace (i.e. characters 09
0a 0b 0c 0d 20) should be excluded, but excluding byte sequences like
"e1 9a 80" (which is the UTF-8 encoding for U+1680 "OGHAM SPACE MARK")
doesn't make sense.

> During the verification process, the client should compare the timestamp
> against the update time obtained from a local clock or a trusted time
> source. If the comparison result indicates that the Manifest at the time
> of receiving was already significantly outdated, the client should
> either fail the verification or require manual confirmation from user.

s/from user./from the user./

> ``TIMESTAMP ``
>   Specifies a timestamp of when the Manifest file was last updated.
>   The timestamp must be a valid second-precision ISO8601 extended format

s/ISO8601/ISO 8601/

> ``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). *Path* must be a plain file or directory
>   path without a trailing slash, and must not contain wildcards.

What does that mean? Wildcards are not special (so "foo*" will match
literally), or wildcard characters like "*" are not allowed at all?

> ``AUX   ...``
>   Equivalent to the ``DATA`` type, except that the filename is relative
>   to ``files/`` subdirectory.

s/to/to the/

> 3. Process all ``MANIFEST`` entries, recursively. Verify the Manifest
>files according to `file verification`_ section, and include their

s/according to/according to the/

> 6. Verify the entries in *covered* set for incompatible duplicates

s/in *covered* set/in the *covered* set/

> 7. Verify all the files in the union of the *present* and *covered*
>sets, according to `file verification`_ section.

s/to/to the/

>a. If a ``IGNORE`` entry in the ``Manifest`` file covers
>   the *original* directory (or one of the parent directories), stop.

s/a ``IGNORE`` entry/an ``IGNORE`` entry/

> An example top-level Manifest file for the Gentoo repository would have
> the following content::

> TIMESTAMP 2017-10-30T10:11:12Z
> IGNORE distfiles
> IGNORE local
> IGNORE lost+found
> IGNORE packages
> MANIFEST app-accessibility/Manifest 14821 SHA256 1b5f.. SHA512 f7eb..
> ...
> MANIFEST eclass/Manifest.gz 50812 SHA256 8c55.. SHA512 2915..
> ...

> An example modern Manifest (disregarding backwards compatibility)
> for a package directory would have the following content::

> DATA SphinxTrain-0.9.1-r1.ebuild 932 SHA256 3d3b.. SHA512 be4d..
> DATA SphinxTrain-1.0.8.ebuild 912 SHA256 f681.. SHA512 0749..
> DATA metadata.xml 664 SHA256 97c6.. SHA512 1175..
> DATA files/gcc.patch 816 SHA256 b56e.. SHA512 2468..
> DATA files/gcc34.patch 333 SHA256 c107.. SHA512 9919..
> DIST SphinxTrain-0.9.1-beta.tar.gz 469617 SHA256 c1a4.. SHA512 1b33..
> DIST sphinxtrain-1.0.8.tar.gz 8925803 SHA256 548e.. SHA512 465d..

Update hashes to BLAKE2B SHA512?

> This specification aims to avoid arbitrary restrictions. For this
> reason, the filename characters are only restricted by excluding two

s/the filename characters/filename characters/

> technically problematic groups:

> 1. The NULL character (``U+``) is normally used to indicate the end
>of a null-terminated string. Its use could therefore break programs
>written using C. Furthermore, it is not allowed in any known
>filesystem.

> 2. The whitespace characters are used to separate Manifest fields. 

Re: [gentoo-dev] [RFC] GLEP 74 post-Council review update [v2]

2017-11-20 Thread Michał Górny
W dniu czw, 16.11.2017 o godzinie 11∶19 +0100, użytkownik Michał Górny
napisał:
> Hi, everyone.
> 
> Here's the updated version of GLEP 74 taking into consideration
> the points made during the Council pre-review.
> 
> ReST: https://dev.gentoo.org/~mgorny/tmp/glep-0074.rst
> HTML: https://dev.gentoo.org/~mgorny/tmp/glep-0074.html
> 

New changes:

9d819c9 glep-0074: Disallow filenames containing whitespace
4124b2f glep-0074: Explicitly specify UTF-8 encoding
7f9bd9f glep-0074: Include suggestions from Daniel Campbell


---
GLEP: 74
Title: Full-tree verification using Manifest files
Author: Michał Górny ,
Robin Hugh Johnson ,
Ulrich Müller 
Type: Standards Track
Status: Draft
Version: 1
Created: 2017-10-21
Last-Modified: 2017-11-16
Post-History: 2017-10-26, 2017-11-16
Content-Type: text/x-rst
Requires: 59, 61
Replaces: 44, 58, 60
---

Abstract


This GLEP extends the Manifest file format to cover full-tree file
integrity and authenticity checks. The format aims to be future-proof,
efficient and provide means of backwards compatibility.


Motivation
==

The Manifest files as defined by GLEP 44 [#GLEP44]_ provide the current
means of verifying the integrity of distfiles and package files
in Gentoo. Combined with OpenPGP signatures, they provide means to
ensure the authenticity of the covered files. However, as noted
in GLEP 57 [#GLEP57]_ they lack the ability to provide full-tree
authenticity verification as they do not cover any files outside
the package directory. In particular, they provide multiple ways
for a third party to inject malicious code into the ebuild environment.

Historically, the topic of providing authenticity coverage for the whole
repository has been mentioned multiple times. The most noteworthy effort
are GLEPs 58 [#GLEP58]_ and 60 [#GLEP60]_ by Robin H. Johnson from 2008.
They were accepted by the Council in 2010 but have never been
implemented. When potential implementation work started in 2017, a new
discussion about the specification arose. It prompted the creation
of a competing GLEP that would provide a redesigned alternative to
the old GLEPs.

This specification is designed with the following goals in mind:

1. It should provide means to ensure the authenticity of the complete
   repository, including preventing the injection of additional files.

2. The format should be universal enough to work both for the Gentoo
   repository and third-party repositories of different characteristics.

3. The Manifest files should be verifiable stand-alone, that is without
   knowing any details about the underlying repository format.


Specification
=

Manifest file format


This specification reuses and extends the Manifest file format defined
in GLEP 44 [#GLEP44]_. For the purpose of it, the *file type* field is
repurposed as a generic *tag* that could also indicate additional
(non-checksum) metadata. Appropriately, those tags can be followed by
other space-separated values.

Unless specified otherwise, the paths used in the Manifest files
are relative to the directory containing the Manifest file. The paths
must not reference the parent directory (``..``).

The Manifest files use UTF-8 encoding.


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.

The top-level Manifest may reference sub-Manifests contained
in subdirectories of the repository. The sub-Manifests are traditionally
named ``Manifest``; however, the implementation must support arbitrary
names, including the possibility of multiple (split) Manifests
for a single directory. The sub-Manifest can only cover the files inside
the directory tree where it resides.

The sub-Manifest can also be signed using OpenPGP armored cleartext
format. However, the signature verification can be omitted since it
already is covered by the signed top-level Manifest.


Directory tree coverage
---

The specification provides three ways of skipping Manifest verification
of specific files and directories (recursively):

1. explicit ``IGNORE`` entries in Manifest files,

2. injected ignore paths via package manager configuration,

3. using names starting with a dot (``.``) which are always skipped.

All files that are not ignored must be covered by at least one
of the Manifests.

A single file may be matched by multiple identical or equivalent
Manifest entries, if and only if the entries have the same semantics,
specify the same size and the checksums common to both entries match.
It is an error for a single file to be matched by multiple entries
of different semantics, file size or checksum values. It is an error
to specify another entry for 

Re: [gentoo-dev] Packages up for grabs

2017-11-20 Thread R0b0t1
On Monday, November 20, 2017, Amy Liffey  wrote:
> dev-lang/clojure

I have some interest in helping with clojure. I have interacted with the
proxy maintainers before - do I need to wait for it to break?

Cheers,
R0b0t1


[gentoo-dev] Re: Prefix bootstrap script maintainability (Was: No more stable keywords for Games)

2017-11-20 Thread R0b0t1
Hello friends!

On Monday, November 20, 2017, Sergei Trofimovich  wrote:
> On Sun, 19 Nov 2017 22:47:35 -0600
> R0b0t1  wrote:
>
>> Understanding an existing codebase should not be a technical
>> challenge. I had to resort to reimplementing all of the steps myself,
>> in part to understand if they were done properly in the first place.
>
> Looks like you are an expert in this area now and are perfectly capable
> of submitting the patches. I can review them at least for crossdev.
>

In my goal to understand bootstrap-rap I am still in the process of
creating something crossdev-like that can be used to generate a toolchain.

A recurring problem I have had is that this set of related tasks -
generating cross compilers and packages, generating an initramfs, or
generating a prefixed pseudoinstallation - all start by reimplementing some
subset of portage.

For prefix/RAP it makes sense, for the others possibly not.

>> Unfortunately these are things that the original authors should
>> produce. Experience has shown me that documentation written by
>> ancillary contributors that do not have deep experience with the code
>> base is poor.
>
> If you have invested some time to understand the code you and understood
> at least something you should be perfectly capable of submitting a patch
> to document a thing or two that took you time to grasp.
>

Yes, that is what I am doing with my own code as I have the time to write
it. I mostly still have no idea what is going on in the already written
code.

> Nobody knows what is hard for you to understand except yourself.
>

People will often find tasks similarly difficult. This is why I am
surprised documentation is lacking for specific projects, or, I suppose,
any software package that has ever been created.

Cheers,
R0b0t1


Re: [gentoo-dev] [RFC] GLEP 74 post-Council review update

2017-11-20 Thread Michał Górny
W dniu pią, 17.11.2017 o godzinie 12∶37 -0800, użytkownik Daniel
Campbell napisał:
> > 
> > [snip]
> > Non-strict Manifest verification
> > 
> > 
> > Originally the Manifest2 format provided a special ``MISC`` tag that
> > was used for ``metadata.xml`` and ``ChangeLog`` files. This tag
> > indicated that the Manifest verification failures could be ignored for
> > those files unless the package manager was working in strict mode.
> > 
> > The first versions of this specification continued the use of this tag.
> > However, after a long debate it was decided to deprecate it along with
> > the non-strict behavior, and require all files to strictly match.
> 
> It may be outside the scope of the GLEP, but a link to said long debate
> might be relevant to the reader, especially if they have suggestions or
> points that have already been discussed in the debate.

It's been on IRC.

> Aside from the few nitpicks this looks good. Hope this helps.

I think I've fixed every single one of them. I'm going to fix one issue
I've noticed (lack of filename whitespace restriction) and resubmit.

-- 
Best regards,
Michał Górny




Re: [gentoo-dev] Packages up for grabs

2017-11-20 Thread Jonas Stein
> app-text/tree

I will take care of this one.

--
Best,
Jonas



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Packages up for grabs

2017-11-20 Thread Amy Liffey
Hello all,
The following packages are up for grabs:

app-cdr/cdw
app-misc/figlet
app-text/tree
dev-lang/nasm
dev-lang/blassic
dev-lang/clojure
app-admin/syslog-ng
dev-libs/eventlog

Cheers,
Amy Liffey



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] NEWS item for games destabling

2017-11-20 Thread Róbert Čerňanský
On Mon, 20 Nov 2017 10:26:29 +0100
David Seifert  wrote:

> Round 2 (with correct whitespace this time):
> 
> Title: No stable KEYWORDS for Gentoo Games
> Author: David Seifert 
> Content-Type: text/plain
> Posted: 2017-11-20
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Keyword: amd64 x86
> 
> As the Games team does not have enough manpower to keep tabs on all
> games packages, we have dropped all ebuilds maintained by the games
> project to unstable KEYWORDS (without those required by other stable
> packages). If you have any of these stable games packages installed,
> you will have to add them to /etc/portage/package.accept_keywords/
> manually. Failures related to missing stable KEYWORDS will show up as
> 
>   The following keyword changes are necessary to proceed:
>(see "package.accept_keywords" in the portage(5) man page for more
> details)
>   # required by @selected
>   # required by @world (argument)
>   =games-action/0verkill-0.16-r4 ~amd64
> 
> While we accept that this will cause some irritation for the
> community, pretending we have a well supported games collection by
> having a wealth of stable games packages is misleading at best. We
> welcome contributions from outsiders willing to polish up the games
> landscape in Gentoo via the Proxy Maintainers.

What does it mean for the future?  Should not users bother to test &
write stabilization request bugs for games anymore?  Or stabi
requests will still be accepted?

Robert


-- 
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk



Re: [gentoo-dev] NEWS item for games destabling

2017-11-20 Thread David Seifert
Round 2 (with correct whitespace this time):

Title: No stable KEYWORDS for Gentoo Games
Author: David Seifert 
Content-Type: text/plain
Posted: 2017-11-20
Revision: 1
News-Item-Format: 1.0
Display-If-Keyword: amd64 x86

As the Games team does not have enough manpower to keep tabs on all
games packages, we have dropped all ebuilds maintained by the games
project to unstable KEYWORDS (without those required by other stable
packages). If you have any of these stable games packages installed,
you will have to add them to /etc/portage/package.accept_keywords/
manually. Failures related to missing stable KEYWORDS will show up as

  The following keyword changes are necessary to proceed:
   (see "package.accept_keywords" in the portage(5) man page for more
details)
  # required by @selected
  # required by @world (argument)
  =games-action/0verkill-0.16-r4 ~amd64

While we accept that this will cause some irritation for the community,
pretending we have a well supported games collection by having a
wealth of stable games packages is misleading at best. We welcome
contributions from outsiders willing to polish up the games landscape
in Gentoo via the Proxy Maintainers.



Re: [gentoo-dev] Re: Prefix bootstrap script maintainability (Was: No more stable keywords for Games)

2017-11-20 Thread Sergei Trofimovich
On Sun, 19 Nov 2017 22:47:35 -0600
R0b0t1  wrote:

> Understanding an existing codebase should not be a technical
> challenge. I had to resort to reimplementing all of the steps myself,
> in part to understand if they were done properly in the first place.

Looks like you are an expert in this area now and are perfectly capable
of submitting the patches. I can review them at least for crossdev.

> Unfortunately these are things that the original authors should
> produce. Experience has shown me that documentation written by
> ancillary contributors that do not have deep experience with the code
> base is poor.

If you have invested some time to understand the code you and understood
at least something you should be perfectly capable of submitting a patch
to document a thing or two that took you time to grasp.

Nobody knows what is hard for you to understand except yourself.

-- 

  Sergei


pgpIXGfhzmhTv.pgp
Description: Цифровая подпись OpenPGP