Firefox says Plugin "outdated""vulnerable"

[coyote2]

Firefox says the "VLC WEb Plugin" is "outdated/vulnerable", though the current VLC2.1.2 says the Mozilla plugin is installed (it's checked).

Firefox26 (though it's been this way for many versions, on both of my XP Pro sp3 computers).

Advice, please?

[Chad.Farmer]

This problem has been reported before. I was told that VLC updates the internal file version in its builds only when that module's source changes. So the file npvlc.dll installed by VLC package 2.1.2 has an internal version of 2.1.0. Presumably the security fixes in 2.1.2 are in other parts of the VLC package.

VLC package 2.1.0 has been marked as "vulnerable" by Firefox. I assume this is true. The problem is that Firefox only has the path to the plugin dll. Firefox doesn't know (or want to know) the internals of VLC packaging and distribution. So when Firefox checks the plugin, it sees "2.1.0" which has been marked as vulnerable.

Of course, re-installing VLC 2.1.2 does not help because it installs again the npvlc.dll marked as version 2.1.0. And Firefox correctly has VLC version 2.1.0 identified as "vulnerable".

As a user, my opinion is that VLC should change their build process to update the version in npvlc.dll in every build. This would resolve the Firefox problem. The justification is that for this file, the file version needs to identify the package version as part of the plugin API. VLC seems reluctant to do this.

An alternative would be to add a function to that plugin API that reports the installed package's version (not the plugin file version). That would require a change by Firefox to use the new function to check package version, but at least it would eliminate these annoying "updated" warnings that persist until the next major version of VLC is released.

[Rémi Denis-Courmont]

No, this is a problem in Firefox and what you say has been rebuffed a number of times here already.

[Jean-Baptiste Kempf]

2.1.3 should not have the issue anymore, btw...

[meacara]

VLC 2.1.3 doesn't solve it. I installed first the X86 version of 2.1.3 because the site couldn't tell I had an X64 system, then the X64 version and restarted firefox. Firefox is STILL saying that the plugin is vulnerable despite the upgrade specifically including the firefox plugin.

[Jean-Baptiste Kempf]

the firefox is still wrong then...

[josephrot]

Firefox browser Windows 7 versions 31, 32 and now 33, do NOT recognize that VideoLAN Ricewind (2.1.5) plug-in exists. De-installing VideoLAN totally, system reset, then re-install VideoLAN 2.1.5. Ricewind dose nothing to improve situation.

The problem is that VideoLAN 2.1.5 installer. is NOT updating the plug-in to version 2.1.5., but is remaining at 2.1.3

Video LAN plug-in 2.1.3 continues to work in Firefox 33, but VideoLAN plug-in 2.1.5 does not install nor show up in Firefox..

Detailed conversations with both VideoLAN staff and Mozilla Firefox staff shows that each is finger-pointing to the other as the cause.

Who's going to be "first" to properly address this rather frequently-seen situation?

Joe
Skype: joerotello

[Rémi Denis-Courmont]

The last release of the browser plugin is version 2.1.3. You´re not making any sense.

[josephrot]

The last release of the browser plugin is version 2.1.3. You´re not making any sense.

Excuse me, with all due respect -- and I truly respect the VideoLAN team -- YOU are making a little "nonsense"...

The last release of VideoLAN 2.1.5. ALSO CARRIES ALONG/SHOULD ALSO what should be a 2.1.5 level browser plug-in, according to both past VideoLAN history and the procedures we have seen over time from both VideoLAN and Mozilla Firefox.

Firefox 31, 32 and 33 are all calling 2.1.3 plugin "outdated" or "vulnerable and outdated". Historically from VidoLAN, when in the past this FF message has been seen, say in VideoLAN 2.1.1 for example, VideoLAN ALSO then released an updated browser plug-in...and then the FF message vanished.

Please advise.

Joe
Skype: joerotello

[Rémi Denis-Courmont]

The installer contains over fifty different software components, all with their version numbers. One of them is VLC media player version 2.1.5 and another one is the VLC NPAPI browser plugin version 2.1.3. Live with it.

What you describe is clearly and definitely a Firefox bug, unless they consider that even the last version is outdated (which makes no sense).

[josephrot]

The installer contains over fifty different software components, all with their version numbers. One of them is VLC media player version 2.1.5 and another one is the VLC NPAPI browser plugin version 2.1.3. Live with it.

Possibly rhetorical question: Why would VideoLAN users have to live with VLC NPAPI browser plugin version 2.1.3, when VideoLAN should issue a VLC NPAPI browser plugin version 2.1.5 that would satisfy both VideoLAN users needs and those of Mozilla, and those of Firefox users....

At that point, VLC NPAPI browser plugin version 2.1.5 would be "numerically match" to Rincewind 2.1.5 executable.

The Immediate Effect: Then users of both VideoLAN and Firefox would "shut the heck up" and stop pestering VideoLAN's hard-working people with mundane problems and questions like this ?

Joe Rotello / Knoxville, TN / USA

[Rémi Denis-Courmont]

What part of "This is a Firefox bug" do you not understand?

Complain to Mozilla. At this point, I am closing the discussion. This is a waste of time.

[josephrot]

What part of "This is a Firefox bug" do you not understand?

Complain to Mozilla. At this point, I am closing the discussion. This is a waste of time.

OK, then. At least we tried to show you and VideoLAN where Mozilla proved without a doubt that the situation lies in BOTH Mozilla and VideoLAN camps.

Appreciate your information, expertise and candor...and I truly mean that...we simply agree to disagree.

Yet ignoring the true situation, by both camps doing so "hurts" everyone...the users, the two camps, eventually the software products integrity, and so forth.

Joe / Knoxville, TN

[marrazzo]

I am here for the same issue as coyote2.
Evidently I am not alone since there are a number of posts inquiring about this matter, and a good number of views for each of these posts.

There really is no good reason to keep the plugin as a separate version number since the plugin operates with the VideoLAN application. It creates confusion and unnecessary concerns. You could point the finger at Mozilla for noticing that your version numbering system is aberrant, but I would ask that you unify the numbering systems between these VideoLAN products which operate interdependently and are delivered simultaneously from your servers.

[josephrot]

What affects ALL of us that happen to use VideoLAN product or player plug-in with Firefox, is that both "camps" -- Mozilla AND VideoLAN.org power players -- do NOT care enough about their users to stop arguing pointlessly with both camps users and simply apply a SIMPLE programming fix to one or both products.

Month after month of problems remaining, complaints resulting in finger pointing by both camps, etc.

Are there any true caring adults at both camps ...or are they both resigned to this childish bickering and finger-pointing ?

[Rémi Denis-Courmont]

What part of "closing the discussion" do you not understand?

[Rémi Denis-Courmont]

There really is no good reason to keep the plugin as a separate version number since the plugin operates with the VideoLAN application. It creates confusion and unnecessary concerns. You could point the finger at Mozilla for noticing that your version numbering system is aberrant, but I would ask that you unify the numbering systems between these VideoLAN products which operate interdependently and are delivered simultaneously from your servers.

You have clearly not read the explanations that were given a number of times already. Or you have decided to ignore them because they do not fit your argumentation.

Either way, you are wrong.

[alfs]

@josephrot and @marazzo:
I'm not sure what you are thinking or how you are getting to your conclusion, but please allow me to re-try explaining why this problem is truly a Mozilla problem (and reported by me as such), and not a VideoLAN problem.

When Microsoft is releasing a new version of Windows, let's say version 8.1, do you then consider they should at the same time release MS Excel v8.1, PowerPoint v8.1, Biztalk server v8.1 and Sharepoint v8.1? That is basically the effect of what you are stating/asking/requesting above.

The browser plugin for VLC is a completely separate piece of software from the VLC player. Why should its release cycle and versioning be pegged to that of the player? Why should VideoLAN keep changing the version numbers for the plugin when they release a new VLC player version and nothing has been changed in the plugin? That would simply mean copying the exact same software and give it a new version number, and it would mean that all distributors (such as all the Linux distros etc.) would have to manage another release which isn't actually a release at all.

Most software created today include loads of external (third party, and often open source/free software) libraries/components. This is also the fact for VLC player. Each party using a library as a part of their software cannot and should not assign any version number to that library, as this is done by the team/organisation releasing the library itself. Therefore, the software packages using these components will include many libraries (components) with different versions. It is very natural, the only thing making sense, and it is the truth for any software from Apple's OS X to VideoLAN's VLC player.

The problem is that Mozilla doesn't seem to be keen on accepting and actually catering for this.
I have no idea why, but they seem to think that when some version of the VLC player product is released, a similar version of the plugin should also be released. As explained above, this is the same as expecting Excel 8.1 to be released at a part of Windows 8.1, and I have no idea why they expect it or how they are managing their system. Maybe there is a Mozilla database where somebody entered some VLC browser plugin version to be expected (i.e. the current version), but when such a version doesn't exist, it is clearly pure stupidity to add such a requirement. Also, this is obviously done without even liaising with the party responsible for the plugin, which in my eyes is very strange. Why would some distributor of the plugin decide to require a version without asking the ones who release the plugin? Shouldn't they be the people to keep track of the plugin versions?

I've seen a load of support questions on this matter, and truly, I do understand very well that the VideoLAN team, who is actually doing this great work for free, in their spare time, get annoyed by all the problems caused by Mozilla. How many hours of support are wasted on these questions?

I hope this made it a bit clearer to you both, and that you realise the plugin is a separate library installed separately from the VLC player!

[wensveen]

Hi,
I hope it's alright if I just reiterate the problem here, just to make sure I understand it correctly?

There are two perspectives, each with their own concerns:
1. VLC, consisting of the main application and the browser plugin (amongst other components). When a bug is fixed in either component the component is released with a new version number, leaving the other component's version alone. This seems like a logical thing to do (like the Windows / Office version argument (although it's not quite true, but that doesn't matter, the point is clear enough)). So when a problem was found in in the VLC main program that shipped with VLC plugin 2.1.3, it was fixed and released with a new version number (presumably, the version numbers were once equal?), namely 2.1.5 (or 2.1.4 and then 2.1.5, irrelevant).

2. The browser, wanting to make sure their users use up-to-date and secure software with up-to-date and secure plugins. So when VLC released version 2.1.5 of the main program, it is in their best interest to alert their users to that fact and suggest they download the new version. The problem is, when asking the plugin for its version it receives the plugin version, 2.1.3. The plug-in itself wasn't insecure or outdated to begin with. That leaves the question of how Firefox is to know when they should alert their users. The reasoning "2.1.3 is the newest version of the plugin, so all is well" is incorrect, because when the main VLC program is also 2.1.3, the plugin could allow some vulnerability to seep through (I don't know if this is possible in this case, but theoretically this is true, right?). So what we want is for Firefox to see is "this is plugin version 2.1.3 using program version 2.1.5, so all is well". I guess the question is if this is possible or not. If so, then yes, Firefox should fix their version check. If not, then VLC and Firefox should cooperate towards a solution. My guess is that this isn't possible with NPAPI, so maybe NPAPI should be fixed. But as a workaround, the version number of the plugin could contain some hint that the main program is updated (maybe something like "2.1.3.0+vlc2.1.5.0" is possible? again, I'm not familiar with NPAPI).

What I truly don't understand, even when VLC would be absolutely right in their position, is that it is in their best interest as well to have Firefox alert their users to the fact that a new version of VLC is released and that they should go and download it. Isn't that what you want too? I assume that is why you do your own version check on start-up of the program too, to make sure we don't run old and insecure version of the software. Currently, there is a lot of doubt about how secure VLC is, because Firefox says so, and while technically incorrect, it does affect user opinion.

Lastly, I do want to point out the difference between a software suite, with all software having the same version, and all of the software of the same vendor. So while it would indeed be completely illogical for Word to change its version when a new version of Windows is released, it's actually quite logical and expected that when a new version of the Office Suite is released, that all the components get the same new version. Even if some part hasn't been updated meanwhile. I think that I would complain after buying Office 2016 and fired up Word, and it would happily inform me that I was running Word 2013 because it hasn't been updated that much. In that sense, VLC "the suite" containing the plugin AND the program, which is also released as such (download VLC version 2.1.5 now!), should contain program version *and* plugin version 2.1.5, in my humble opinion. Even if this is just a technicality to let external programs know they're dealing with a component of the latest version of the suite.

Best regards,
Matthijs

PS. What do you do when the plugin has a bug which is fixed? Does the VLC program (and suite) version remain the same? (download VLC version 2.1.5 now! again! because it's changed! really!)

[Rémi Denis-Courmont]

So take a typical case. There is a security vulnerability libavcodec, one of the audio/video decoding library by VLC. The bug is fixed in libav's libavcodec version 10.1 and in FFmpeg's libavcodec version 2.1.

How does that get mapped into the VLC browser plugin version? Well, it is not and it probably never will for somewhat obvious practical reasons. They are separate components and you can have different mixes of version numbers.

I guess Mozilla refuses to admit that there version checks are a big failure because they have no other solutions. They seem to prefer to defame other open-source projects and cause their user needless alarm and software dysfunction. Of course, until someone actually files a bug with them, this is only guessing. (I don't use their crap anymore so don't count on me to file a bug.)

[josephrot]

Many sincere thanks to all the respondents, and the detailed discussions ARE appreciated. Having read all of the new responses to this "situation", believe that we all more fully understand the various facets. I think where the concerns and frustrations started was when the involved programming parties appeared to be pointing "it's the other person's fault" at each other, instead of "simply" addressing and "curing" the problem.

Recent communications with Mozilla appear to indicate that many of the Firefox programming staff and testers also use VLC themselves and they finally do have changes to the Firefox PlugIn's Update check on the chart to be "fixed". Thus, the discussions and complaints to both VLC and to Mozilla are being heard and considered. I have not heard of a definitive "will be fixed by" date from Mozilla, but I am advised it is very soon now in nature.

Last but not at all least, I am a "lifelong" champion and supporter of both VLC and Mozilla Firefox, as both represent frankly great ideas and sound products...and I believe that I speak for many others in hoping both continue as such.

Joe

[wensveen]

@josephrot: That's great news. I think the people that are reading and participating in this topic are all supportive of both VLC and Firefox, or we wouldn't have cared at all. So it's good to hear that common ground has been found and a solution can be expected in the future. Is there a bug report or something you can link to?

@RDC: I see your point. I saw your point before, actually, and you make a good case. I don't think Mozilla is purposely trying to defame other Open Source projects. Why would they? They have nothing to gain by that. As I user, I'm very happy that FF warns me when I use a vulnerable java or flash plugin.
A plugin that is effectively an intermediary towards a larger package, like VLC, is problematic. If I wrote a plugin that gave the browser direct access to the command line of the machine it's running on, that would mean that while even though the plugin itself could be bug-free, a lot of vulnerabilities might be exposed by this plugin. One cannot expect the plugin to release an updated version each and every time some arbitrary command or library is updated. BUT, when the plugin is an intermediary towards something controlled mostly by the same vendor, I would expect a new version with each new release (BTW, java does this too). At least to the point you have control over it. So when the library is a shared one, external to the application and updated separately from the application (e.g. apt-get install libavcodec) a new vlc plugin version (browser-plugin-vlc) isn't necessarily warranted. But when the application as a whole is updated and shipped together with updated libraries, then one might expect a new plugin version too. Again, I consider the VLC suite as a whole to have a certain version, but that is just my opinion, which isn't shared by everyone and I respect that choice.

I don't think I've brought anything new to the table, so I'll refrain from repeating myself next time . Good to hear Mozilla is working on it, and thanks for all answers and explanations.

[Rémi Denis-Courmont]

So when the library is a shared one, external to the application and updated separately from the application (e.g. apt-get install libavcodec) a new vlc plugin version (browser-plugin-vlc) isn't necessarily warranted.

Firefox is also complaining on Linux that plugin version 2.1.3 is vulnerable - even though on Debian/Ubuntu (and Linux in general), the web plugin and the player are completley separate packages that are updated separately... So there you go.

Besides, even on Windows you can install the plugin and the player separately. They are bundled in the official executable installer only for obvious user convenience.

[alfs]

@Matthijs:
It's perfectly ok with me to summarise like you do! However, I don't really understand (or agree with) your conclusions...

1. You seem to insist on considering the VLC browser plugin as *A PART OF* the VLC Media Player. It is not. I'm not sure whether your installation (maybe on Windows) is bundling the two, therefore making the plugin seem like it's a library of the player itself, but for me (using Linux and aptitude package manager) it is two completely different pieces of software installed separately. (Obviously, there is a dependency from the plugin to have VLC player itself, but there is no dependency the other way around.) If a vulnerability is found in e.g. one of the codecs used by the VLC player, somebody (release responsible for that codec) is releasing a new version. In that case, any software using this topical codec also needs to pull in the new version (replace the old codec version), re-run their tests, possibly fix sxomething and finally compile their software package with the new codec and release the outcome with a new version number. The browser plugin *IS NOT* such a library -- it is not pulled in and causing a recompile of the VLC media player in a similar manner. Given that interfaces are not changed, the old plugin is still able to make the new version of VLC media player work within the browser frame. I don't have to upgrade the plugin, and all the distributors (e.g RedHat, Ubuntu/Canonical, Apple, ...) won't have to push a new plugin version to their users (similar to Windows update, if you are a Windows user).

2. Now you write this:

The browser, wanting to make sure their users use up-to-date and secure software with up-to-date and secure plugins. So when VLC released version 2.1.5 of the main program, it is in their best interest to alert their users to that fact and suggest they download the new version. The problem is, when asking the plugin for its version it receives the plugin version, 2.1.3. The plug-in itself wasn't insecure or outdated to begin with. That leaves the question of how Firefox is to know when they should alert their users.

Even though I think I understand your intent, I also think there are misundertandingings causing this discussion to go on, and really -- we need to get this straight so people (i.e. we, the users) can start bugging Mozilla rather than peppering VideoLAN's forums/support with these things!

The browser, wanting to make sure their users use up-to-date and secure software with up-to-date and secure plugins.

The browser should not care one single bit about other software I am running on my computer except for the browser itself and its plugins.

So when VLC released version 2.1.5 of the main program, it is in their best interest to alert their users to that fact and suggest they download the new version.

As long as you mean VideoLAN by "their best interest", yes. If you mean Firefox, absolutely not! Why on the earth should Firefox care about which version of VLC (or Libre Office or Adobe Acrobat or whatever) I am running on my computer? I have a system distributor for that (in my case Canonical, providing timely updates to any package I have installed via Ubuntu Software market) *AND* this is the exact reason why VLC media player is checking for new versions at startup just like you point out yourself. I don't want Mozilla to start checking whatever runs on my computer, and I really don't think you do either.
And finally: How do they even know that VideoLAN released the new version 2.1.5 in your case? Certainly VideoLAN didn't tell them anything about any update to the browser plugin (which hasn't taken place), and I have no idea where they picked up the update to the media player. Furthermore, I don't understand why they make any assumption such as this (i.e. browser plugin being updated) without even checking with VideoLAN, who is the one and only authoritative source of version information for the VLC products. The only reason I can see for this is Mozilla's habit of synchronising the versioning of their products, but really -- they are among the few, and they should not expect others to do the same.

So what we want is for Firefox to see is "this is plugin version 2.1.3 using program version 2.1.5, so all is well".

No, I don't want or need Firefox to see this, and I don't understand why anyone else would want to use Firefox as their "version control agent". In my eyes, there is nothing to fix in NPAPI to support such a thing, but Mozilla needs to realise the architecture and the fact that they cannot control the entire computer of their users.

What I truly don't understand, even when VLC would be absolutely right in their position, is that it is in their best interest as well to have Firefox alert their users to the fact that a new version of VLC is released and that they should go and download it. Isn't that what you want too?

Nope again. (Well, I cannot speak for VideoLAN, obviously, but at least for myself as a user...and I would guess it's very likely to go on behalf of VideoLAN as well...) If a new version of the *browser plugin* is released, however, THAT is a different matter, and exactly the difference between those two things is what this entire thread is trying to explain. (Again: If a new version of the VLC player is released, the player would tell you upon startup, independent of Mozilla/Firefox and/or whether the plugin is used, and in my case, the new version would also get pushed by my system update feature, managed by the distributor.)

Currently, there is a lot of doubt about how secure VLC is, because Firefox says so, and while technically incorrect, it does affect user opinion.

Yes, and this is the reason I'm getting upset, writing a lot more than I should and also reporting this to Mozilla, as in my eyes it's plainly a bug on their side! Rather than arguing in this thread, we should all push on Mozilla to fix the problem asap, as both the VLC browser plugin and Firefox are very popular and widespread software packages used by a less tech savvy audience, who shouldn't be falsely scared like this!

Lastly, I do want to point out the difference between a software suite, with all software having the same version, and all of the software of the same vendor.

Sure, my comparison was maybe far fetched (or plainly stupid), sorry, *BUT* you are now considering the "branding version" from Microsoft, and your assumption about "a software suite, with all software having the same version" is false. On my virtual Windows machine, I am running MS Office 2010. However, we all know that there are numerous "service packs" and fixes (many of them also security/vulneraility improvements) pushed through Windows update all the time, exactly like what is happening to the VLC media player. if you look at the real version numbers for the products inside the MS Office package, here's what I currently have:

• Outlook v14.0.7128.5000
• Excel v14.0.7140.5002

These are not the same. (Also, your example comparing Office 2016 to 2013 would be more equivalent to VLC player v1 to v2 (or v2 to future v3) -- this means Microsoft is shrinkwrapping a new top level version of the suite, which holds completely new versions of the products...at least a makeover, but commonly also feature additions. I think the difference between the version numbers I've included above for Outlook and Excel compares better to the 3rd level update from 2.1.3 to 2.1.5 discussed here; The diff between Outlook and Excel are at the 3rd level just like 2.1.3 vs. 2.1.5, the 3rd level updates are handled fairly similarly (Windows update vs. VLC update) and probably the updates are holding approximately the same amount/level of changes, I would guess.)

PS. What do you do when the plugin has a bug which is fixed? Does the VLC program (and suite) version remain the same? (download VLC version 2.1.5 now! again! because it's changed! really!)

Well, it's kind of funny that you end by asking this question, really, since this is exactly when Firefox *should* tell you that your plugin is outdated and that you should upgrade...
As mentioned earlier: There is no need to relase the VLC media player again to fix something in the browser plugin (given that APIs are kept unchanged etc.). On my part, I will have the new version of the plugin pushed by my package system, and this is the exact moment that Mozilla should start caring. If this would happen, I assume that VideoLAN would inform Mozilla asap when a new version of their browser plugin is available.
On the contrary, when the player itself gets upgraded, and VideoLAN is *NOT* releasing anything to the Firefox plugin market, why does Mozilla start assuming something??!
(If, in your Windows installation binary package aka the VLC-intall.exe, the plugin is bundled, it would simply ask to be upgraded after installation, I guess. This is more or less like Windows asks to have all service packs and fixes downloaded and installed if you reinstall your computer from a DVD or from a rescue partition. In my case, the browser plugin is not bundled with the player, and I have to admit I haven't bothered checking other versions for other platforms.)

You end off saying

[...] then VLC and Firefox should cooperate towards a solution.

I think we all agree, and the single thing VLC can really do is to report to Mozilla that Firefox' is currently creating a mess for both VideoLAN (whose poor people have to read all of this and answer the same questions over and over 52365 times) and for all the users.
What WE (the users) should do is moving to Mozilla's support forums and report the problem there. That's the only way to get the problem fixed, really, and it's also the correct audience for our expessions of unhappiness. (FYI: I also have problems with Adobe Flash plugin -- the effect is the same, i.e. Firefox constantly whining about a vulnerable version even though I have the very latest release, but in this case it's technically a slightly different reason.)

So everyone: Go file the problem with Mozilla!

Cheers

[DewiMorgan]

As a programmer, here's the way it looks to me.

Say I write a plugin that allows people to use SSH in the browser. Say in version 1.0.0 of my plugin, I allow all versions of SSL, and maybe a zillion other protocols, or maybe not (you can imagine this scenario both ways: the end answer doesn't seem affected, to me).

Some versions of SSL contain known vulnerabilities, which can be exploited over the web, through my plugin.

The Mozilla programmers ask me how, using only the interface I have provided them, they can tell if the version of SSL that my plugin is currently configured to use will be dangerous for their users to run.

Here are some responses I can give:
1) You cannot. Screw you, and screw your users.
2) You can roll your own thing to grope into my keys in the registry, find which chat clients are configured, and find which SSL clients I have installed, then go and grope into *their* registry keys or whatever to find where *they* are installed, and then check the version of those SSL clients using whatever custom method each one requires, because I'm a special snowflake and you should spend lots and lots of programmer time just on my one plugin. I tell all my users they should file a bug with you, to make you do this. It is not, I assert, my responsibility to check whether it's safe for my program to pass some invalid arguments to some insecure version of the SSL client.
3) I'll make a new API (which you must write extra code to handle, because I am a special snowflake) that lets you query the installed version of every single one of my dependencies.
4) I'll release a version 1.0.1 which prevents (or at least warns) users from running it with known-flawed SSL versions, and recommends or requires they upgrade. The browser manufacturers can just check my version number. I acknowledge in this way that it is my responsibility to check that the applications called through me cannot be exploited.

As a programmer, only option 4 seems legitimate.
Option 3 would work, but raises privacy concerns and is also pointlessly more work on both sides.
Option 2 is an obvious and shameful attempt to avoid work and shift blame that would bring shame to anyone saying it.
Option 1 is, I'm betting, probably the most common response Mozilla gets. At least it's not as intellectually dishonest as option 2.

If I know that there is a version of SSL which can be exploited through my plugin, and I don't release a version of my plugin that checks against this, then my plugin is an attack vector, and is justly marked as insecure by Mozilla.

So, seems to me, whether or not they are released in a single package, whether or not they are written by the same people, the authors of the VLC plugin should make a version which checks that it is not being used with a known-vulnerable version of the VLC app. Otherwise, it is an attack vector, and is justly marked as insecure.

The fact that they are released separately is not an excuse to do nothing and not increment their version number: but it is a reason that even if they released 2.1.5, without a safety check, it should still be marked as a a valid attack vector: people could download and install the new plugin without upgrading their VLC, so there'd be no confidence that the problem was patched.

TL;DR: VLC plugin 2.1.3 is a known attack vector and should remain marked as insecure, unless and until they release a version that prevents use with known-insecure VLC players.