Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements

[Brian Harring]

On Sun, May 21, 2006 at 12:10:40PM +0900, Georgi Georgiev wrote:
> Just two points:
> 
> - standards should not be set by the primary package manager
> - the primary package manager does not have to be developed by Gentoo.
> 
> More about it below:
> 
> maillog: 20/05/2006-14:54:18(+0200): Paul de Vrieze types
> > The primary package  manager is the package manager that  sets the
> > standards for the  tree.  All  ebuilds  in the  tree  must function
> > with  the primary  package manager.  As  the primary package manager
> > sets  the standard it does  not have to maintain compatibility with
> > other package managers.
> 
> I personally hate the way this sounds. It implies that the package
> manager comes before the standards while it should be the other way
> around. Plus, it would not solve the main problem -- that there are no
> set standards for the tree. You accept the GLEP like this and there will
> continue to be no standards.



So... where's the standard? :)
Right, no doc yet that's official, thus at this juncture, what's 
there now (portage) is the effective standard.

Said in the last thread, chunking out a formal EAPI=0 definition from 
the tree/portage implementation, tiz a good thing.  But until that's 
done (and folks agree it's the standard), portage (primary manager) 
rules, thus doc it out (as I've suggested to ciaran for the 
slot value and use/slot dep restrictions he's added) if you're after 
changing the existing definition.

Not saying I like it, but it's the reality of current situation- the 
intention of the glep is to prevent lock in, and to keep the tree 
unified in terms of support (avoid fracturing of the env the tree has 
been written against), either a doc standard is created for EAPI=0, or 
portage defines the standard (since it's primary).


> The process should go like this:
> 
> 1. Standars are set (by the council or whatever).
> 2. They are implemented in the official package manager.
> 3. Other package managers follow suit.

Council really shouldn't be involved sans big changes imo, and big 
changes imo should require gleps (both from an archive standpoint, and 
from fitting the council in via existing process of gleps).

One concern out of all of this is ensuring that their isn't 
ping/ponging back and forth as to which manager is 'official'; arms 
race in terms of features supported by each manager is a good thing 
imo, but need to keep that from causing chaos for devs in terms of 
changing standards.

~harring


pgpa1x9wBpjMZ.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements

[Georgi Georgiev]

Just two points:

- standards should not be set by the primary package manager
- the primary package manager does not have to be developed by Gentoo.

More about it below:

maillog: 20/05/2006-14:54:18(+0200): Paul de Vrieze types
> The primary package  manager is the package manager that  sets the
> standards for the  tree.  All  ebuilds  in the  tree  must function
> with  the primary  package manager.  As  the primary package manager
> sets  the standard it does  not have to maintain compatibility with
> other package managers.

I pesonally hate the way this sounds. It implies that the package
manager comes before the standards while it should be the other way
around. Plus, it would not solve the main problem -- that there are no
set standards for the tree. You accept the GLEP like this and there will
continue to be no standards.

The process should go like this:

1. Standars are set (by the council or whatever).
2. They are implemented in the official package manager.
3. Other package managers follow suit.

Take the application servers as a good example. You have Java Servlet
Technology, and JavaServer Pages Technology. So far, so good. These are
developed by Sun. And you also have Apache Tomcat which is the official
reference implementation.  So you have the standards set by Sun, and you
have an open community implementing them in the "official" container
*later*. And pay attention that these are not maintained by the same
organization.

And what about the web. You have the W3C that sets the standards for web
pages. And you have no single browser to implement them all. So, in
order for a package manager to be recognized by Gentoo it should not
implement *all* standards. I.e. if you have news delivered with the
tree, you could support a package manager that cannot read the news as
primary.  After all this is not a major feature and does not contradict
"All ebuilds should work with the primary package manager". And you can
have a separate news reader the cooperates with the primary package
manager or not.

-- 
\Georgi Georgiev   \  Ignorance is when you don't know anything  \
/ [EMAIL PROTECTED]/  and somebody finds it out. /
\  http://www.gg3.net/ \ \


pgpaPJU9FXtoj.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Signing everything, for fun and for profit

[Robin H. Johnson]

On Sat, May 20, 2006 at 06:54:44AM -0400, Peter wrote:
> On Thu, 18 May 2006 23:45:17 +0200, Patrick Lauer wrote:
> 
> >The problem, in short, is how to handle the checksumming and signing of
> >gentoo-provided files so that manipulation by external entities becomes
> >difficult.
> all snip...
> 
> PMFJI, but as a user, not a security expert, I had a few thoughts that I'd
> like to throw in. Thanks to Patrick, he helped me to drill down some of
> the ideas and I present them for consideration. It's just a framework, so
> I will be brief.
Even larger snip.

I was actually looking at something similar to this, for the 'simple'
portion of Patrick's plan. You have most of the major ideas down, but
missed a few holes, and sticking points.

I'll try to get a writeup of it out later tonight, got a double-date
first ;-).

Thanks for the good writeup of Slackware as well, it's one I didn't
elaborate much on when I previously described the processes of
RPM-distros and Debian.

-- 
Robin Hugh Johnson
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgphsW0CfXK1Z.pgp
Description: PGP signature

Re: [gentoo-dev] Signing everything, for fun and for profit

[Robin H. Johnson]

On Sat, May 20, 2006 at 03:21:13PM +0200, Jan Kundr?t wrote:
> I don't know much about cryptography, but could you please elaborate on
> why is using one subkey for all the stuff considered a Bad Thing?
The basic form of it, is a vulnerability towards a class of attacks that
require a large supply of signed/encrypted material.
For a primer on various modes of using block ciphers, see 
Wikipedia: http://tinyurl.com/bbcmf

It's conceivable that (and this is the absolute worst case), under this
class of attack, a lot of signing may ultimately reveal bits of your
key, because the attacker has both the plaintext and ciphertext, and can
ultimately compute it - this can either be brute-force, or
mathematically (consider it solving algebra).

> Off-topic question - I've already met Alice, verified her identity,
> signed her keys and now she wants me to sign her new subkey with same
> name, e-mail etc because the old one has expired. Alice lives in Canada
> so I can't meet her easily. Should I sign it again with the same level
> of "trust"?
I think you missed something in my original email, namely that you don't
sign subkeys, you sign uids.

Since uids don't expire that part is irrelevant, but they can be revoked 
- then this becomes the same as bob's case below.

Note:
Unless you are using the 'tsign' command under GnuPG, the trust question
it asks you is only for it's local database, and is NOT included with
the exported keys that are sent to keyservers or other users. So let's
assume you are using tsign as well.

> Another situation - Bob, Alice's boyfriend, lives in Canada. I've met
> him before, verified his identity and signed his subkey for
> [EMAIL PROTECTED] Now he wants my signature for [EMAIL PROTECTED] Should I
> sign it?
Actual answer:
You'll need to rely on your discretion a bit, but you can narrow down
the possibilities for attacks by following a specific process (and there
is a package that makes this much easier, but it's only available in
Debian's SVN at the moment http://tinyurl.com/ggueq).
0. Bob sends you a request about his new uid, signed with his key that
   you can verify.
1. Sign the new uid, and export the uid signature to a file.
2. Delete the signature from your keyring, you don't want it trusted yet
   (you can avoid this is you have a temp clone of your keyring).
3. Send Bob an encrypted email, with the uid signature file attached.
4. Bob needs to be able to decrypt the email using his GnuPG - thus
   associating the email address listed in his key with his key - if she
   can't decrypt the email - she's an imposter that has taken over the
   email account.

-- 
Robin Hugh Johnson
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgp0905KBwRTc.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements

[Thomas Cort]

On Sat, 20 May 2006 17:11:57 +0200
Paul de Vrieze <[EMAIL PROTECTED]> wrote:
> > > The primary package manager is maintained on official gentoo
> > > infrastructure, under control of gentoo developers.
> >
> > I don't really see this as a requirement. Many Linux distributions use
> > package managers that they don't have direct control over. Ubuntu uses apt,
> > Mandrake uses rpm, etc.
> 
> Those are binary distributions. Even they have extensions in their own 
> package 
> managers. Binary distribution is easier than from source. One of the 
> strengths of Gentoo is formed by the package manager. If the package manager 
> is out of control of gentoo, this means that Gentoo no longer has control 
> over its future or its features.

I definitely agree that Gentoo needs a team of people to deal with the primary 
package manager, it is one of the most important tools in a Linux system. It is 
especially important in Gentoo where the package manager is, at this point in 
time, required to install a standard desktop system. I disagree that the 
package manager needs to be directly maintained by Gentoo. Since Gentoo will 
never depend upon a piece of non-Free software[1], it is safe to assume that 
the package manager is Free software (aka open source). Because of this, we 
will never be locked-in, helpless, or under the control of an external project. 
If we dislike the direction in which it is going or want to add our own 
features, then we are free to do so either by submitting patches upstream, 
adding our own custom gentoo patches to the stock sources, or by forking the 
project entirely.

So what I suggest is the following:

"While it is desirable that the primary package manager be maintained on 
official gentoo infrastructure, under the control of gentoo developers, it is 
not required. During the path to becoming the primary package manager, the 
package manager maintainers must be asked if they would like their project to 
be an official Gentoo project. The package manager maintainers have the right 
to refuse such an offer if there is a team of at least 3 Gentoo developers that 
understand the package manager source code and are willing to deal with bugs, 
testing, feature enhancements, modifications, and integration."

I hope the above is an acceptable compromise. It aims at making the project an 
official Gentoo project while still allowing package managers that aren't under 
Gentoo's direct control. In that case there are still Gentoo developers who 
have a handle on the code and can make any modifications / enhancements / 
feature changes that are required by Gentoo.

[1] http://www.gentoo.org/main/en/contract.xml


pgpMG26YbC1mC.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements

[Paul de Vrieze]

On Saturday 20 May 2006 18:00, Alec Warner wrote:
> Paul de Vrieze wrote:
> > The promissed glep on package manager requirements. Please comment on it.
> > There are some parts that may be controversial (portage has in the past
> > not provided support for reverting to stable either), but please keep the
> > discussion on topic.
> >
> > Paul
>
> s/primary/official/g
>
> This primary business is silly IMHO.  GCC is Gentoo's official compiler,
>   baselayout is the "official" init system, etc...

There might be multiple official package manager. Only one has the lead 
position from a gentoo point of view. Please also be aware that the term 
primary is from the point of view of gentoo, not from user point of view. 
This GLEP does not mean that there can not be multiple package managers that 
could play the role of primary package manager for a system.

>
> There is precedent here, and you are ignoring it.
>
> Basically this whole GLEP is a reactive farse.  I realize thats not your
> intention, you seriously want a defined manner in which many package
> managers can live.  However reading the GLEP it seems to be built
> completely against Paludis; stacking the deck as it were.  However I
> left other comments below ;)

I am not against paludis at all. I want to set the playing field on which 
alternate package managers can thrive. This way there would be a way in which 
package managers can live along eachother and better gentoo. I realise this 
should have been written earlier, preventing wasted efforts, and I am sorry I 
did not do it before.

On design quality I'd like to say that design quality is not only formed by 
how well the design is on itself. It is even much more how well a system fits 
in its environment. Ignoring what is already there is the easy way out. A way 
in which a transition can be made without breaking what is there, and still 
ensuring a good design after the transition. That is really great design.

I'll react on your comments below.

> >
> > Not a problem for this GLEP. There is no previous standard as the issue
> > did not exist before. This GLEP is to prevent future compatibility
> > issues.
>
> If there is Official and 'everything else" I think this whole section
> can be dropped.

The thing is that there are possibilities in between them. They might not be 
used, but we owe it to current and future package manager designers to allow 
this possibility. A secondary package manager that installs rpm packages 
(perhaps for LSB compatibility) can very well be official, but not even able 
to set the standard on packages (hell it uses rpm's).


> > As a package manager is in a state of higher support there are higher
> > requirements to it. The purpose of these requirements is to ensure the
> > unity of the distribution and the package tree. For this purpose it is
> > needed that there is only one primary package manager.
>
> One official package manager, but many can be used.

Certainly true. I've added something to this extend to the next revision.

>
> > primary package manager requirements <#id13>
> >
> > The primary package manager is the package manager that sets the
> > standards for the tree. All ebuilds in the tree must function with the
> > primary package manager. As the primary package manager sets the
> > standard it does not have to maintain compatibility with other package
> > managers.
>
> This outlook inhibits innovation in the tree.  I agree with stephen, in
> that the tree should set the standard.  If you want a new feature in the
> tree, I think a proposal would be good ( not a GLEP necessarily, but a
> tree proposal ).  I think crap goes in that is not discussed in advance...
>
> One could say, the official package manager sets the standard such that
> someone needs to have support in the package manager for it to operate
> properly.

Look at this way. It is only a standard when it is supported in a testing 
version of the primary package manager.

> However in many industries you find the opposite.  First a standard is
> set, then a prototype (reference board, whathaveyou) is created, then it
>   is released for companies to use.  Here you want the opposite.  The
> feature as an idea is created, portage implements it, then the other
> package managers copy it?  Sounds silly ;)

Package managers may implement anything they want. Packages (not package 
managers) may only use it when the primary package manager supports it. I 
have got clarified it in the new revision that not only the implementation 
determines the standard, but also the existing guidelines, qa tools, etc. As 
example paludis would be perfectly right in not supporting all kinds of 
toplevel magic. Even though portage will not complain it is accepted as 
something that must not be done.

>
> > The primary package manager does however have the responsibility that it
> > must be very stable. The primary package manager must maintain
> > compatibility with old versions of itself for extended periods 

Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements

[Paul de Vrieze]

On Saturday 20 May 2006 19:45, Marius Mauch wrote:
> On Sat, 20 May 2006 15:41:37 +0100
>
> Stephen Bennett <[EMAIL PROTECTED]> wrote:
> > > The primary package  manager is the package manager that  sets the
> > > standards for the  tree. All  ebuilds  in the  tree  must function
> > > with  the primary  package manager. As  the primary package manager
> > > sets  the standard it does  not have to maintain compatibility with
> > > other package managers.
> >
> > The current 'Portage defines the tree format' is IMO a cause of a lot
> > of problems at the moment. It would be better, I think, to define in a
> > package-manager-agnostic document just what the current ebuild format
> > (EAPI 0) means. If at any point in the future the primary package
> > manager changes in what it supports and/or requires, a new EAPI spec
> > is written. The council, or some other body, can then define which
> > EAPI formats may be used by ebuilds in the tree.
>
> Full ACK on this one, though EAPI itself is insufficient, it would only
> define the ebuild format, but you also have to look at the repo itself
> (see past -portage-dev discussions about this), e.g. for the Manifest
> or profile formats.
> It's not that easy to conform to a spec that doesn't really exist
> (unless you consider the implementation as spec).

I have no problem with this. In principle it is unavoidable that a package 
manager deviates in certain points with the actual standard. This is already 
true for portage. While there is no formal standard, a partial description 
can be found in the various authoring guides. The point of the part in the 
glep is more to say that the maintainers of the primary package manager have 
control over the format. I will add text to this effect to the GLEP.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpnVVa4IO6v7.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements

[Marius Mauch]

On Sat, 20 May 2006 15:41:37 +0100
Stephen Bennett <[EMAIL PROTECTED]> wrote:

> > The primary package  manager is the package manager that  sets the
> > standards for the  tree. All  ebuilds  in the  tree  must function
> > with  the primary  package manager. As  the primary package manager
> > sets  the standard it does  not have to maintain compatibility with
> > other package managers.
> 
> The current 'Portage defines the tree format' is IMO a cause of a lot
> of problems at the moment. It would be better, I think, to define in a
> package-manager-agnostic document just what the current ebuild format
> (EAPI 0) means. If at any point in the future the primary package
> manager changes in what it supports and/or requires, a new EAPI spec
> is written. The council, or some other body, can then define which
> EAPI formats may be used by ebuilds in the tree.

Full ACK on this one, though EAPI itself is insufficient, it would only
define the ebuild format, but you also have to look at the repo itself
(see past -portage-dev discussions about this), e.g. for the Manifest
or profile formats.
It's not that easy to conform to a spec that doesn't really exist
(unless you consider the implementation as spec).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements

[Alec Warner]

Paul de Vrieze wrote:
The promissed glep on package manager requirements. Please comment on it. 
There are some parts that may be controversial (portage has in the past not 
provided support for reverting to stable either), but please keep the 
discussion on topic.


Paul




s/primary/official/g

This primary business is silly IMHO.  GCC is Gentoo's official compiler, 
 baselayout is the "official" init system, etc...


There is precedent here, and you are ignoring it.

Basically this whole GLEP is a reactive farse.  I realize thats not your 
intention, you seriously want a defined manner in which many package 
managers can live.  However reading the GLEP it seems to be built 
completely against Paludis; stacking the deck as it were.  However I 
left other comments below ;)








[Gentoo]  	[*Gentoo Linux Home 
*] [*GLEP Index 
*] [*GLEP Source 
*]


GLEP:   49
Title:  Alternative Package Manager requirements
Version:2214
Last-Modified:	2006-05-20 14:51:41 +0200 (Sat, 20 May 2006) 
 


Author: Paul de Vrieze ,
Status: Draft
Type:   Standards Track
Content-Type:   text/x-rst 
Created:18-May-2006
Post-History:   19-May-2006



Contents

* Abstract <#abstract>
* Motivation <#motivation>
* Rationale <#rationale>
* Backwards Compatibility <#backwards-compatibility>
* Categories of package managers <#categories-of-package-managers>
* Package manager requirements <#package-manager-requirements>
  o primary package manager requirements
<#primary-package-manager-requirements>
  o candidate primary package manager requirements
<#candidate-primary-package-manager-requirements>
  o secondary package manager requirements
<#secondary-package-manager-requirements>
  o third party package manager requirements
<#third-party-package-manager-requirements>
* transition phases <#transition-phases>
  o primary package manager transition phase
<#primary-package-manager-transition-phase>
  o Secondary package manager to candidate primary package
manager transition

<#secondary-package-manager-to-candidate-primary-package-manager-transition>
  o Third party to other transition
<#third-party-to-other-transition>
* References <#references>
* Copyright <#copyright>


  Abstract <#id7>

This GLEP describes four classes of package managers. What the 
requirements for them are, and what support they can receive.



  Motivation <#id8>

To set a standard that package managers that seek gentoo project 
approval and support should adhere to.



  Rationale <#id9>

Currently portage is showing its age. The code of portage does not seem 
to be salvageable for new versions. There are two known alternative 
package managers that claim a level of portage compatibility. These 
alternatives are paludis  [1] <#id1> and 
pkgcore  [2] 
<#id3>. Before these alternatives are developed further, a set of rules 
should be created to level the playing field and ensuring that decisions 
can be made clearly.



  Backwards Compatibility <#id10>

Not a problem for this GLEP. There is no previous standard as the issue 
did not exist before. This GLEP is to prevent future compatibility issues.



If there is Official and 'everything else" I think this whole section 
can be dropped.



  Categories of package managers <#id11>

We distinguish four categories of package managers. While a package 
manager can transition from one category to another, it can not be in 
two categories at the same time. It can be in a state of transition though.


/Primary Package Manager/
There is one primary package manager. Currently this position is
held by portage. The primary package manager is assigned by the
council and all packages in the official tree must be installable by
a useable version of the primary package manager.
/Candidate Primary Package Managers/
A candidate Primary Package Manager does aim, or show an aim, at
replacing the current primary package manager. At a point where the
package manager is deemed stable a decision must be made whether
this package manager should become the new primary package manager.
At that point the primary package manager transition phase
<#primary-package-manager-transition-phase> starts.
/Secondary Package Managers/

A secondary package manager is a package manager that coexists with
the primary package manager, while not aiming to rep

Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements

[Paul de Vrieze]

On Saturday 20 May 2006 11:51, Thomas Cort wrote:
> On Sat, 20 May 2006 14:54:18 +0200
>
> Paul de Vrieze <[EMAIL PROTECTED]> wrote:
> > *Primary Package Manager*
> >There  is one primary  package manager.
>
> Gentoo has always been about choice, could you explain what is the
> rationale behind having only one primary package manager?

Ok, I'll go along the various situations with two primary package managers 
that can exist (it has to do with network effects):

- There are two primary package managers, A and B. Package manager B accepts 
ebuilds that package manager A does not accept. At this point package manager 
B is the most useful. As there is no problem with using package manager B, 
all authors who need package manager B features use it. They forget about 
package manager A. As a result, it will not be long before a significant part 
of the tree does no longer work with package manager A. It is only a matter 
of time before the (often highly complex, and in need of such features) core 
packages that everyone needs is in this set. Effectively obsoleting package 
manager A.

- There are two primary package managers, C and D. Each one supports features 
the other one doesn't. While this situation seems different, it actually 
isn't that different. In the beginning they each have 50% of the packages 
that are not usable by both. At some point this 50% will change. At that time 
ebuild authors have to choose when they need a new feature. In most cases 
they will choose for that package manager (D) that is used by most people. 
This increases the incentives for users to use package manager D. This again 
leads more ebuild authors into using package manager D, etc. Again leading to 
one package manager to be obsoleted.

The situations described above are what is called a network effect. They show 
why everyone uses internet instead of some people using compuserve, some 
people america online, some people internet, and yet some other people still 
using bbs systems. It also explains why windows is by nature a monopoly and 
why linux has such problems being an alternative operating system (see the 
interaction between features, compatibility and amount of users).

> > All ebuilds in the tree must function with the primary package
> > manager.
>
> I definitely see this is as a requirement. One thing I am wondering is, who
> is responsible for testing the over 24,000 ebuilds in the tree to make sure
> that they work with the new package manager? Is it the package manager
> team, arch teams, package/herd maintainers, arch/herd testers, or others?

The other package manager team is responsible for initial testing. At a point 
where a package manager is accepted as candidate replacement or secondary 
package manager, it is acceptable that bugs are filed against packages that 
do not work with the other package manager. If they are caused by the 
standard (written standard, not things that are accepted by the primary by 
accident) not being accepted by the secondary or candidate replacement 
package manager this is a bug on that package manager, otherwise on the 
violating package. For a secondary package manager this only, when its usage 
makes sense on the package in the first place.

> > The primary package manager is maintained on official gentoo
> > infrastructure, under control of gentoo developers.
>
> I don't really see this as a requirement. Many Linux distributions use
> package managers that they don't have direct control over. Ubuntu uses apt,
> Mandrake uses rpm, etc.

Those are binary distributions. Even they have extensions in their own package 
managers. Binary distribution is easier than from source. One of the 
strengths of Gentoo is formed by the package manager. If the package manager 
is out of control of gentoo, this means that Gentoo no longer has control 
over its future or its features.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpyE9SbwJp4b.pgp
Description: PGP signature

[gentoo-dev] Re: Re: Signing everything, for fun and for profit

[Peter]

On Sat, 20 May 2006 15:37:54 +0100, Chris Bainbridge wrote:

> On 20/05/06, Peter <[EMAIL PROTECTED]> wrote:
>> PMFJI, but as a user, not a security expert, I had a few thoughts that I'd
>> like to throw in. Thanks to Patrick, he helped me to drill down some of
>> the ideas and I present them for consideration. It's just a framework, so
>> I will be brief
> 
Thanks for not throwing me overboard to the sharks! I had a few comments.

> Thanks for your input. From a security point of view your scheme is
> fine, but as pointed out by others you won't be able to selectively
> rsync parts of the tree. That will require a signature for each
> manifest, and a manifest for every directory. The problem I see is that
> the manifest is going to have to include a hash for each subdirectory -
> otherwise you open the possibility of someone replacing a directory with
> one from the past that contains some known insecurity, or corrupting the
> tree by swapping random directories, and yet the signatures remain
> valid. Of course, that hash changes if you allow people to rsync_exclude
> directories, and hence the signature changes. So you can either accept
> that if you selectively rsync then you won't be able to verify the
> signed tree, or accept that there is a known security problem with
> having no signed link between parent and child directories, or come up
> with a different scheme.

I'm not sure this is so. Yes, the Manifest file will have to include all
files in it's current and child[ren] directories. However, this is done
now. You would have to include eclass and profiles to have Manifests also.

I do not see how using rsync exclude would affect this scheme. If someone
wants to emerge samba and exclude KDE, the hash of the samba Manifest
will be there to check against. I'm not interested in signing the entire
tree. I am interested in signing the hashes of all Manifests in the tree
as a list. So, during the emerge process, as each package is emerged, the
first thing that occurs is to check the hash of the package Manifest file
against the stored hash in the signed Master Manifest file. Sort of like:

In pigeon bash and pseudo code, here's how I envision the check.
gpg --verify MasterManifestFile
# if error then abort
M_HASH=${grep "samba/Manifest" MasterManifestFile)
# probably need to use cut or something here...
C_HASH=$(md5sum samba/Manifest)
if M_HASH -ne C_HASH then abort

> Obviously the manifests also have to be checked to make sure they're
> valid - this is currently done for package directories at emerge time,
> it would need to be extended to all other directories. I'd prefer the
> checks done at sync time since that's a one time cost and you don't have
> to figure out exactly what files will be used by each emerge operation.

My thought was, that even if someone inserted a rogue package onto one of
the mirrors, a) altering the MasterManifest file would be difficult since
the signed part would not match, b) The Manifest hash would not match, or
if the bad guy did not alter the Manifest, the hash of its files would not
match (such as replacing a source dl location).

Anyway, thanks for taking a look.

-- 
Peter


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements

[Paul de Vrieze]

On Saturday 20 May 2006 15:47, Dan Meltzer wrote:
> >A secondary package manager is a package manager that instead of directly
> >aiming at replacing  portage as  primary package manager.
>
> What does it do instead?

I've just committed a new revision, but it cooperates. A slip up on my part.

> >The first restriction is that no packages in the tree must rely on the
> >secondary package  manager. While packages  may provide  a level  of
> >support (while being compatible  with  the  primary  package  manager) 
> >this  may  not result  in  a significant increase  of features.
>
> Why can a certain ebuild not DEPEND specifically on a third party
> package manager?

Basically if an official ebuild requires a third party package manager, this 
means that gentoo has a requirement on that package manager. If such a 
package manager at the same time offers support for all packages that the 
primary package manager supports, this means that in fact users will consider 
this secondary package manager to be their primary package manager. This 
leads to a decision by default as the council can at such a point only rubber 
stamp things. My aim is to make things such that the council can still make a 
real decision.

> I think you raise some good points in this email, however I think the
> overall aim is flawed.  The package manager should be just as
> switching as the compiler, the libc, the baselayout, or the kernel.
> None of these require anywhere near as many hoops to jump through to
> be supported in gentoo, and they all have their own fixes that need to
> be made.  No changes should be made to the tree which directly impedes
> the ability of the "primary package manager" to do its job, but at the
> same time, no changes should be made which impede other package
> managers from outperforming the "primary package manager".  Forcing
> package managers to stay even with all of portages ideosyncrocies is
> just holding back new package managers from making progress.

A package manager is not a compiler. To put it in a compiler setting, imagine 
that only a C or a C++ compiler can be installed at one point. The primary 
compiler for all files is C. At some point someone comes around and says. 
I've got this very nice compiler and it uses the C++ language that is more or 
less compatible with C. Then some code maintainers run of and use all the 
additional features of C++. If this code is then to be a consistent whole, 
this means that all code must be compiled with this C++ compiler. In effect 
replacing C as default language by C++.

It is very hard to revert back to C from C++. The leaders of the group had no 
say in whether it was good to go to C++ (maybe the compilation time is a 
serious issue), but have to accept it at this point because keeping the old C 
compiler is a race long lost.

--

I do not think that alternative package managers should be limited in what 
they do. What I think is that their additional features should not be used in 
the official tree (overlays is another point) to avoid the situation where 
the council can no longer make the decision to go for the better package 
manager.

There are many changes that can be made without hitting this problem. Multilib 
systems can work in such a way that portage just sees it as one package while 
the multilib package manager knows that it is a package consisting of 3 parts 
(32bit part, shared part, and 64 bit part). It is also possible to have a 
functionally equivalent package database that has a higher speed, or no 
longer needs a cache, than the portage compatible one.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpJzZ0bXo3Kp.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Signing everything, for fun and for profit

[Chris Bainbridge]

On 20/05/06, Peter <[EMAIL PROTECTED]> wrote:

PMFJI, but as a user, not a security expert, I had a few thoughts that I'd
like to throw in. Thanks to Patrick, he helped me to drill down some of
the ideas and I present them for consideration. It's just a framework, so
I will be brief


Thanks for your input. From a security point of view your scheme is
fine, but as pointed out by others you won't be able to selectively
rsync parts of the tree. That will require a signature for each
manifest, and a manifest for every directory. The problem I see is
that the manifest is going to have to include a hash for each
subdirectory - otherwise you open the possibility of someone replacing
a directory with one from the past that contains some known
insecurity, or corrupting the tree by swapping random directories, and
yet the signatures remain valid. Of course, that hash changes if you
allow people to rsync_exclude directories, and hence the signature
changes. So you can either accept that if you selectively rsync then
you won't be able to verify the signed tree, or accept that there is a
known security problem with having no signed link between parent and
child directories, or come up with a different scheme.

Obviously the manifests also have to be checked to make sure they're
valid - this is currently done for package directories at emerge time,
it would need to be extended to all other directories. I'd prefer the
checks done at sync time since that's a one time cost and you don't
have to figure out exactly what files will be used by each emerge
operation.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements

[Stephen Bennett]

I agree with the basic intent here, but remain unconvinced that this is
the best way to solve the problems at hand. See below for comments on
particular parts, and for what I believe could be a more elegant
solution. It's not a complete proposal and will be rather rough around
the edges, being more of a brain dump at the moment, but as far as I
can see it addresses all the issues that need to be.


On Sat, 20 May 2006 14:54:18 +0200
Paul de Vrieze <[EMAIL PROTECTED]> wrote:

> Backwards Compatibility
> ===
>
> Not a problem for this GLEP. There is no previous standard as the
> issue did not exist before. This GLEP is to prevent future
> compatibility issues.

There's a strong argument for saying that converting Portage to fit
the proposed standards for a primary package manager is a backwards
compaibility consideration. Or, with my below suggestion, making sure
that all existing ebuilds conform to the formalised ebuild
specification.

> The primary package  manager is the package manager that  sets the
> standards for the  tree. All  ebuilds  in the  tree  must function
> with  the primary  package manager. As  the primary package manager
> sets  the standard it does  not have to maintain compatibility with
> other package managers.

The current 'Portage defines the tree format' is IMO a cause of a lot
of problems at the moment. It would be better, I think, to define in a
package-manager-agnostic document just what the current ebuild format
(EAPI 0) means. If at any point in the future the primary package
manager changes in what it supports and/or requires, a new EAPI spec is
written. The council, or some other body, can then define which EAPI
formats may be used by ebuilds in the tree.

> The primary package manager is maintained on official gentoo
> infrastructure, under control of gentoo developers.

Reasoning behind this requirement? I can understand the sentiment, but
if gentoo developers have a sufficient degree of control over the
codebase, does it matter where it is hosted? If the worst comes to the
worst, require that any supported package manager be licensed under
GPL-2 and a group of Gentoo developers can simply pick up the latest
version available and fork if it is required. 


> candidate primary package manager requirements
> 
> 
> A  candidate  primary  package  manager  aims to  replace  the
> primary  package manager.  The council  is responsible  for deciding
> whether this  is  done. The requirements are  there to ensure that it
> is actually possible  to transition a candidate primary package
> manager into the primary package manager.

To throw out a potentially controversial question: is there any reason
behind the implicit assumption that there can only be one fully
supported primary package manager? If, as I suggested above, the ebuild
format and environment is formally defined in such a manner, it should
be entirely possible to support two or more alternative package
managers. Currently this would be impractical at best because of the
possibility of ebuilds working with one and not the other, but with a
formal specification of the ebuild environment it becomes possible to
define in such a case whether it is a package manager bug or whether
the ebuild is making assumptions that are not valid according to the
specification.

> First of all,  there must exist a  transition path. This means that
> the on disk data of  the primary package manager  can be used  by (or
> converted to  a format usable by) the candidate primary package
> manager.

This requirement seems perfectly reasonable.

> Second, there  must be a test  path. It must  be possible for the
> developers to test out  the candidate primary package  manager on
> their  working systems. This means that  the transition path  must
> exist. This  also means that there  are no serious obstacles for
> reverting to the current primary package manager.

It strikes me that this, as well as the next requirement, can easily be
achieved by chrooting, regardless of any compatibility or lack thereof
between the two package managers.

> Fourth, there must  be support. This means that the  package manager
> is actively maintained  under  control  of  gentoo.  If  it  is  not
> maintained  on  gentoo infrastructure, the  means must be there  to
> move the package  manager, with its change history, to gentoo
> infrastructure.  This means that it must be maintained on a  gentoo
> supported versioning system,  or on a version  system whose history
> can be converted to a gentoo supported versioning system.

Define "under control of gentoo". Also see above comment regarding
Gentoo infrastructure.

> A secondary package manager is a package manager that instead of
> directly aiming at replacing  portage as  primary package manager.  As
> such a  secondary package manager does not set  the standard on the
> tree, but follows  the standard set by the primary package manager.

Can't

[gentoo-dev] Don't filter --as-needed !

[Diego 'Flameeyes' Pettenò]

Please, don't filter --as-needed i your ebuild. If your package does not build 
with --as-needed, leave the bug open, and I'll eventually take care of it 
(when I have time, time constrain is my only problem).

If you filter --as-needed you are masking bugs, because the package might be 
relying on other packages that links against it to know how it was build, and 
it's not only annoying but useless as we're using ELF (a part OSX, but they 
are fine too).

So please don't filter --as-needed. Really. If the bug clutters your view, 
change the query to ignore bugs of priority P5 and set it to P5.

Not only it clutters the linking in final stages, but it also makes more 
difficult handling of revdep-rebuild with soname, as it will trigger on 
properly built system more rebuild than needed.

If you want to fix --as-needed by yourself follow the guide[1], else just 
leave the bug open blocking bug #129413.

[1] http://www.gentoo.org/proj/en/qa/asneeded.xml
-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpH1LVRGJ34W.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements

[Thomas Cort]

On Sat, 20 May 2006 14:54:18 +0200
Paul de Vrieze <[EMAIL PROTECTED]> wrote:
> *Primary Package Manager*  
>There  is one primary  package manager.

Gentoo has always been about choice, could you explain what is the rationale 
behind having only one primary package manager?

> All ebuilds in the tree must function with the primary package
> manager.

I definitely see this is as a requirement. One thing I am wondering is, who is 
responsible for testing the over 24,000 ebuilds in the tree to make sure that 
they work with the new package manager? Is it the package manager team, arch 
teams, package/herd maintainers, arch/herd testers, or others?

> The primary package manager is maintained on official gentoo infrastructure,
> under control of gentoo developers.

I don't really see this as a requirement. Many Linux distributions use package 
managers that they don't have direct control over. Ubuntu uses apt, Mandrake 
uses rpm, etc.

~tcort


pgp64t2IttlC2.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements

[Dan Meltzer]

A secondary package manager is a package manager that instead of

directly aiming

at replacing  portage as  primary package manager.

What does it do instead?


The first restriction is that no packages in the tree must rely on

the secondary

package  manager. While packages  may provide  a level  of support

(while being

compatible  with  the  primary  package  manager)  this  may  not

result  in  a

significant increase  of features.


Why can a certain ebuild not DEPEND specifically on a third party
package manager?

I think you raise some good points in this email, however I think the
overall aim is flawed.  The package manager should be just as
switching as the compiler, the libc, the baselayout, or the kernel.
None of these require anywhere near as many hoops to jump through to
be supported in gentoo, and they all have their own fixes that need to
be made.  No changes should be made to the tree which directly impedes
the ability of the "primary package manager" to do its job, but at the
same time, no changes should be made which impede other package
managers from outperforming the "primary package manager".  Forcing
package managers to stay even with all of portages ideosyncrocies is
just holding back new package managers from making progress.

On 5/20/06, Paul de Vrieze <[EMAIL PROTECTED]> wrote:


The promissed glep on package manager requirements. Please comment on it.
There are some parts that may be controversial (portage has in the past not
provided support for reverting to stable either), but please keep the
discussion on topic.

Paul

--
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


GLEP: 49
Title: Alternative Package Manager requirements
Version: $Revision: 2214 $
Last-Modified: $Date: 2006-05-20 14:51:41 +0200 (Sat, 20 May 2006) $
Author: Paul de Vrieze <[EMAIL PROTECTED]>,
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 18-May-2006
Post-History: 19-May-2006


Abstract


This GLEP describes four classes of package managers. What the requirements for
them are, and what support they can receive.


Motivation
==

To set a standard that package managers that seek gentoo project approval and
support should adhere to.


Rationale
=

Currently portage is  showing its age. The  code of portage does not  seem to be
salvageable for new  versions. There are two known  alternative package managers
that claim a  level of portage compatibility. These  alternatives are `paludis`_
and `pkgcore`_.  Before these alternatives are developed further, a set of rules
should be created to level the  playing field and ensuring that decisions can be
made clearly.


Backwards Compatibility
===

Not a problem for this GLEP. There is no previous standard as the issue did not
exist before. This GLEP is to prevent future compatibility issues.


Categories of package managers
==

We distinguish four categories of package managers. While a package manager can
transition from one category to another, it can not be in two categories at the
same time. It can be in a state of transition though.

*Primary Package Manager*
   There  is one primary  package manager.  Currently this  position is  held by
   portage.  The primary  package manager  is assigned  by the  council  and all
   packages in the official tree must be installable by a useable version of the
   primary package manager.

*Candidate Primary Package Managers*
   A candidate  Primary Package Manager does  aim, or show an  aim, at replacing
   the current primary package manager. At  a point where the package manager is
   deemed stable  a decision  must be made  whether this package  manager should
   become the  new primary package manager.  At that point  the `primary package
   manager transition phase`_ starts.

*Secondary Package Managers*
   A  secondary package  manager is  a package  manager that  coexists  with the
   primary package  manager, while  not aiming to  replace it.  Package managers
   that would fall into this category are:

   - Experimental package managers. Package managers  whose purpose it is to try
 out new features.

   - Focussed package  managers. For example  a package manager that  allows the
 use of rpm formatted binary packages would be an example.


*Third Party Package Managers*
   A third party  package manager is any package  manager that lacks recognition
   from gentoo as being in any other category. A third party package manager may
   or may not have a gentoo package, but is not supported beyond that.


Package manager requirements


As  a  package  manager is  in  a  state  of  higher  support there  are  higher
requirements to it. The purpose of  these requirements is to ensure the unity of
the distribution and the package tree.  For this purpose it is needed that there
is only one primary package manager.


primary package manager requireme

Re: [gentoo-dev] New darcs.eclass

[Aron Griffis]

Henrik Brix Andersen wrote: [Sat May 20 2006, 04:50:22AM EDT]
> On Fri, May 19, 2006 at 10:36:42PM -0400, Aron Griffis wrote:
> > Along these lines, I added my mercurial.eclass to the tree.  I use it
> > personally for a couple projects, and figured it might help prevent
> > other people from needing to re-invent the wheel.
> 
> Errr... you added a new eclass without posting it to this mailing
> list for review first?

I've never posted an eclass here for review, and I don't think I've
ever announced one before either, so let's call this progress. ;-)

If you'd like to review it, I'd appreciate the input.

Thanks,
Aron

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Signing everything, for fun and for profit

[Jan Kundrát]

Robin H. Johnson wrote:
> Additionally, if the developer uses the singular primary key for a lot of
> stuff, it is more vulnerable to attack.
> 
> 
> Instead, the developer should create a subkey that is used for signing Gentoo
> work only. They should not sign anything else with this, including their 
> Gentoo
> email.
> 
> They may have an additional subkey for signing their Gentoo email if they 
> wish.
> 

I don't know much about cryptography, but could you please elaborate on
why is using one subkey for all the stuff considered a Bad Thing?

> UID signatures:
> ---
> As I wrote last year, these may take several forms.
> We are concerned with several properties that they may have:
> 
> Expiry dates of signatures:
> Unlike expiry dates of cryptokeys, these may not be changed - by default, they
> take on the expiry date of the certifying cryptokey, although a lower value 
> may be
> set. If you have an existing signature that has expired, you need to get your
> uid signed again.

Off-topic question - I've already met Alice, verified her identity,
signed her keys and now she wants me to sign her new subkey with same
name, e-mail etc because the old one has expired. Alice lives in Canada
so I can't meet her easily. Should I sign it again with the same level
of "trust"?

Another situation - Bob, Alice's boyfriend, lives in Canada. I've met
him before, verified his identity and signed his subkey for
[EMAIL PROTECTED] Now he wants my signature for [EMAIL PROTECTED] Should I
sign it?

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements

[Ferris McCormick]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I have not read this carefully.  There is a lot to work through.  At first 
reading, I like it a lot.


Regards,
Ferris

- --
Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]>
Developer, Gentoo Linux (Devrel, Sparc)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2-ecc0.1.6 (GNU/Linux)

iD8DBQFEbxbHQa6M3+I///cRAo9yAJsEF/hxaLrztTnBlNH6I2ZE/pR5hACghqhY
DUyfxAlIDVdWBU70tre3nYg=
=tvyX
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Signing everything, for fun and for profit

[Patrick Lauer]

On Sat, 2006-05-20 at 10:13 +0200, Thierry Carrez wrote:
> Patrick Lauer wrote:
> 
> > Signing strategies
> > ==
> > 
> > Once there is an agreement on what files to sign with what kind of keys
> > there remains the question how to sign it. There are at least three
> > strategies:
> > [...]
> 
> I prefer a semi-secure solution appearing soon rather than waiting
> another three+ years for a potentially better solution.
A staged plan might be best then:
- implement a simple master-key signing
- discuss the more complex distributed models
- implement the distributed models if agreed upon

> Currently users only have two choices :
> 
> - masterkey-signed portage snapshots
> - unsigned (and so, insecure) rsync mirrors
> 
> This is obviously not satisfying.
Yes. It also gives us ~100 single points of attacks as every compromised rsync 
mirror could go undetected for a long time.

> It has taken years to try to get per-developer signing implemented,
> without success. We should try to do masterkey signing ("simple" method)
> and see if we go somewhere. It's is so much better than nothing.
There is no authority that "forces" signing.
Making signing mandatory should not cause big problems now ...

> So I would rather work on ensuring everything in portage gets properly
> signed rather than designing key policies, cross-signing strategies and
> ways to force developers to sign properly. Given the current state of
> Gentoo it is a much more reachable goal.
"properly signed" implies some standard or policy to measure it against.

So we need to have some agreement what is needed to assure "properly
signed everything" - it looks like the centralized masterkey model will
have the smallest impact on all involved. Then we look at all issues
this model has, try to fix all bugs - then we have a plan to implement,
and I hope that this will happen in a reasonable timeframe.

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Signing everything, for fun and for profit

[Patrick Lauer]

On Fri, 2006-05-19 at 22:03 -0400, Ned Ludd wrote:
> If there is anything you or genone need to make signing happening you
> have to the full support of the 

> council
That should not be difficult if the proposal is discussed and accepted
by all other groups

> infra
it should be non-invasive and well documented

> hardened/security.
... while offering good security

So I suggest that infra and hardened/security warn of any problems they
see, it would be silly to have a detailed battleplan only to have
someone kill it at the last minute ...

=

Some short comments on robbat2's proposal:
> > Summary:
> > ---
> > This is a brief summary of the suggestions and choices above.
> > This summary outline is assuming a model such as the hybrid or complex
> > models.
> > 
> > - Each developer shall have a GnuPG key.
> > - Each developer key shall contain at least one uid, with name and Gentoo 
> > email
> >   address of the developer.
> > - Each developer must create a secondary cryptokey with the following
> >   parameters (designated as their Gentoo signing cryptokey):
> >   Key Type: RSA
> >   Key Length: 2048 or 4096
> >   Expiry time: Set at 6 months out
> >   Usage: Marked as signing only.
I think these parameters are acceptable. I can't think of compelling
technical reasons to change them.

> > - Each developer shall regularly update the expiry time (GnuPG enforces
> >   this) of the cryptokey, keeping it no further than 6 months ahead of
> >   the present date, except where otherwise decided.
Enforcing this will be difficult, so I think it should be seen as a
strong guideline (we can't stop you, but please don't mess up)

> > - Each developer should have a revocation certificate for their key, and
> >   store two copies in a secure offline location (I suggest two CD-RWs,
> >   of different brands, stored in separate locations, refreshed every 6
> >   months, but floppy disks would work as well).
No way to enforce this

> > - Each developer will sign all of their commits with their Gentoo
> >   signing cryptokey only. They should not sign anything else, nor use
> >   other cryptokeys for signing Gentoo commits.
> > - (Optional, for those creating new keys only) a best practice would be
> >   to have a primary key that is marked as certifying only.
Sounds reasonable
 
> > (This part here needs more discussion, which may end up that N=1 is
> > valid).
> > - There will be N master keys. 
For N>1: who controls the master keys?

> > - A master key will have a secondary cryptokey conforming to the same
> >   requirements as the developer Gentoo signing cryptokey.
> > - A master key will certify all Gentoo developer keys on a regular
> >   basis. This can be done on 4 month intervals safely, with once-off
> >   events to sign keys of incoming developers, or other special cases.
Why not sync this to the 6 month expiry time?
Also you might want to add:
- All keys and the master key shall be made available on Gentoo media
(install-cd etc) and other ressources (ebuilds, download from known
locations, stored on public keyservers)

> > - When a developer leaves, the certification on their key shall be
> >   revoked.
> > - Both infra and the council should hold the revocation control for a
> >   master key in some way so that cooperation is needed to actually revoke
> >   a master key.
This will be very tricky to implement. 
> > (For future stuff:)
> > For performing releases of Gentoo (releng), a designated key be used,
> > and be certified by the master key.
This should be discussed with releng. While I don't see why they should
disagree I dislike forcing any policy on others.
 
> > Outstanding points:
> > ---
> > - Discussion of how the keymaster(s) should operate to maintain the
> >   keyring.
Plus, of course, what to sign, how to sign it, how to handle failures.

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] RFC: GLEP 49 - Package manager requirements

[Paul de Vrieze]

The promissed glep on package manager requirements. Please comment on it. 
There are some parts that may be controversial (portage has in the past not 
provided support for reverting to stable either), but please keep the 
discussion on topic.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net
Title: GLEP 49 -- Alternative Package Manager requirements











[Gentoo Linux Home]
[GLEP Index]
[GLEP Source]






GLEP:49

Title:Alternative Package Manager requirements

Version:2214

Last-Modified:2006-05-20 14:51:41 +0200 (Sat, 20 May 2006)

Author:Paul de Vrieze ,

Status:Draft

Type:Standards Track

Content-Type:text/x-rst

Created:18-May-2006

Post-History:19-May-2006





Contents

Abstract
Motivation
Rationale
Backwards Compatibility
Categories of package managers
Package manager requirements
primary package manager requirements
candidate primary package manager requirements
secondary package manager requirements
third party package manager requirements


transition phases
primary package manager transition phase
Secondary package manager to candidate primary package manager transition
Third party to other transition


References
Copyright



Abstract
This GLEP describes four classes of package managers. What the requirements for
them are, and what support they can receive.


Motivation
To set a standard that package managers that seek gentoo project approval and
support should adhere to.


Rationale
Currently portage is  showing its age. The  code of portage does not  seem to be
salvageable for new  versions. There are two known  alternative package managers
that claim a  level of portage compatibility. These  alternatives are paludis [1]
and pkgcore [2].  Before these alternatives are developed further, a set of rules
should be created to level the  playing field and ensuring that decisions can be
made clearly.


Backwards Compatibility
Not a problem for this GLEP. There is no previous standard as the issue did not
exist before. This GLEP is to prevent future compatibility issues.


Categories of package managers
We distinguish four categories of package managers. While a package manager can
transition from one category to another, it can not be in two categories at the
same time. It can be in a state of transition though.

Primary Package Manager
There  is one primary  package manager.  Currently this  position is  held by
portage.  The primary  package manager  is assigned  by the  council  and all
packages in the official tree must be installable by a useable version of the
primary package manager.
Candidate Primary Package Managers
A candidate  Primary Package Manager does  aim, or show an  aim, at replacing
the current primary package manager. At  a point where the package manager is
deemed stable  a decision  must be made  whether this package  manager should
become the  new primary package manager.  At that point  the primary package
manager transition phase starts.
Secondary Package Managers
A  secondary package  manager is  a package  manager that  coexists  with the
primary package  manager, while  not aiming to  replace it.  Package managers
that would fall into this category are:

Experimental package managers. Package managers  whose purpose it is to try
out new features.
Focussed package  managers. For example  a package manager that  allows the
use of rpm formatted binary packages would be an example.


Third Party Package Managers
A third party  package manager is any package  manager that lacks recognition
from gentoo as being in any other category. A third party package manager may
or may not have a gentoo package, but is not supported beyond that.



Package manager requirements
As  a  package  manager is  in  a  state  of  higher  support there  are  higher
requirements to it. The purpose of  these requirements is to ensure the unity of
the distribution and the package tree.  For this purpose it is needed that there
is only one primary package manager.

primary package manager requirements
The primary package  manager is the package manager that  sets the standards for
the  tree. All  ebuilds  in the  tree  must function  with  the primary  package
manager. As  the primary package manager sets  the standard it does  not have to
maintain compatibility with other package managers.
The primary package manager does however have the responsibility that it must be
very stable.  The primary package  manager must maintain compatibility  with old
versions of itself  for extended periods of time. This  compatibilty time is set
by the council. The  suggested time would be one year from  the point that there
is a compatible stable version for all supported architectures.
Another compatibilty  requirement for the  primary package manager is  a limited
forward  compatibility.  It must  always  be  possible  to transition  from  the
unstable version of the primary package manager to a stable version. This may be
done either by first introducin

[gentoo-dev] Re: Signing everything, for fun and for profit

[Peter]

On Thu, 18 May 2006 23:45:17 +0200, Patrick Lauer wrote:

>The problem, in short, is how to handle the checksumming and signing of
>gentoo-provided files so that manipulation by external entities becomes
>difficult.

all snip...

PMFJI, but as a user, not a security expert, I had a few thoughts that I'd
like to throw in. Thanks to Patrick, he helped me to drill down some of
the ideas and I present them for consideration. It's just a framework, so
I will be brief.

Here are the main requirements of this scheme:

1) I believe there should be a gentoo uber-key. One, similar to Slackware
Security, which is used to authenticate everything coming from Gentoo.

2) Every first or second level directory in portage should have a Manifest
of all files in it and below, not just ebuilds. All ebuilds have Manifest
files, but eclass does not, and profiles does not AFAIK. These Manifest
files, like now, will contain checksums of all files in and below its
directory.

(right now, signing of Manifests is woefully inconsistent. There are 5400
signed Manifests and the remainder unsigned. Who they are signed by is
unclear. Some I cannot even find on public key servers!)

3) Similar to what is done at keysigning parties, a hash of all Manifest
files would be generated and signed by the uber-key. This hash should be
generated from the actual portage tree prior to being propogated through
the mirror system.

Just an example, but I tried this in ${PORTDIR}

# find . -name "Manifest" -exec openssl dgst -ripemd160 {} ";" 
>MasterManifestFile.txt

(of course, gpg, md5sum, or related commands could be used. or a perl or
python substitute used. The above was just for illustration).

(where this master file gets stored is not settled now. I think it
should not be propogated, but kept off the mirrors. Others disagree. But
the concept is that it exists and gets signed)

4) When a user emerges an ebuild, he/she would check the hash of
the Manifest in the ebuild he or she is downloading against the
MasterManifestFile.txt file.

The rationale is that if Joe Bad Guy uploads a malicious ebuild to a
mirror he has access to, complete with a new manifest, it won't checksum
correctly against the master list, and the user can be protected. Having a
single hash of all Manifest files protects against intrusion into
parts of the distribution system. It also makes it OK for a user to download 
files that are not affected easily. And, since all directories would have
Manifests, and I would include profiles and eclass as well, they are
protected too.

And, since the MasterManifestFile.txt file is signed by the uber Gentoo
key, tampering with it would be difficult.

5) Every time a new file is added to the main tree, new Manifests must be
generated and a new master list created.

Essentially, what this scheme accomplishes is a double check on Manifests.
What it does not deal with is who signs each Manifest. I am not sure about
that. For example, some Manifest files are signed by now-revoked keys.
Some I can't find on keyservers. And, signing a Manifest file only does
not deal with all the other files. I'm not sure Manifests need to be
signed, but that's out of my realm of expertise and really is a policy
decision. I'm also not sure of the benefit of signing all files either.
Right now, signing of Manifest files is not enforced. How could you
enforce signing all files then?

Here's a snippet of what a Master file could look like using just one
directory, x11-base:

find -name "Manifest" -exec -ripemd160 \{} ";" | gpg --clearsign -

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

RIPEMD160(./xdirectfb/Manifest)= ca5398a78e9f92cff3c704255caec2b6589b0ccb
RIPEMD160(./xorg-x11/Manifest)= 527c1977c0e799aa41dbfa7e5ff3d4fa1026e8be
RIPEMD160(./x11-drm/Manifest)= 2836d93a85c0b7dcb58e3b2dc924d9bd9d8f8cf8
RIPEMD160(./xorg-server/Manifest)= 281e13187104e89525d081a92dc81b3e8b018dce
RIPEMD160(./kdrive/Manifest)= 2559c92f4a94063271959557bf6c084c4da03b53
RIPEMD160(./opengl-update/Manifest)= 534ec81aa9485b020c07cd7800fb60588d141e35
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEbvHJTTfGLUZ/v30RA5AKAKDJFRKIB3GwxYC4iUEVLMg+uuZ6gACgsIco
gSaCIOauDmFjtJNoK0f7bPs=
=Qm0N
-END PGP SIGNATURE-

A benefit of this scheme, is that instead of checksumming the thousands of
individual files in portage, we're only interested in the Manifests. The
entire tree of Manifests is <1Mb. Grepping a file would be fast, needing 
only the ebuild name and the word Manifest.

What would need to be determined is what checksumming method to use, and
to require gpg as a dependancy of portage so that signature verification
can be done on the Master File.

I also believe that live cds and other output from gentoo should be signed
as well. I looked at the 2006.0 cd and saw nothing on it.

Here's the Slackware approach that I am very familiar with. On the root
directory of each CD is a list of checksums called CHECKSUMS.md5. Pat
(Volkerding) then creates a detached signa

Re: [gentoo-dev] New darcs.eclass

[Henrik Brix Andersen]

On Fri, May 19, 2006 at 10:36:42PM -0400, Aron Griffis wrote:
> Along these lines, I added my mercurial.eclass to the tree.  I use it
> personally for a couple projects, and figured it might help prevent
> other people from needing to re-invent the wheel.

Errr... you added a new eclass without posting it to this mailing list
for review first?

./Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd


pgp6n7PvSiBEc.pgp
Description: PGP signature

Re: [gentoo-dev] Signing everything, for fun and for profit

[Thierry Carrez]

Patrick Lauer wrote:

> Signing strategies
> ==
> 
> Once there is an agreement on what files to sign with what kind of keys
> there remains the question how to sign it. There are at least three
> strategies:
> [...]

I prefer a semi-secure solution appearing soon rather than waiting
another three+ years for a potentially better solution.

Currently users only have two choices :

- masterkey-signed portage snapshots
- unsigned (and so, insecure) rsync mirrors

This is obviously not satisfying.

It has taken years to try to get per-developer signing implemented,
without success. We should try to do masterkey signing ("simple" method)
and see if we go somewhere. It's is so much better than nothing.

So I would rather work on ensuring everything in portage gets properly
signed rather than designing key policies, cross-signing strategies and
ways to force developers to sign properly. Given the current state of
Gentoo it is a much more reachable goal.

-- 
Thierry Carrez (Koon)
Gentoo Security Team and Gentoo Council Member
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New git.eclass

[Donnie Berkholz]

Fernando J. Pereda wrote:
> I'd like people who use Git eclass to test it and see if any of the
> 'features' I introduced break things for them.

I just incorporated much of this into my version (minus some whitespace
changes) and pushed it up. Seems to work fine on my stuff, although the
additional time taken by the repack and prune is mildly annoying,
particularly considering the point of git is to be fast at the cost of
disk space rather than vice versa. =)

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature