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

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,