Re: [gentoo-dev] Policy regarding enabling IUSE defaults application in ebuild

[Robert Buchholz]

On Monday 08 June 2009, Maciej Mrozowski wrote:
...
> While it usually doesn't do any particular harm (but I guess security
> and prefix/alt team won't agree on this) - insanely enabling
> everything by default is not the best idea in my opinion.

The Security Team supports all use flag combinations, even those not 
enabled by default. Masked use flags are not supported. As far as 
proactively disabling certain codecs go, that certainly exploits of 
certain (disabled) codecs. However, if the user was tricked into 
downloading a file and will see that he cannot play it due to a missing 
codec, he might just enable that use flag and rety.
The only way to be safe is to minimize the untrusted input to your 
application, keep it updated, and employ other means of hardening 
(privilege separation).

> Of course we need an example. Let's have a look at latest stable
> media- video/mplayer-1.0_rc2_p20090322 ebuild:
...
> Personally I'd really like to hear some explanation from maintainers
> about the reasons mplayer needs all those dependencies or why they
> are *really* recommended for every user of *any* profile (let me
> remind this).

You should see the list of referenced bug reports in the ChangeLog for 
an explanation: https://bugs.gentoo.org/show_bug.cgi?id=260588

As stated there, all internally supported codecs are enabled, and only 
very few default USE flags require external deps.

> But thats's not the point - the point is, Gentoo probably needs some
> policy to advise, when some newly added USE flags are appropriate to
> be enabled by default.
>
> I suggest as follows:
> - When newly added USE flag makes already provided feature optional -
> needs to be enabled by default (this is required to make package
> feature set somewhat invariant after update)
> - When newly added USE flag adds new feature that is considered very
> common (that's tricky part and decision should be always made by
> herd, not individual developer) *but* *does* *not* *pull* *any*
> *dependencies* - enable by default - in any other case *do* *not*
> *enable* by default - (why? because "I use it so I'll enable it by
> default" is not enough of an explanation)
>
> What's the opinion on that? I guess we need some policy or at least
> some suggestion mentioned in devmanual - really..

I am in favor of applying common sense (hah!). An application (and an 
OS, in general) in the default config should run the common use cases, 
and some more. It's just as easy to remove a use flag as it is to 
enable it.
And personally, I hate having to enable USE=png on all my desktop 
machines so I can use a desktop background. Just as much as I hate 
downloading some video and realizing I forgot to add USE=schroedinger 
for mplayer, and then wait for a recompile before the fun.


Robert