[Pkg-chromium-maint] Bug#651912: sandboxing-related renderer crash ("Aw, snap") when loading NSS modules

[Jonathan Nieder]

tags 651912 + pending
quit

Jonathan Nieder wrote:
> Vincent Bernat wrote:
>> 03:19, Jonathan Nieder <jrnieder at gmail.com> disait :

>>> | SECStatus
>>> | RNG_RNGInit(void)
>>> | {
>>> |     /* Allow only one call to initialize the context */
>>> |     fprintf(stderr, "about to call rng_init()\n");	<--- reached
>>> |     PR_CallOnce(&coRNGInit, rng_init);
>>> |     fprintf(stderr, "not printed\n");		<--- not reached
>
> The underlying problem was probably fixed by [1].  Thanks to rsleevi
> for pointing it out[2].

Looks like the /dev/urandom guess was wrong.  Based on testing, this
is fixed by upgrading to libnspr4 2:4.9-2 (4.9-1 still reproduces the
bug).  Most prominent change from that update:

   * debian/control, debian/libnspr4*, debian/rules,
     mozilla/nsprpub/config/rules.mk, mozilla/nsprpub/configure.in,
     mozilla/nsprpub/lib/ds/Makefile.in,
     mozilla/nsprpub/lib/libc/src/Makefile.in,
     mozilla/nsprpub/pr/src/Makefile.in: Move to unversioned library.
     ABI compatibility is ensured upstream, and the SO version, if it needed
     a change at any time, would be a change in the library name. There is
     no reason to keep making compatibility more difficult with other distros
     and upstream binary releases. While previous versions were one-way
     compatible (binaries built against other distros or upstream nspr could
     work on Debian), this approach works both ways.

I don't understand why this changed anything.  Mike, does this make
any sense?  (Why would changing the soname of libnspr4 make it easier
to resolve references from libsoftokn3.so to nspr functions?)

Thanks again for your help and sorry to take so long at this.  The
next upload will automatically bring in an appropriate dependency.
Marking pending.