UserAgent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0 Steps to reproduce the problem: 1. dnf update 2. google-chrome-beta update 3. no flash available What is the expected behavior? package have /opt/google/chrome/PepperFlash/libpepflashplayer.so What went wrong? dnf --disablerepo='*' --enablerepo="google*" repoquery --available google-chrome-stable -l | grep -i pepper /opt/google/chrome/PepperFlash /opt/google/chrome/PepperFlash/libpepflashplayer.so /opt/google/chrome/PepperFlash/manifest.json but not appears in beta neither in unstable package Did this work before? Yes in previous version google-chrome-beta-53.0.2785.92-1.x86_64 Chrome version: Version 54.0.2840.16 beta (64-bit) Channel: beta OS Version: google-chrome-beta-54.0.2840.16-1.x86_64 Flash Version: Shockwave Flash 22.0 r0
Sep 10 2016,
The solution: http://superuser.com/questions/970130/cannot-install-npapi-flash-player-plug-in-in-google-chrome and https://support.google.com/chrome/answer/6213033?hl=en but I'd like have flash_player_ppapi install in system that in all browser of all users ... this flash_player_ppapi also works in firefox.
Sep 20 2016,
Sep 22 2016,
Sep 22 2016,
r414249 / working as intended?
Sep 25 2016,
No , I want flash installed just one time in all system, be system wild and not install in every profile of every user. This r414249 is in new beta and do exactly what I don't want, that is "Unbundle Flash on Linux". Thanks.
Sep 26 2016,
@thestig: Hey, would you mind responding to comment#5 ? I really appreciate your help. Removing bisect label for now, feel free to add if required. Thank you!
Sep 26 2016,
For many reasons, I don't think the decision to separately update Flash and Chrome ("unbundling") will be reversed, so in a technical sense this is working as intended and I'm going to mark the bug as such. That being said, we understand that this is sub-optimal for many use cases. At this time we don't have a mechanism to install components system-wide, but this is a feature we've been looking at for a while and would like to have soon.
Oct 13 2016,
With Wireshark I found that Google Chrome 54 downloads Flash 220.127.116.11 PPAPI for Linux from this URL: http://redirector.gvt1.com/edgedl/release2/rpofl8ynzf9r05ca7iim67wdwf3t0zpuehwy3aswydc9g91q5c4iydolh9lt5toluyuq2phjg168mcvxxhntm3n79e4nw3mrx1j/18.104.22.168_linux_PepperFlashPlayer.crx It would be fairly easy to catch the DNS requests for redirector.gvt1.com to return the IP of any server. According to this page a CRX file is a ZIP file with the author public key and a SHA-1 signature of its payload: https://developer.chrome.com/extensions/crx I found this topic on Stack Exchange stating that SHA-1 is not considered collision resistant, so even if the public key of the author is known to Chrome beforehand and checked against the public key in the CRX file it would still be possible to manipulate the CRX file in a way that the signature matches the payload. Still, it would require a big computational effort: https://crypto.stackexchange.com/questions/6506/is-sha-1-still-practically-secure-under-specific-scenarios/6510#6510 Is it possible that the update mechanism of Flash implemented in Google Chrome 54 could be vulnerable to MITM attacks? Or are they more safeguards I am missing here?
Oct 13 2016,
There are additional protections: prior to initiating the download, the update system learned the expected SHA-256 hash of the payload from the Omaha update-check (which is in turn protected by a signing protocol called CUP). We then verify that hash prior to doing anything else with the CRX file. You can learn more at https://github.com/google/omaha/blob/master/doc/ServerProtocolV3.md if you are curious.
Sign in to add a comment