[gentoo-dev] Packages up for grabs due lavajoe retirement

[gentoo-dev] Packages up for grabs due lavajoe retirement

[Pacho Ramos]

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

media-gfx/xv
sys-apps/more
media-sound/logitechmediaserver-bin -> this package is "special", it's
maintained by a proxy maintainer but it was reassigned to
maintainer-needed instead of proxy-maint herd. Was reviewing to reassign
it when I saw:
https://bugs.gentoo.org/show_bug.cgi?id=251494

that I have no idea about how to handle :|




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Packages up for grabs due lavajoe retirement

[Tomáš Chvátal]

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

Dne Pá 30. listopadu 2012 20:37:22, Pacho Ramos napsal(a):
> media-sound/logitechmediaserver-bin -> this package is "special", it's
> maintained by a proxy maintainer but it was reassigned to
> maintainer-needed instead of proxy-maint herd. Was reviewing to reassign
> it when I saw:
> https://bugs.gentoo.org/show_bug.cgi?id=251494
> 
> that I have no idea about how to handle :|

Simple,
add hardmaks explaining possible secuirty issues due to bundling earth&heaven, 
and then let the proxymaintainer play with it if he wants.

The mask will be lifted only under condition these issues are fixed.
People can unmask quite easily if they want, we don't need everything in 
stable :-)

Tom

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Packages up for grabs due lavajoe retirement

[Rich Freeman]

On Fri, Nov 30, 2012 at 4:13 PM, Tomáš Chvátal <tomas.chvatal@gmail.com> wrote:
> Dne Pá 30. listopadu 2012 20:37:22, Pacho Ramos napsal(a):
>> media-sound/logitechmediaserver-bin -> this package is "special", it's
>> maintained by a proxy maintainer but it was reassigned to
>> maintainer-needed instead of proxy-maint herd. Was reviewing to reassign
>> it when I saw:
>> https://bugs.gentoo.org/show_bug.cgi?id=251494
>>
>> that I have no idea about how to handle :|
>
> Simple,
> add hardmaks explaining possible secuirty issues due to bundling earth&heaven,
> and then let the proxymaintainer play with it if he wants.
>
> The mask will be lifted only under condition these issues are fixed.
> People can unmask quite easily if they want, we don't need everything in
> stable :-)

I can't say that I agree with this needing to be masked.  If it HAS a
known security issue, then mask it.  If the only issue is that it
bundles too many libs, well, then just stick an ewarn in there or
something but make it the user's call.

Should we mask chrome while we're at it (and yes, I'm aware that the
chromium team is doing their best to remove these, but there are MANY
left)?  How about mythtv - that bundles ffmpeg?

Yes, it is lousy practice, but our options are to change the world,
practically fork upstream, or refuse to include useful packages.  It
is admirable when we can remove bundled libs, but this should not be
mandatory for having a package in the tree.  Actual security issues
should be fixed, of course, or masked.

Sure, it ain't perfect or pretty, but it works.  And when dealing with
outsiders, whether they are proxy maintainers or our founder, can we
at least try to be polite?

Rich

Re: [gentoo-dev] Packages up for grabs due lavajoe retirement

[Tomáš Chvátal]

Dne So 1. prosince 2012 06:42:13, Rich Freeman napsal(a):
> On Fri, Nov 30, 2012 at 4:13 PM, Tomáš Chvátal <tomas.chvatal@gmail.com> 
wrote:
> > Dne Pá 30. listopadu 2012 20:37:22, Pacho Ramos napsal(a):
> >> media-sound/logitechmediaserver-bin -> this package is "special", it's
> >> maintained by a proxy maintainer but it was reassigned to
> >> maintainer-needed instead of proxy-maint herd. Was reviewing to reassign
> >> it when I saw:
> >> https://bugs.gentoo.org/show_bug.cgi?id=251494
> >> 
> >> that I have no idea about how to handle :|
> > 
> > Simple,
> > add hardmaks explaining possible secuirty issues due to bundling
> > earth&heaven, and then let the proxymaintainer play with it if he wants.
> > 
> > The mask will be lifted only under condition these issues are fixed.
> > People can unmask quite easily if they want, we don't need everything in
> > stable :-)
> 
> I can't say that I agree with this needing to be masked.  If it HAS a
> known security issue, then mask it.  If the only issue is that it
> bundles too many libs, well, then just stick an ewarn in there or
> something but make it the user's call.

Bundling few libs and bundling 40 of them is bit of difference, will YOU do 
the audit?
Also other teams actively work on the unbundling, while there is track of no 
will to actually make it buildable with system libs.

Also the security is not the only problem here, it can also cause runtime 
issues. Like bundled lib does not work with xyz because it does not apply 
patch X that we have in main tree.

> 
> Should we mask chrome while we're at it (and yes, I'm aware that the
> chromium team is doing their best to remove these, but there are MANY
> left)?  How about mythtv - that bundles ffmpeg?

Mythtv and its bundling is really horrible and actually not needed at all by 
upstream.. This is the reason why it for example is not included in debian at 
all (external repos of course have it).

> 
> Yes, it is lousy practice, but our options are to change the world,
> practically fork upstream, or refuse to include useful packages.  It
> is admirable when we can remove bundled libs, but this should not be
> mandatory for having a package in the tree.  Actual security issues
> should be fixed, of course, or masked.
> 
> Sure, it ain't perfect or pretty, but it works.  And when dealing with
> outsiders, whether they are proxy maintainers or our founder, can we
> at least try to be polite?

Yes we should be polite and nice, and I think explaining the guy why it will 
be masked is enough. He can still work on it in main tree where it will for 
sure get way larger audience than if it would be sitting in some overlay, and 
users would have to read the mask before using it so they will have to use 
their brains at least a bit.

Still keep in mind most distros won't allow inclusion of such software into 
main repositories at all, so we allow something fishy others avoid a lot.

Re: [gentoo-dev] Packages up for grabs due lavajoe retirement

[Rich Freeman]

On Sat, Dec 1, 2012 at 7:32 AM, Tomáš Chvátal <tomas.chvatal@gmail.com> wrote:
> Bundling few libs and bundling 40 of them is bit of difference, will YOU do
> the audit?

We don't require security audits for packages to be in portage.  Any
package can have a security problem, whether it is in a bundled lib or
otherwise.  Besides, if we can trust Google to audit their bundled
libs, why can't we trust other upstreams to do the same if they do not
have a bad reputation?  And the last time I checked chromium had a ton
of bundled libs - just extract the source tarball and note that about
90% of the file size is in the 3rd party tree (and as I said, to their
credit the chromium team has done a wonderful job of eliminating the
need to build a fair bit of that).

> Still keep in mind most distros won't allow inclusion of such software into
> main repositories at all, so we allow something fishy others avoid a lot.

Yeah, but with other distros there is a much stronger tradition of
alternate repositories.

Half the stuff we stick in portage isn't in main repository for
distros like Debian/Ubuntu.

The other issue is that we're always tweaking ebuilds so that we can
do dependency bumps.  Packages not in portage don't benefit from that,
so they're much more prone to breaking.  A distro like Debian/Ubuntu
freezes the core libs so that alternate repository maintainers only
have to mess with their packages a few times per year on a
well-defined schedule.

And if we force some types of packages to be masked all the time, then
what do we do if we actually need to mask them for removal or
security.  Users won't even realize they have a known flaw, because
they had to unmask the package just to install it.  I think there is a
big difference between "bundles libs and therefore might have a
security issue" and "has a known security issue."

I also am not convinced that bundling libs actually exposes you to
more security issues. It simply makes it more likely that you'll be
exposed to a discovered security issue.  If I have a million lines of
code that is a million places I could be vulnerable.  If I half half a
million lines of original code and half a million lines of bundled
libs, that is a million places I could be vulnerable, except that at
least the libs have gotten more eyeballs.  The reason that zlib issues
get talked about is that people actually security audit zlib.  Nobody
security audits stuff like amarok so it could have 10x as many
security holes and nobody would notice, but if it bundled a vulnerable
zlib version suddenly everybody would notice that.

I'm all for trying to unbundle things, but I don't think failure to do
so is a reason to mask a package.  That is an upstream quality issue,
and if we can improve on it great, but if not, well, I think emacs is
painful to use but I'm not going to ask for it to be masked until we
can patch in the vim key bindings.

I recall having a similar email discussion to this one years ago.  I
think an issue is that everybody wants quality but no two people can
agree on what exactly the standards should be.  I think we almost need
some way to flag packages by quality level.  If you could tag a
package with "includes unaudited bundled libraries" the way you can
tag it with "has a non-free license" then end users could choose the
stance they want.  Of course, to do that right you'd probably need
context.  As drobbins pointed out in the bug report my stance towards
a media player is likely to be different from my stance towards a web
server/browser or email client.  And yet, I do use chromium as my
browser despite the fact that it still bundles a ton of libs.

Rich

Re: [gentoo-dev] Packages up for grabs due lavajoe retirement

[Chí-Thanh Christopher Nguyễn]

Tomáš Chvátal schrieb:
> Bundling few libs and bundling 40 of them is bit of difference, will YOU do 
> the audit?
> Also other teams actively work on the unbundling, while there is track of no 
> will to actually make it buildable with system libs.
> 
> Also the security is not the only problem here, it can also cause runtime 
> issues. Like bundled lib does not work with xyz because it does not apply 
> patch X that we have in main tree.

I agree that this package should not be marked stable unless the security
team agrees.
But IMO the package can stay ~arch unless there are actual security/runtime
problems. If such problems are found, then it can be p.masked with reference
to the bug report.

> Still keep in mind most distros won't allow inclusion of such software into 
> main repositories at all, so we allow something fishy others avoid a lot.

The same is true for non-redistributable software (RESTRICT="mirror" and/or
"bindist"), software redistributable only in source form (bindist) or
software that may only be downloaded manually (fetch).


Best regards,
Chí-Thanh Christopher Nguyễn

[gentoo-dev] Re: Packages up for grabs due lavajoe retirement

[Duncan]

Rich Freeman posted on Sat, 01 Dec 2012 08:46:34 -0500 as excerpted:

> And if we force some types of packages to be masked all the time, then
> what do we do if we actually need to mask them for removal or security. 
> Users won't even realize they have a known flaw, because they had to
> unmask the package just to install it.  I think there is a big
> difference between "bundles libs and therefore might have a security
> issue" and "has a known security issue."

Very good point.

Being a (somewhat pragmatic) security emphasis person by default, as well 
as a freedomware person, I had been leaning toward the "mask it and let 
the user decide" viewpoint, but this question changed my mind entirely.

What about this for a reasonable but still somewhat strict compromise?

a) A pkg_pretend phase that checks for a set variable (like 
I_KNOW_THE_SECURITY_ISSUES), and dies with an appropriate warning if it's 
not set.

b) With (a) in place, keeping the package unmasked (unless (c)) but 
forever ~arch, no stable.

c) Deal with known security issues as normal, that is, mask the package, 
with possible eventual removal.


It seems to me that this is a reasonable compromise giving both sides 
what they want.  (a) forces the user into a hard opt-in to actually 
install the package, (b) keeps the package at least visible to ordinary 
users (those willing to deal with ~arch at least), and (c) means we can 
still notify users that have opted-in when there's a known security issue.

If this proves to be a reasonable compromise, it's possible there's other 
packages for which it can be used as well.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Packages up for grabs due lavajoe retirement

[Alec Warner]

On Sat, Dec 1, 2012 at 6:20 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Rich Freeman posted on Sat, 01 Dec 2012 08:46:34 -0500 as excerpted:
>
>> And if we force some types of packages to be masked all the time, then
>> what do we do if we actually need to mask them for removal or security.
>> Users won't even realize they have a known flaw, because they had to
>> unmask the package just to install it.  I think there is a big
>> difference between "bundles libs and therefore might have a security
>> issue" and "has a known security issue."
>
> Very good point.
>
> Being a (somewhat pragmatic) security emphasis person by default, as well
> as a freedomware person, I had been leaning toward the "mask it and let
> the user decide" viewpoint, but this question changed my mind entirely.
>
> What about this for a reasonable but still somewhat strict compromise?
>
> a) A pkg_pretend phase that checks for a set variable (like
> I_KNOW_THE_SECURITY_ISSUES), and dies with an appropriate warning if it's
> not set.
>
> b) With (a) in place, keeping the package unmasked (unless (c)) but
> forever ~arch, no stable.
>
> c) Deal with known security issues as normal, that is, mask the package,
> with possible eventual removal.
>
>
> It seems to me that this is a reasonable compromise giving both sides
> what they want.  (a) forces the user into a hard opt-in to actually
> install the package, (b) keeps the package at least visible to ordinary
> users (those willing to deal with ~arch at least), and (c) means we can
> still notify users that have opted-in when there's a known security issue.

Look, if you want to make a policy about the stuff, then make a
policy, get council approval, and write it down.
Don't make up silly half-solutions.

-A

>
> If this proves to be a reasonable compromise, it's possible there's other
> packages for which it can be used as well.
>
> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
>
>

Re: [gentoo-dev] Re: Packages up for grabs due lavajoe retirement

[Rich Freeman]

On Sat, Dec 1, 2012 at 9:37 PM, Alec Warner <antarus@gentoo.org> wrote:
> Look, if you want to make a policy about the stuff, then make a
> policy, get council approval, and write it down.
> Don't make up silly half-solutions.

Sure, but I'm not aware of any policy at all concerning packages that
contain bundled libraries.

Rich

Re: [gentoo-dev] Re: Packages up for grabs due lavajoe retirement

[Alec Warner]

On Sat, Dec 1, 2012 at 6:41 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Sat, Dec 1, 2012 at 9:37 PM, Alec Warner <antarus@gentoo.org> wrote:
>> Look, if you want to make a policy about the stuff, then make a
>> policy, get council approval, and write it down.
>> Don't make up silly half-solutions.
>
> Sure, but I'm not aware of any policy at all concerning packages that
> contain bundled libraries.
>
> Rich
>

I know, but some people seem to think Gentoo should have one. Hence my
request to write one down, and get it approved. The point of the
council is to be the decider here; to say 'oh this policy is
reasonable' or 'oh this policy is silly.' I think we are far past the
point where we can reach consensus on the list; that is why we have a
set of people to make these decisions.

-A

Re: [gentoo-dev] Re: Packages up for grabs due lavajoe retirement

[Michał Górny]

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

On Sun, 2 Dec 2012 02:20:07 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Rich Freeman posted on Sat, 01 Dec 2012 08:46:34 -0500 as excerpted:
> 
> > And if we force some types of packages to be masked all the time, then
> > what do we do if we actually need to mask them for removal or security. 
> > Users won't even realize they have a known flaw, because they had to
> > unmask the package just to install it.  I think there is a big
> > difference between "bundles libs and therefore might have a security
> > issue" and "has a known security issue."
> 
> Very good point.
> 
> Being a (somewhat pragmatic) security emphasis person by default, as well 
> as a freedomware person, I had been leaning toward the "mask it and let 
> the user decide" viewpoint, but this question changed my mind entirely.
> 
> What about this for a reasonable but still somewhat strict compromise?
> 
> a) A pkg_pretend phase that checks for a set variable (like 
> I_KNOW_THE_SECURITY_ISSUES), and dies with an appropriate warning if it's 
> not set.
> 
> b) With (a) in place, keeping the package unmasked (unless (c)) but 
> forever ~arch, no stable.

You just requested us to have a package which intentionally fails
to build by default. And we're not supposed to fix this nor mask it...

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

[gentoo-dev] Re: Packages up for grabs due lavajoe retirement

[Duncan]

Michał Górny posted on Sun, 02 Dec 2012 09:35:45 +0100 as excerpted:

> On Sun, 2 Dec 2012 02:20:07 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
> 
>> Rich Freeman posted on Sat, 01 Dec 2012 08:46:34 -0500 as excerpted:
>> 
>> > And if we force some types of packages to be masked all the time,
>> > then what do we do if we actually need to mask them for removal or
>> > security.

>> Very good point.

>> What about this for a reasonable but still somewhat strict compromise?
>> 
>> a) A pkg_pretend phase that checks for a set variable (like
>> I_KNOW_THE_SECURITY_ISSUES), and dies with an appropriate warning if
>> it's not set.
>> 
>> b) With (a) in place, keeping the package unmasked (unless (c)) but
>> forever ~arch, no stable.
> 
> You just requested us to have a package which intentionally fails to
> build by default. And we're not supposed to fix this nor mask it...

That's what pkg_pretend is FOR, to notify users about seriously out of 
the ordinary situations such as incredibly resource-intensive builds, or 
unusual packages that might place their system in danger, that need some 
manual attention in the pretend phase, before the actual build gets under 
way.

They'll deal with it once, before the install starts, either deciding to 
set the variable, or deciding the risk is too great and that they don't 
need the package /that/ much after all.  Either way, they'll be informed 
about the risks and won't have to worry about it again during routine use 
and updates, but if they do choose to install, will still be informed by 
the usual security mask mechanism if there's an actual known 
vulnerability.

I actually have some experience with such variables as I've set the 
I_KNOW_WHAT_I_AM_DOING var for glibc so I can downgrade back to the very 
same binpkg I was using just minutes before, when I find a problem with 
an upgrade.  I understand why the variable test is there for glibc, but 
it was irritating non-the-less, especially since simply setting it when I 
had the problem wouldn't work, since it wasn't set in the binpkg.  I have 
similar var settings for grub, so it doesn't try to mount /boot.  But 
setting a variable for a single package via /etc/portage/env/* and 
rebuilding "just works" and must be done only once.  No further worries 
about it after that.

Basically it's the same thing as having to accept a license before first 
install, only in this case it's effectively that they have to accept a 
gentoo warning, due to even more out of the ordinary conditions for a 
gentoo package.

A fetch-restrict is far worse since it requires jumping thru the hoops 
for every upgrade.  Yet we do that on a number of packages.  Are they all 
masked?  (For all I know they might be as I don't use any such packages.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Packages up for grabs due lavajoe retirement

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/12/12 03:35 AM, Michał Górny wrote:
> On Sun, 2 Dec 2012 02:20:07 +0000 (UTC) Duncan
> <1i5t5.duncan@cox.net> wrote:
> 
>> Rich Freeman posted on Sat, 01 Dec 2012 08:46:34 -0500 as
>> excerpted:
>> 
>>> And if we force some types of packages to be masked all the
>>> time, then what do we do if we actually need to mask them for
>>> removal or security. Users won't even realize they have a known
>>> flaw, because they had to unmask the package just to install
>>> it.  I think there is a big difference between "bundles libs
>>> and therefore might have a security issue" and "has a known
>>> security issue."
>> 
>> Very good point.
>> 
>> Being a (somewhat pragmatic) security emphasis person by default,
>> as well as a freedomware person, I had been leaning toward the
>> "mask it and let the user decide" viewpoint, but this question
>> changed my mind entirely.
>> 
>> What about this for a reasonable but still somewhat strict
>> compromise?
>> 
>> a) A pkg_pretend phase that checks for a set variable (like 
>> I_KNOW_THE_SECURITY_ISSUES), and dies with an appropriate warning
>> if it's not set.
>> 
>> b) With (a) in place, keeping the package unmasked (unless (c))
>> but forever ~arch, no stable.
> 
> You just requested us to have a package which intentionally fails 
> to build by default. And we're not supposed to fix this nor mask
> it...
> 

...  a die in pkg_pretend is "fails to be permitted to emerge", not
"fails to build".  And this would be essentially a p.mask but without
it using the portage p.mask (and its various connotations).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlC7qWsACgkQ2ugaI38ACPCh9gEAsBPiECtphA9/H33ucTrfHpQd
2j0dNDOxVxsX+BjOXqQA/2PS3sMy1X8G8+pvj6p7lRsbm0a8IuT1jWNE0pu5TrfC
=Z0nu
-----END PGP SIGNATURE-----

[gentoo-dev] Re: Packages up for grabs due lavajoe retirement

[Duncan]

Ian Stakenvicius posted on Sun, 02 Dec 2012 14:18:04 -0500 as excerpted:

> ...  a die in pkg_pretend is "fails to be permitted to emerge", not
> "fails to build".  And this would be essentially a p.mask but without it
> using the portage p.mask (and its various connotations).

Exactly.  =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Packages up for grabs due lavajoe retirement

[Jeroen Roovers]

On Sat, 1 Dec 2012 21:41:35 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> On Sat, Dec 1, 2012 at 9:37 PM, Alec Warner <antarus@gentoo.org>
> wrote:
> > Look, if you want to make a policy about the stuff, then make a
> > policy, get council approval, and write it down.
> > Don't make up silly half-solutions.
> 
> Sure, but I'm not aware of any policy at all concerning packages that
> contain bundled libraries.

https://bugs.gentoo.org/show_bug.cgi?id=251464


     jer