Home | Blog | Software | Reviews and Features | Forum | Help | Donate | About us
topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • September 27, 2016, 08:53:19 AM
  • Proudly celebrating 10 years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: Fixing OpenSSL security vulnerabilities by forking it  (Read 960 times)

40hz

  • Supporting Member
  • Joined in 2007
  • **
  • Posts: 11,763
    • View Profile
    • Donate to Member
Fixing OpenSSL security vulnerabilities by forking it
« on: April 26, 2014, 11:12:48 AM »
This in from The Register. OpenBSD steps up to the plate:


Quote
OpenBSD founder wants to bin buggy OpenSSL library, launches fork
One Heartbleed vuln was too many for Theo de Raadt
By Neil McAllister, 22 Apr 2014


In the wake of the Heartbleed bug fiasco, members of the OpenBSD project have forked the popular OpenSSL library with the aim of creating a new version that they say will be more trustworthy.

Even though OpenSSL is open source software, for a full two years its entire development community managed to overlook the crucial bug that eventually triggered a web-wide panic.

The library has since been patched to address the flaw, but fallout from the crisis is still being felt, and the programmer whose error caused all the ruckus says there just aren't enough people scrutinizing the OpenSSL code to spot difficult-to-find bugs.

The LibreSSL project wants to change that. A fork of OpenSSL, LibreSSL was created by members of the highly security-conscious OpenBSD operating system community – including its cantankerous founder Theo de Raadt, who has publicly criticized OpenSSL as a project "not developed by a responsible team."

The group's goal is to provide a drop-in replacement for OpenSSL that has been substantially rewritten and audited for potential security vulnerabilities. The API won't change, they say, but much of the current code will. <more>

(Full article may be found here.)

 8)