Future of nspluginwrapper

[David Benjamin]

Hi all,

So, as you might have noticed, I've stopped doing much work on
nspluginwrapper. Adobe released a stable 64-bit version of Flash for
Linux some time ago, so there is no more need for the common case of
running 32-bit Flash on a 64-bit browser. Not to mention the web
moving away from plugins in general. And, while the project is still
somewhat interesting to me, I don't appear to have much motivation to
work on a tool that I do not personally use.

If you are still using nspluginwrapper to run Adobe's Flash on i386 or
x86-64 Linux, I recommend against it. I know some distributions will
wrap every plugin installed on the system. Please do not do this. It's
really only a source of instability. nspluginwrapper has never been a
sandboxing solution; you can't actually sandbox a general NPAPI
plugin. (If you want sandboxed Flash, I think Chrome's built-in PPAPI
Flash is your only option.) It also really doesn't do much against
hung or crashed plugins[1].

Of course, there are still uses where nspluginwrapper isn't easily
avoidable. The Adobe Reader plugin is only 32-bit[2], and there other
less common 32-bit-only plugins. Or if you are running on ARM or BSD,
I believe people have used nspluginwrapper with qemu and whatnot. But
since none of those uses apply to me, I may not be the best person to
maintain the project for them.

I have some unreleased fixes (that I mostly forgot I never
released...) in git since 1.4.4, so at the least I'll make a 1.4.6
release with them. They're fairly uninteresting, except that one fixes
a long-standing browser crash on nspluginwrapper upgrade. Past that,
I'll try to fix things as I can, but realistically I'm not likely to
do much. These days my attention has been given to other projects. So
if there is anyone interested for whom the project is more relevant, I
am happy to hand over maintainership. I had a number of plans to
improve things, particularly the configuration tool and wrapper
generation, and I'll detail them to anyone interested. There are also
some unresolved bugs like some issue with Adobe Reader. I doubt I'll
get to addressing them myself.

It's been a fun, if brief, ride. I hope my tenure has made the project
more stable.

David

[1] It is true that nspluginwrapper pushes the plugin out-of-process
and provides some minimal robustness here. However, Chrome, Firefox,
and now Opera all provide this feature built-in and are far more
robust. Both because their code is much better tested and because
nspluginwrapper can't do a lot here. In fact, many of nspluginwrapper
changes in my tenure, if anything, decreased its robustness to
misbehaving plugins. Many of those tricks result in incorrect behavior
in synchronous NPAPI and caused crashes in Flash. Browsers only speak
NPAPI on one end and have slightly more flexibility here. If your
browser does not do this natively, consider asking them to implement
the same feature. Think of it as one of many ways browsers compete
with each other. Multiprocess tricks are a pretty standard these days,
at least for plugins.

[2] Well, you can use Chrome's built-in PDF renderer or download the
files. And I think Firefox is getting a Javascript PDF viewer soon.
But supposing you specifically want Adobe Reader's plugin.