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

[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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090929/3466ac02/attachment.sig>