[RFC] Support Chrome's $XDG_CONFIG_DIR/google-chrome*/PepperFlash habit

[pritambaral]

Prologue

On systems where Chrome cannot update itself, it downloads updates to flash to a user-writable directory and runs it from there. This is obviously a nice thing, because, in the event of a flash vuln., the entire browser doesn't have to be redownloaded, or even the user notified and bothered to initiate a browser update.

The way it works is Google downloads each version of PepperFlash to a folder:

$XDG_CONFIG_DIR/google-chrome{|-beta|-unstable}/PepperFlash/<pepperflash-version>

and keeps a note of the latest version at

$XDG_CONFIG_DIR/google-chrome{|-beta|-unstable}/PepperFlash/latest-component-updated-flash

which is a json file with the following sample contents:

{
  "Hash": "PRcNGh3ilV6Ryn8FuYwP8oETM5BJCogYtoNBayBNPSE=",
  "HashAlgorithm": 0,
  "PluginPath": "/home/pritam/.config/google-chrome-unstable/PepperFlash/21.0.0.216/libpepflashplayer.so",
  "PluginVersion": "21.0.0.216",
  "Version": 16
}

Proposal

I propose to implement support for detecting presence and freshness (no pun intended) of such libpepflashplayer.sos. I intend to go about it in the following manner:

1. Implement scanning for the latest-component-updated-flash json file, given an $XDG_CONFIG_DIR path. How to distinguish between the absolute paths that are hardcoded in pepperflash_path_list inside config_pepperflash.c right now and the new $XDG_CONFIG_DIR paths is also something I'm seeking comments on. Right now I'm thinking of checking the first character of each path to see if it's a / or a $. Other ideas I can think of are:
   1. Expanding all paths and checking for both libpepflashplayer.so (as is done right now) and latest-component-updated-flash in each expanded path, and
   2. Using separate variables for absolute paths (e.g.: the current pepperflash_path_list will be renamed to pepperflash_absolute_path_list or something like that) and xdg paths.
2. Implement going through all paths and picking the latest version available. Right now, freshplayer simply picks the first path that has a regular, readable libpepflashplayer.so.

I was thinking of implementing #1 in config_pepperflash.c, but found that the version choosing logic is in np_entry.c. I could simply do the scanning and choosing amongst xdg paths in config_pepperflash.c and return from fpp_config_get_plugin_path_list with just that one path added, but that would still require maintaining two copies of the version choosing logic. Which is why I'd like to move all of the version choosing logic into config_pepperflash.c.

---

Waiting for comments

[i-rinat]

Which is why I'd like to move all of the version choosing logic into config_pepperflash.c.

I think that option would be the best one. There is also no need of returning a list, one path is good enough.

[pritambaral]

@i-rinat What do I do about the usage of fpp_plugin_get_plugin_paths in config_nacl.c, config_libpdf_backend.c, and config_libpdf_frontend.c? Do I also refactor the three of them to return a single path?

[pritambaral]

Also, what is the current status of those three plugins? Are they even enabled/used?

[i-rinat]

Do I also refactor the three of them to return a single path?

That would be great. I think, it would be fine if they return just single "/opt/google/chrome", without and searing logic involved.

Also, what is the current status of those three plugins? Are they even enabled/used?

They are both disabled by default. NaCl isn't working at all, it's not finished. Libpdf backend part is kind of working, but it's useless without frontend part, which is not implemented. Latter requires porting Javascript code from Chrome PDF extension.

[pritambaral]

@i-rinat I have initiated a PR (which is a Work-In-Progress right now). The first (and only, right now) commit in it moves version choosing logic into each plugin. Do have a look.

[i-rinat]

Implemented in da0120a018d634f8825f15988f3b8fcec11ce6c6. Code searches in all paths, then selects one with newest version. Chrome beta and unstable paths were removed, since they almost always have some beta-versions with higher numbers in version strings.