Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two

[Brian Harring <ferringb@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3008 bytes --]

On Sat, Nov 05, 2005 at 05:45:35PM +0000, Ciaran McCreesh wrote:
> | > News items may be signed using GPG. If this is done, a detached
> | > signature should be used.
> | 
> | I'd argue for must be, personally.  A bogus news item claiming to be 
> | from portage devs, telling users to change their SYNC setting could 
> | cause massive mayhem.
> 
> Signing elsewhere isn't mandatory yet.

Deal with it ;)

New additions to the tree that don't require signing 
just shove more load onto anyone who is trying to make the entire tree 
signed- you're already placing it in the tree so it doesn't make screw 
with future portage plans (news directory), this isn't much different.

Note also I'm not stating your example clients must handly signing- 
it'll ugly up the trivial exmples a bit, but the messages delivered 
*must* be signed from where I'm sitting.

It's easy to state that "well others don't have to sign"; the problem 
here is that you must start somewhere.  If the whole effort of signing 
is abandoned, the restriction that all news items be signed is easily 
dropped- going in reverse (retroactively getting authors to sign their 
old news) is a bit of work that could be avoided.


> | Still haven't address my point about
> | A) package moves combined with news entries
> 
> Gotta handle those manually / with epkgmove. Someone could write a
> server-side handler for automatic updates if they want, but given that
> package moves are already a case of "do all the things on a big list",
> it's not much added complexity...

Note it please; it's a concern.

> | No go on -core imo; it's a community/dev issue, should be visible to 
> | the general public rather then hidden away in the ml we do our
> | flaming in.
> 
> There *might* be legit security reasons for using -core, for example
> for nasty "upgrade required" security bugs that we can't disclose
> before a given date. Hopefully this will never happen.

Valid point, which will hopefully be noted in v3 of the glep? :)

> | Already pointed out that this won't fly looking forward, it
> | implicitly assumes a single repository.
> 
> Again, we can deal with that if Portage ever gets multiple repo
> support. Until it does, I'm not trying to guess how it's going to end
> up being implemented.

*cough* PORTDIR_OVERLAY *cough*

Already have multiple repo support.  Assumed you meant standalone, in 
which case I still think you're dodging support that must be there.

Changing it after the fact because it wasn't design with an extra bit 
of forward thinking isn't something I'm incredibly game for.  Yes it's 
extra work for you, but you're proposing the change ;)

You're going for forward compatibility... this is just that.

> | Nuke flashy (any phrasing that allows for blinking crap sliding into
> | portage I instinctively dislike).
> 
> Is there a technical name for the big red !!!!! messages?

Freaking annoying, is the technical term I use.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]