unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Julien Lepiller <julien@lepiller.eu>
To: 38831@debbugs.gnu.org, mhw@netris.org, kuba@kadziolka.net
Subject: bug#38831: IceCat: some codecs don't work without workaround
Date: Thu, 16 Jan 2020 07:29:01 -0500	[thread overview]
Message-ID: <28E76491-53BA-47BA-B00E-669D1DC93B61@lepiller.eu> (raw)
In-Reply-To: <87pnfj7waa.fsf@netris.org>

Le 16 janvier 2020 01:24:50 GMT-05:00, Mark H Weaver <mhw@netris.org> a écrit :
>Hi Jakub,
>
>Jakub Kądziołka <kuba@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.

  reply	other threads:[~2020-01-16 12:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87blts4gmv.fsf@gmail.com>
2019-11-03 16:33 ` Video Rendering Issues on IceCat Raghav Gururajan
2019-11-03 22:37   ` bug#38045: " Christopher Lemmer Webber
2019-11-04  0:41   ` Chris Marusich
2019-11-04 13:02   ` Raghav Gururajan
     [not found]   ` <973472324a8a0c24073a9f7106bff044@disroot.org>
2019-11-04 16:25     ` Mark H Weaver
     [not found]     ` <874kzjmww2.fsf@netris.org>
2019-11-04 16:36       ` Mark H Weaver
2020-01-16  6:24   ` bug#38045: IceCat: some codecs don't work without workaround Mark H Weaver
2020-01-16 12:29     ` Julien Lepiller [this message]
2019-12-31 14:24 bug#38831: " Jakub Kądziołka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=28E76491-53BA-47BA-B00E-669D1DC93B61@lepiller.eu \
    --to=julien@lepiller.eu \
    --cc=38831@debbugs.gnu.org \
    --cc=kuba@kadziolka.net \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).