Where is a check that http://ciscobinary.openh264.org/openh264.. is safe? Why no https and no hash for it?
It's downloaded on first start, by default, without consent, from insecure connection.
https://ciscobinary.openh264.org/ has certificate errors : "ciscobinary.openh264.org uses an invalid security certificate. .. valid for a248.e.akamai.net, *.akamaized.net, *.akamaihd-staging.net, *.akamaihd.net, *.akamaized-staging.net)
On http://forums.mozillazine.org/viewtopic.php?f=38&t=2886203 someone is saying it may be a threat. On https://bugzilla.mozilla.org/show_bug.cgi?id=1009816 they discuss installation with manifest and hashes - but I did not see it happened in that case. I assume windows certificates as not safe - but are they even checked with this install and how could it be enough?
Why no https at least? What about hash?
Solução escolhida
http://forums.mozillazine.org/viewtopic.php?f=7&t=3025690:
> Bug 1102531 - On-demand download of Cisco H.264 plugin should occur over HTTPS > https://bugzilla.mozilla.org/show_bug.cgi?id=1102531
Ler esta resposta no contexto 👍 0Todas as respostas (3)
Part of an answer ( https://wiki.mozilla.org/GeckoMediaPlugins ):
GMPs can only be loaded out-of-process, there is no in-process option. Furthermore, child processes may be sandboxed, so GMPs cannot depend on being able to do things outside of the sandbox (like write to disk).
The child process will load the GMP's DLL into the process, then call the publicly exposed GMPInit function. Next Gecko will call the publicly exposed GMPGetAPI function, requesting the desired API data (see the Base API section for more info).
Solução escolhida
http://forums.mozillazine.org/viewtopic.php?f=7&t=3025690:
> Bug 1102531 - On-demand download of Cisco H.264 plugin should occur over HTTPS > https://bugzilla.mozilla.org/show_bug.cgi?id=1102531
That's good work. It did not take you too long to figure out. It does however highlight the advantages of implementing
- Bug 1102531 - On-demand download of Cisco H.264 plugin should occur over HTTPS
Unfortunately at Mozilla there are often limited resources and a need to prioritise work, and for various reasons - including a security comment #c2 -- that bug looks like its on the back burner.