Fwd: [Fedora-packaging] Exemption for bundling local copy of system library?

Tue Sep 29 20:30:21 UTC 2009

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 at gmail.com>
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 at redhat.com>, Fedora Devel
<fedora-devel-list at redhat.com>

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 at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

-- 
Michel Alexandre Salim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20090929/37b7cb34/attachment.sig>