FFS
"VLC's developers, Videolan Software, were informed of the flaws on Boxing Day and had not issued fixes for the latest stable version, 2.1.5, by the time of disclosure 9 January"
Curse those people having holidays!
A Turkish hacker has revealed two zero-day vulnerabilities in library code used by the popular VLC media player and others. The data execution prevention (CVE-2014-9597) and write access (CVE-2014-9598) violation vulnerabilities could lead to arbitrary code execution, researcher Veysel Hatas said in a post. "VLC Media Player …
This post has been deleted by its author
I find that a bit quick, for disclosure.
To think that MS were whining about 90 days +!
And the fix is in the developer version, according to the article.
Sorry, but if you did that to a commercial project, they'd tear your arms off and beat you to death with the soggy end.
But two weeks is barely adequate to test a fix.
This post has been deleted by its author
>>"And why was it impossible to him to keep quiet until Version 2.2.0-rc2 went live?"
I suspect because then they wouldn't get the "prestige" of having found two dangerous zero-day exploits. Probably saw it in the upcoming developer release, thought their chance of some press was going away, and announced it. Sad.
So, he didn't try the latest VideoLAN build where he would have found that the bugs weren't there, he didn't report the bugs to the right people (FFmpeg for avcodec instead of VideoLAN), and then he let the world and dog know about it maybe because otherwise he wouldn't get the glory.
If your application is vulnerable, then it's your problem, whether it stems from an underlying library or not.
If this is the case, then LOTS of other ffmpeg-based players and converters are probably similarly vulnerable. I love ffmpeg, it can read and write practically anything for free, but this is one of the downsides of a monoculture.
When closing a bug report as not being caused by your application, you should file a bug to the library where the actual cause lies. Hopefully they have done this, but I for one couldn't spot these on the ffmpeg bug system. Could of course just be a more detailed description that sounds different.
"So, he didn't try the latest VideoLAN build where he would have found that the bugs weren't there"
Maybe he did and realised they had already fixed it, so decided to disclose it before the fix was released to get rich and internet famous.
"I love ffmpeg, it can read and write practically anything for free, but this is one of the downsides of a monoculture"
...as opposed to instead having either dozens of vulnerable codecs, or missing enough codecs that idiots will download anything that a quick web search reveals MIGHT play their content, infecting themselves with viruses, adware, and at the minimum, installing poorly-written software that probably uses the ffmpeg library anyway, or God forbid, Quicktime.
This post has been deleted by its author
Or perhaps Win7 doesn't let your dodgy apps run rampantly through the system raping whatever they like along the way? ;)
I wish my apps would do something fun and interesting like that but, alas, they don't.
I should have made my post a little more clear; I meant the development platforms on XP are more solid than on Win 7 and they move faster too which is why my live data cruncher runs on XP as I can't hang around all night for W7.
Mind you, if I could only find my Win2K disks...
Perhaps he prefers to use a stable system. As I do for my development; the Win7 machine is too flaky compared to XP.
If a professional developer does not understand the implications of using an outdated and unsupported version of someone else's software, then I really don't know what to say.
I am disappoint.
Well, if no-one is able to access the machine then it makes no difference if it is supported or not. And are all of the bugs, exploits, holes stomped on, fixed or blocked in the latest o/s? No.
Then it doesn't matter two hoots what I use.
Secondly, there are some compatability issues with the later o/s which aren't in the older ones for some applications which MS have 'promised' to fix and haven't.
And, lastly, shove XP on a new machine run a massive database bashing exercise (say a few million SQL queries) then do the same on Win7. Compare the run times for both.
And if you are still disappoint (sic) then, fair enough, I deserve that downvote.
I would not run a database nor on XP nor on W7. Neither are optimized for server tasks. Anyway the OS matters little when it comes to databases - raw I/O speed and memory size matter far more. And here a 64 bit 7 will outperform any 32 bit XP - and even a 64 bit XP which was mostly a "proof of concept". Moreover the 7 kernel is far better optimized to use a large amount of memory and multicore processors (which were not available when XP was designed - IIRC XP came also with an HAL optimized for single core single processor hardware...)
And if you're just running the client running the queries against a DB server, well, again, the OS matters very little....
If your code shows huge differences between the two OS, I guess you have some hidden issues in your code.
Surely not all bugs are fixed in 7, but XP won't get any bugs fixed. And newer apps may use APIs not available on XP.
Well, if no-one is able to access the machine then it makes no difference if it is supported or not. And are all of the bugs, exploits, holes stomped on, fixed or blocked in the latest o/s? No.Then it doesn't matter two hoots what I use.
It was more a dig aimed at the usual response given when someone asks for help with issues with Software v(N-2), aka "version N is the currently supported version, please upgrade".
An airgapped XP machine is as secure as any airgapped machine. I'd still recommend rebuilding that dodgy Win7 box (it should be stable, we have stable Win7 boxen here) and when you have it working properly, migrate to that as your dev box. The additional thread scheduling and handling thingies, and the ability to just throw RAM at the problem (yay 64-bit OS!) hopefully outweigh the effort of kicking it into shape.
Secondly, there are some compatability issues with the later o/s which aren't in the older ones for some applications which MS have 'promised' to fix and haven't.
Whenever I've had support requests for older apps on a newer OS, I've usually gone the route of upgrading the user to the version which is certified to work with the newer OS (and waiting for that version to be released, in one or 2 cases). I don't know how much effort is required to build Win7 / 8 / 10 compatible apps out of an older XP codebase, however given XP is unsupported I had kind of assumed that everyone would be making the switch anyway.
And, lastly, shove XP on a new machine run a massive database bashing exercise (say a few million SQL queries) then do the same on Win7. Compare the run times for both.
So, assuming you mean to run both on the same hardware and only the OS differs, I'll specify a machine with an i7 5960X (8 core with hyperthreading), 32GB RAM and running 2x 512GB SSDs in a RAID stripe. I've deliberately picked stuff I think XP will struggle to support or use; 16 virtual cores (does the XP HAL allow for 16 simultaneous threads?), more than 4GB of RAM (32-bit XP will also only allocate 2GB to any one user process), and SATA3 drives.
Will XP be quicker in that situation? I suspect not, because I've skewed it to try and hobble XP. However any enthusiast (and most corporate number crunching users) run a 64-bit OS and have >4GB RAM for very similar purposes. We have a few data analysts here that run local database servers (16+GB RAM in those boxes), are you sure that they would see a performance increase if I were to switch them to XP?
This post has been deleted by its author
That was my first thought as well. Given the lack of portability of FLV and M2V compared to other formats (MP4), I can't imagine I've used either since the days of Win98. I'm sure there'll be some l33t troll that will claim this upsets their entire home setup, but surely this is much ado about nothing, in terms of impact.