Language Selection

English French German Italian Portuguese Spanish

Opera on Handling Security

Filed under
Security

Recently, some of our users have asked why we chose to disclose a potential security issue only after the release of Opera 9.10. Let me try to give a short overview on how security issues get reported and disclosed - and not only at Opera, but in most applications: it might help some people to understand how this works.

When somebody discovers a vulnerability in an application, they should report it to the vendor. It can happen that the reporters give a deadline by when they want to make full disclosure of the vulnerability, but usually the reporter and the vendor work out a disclosure date that makes both happy. If the exploit is not clear, both work on details and a PoC (proof of concept). When a fix has been made and a public release is available, both the reporter and the vendor publish an advisory. The vendor usually credits the reporter in the advisory for the discovery of the vulnerability.

It is important that both parties do respect each other: if a fix is included also in development snapshot builds that reach a public audience (like the weekly builds on this blog), fixes for the vulnerability are not announced: this is a form of respect both for the reporter and for all the users that only upgrade to stable releases. Making the vulnerability public knowledge before a stable version fixes the issue would leave lots of users vulnerable. Serious reporters do not announce vulnerabilities before vendors have a fix in public builds - and vendors do not announce vulnerabilities before the reporters makes their discovery public, in order to properly credit them.

Full Story.

More in Tux Machines

today's leftovers

Leftovers: Gaming

Leftovers: KDE Software

  • Wayland & Other Tasks Being Worked On For KDE Plasma 5.4
    Now that KDE Plasma 5.3 was released this week, KDE developers are starting to plan out and work on the new material intended for KDE Plasma 5.4.
  • Interview with Wolthera
    My name is Wolthera, I am 25, studied Game Design and currently studying Humanities, because I want to become a better game designer, and I hope to make games in the future as a job. I also draw comics, though nothing has been published yet. [...] After I played a lot with MyPaint, I heard from people that Krita 2.4 was the shit. When I went to the website at the time (which is the one before the one before the current) it just looked alien and strange, and worse: there was no Windows version, so I couldn’t even try it out. So I spent a few more years having fun with MyPaint alone, but eventually I got tired of its brush engine and wanted to try something more rough. When I checked Krita again, it had two things: a new, considerably more coherent website (the one before this one) and a Windows build. Around that time it was still super unstable and it didn’t work with my tablet. But MyPaint also had tablet problems, so I had no qualms about dual booting to Linux and trying it out there.
  • GSoC with KDE
    So, my project is titled: Better Tooling for Baloo. Let me begin by explaining what Baloo is. According to its wiki page it is "Baloo is a metadata and search framework by KDE." What exactly does it mean? Baloo is responsible for providing full text search capabilities to KDE applications. It doesn't end there it also provides searching on basis of metadata of various types of files. To acomplish this it indexes file contents and metadata using various plugins ,called extractors, to handle different types of files. It then exposes the data it has indexed with the help of various API's. So thats a very high level view of how it works. Now, my project, as the title states will provide better tools for Baloo. These tools will mainly be: