Re: [gentoo-dev] treecleaner maskings

2006-12-03 Thread David Shakaryan
Christian Heim wrote:
> #72585 - x11-wm/qvwm 
>  o requested by Jakub Moc on behalf of treecleaner
>  o nothing depends on it
>  o Pending Removal Dec 04th 2006

Although the treecleaners project has been suspended, I have, as a
member of the desktop-wm herd, removed this package.

-- 
David Shakaryan
GnuPG Public Key: 0x4B8FE14B



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Re: Versioning the tree

2006-12-03 Thread Sune Kloppenborg Jeppesen
On Friday 01 December 2006 13:47, Chris Gianelloni wrote:
> Actually, we would have to review the process, since not everything that
> gets a security bug ends up with a GLSA.  My current loose rule is that
> if it deserves a GLSA, then it deserves and update, but I don't know the
> exact criteria the security team uses to decide if something warrants a
> GLSA or not.
http://www.gentoo.org/security/en/vulnerability-policy.xml

For relation between severity level and GLSA publication see Dispatch.

Basically everything that ends up with Trivial severity level will NOT get a 
GLSA and everything that ends up with Minor severity level will get a vote 
from the Security team members. Two yes or no votes normally wins. Everything 
else gets a GLSA.

Then you have to add in Security supported architectures, but that's really of 
no concern to x86.

-- 
Sune Kloppenborg Jeppesen
Gentoo Linux Security Team


pgp5S2l2N6A2k.pgp
Description: PGP signature


[gentoo-dev] Southern California Linux Expo 5x Opens Registration

2006-12-03 Thread Gareth J. Greenaway
Effective immediately, registration for SCALE 5X is available at
http://www.socallinuxexpo.org/order. The Early bird ticket price is $60
for full admission with a $30 admission for students with valid ID.
Gentoo developers can use the GNTOO promotional code for a 40%
discount on the full access pass.  Prices go up Jan 24th, so don't dawdle; 
get registered now!

If you're interested in seeing who's participating in SCALE, the
exhibitor list is at http://socallinuxexpo.com/scale5x/exhibitions.php
Gentoo will be exhibiting at the show, come out and support your
fellow developers!

A partial list of speakers can be viewed at
http://socallinuxexpo.com/scale5x/speakers.php

SCALE will be February 10-11, 2007, at The Westin Los Angeles Airport.
For those staying over, The Westin is offering special hotel room rates
for the Expo. Hotel information is available here:
http://socallinuxexpo.com/scale5x/location.php


-- 
Gareth J. Greenaway  | [EMAIL PROTECTED]
Voice - 877-831-2569 x130
Southern California Linux Expo
http://www.socallinuxexpo.org
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Portage feature addition

2006-12-03 Thread Zac Medico
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Daniel Drake wrote:
> Alec Warner wrote:
>> This is to prevent people from sticking a random unchecksum'd ebuild
>> in your tree and then having portage source it for depend() metadata
>> and then getting bitten by some global scope nasties.
> 
> Is this really the correct solution to this "problem"?
> 
> I can't see the use case: do people really download (potentially
> malicious) ebuilds, stick them in their overlay, and then *not* use them?
> 
> Somehow I don't think that's true - people will generally download
> ebuilds, and use them (even if they fail during compilation, they will
> have been used in some form).
> 
> If you start requiring people to create Manifests for these ebuilds,
> they will do so, and this has not changed the security implications of
> these "untrusted" ebuilds.
> 
> Am I missing something?
> 
> Daniel

The plan is to eventually include digital signature verification
together with the Manifest verification.  The framework isn't
completely implemented yet, but we're beginning to put some of the
required mechanisms into place.

Considering that repoman users generally have complete trust in
their cvs checkout, I suppose it would make sense to allow repoman
features to be configured separately.  For example, we could allow
you to set REPOMAN_FEATURES="-strict" in make.conf so that you won't
be bothered by broken Manifests when running repoman.

Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFc4bT/ejvha5XGaMRAiYbAJwIWJF7lCR7ICMmJGAfDOQlZNtlHACfYqJp
fUERS53nyQ2kQf1QMb3rd5k=
=5cht
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Portage feature addition

2006-12-03 Thread Daniel Drake

Alec Warner wrote:
This is to prevent people from sticking a random unchecksum'd ebuild in 
your tree and then having portage source it for depend() metadata and 
then getting bitten by some global scope nasties.


Is this really the correct solution to this "problem"?

I can't see the use case: do people really download (potentially 
malicious) ebuilds, stick them in their overlay, and then *not* use them?


Somehow I don't think that's true - people will generally download 
ebuilds, and use them (even if they fail during compilation, they will 
have been used in some form).


If you start requiring people to create Manifests for these ebuilds, 
they will do so, and this has not changed the security implications of 
these "untrusted" ebuilds.


Am I missing something?

Daniel
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Portage feature addition

2006-12-03 Thread Alec Warner

Jeroen Roovers wrote:

On Sun, 03 Dec 2006 15:03:27 -0800
Zac Medico <[EMAIL PROTECTED]> wrote:


Apparently `repoman fix` doesn't currently work for that particular
case, which is definitely a bug.  If you can simply run `repoman
fix`, will that be convenient enough?


I would like to be able to run `repoman full` without needing to touch
the digests at all or with FEATURES=-strict. For an arch dev, the
digests are normally fine already and Manifest is automatically fixed
when running repoman commit. The danger of global scope nasties ought to
be very limited by the time a package is ready for arch keywording.


FEATURES="digest" repoman full
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Portage feature addition

2006-12-03 Thread Jeroen Roovers
On Sun, 03 Dec 2006 15:03:27 -0800
Zac Medico <[EMAIL PROTECTED]> wrote:

> Apparently `repoman fix` doesn't currently work for that particular
> case, which is definitely a bug.  If you can simply run `repoman
> fix`, will that be convenient enough?

I would like to be able to run `repoman full` without needing to touch
the digests at all or with FEATURES=-strict. For an arch dev, the
digests are normally fine already and Manifest is automatically fixed
when running repoman commit. The danger of global scope nasties ought to
be very limited by the time a package is ready for arch keywording.

The problem with FEATURES=-strict is that it isn't clear what it is
actually being strict (or loose) about (maybe the make.conf man page
needs to be updated). Obviously, repoman is *already* able to tell me
whether a digest or Manifest is bad, and should be able to report this
along with all the things it checks for by sourcing the ebuild(s).

IMO this new feature should be enabled only with FEATURES=stricter or
some other smartly named FEATURES flag.


Kind regards,
 JeR
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Portage feature addition

2006-12-03 Thread Zac Medico
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jeroen Roovers wrote:
> On Sun, 03 Dec 2006 01:00:24 -0500
> Alec Warner <[EMAIL PROTECTED]> wrote:
> 
>> This 'feature' is currently controlled via strict, so those that hate 
>> hate hate it can turn it off via FEATURES="-strict"
> 
> It seems that now I have to run repoman with FEATURES=-strict after I
> do as little as change a keyword without running `ebuild 
> manifest`. Is this intended behaviour or a bug? It's highly
> inconvenient...

Whether it's a feature or a bug depends on how you look a it.
Apparently `repoman fix` doesn't currently work for that particular
case, which is definitely a bug.  If you can simply run `repoman
fix`, will that be convenient enough?

Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFc1e9/ejvha5XGaMRAqS6AKDJ92GO6wUgMqttIwHLt7daYhWp6QCfT/pd
BUou3dPOeEwaC7UX8q/twJA=
=FtkT
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Update from User Relations wrt User Representatives.

2006-12-03 Thread Christel Dahlskjaer
As of Friday 17th November, George Prowse, known to most as cokehabit,
has left the Gentoo User Relations project and his position as User
Representative. Regrettably, as things turned out, he did not fit the
role as well as many had hoped, and it was decided that it would be in
everyone's best interests to part ways. We would like to thank George
for his time and work as a user representative, and wish him luck in his
future endeavours.

On a related note, it was resolved at a meeting between User Relations and 
the User Representatives on December 2nd, 2006 to instate Alex Bokag aka 
djay-il as the eleventh and last User Representative. This motion passed 
unanimously and Alex accepted the position with immediate effect. 
We welcome Alex onboard and look forward to working closely with him over the 
next year.

On behalf of User Relations, 
Christel Dahlskjaer.


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


Re: [gentoo-dev] Portage feature addition

2006-12-03 Thread Jeroen Roovers
On Sun, 03 Dec 2006 01:00:24 -0500
Alec Warner <[EMAIL PROTECTED]> wrote:

> This 'feature' is currently controlled via strict, so those that hate 
> hate hate it can turn it off via FEATURES="-strict"

It seems that now I have to run repoman with FEATURES=-strict after I
do as little as change a keyword without running `ebuild 
manifest`. Is this intended behaviour or a bug? It's highly
inconvenient...


Kind regards,
 JeR
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Portage feature addition

2006-12-03 Thread Alec Warner

Mike Frysinger wrote:

On Sunday 03 December 2006 01:00, Alec Warner wrote:

Recently commited to svn (but afaik released only in ~arch) is code to
prevent the sourcing of ebuilds with no manifest.  Thus ebuilds you
randomly download off of bugzilla need to get a lookover from you and
then ebuild foo.ebuild digest'd.


i thought portage always did that ... if you have FEATURES=strict, it'll 
complain that a file doesnt exist in the Manifest and abort

-mike


It will if you try to *install* the ebuild.  But we source it for depend 
info long before that happens.  If we have the depend info cached, we 
trust the cache info to calculate dependencies for other packages, even 
if the ebuild has an incorrect checksum (afaik).

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Portage feature addition

2006-12-03 Thread Ned Ludd
On Sun, 2006-12-03 at 14:33 -0500, Mike Frysinger wrote:
> On Sunday 03 December 2006 01:00, Alec Warner wrote:
> > Recently commited to svn (but afaik released only in ~arch) is code to
> > prevent the sourcing of ebuilds with no manifest.  Thus ebuilds you
> > randomly download off of bugzilla need to get a lookover from you and
> > then ebuild foo.ebuild digest'd.
> 
> i thought portage always did that ... if you have FEATURES=strict, it'll 
> complain that a file doesnt exist in the Manifest and abort

Nope.. Try this..

cd $(portageq envvar PORTDIR)/virtual/
mkdir mike
cd mike
echo 'echo OWNED at phase $EBUILD_PHASE' > mike-0.0.ebuild
emerge -pv mike


> -mike
-- 
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Portage feature addition

2006-12-03 Thread Mike Frysinger
On Sunday 03 December 2006 01:00, Alec Warner wrote:
> Recently commited to svn (but afaik released only in ~arch) is code to
> prevent the sourcing of ebuilds with no manifest.  Thus ebuilds you
> randomly download off of bugzilla need to get a lookover from you and
> then ebuild foo.ebuild digest'd.

i thought portage always did that ... if you have FEATURES=strict, it'll 
complain that a file doesnt exist in the Manifest and abort
-mike


pgpD0SmI16Q3w.pgp
Description: PGP signature


[gentoo-dev] Removed app-cdr/cdrecord-provdvd and app-cdr/dvdrtools

2006-12-03 Thread Lars Weiler
Both were masked since 08 Jul 2006.

The code of app-cdr/cdrecord-prodvd is now included in
app-cdr/cdrtools or app-cdr/cdrkit.  app-cdr/dvdrtools are
dead upstream and not needed any more, as the other
previously mentioned applications are capable of writing
DVDs.

Regards, Lars

-- 
Lars Weiler  <[EMAIL PROTECTED]>  +49-171-1963258
Gentoo Linux PowerPC: Strategical Lead and Release Engineer
Gentoo Infrastructure   : CVS Administrator


pgpC2zzmmQGap.pgp
Description: PGP signature