Exemption for bundling local copy of system library?

[Michel Alexandre Salim]

Hi,

Oolite <http://oolite.org> is currently undergoing review, and a
stumbling block is in its use of its own copy of libjs. An upstream
developer is participating in the review and has a clear explanation
for the rationale:

https://bugzilla.redhat.com/show_bug.cgi?id=459211

libjs is not exposed to any network interfaces, so the risk is
probably quite low -- the alternative is to wait until xulrunner 2.0
is released (the previous stable version has problems in its scripting
mechanism and most third-party add-ons for Oolite do not work on it
anymore.

Would it be alright in this case to bundle libjs?

PS the "no bundled libraries" draft
(http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries) does
not clearly indicate which mailing list is to be used

Thanks,

-- 
Michel Alexandre Salim

[Jon Ciesla]

Michel Alexandre Salim wrote:
>  Hi,
>
>  Oolite <http://oolite.org> is currently undergoing review, and a
>  stumbling block is in its use of its own copy of libjs. An upstream
>  developer is participating in the review and has a clear explanation
>  for the rationale:
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=459211
>
>  libjs is not exposed to any network interfaces, so the risk is
>  probably quite low -- the alternative is to wait until xulrunner 2.0
>  is released (the previous stable version has problems in its scripting
>  mechanism and most third-party add-ons for Oolite do not work on it
>  anymore.
>
>  Would it be alright in this case to bundle libjs?
>
>  PS the "no bundled libraries" draft
>  (http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries) does
>  not clearly indicate which mailing list is to be used
>
>  Thanks,
>
>     
This list is fine.

Based on what I see in the BZ, I'd much rather see you wait until they 
get on the current libjs, especially since it sounds fairly immanent.

-J

-- 
in your fear, seek only peace
in your fear, seek only love

-d. bowie

[Toshio Kuratomi]

On 09/29/2009 11:37 AM, Michel Alexandre Salim wrote:
>  Hi,
>  
>  Oolite <http://oolite.org> is currently undergoing review, and a
>  stumbling block is in its use of its own copy of libjs. An upstream
>  developer is participating in the review and has a clear explanation
>  for the rationale:
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=459211
>  
>  libjs is not exposed to any network interfaces, so the risk is
>  probably quite low -- the alternative is to wait until xulrunner 2.0
>  is released (the previous stable version has problems in its scripting
>  mechanism and most third-party add-ons for Oolite do not work on it
>  anymore.
>  
>  Would it be alright in this case to bundle libjs?
>   
I would argue no.  The guidelines are written to apply to all libraries
except with very limited exceptions to keep this from happening because
security vulnerabilities are not limited to network facing code, suid
code, or any other class that we've been able to identify.  The libz
vulnerability many years ago is the classic example of this.  Many
programs were embedding libz, many statically.  When a security
vulnerability in libz was discovered, we had to find all of those
programs, remove the vulnerable library, patch any code that didn't work
with the newer version, and rebuild all of those packages.  This is not
what you want to do when you are in the time-constrained situation of
putting out a zero day update to the code.

The statement that libjsis not exposed to the network is also not a
guarantee that security problems will be low-impact on several counts:

1) Libraries in C can cause problems in unrelated sections of code
because they can access memory directly.  Sometimes this can lead to
very bad exploits (especially in code with enhanced privileges), other
times it is the first step for an attacker to look for other programs on
your machine that are vulnerable to other sorts of attacks.

2) """Libjs is used to run local user-installed scripts (as parts of
expansion packs) only""".  Although libjs may not retrieve scripts
directly from the network, it is definitely handling data of foreign
origin.  If I download an expansion pack because I saw a review that
made it look really cool and then run it, I am exposing libjs to that
code from a random source.  If there were a buffer overflow in libjs and
someone realized that OOList contains its own copy of libjs, they could
try to craft an expansion pack that takes advantage of that fact.

And it's probably premature to go to FESCo with this.  Firefox does not
use the system libjs.so.  So you should find out if the spidermonkey
maintainer is willing to compile with JS_C_STRINGS_ARE_UTF8.  At present
the only depending package I see is mediatomb so this might be the best
option.

Also note, it sounds like Oolite is updating to js-1.80 -- that's
currently at rc1, not an actual release.  You'll need to work with the
js maintainer and make sure that that is okay as well.

>  PS the "no bundled libraries" draft
>  (http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries) does
>  not clearly indicate which mailing list is to be used
>   
The actual decision is a FESCo decision.  That would be tracked in their
trac instance.  But FPC people are going to have input on it which would
be here.  Everyone on fedora-devel-list has 2 cents to put in on these
cases but very few of them seem to want to look at the problems that
arise with bundling libraries and propose solutions so it's easy to be
mislead into thinking that something's acceptable because it's easy
rather than likely to be denied because there's no basis to grant an
exception.

-Toshio

[Michel Alexandre Salim]

On Tue, Sep 29, 2009 at 3:37 PM, Toshio Kuratomi <a.badger(a)gmail.com&gt; wrote:
>  On 09/29/2009 11:37 AM, Michel Alexandre Salim wrote:
> > Hi,
> >
> > Oolite <http://oolite.org> is currently undergoing review, and a
> > stumbling block is in its use of its own copy of libjs. An upstream
> > developer is participating in the review and has a clear explanation
> > for the rationale:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=459211
> >
> > libjs is not exposed to any network interfaces, so the risk is
> > probably quite low -- the alternative is to wait until xulrunner 2.0
> > is released (the previous stable version has problems in its scripting
> > mechanism and most third-party add-ons for Oolite do not work on it
> > anymore.
> >
> > Would it be alright in this case to bundle libjs?
> >
>
>  I would argue no.  The guidelines are written to apply to all libraries
>  except with very limited exceptions to keep this from happening because
>  security vulnerabilities are not limited to network facing code, suid
>  code, or any other class that we've been able to identify.  The libz
>  vulnerability many years ago is the classic example of this.  Many
>  programs were embedding libz, many statically.  When a security
>  vulnerability in libz was discovered, we had to find all of those
>  programs, remove the vulnerable library, patch any code that didn't work
>  with the newer version, and rebuild all of those packages.  This is not
>  what you want to do when you are in the time-constrained situation of
>  putting out a zero day update to the code.
>  
Understandable. I suppose the best way to proceed is to continue the
review, but wait on the libjs removal for final approval.

>  And it's probably premature to go to FESCo with this.  Firefox
> does not
>  use the system libjs.so.  So you should find out if the spidermonkey
>  maintainer is willing to compile with JS_C_STRINGS_ARE_UTF8.  At present
>  the only depending package I see is mediatomb so this might be the best
>  option. 
Good point; I'll contact both maintainers.

>  Also note, it sounds like Oolite is updating to js-1.80 -- that's
>  currently at rc1, not an actual release.  You'll need to work with the
>  js maintainer and make sure that that is okay as well.
>  
Worse come to worse, we can stay at the last version that support
js-1.70, and probably ask the js maintainer to update Rawhide to
1.80-pre, now that F-12 branching has occured?

Thanks, Toshio and Jon, for the inputs.

-- 
Michel Alexandre Salim

Fwd: Exemption for bundling local copy of system library?

[Michel Alexandre Salim]

Hi all,

I'm writing this because I am currently packaging an application,
Oolite, that would require libjs to be compiled with
-DJS_C_STRINGS_ARE_UTF8, and your packages are directly involved
(either js, or a dependent).

Is there any detrimental effect if libjs is compiled with this
setting? From the upstream bug report, it would seem that it only
affects Mozilla products (which, in Fedora, use xulrunner's libjs).
There is a discussion on a Mozilla mailing list in which CouchDB
developers even request this switch, but I cannot seem to find it
today.

$ repoquery --whatrequires --alldeps js
mediatomb-0:0.11.0-11.fc12.x86_64
gpac-libs-0:0.4.6-0.1.cvs20090919.fc12.i686
gpac-libs-0:0.4.6-0.1.cvs20090919.fc12.x86_64
js-devel-0:1.70-8.fc12.i686
callweaver-javascript-0:1.2.1-2.fc12.x86_64
js-devel-0:1.70-8.fc12.x86_64
couchdb-0:0.9.1-1.fc12.x86_64
js-0:1.70-8.fc12.i686
js-0:1.70-8.fc12.x86_64

If the js maintainers are willing to make the change, then what I
propose is to put up a test build somewhere, and then all of us could
test our packages against this new js, and we can commit it if there
is no breakage.

Thanks,

-- 
Michel

---------- Forwarded message ----------
From: Toshio Kuratomi <a.badger(a)gmail.com&gt;
Date: Tue, Sep 29, 2009 at 3:37 PM
Subject: Re: [Fedora-packaging] Exemption for bundling local copy of
system library?
To: Discussion of RPM packaging standards and practices for Fedora
<fedora-packaging(a)redhat.com&gt;, Fedora Devel
<fedora-devel-list(a)redhat.com&gt;


On 09/29/2009 11:37 AM, Michel Alexandre Salim wrote:
>  Hi,
>
>  Oolite <http://oolite.org> is currently undergoing review, and a
>  stumbling block is in its use of its own copy of libjs. An upstream
>  developer is participating in the review and has a clear explanation
>  for the rationale:
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=459211
>
>  libjs is not exposed to any network interfaces, so the risk is
>  probably quite low -- the alternative is to wait until xulrunner 2.0
>  is released (the previous stable version has problems in its scripting
>  mechanism and most third-party add-ons for Oolite do not work on it
>  anymore.
>
>  Would it be alright in this case to bundle libjs?
>  
I would argue no.  The guidelines are written to apply to all libraries
except with very limited exceptions to keep this from happening because
security vulnerabilities are not limited to network facing code, suid
code, or any other class that we've been able to identify.  The libz
vulnerability many years ago is the classic example of this.  Many
programs were embedding libz, many statically.  When a security
vulnerability in libz was discovered, we had to find all of those
programs, remove the vulnerable library, patch any code that didn't work
with the newer version, and rebuild all of those packages.  This is not
what you want to do when you are in the time-constrained situation of
putting out a zero day update to the code.

The statement that libjsis not exposed to the network is also not a
guarantee that security problems will be low-impact on several counts:

1) Libraries in C can cause problems in unrelated sections of code
because they can access memory directly.  Sometimes this can lead to
very bad exploits (especially in code with enhanced privileges), other
times it is the first step for an attacker to look for other programs on
your machine that are vulnerable to other sorts of attacks.

2) """Libjs is used to run local user-installed scripts (as parts of
expansion packs) only""".  Although libjs may not retrieve scripts
directly from the network, it is definitely handling data of foreign
origin.  If I download an expansion pack because I saw a review that
made it look really cool and then run it, I am exposing libjs to that
code from a random source.  If there were a buffer overflow in libjs and
someone realized that OOList contains its own copy of libjs, they could
try to craft an expansion pack that takes advantage of that fact.

And it's probably premature to go to FESCo with this.  Firefox does not
use the system libjs.so.  So you should find out if the spidermonkey
maintainer is willing to compile with JS_C_STRINGS_ARE_UTF8.  At present
the only depending package I see is mediatomb so this might be the best
option.

Also note, it sounds like Oolite is updating to js-1.80 -- that's
currently at rc1, not an actual release.  You'll need to work with the
js maintainer and make sure that that is okay as well.

>  PS the "no bundled libraries" draft
>  (http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries) does
>  not clearly indicate which mailing list is to be used
>  
The actual decision is a FESCo decision.  That would be tracked in their
trac instance.  But FPC people are going to have input on it which would
be here.  Everyone on fedora-devel-list has 2 cents to put in on these
cases but very few of them seem to want to look at the problems that
arise with bundling libraries and propose solutions so it's easy to be
mislead into thinking that something's acceptable because it's easy
rather than likely to be denied because there's no basis to grant an
exception.

-Toshio


--
Fedora-packaging mailing list
Fedora-packaging(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging




-- 
Michel Alexandre Salim