GNU bug report logs - #38831
IceCat: some codecs don't work without workaround

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38831 in the body.
You can then email your comments to 38831 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jakub Kądziołka <kuba <at> kadziolka.net>
To: bug-guix <at> gnu.org
Cc: mhw <at> netris.org
Subject: IceCat: some codecs don't work without workaround
Date: Tue, 31 Dec 2019 15:24:01 +0100

Hello,

I had some problems with video codecs in IceCat 68.3.0-guix0-preview1.
For example, consider this page: http://demo.nimius.net/video_test/. By
default, the videos under the headings H.264 / AAC and MPEG4 don't work
("No video with supported format and MIME type found.").

The following steps make the first of these videos work:
1. Open about:config
2. Click "I accept the risk!"
3. Set security.sandbox.content.read_path_whitelist to /gnu/store/
   (the trailing / is important).

The instructions were originally sketched out in this help-guix
message:
https://lists.gnu.org/archive/html/help-guix/2019-12/msg00150.html

I believe it would be beneficial to make this a default.

On IRC, bandali suggested that it would be better to only whitelist the
necessary store subdirectories. I don't know how to gather such a list,
but it it seems like a good idea.

I don't know how about:config entries modified by the user behave when
IceCat is updated, but in some of the behaviors I can imagine, the
config entry stops updating, in which case it would be better to add
the paths to some internal whitelist (I reckon such a whitelist already
exists and contains something like /usr/lib).

Regards,
Jakub Kądziołka

CC: mhw as suggested by nckx

Message #12 received at 38831-done <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Jakub Kądziołka <kuba <at> kadziolka.net>
Cc: 38831-done <at> debbugs.gnu.org, 38045-done <at> debbugs.gnu.org
Subject: Re: IceCat: some codecs don't work without workaround
Date: Thu, 16 Jan 2020 01:24:50 -0500

Hi Jakub,

Jakub Kądziołka <kuba <at> kadziolka.net> wrote:
> I had some problems with video codecs in IceCat 68.3.0-guix0-preview1.
> For example, consider this page: http://demo.nimius.net/video_test/. By
> default, the videos under the headings H.264 / AAC and MPEG4 don't work
> ("No video with supported format and MIME type found.").
> 
> The following steps make the first of these videos work:
> 1. Open about:config
> 2. Click "I accept the risk!"
> 3. Set security.sandbox.content.read_path_whitelist to /gnu/store/
>    (the trailing / is important).
> 
> The instructions were originally sketched out in this help-guix
> message:
> https://lists.gnu.org/archive/html/help-guix/2019-12/msg00150.html
> 
> I believe it would be beneficial to make this a default.
> 
> On IRC, bandali suggested that it would be better to only whitelist the
> necessary store subdirectories. I don't know how to gather such a list,
> but it it seems like a good idea.

Thank you for bringing this to my attention.  I agree with Amin Bandali
that a more precise whitelist is preferable.  Moreover, I was not
comfortable whitelisting all of /gnu/store.

I'm glad to report that it appears to be sufficient to whitelist the
RUNPATH of libavcodec.so, plus the /share/mime/ directory from
shared-mime-info.  I've implemented this in commit
429c8284d232c3f9fbe3dc87a3da323f3a864c03 and pushed it to 'master'.

> I don't know how about:config entries modified by the user behave when
> IceCat is updated, but in some of the behaviors I can imagine, the
> config entry stops updating,

As currently implemented, we now arrange to set the *default* value of
'security.sandbox.content.read_path_whitelist' to an appropriate
whitelist.

Users who have customized 'security.sandbox.content.read_path_whitelist'
to work around this issue should now erase that customization, by
right-clicking on its entry in <about:config>, and clicking on "Reset".
It might also be necessary to restart IceCat after doing so.

> in which case it would be better to add the paths to some internal
> whitelist (I reckon such a whitelist already exists and contains
> something like /usr/lib).

I agree that it would be preferable, but I wasn't sufficiently motivated
to implement it.  Feel free to propose a patch.  I'm not sure it would
make much of a difference in practice though, because the net result for
anyone who has customized it to /gnu/store/ will be the same: until they
reset their customization, their effective whitelist will be all of
/gnu/store/*.

What do you think?

Anyway, thanks to everyone who contributed to this fix!  I'm closing
both the older bug (38045) and the more recent duplicate (38831), but
feel free to reopen if appropriate.

       Mark

Message #15 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Julien Lepiller <julien <at> lepiller.eu>
To: bug-guix <at> gnu.org, Mark H Weaver <mhw <at> netris.org>,
 Jakub Kądziołka <kuba <at> kadziolka.net>
Subject: Re: bug#38831: IceCat: some codecs don't work without workaround
Date: Thu, 16 Jan 2020 07:29:01 -0500

Le 16 janvier 2020 01:24:50 GMT-05:00, Mark H Weaver <mhw <at> netris.org> a écrit :
>Hi Jakub,
>
>Jakub Kądziołka <kuba <at> kadziolka.net> wrote:
>> I had some problems with video codecs in IceCat
>68.3.0-guix0-preview1.
>> For example, consider this page: http://demo.nimius.net/video_test/.
>By
>> default, the videos under the headings H.264 / AAC and MPEG4 don't
>work
>> ("No video with supported format and MIME type found.").
>> 
>> The following steps make the first of these videos work:
>> 1. Open about:config
>> 2. Click "I accept the risk!"
>> 3. Set security.sandbox.content.read_path_whitelist to /gnu/store/
>>    (the trailing / is important).
>> 
>> The instructions were originally sketched out in this help-guix
>> message:
>> https://lists.gnu.org/archive/html/help-guix/2019-12/msg00150.html
>> 
>> I believe it would be beneficial to make this a default.
>> 
>> On IRC, bandali suggested that it would be better to only whitelist
>the
>> necessary store subdirectories. I don't know how to gather such a
>list,
>> but it it seems like a good idea.
>
>Thank you for bringing this to my attention.  I agree with Amin Bandali
>that a more precise whitelist is preferable.  Moreover, I was not
>comfortable whitelisting all of /gnu/store.
>
>I'm glad to report that it appears to be sufficient to whitelist the
>RUNPATH of libavcodec.so, plus the /share/mime/ directory from
>shared-mime-info.  I've implemented this in commit
>429c8284d232c3f9fbe3dc87a3da323f3a864c03 and pushed it to 'master'.
>
>> I don't know how about:config entries modified by the user behave
>when
>> IceCat is updated, but in some of the behaviors I can imagine, the
>> config entry stops updating,
>
>As currently implemented, we now arrange to set the *default* value of
>'security.sandbox.content.read_path_whitelist' to an appropriate
>whitelist.
>
>Users who have customized
>'security.sandbox.content.read_path_whitelist'
>to work around this issue should now erase that customization, by
>right-clicking on its entry in <about:config>, and clicking on "Reset".
>It might also be necessary to restart IceCat after doing so.
>
>> in which case it would be better to add the paths to some internal
>> whitelist (I reckon such a whitelist already exists and contains
>> something like /usr/lib).
>
>I agree that it would be preferable, but I wasn't sufficiently
>motivated
>to implement it.  Feel free to propose a patch.  I'm not sure it would
>make much of a difference in practice though, because the net result
>for
>anyone who has customized it to /gnu/store/ will be the same: until
>they
>reset their customization, their effective whitelist will be all of
>/gnu/store/*.
>
>What do you think?
>
>Anyway, thanks to everyone who contributed to this fix!  I'm closing
>both the older bug (38045) and the more recent duplicate (38831), but
>feel free to reopen if appropriate.
>
>       Mark

Hi,

Thanks for the fix! We'll need something similar for webgl (mesa and dependencies at least), unless your patch already fixes it? I haven't checked.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.