Language Selection

English French German Italian Portuguese Spanish

Red Hat's security issue

Filed under
Linux
Security

Last month, Red Hat issued a security bulletin. Not all that went on is clear, but it seems that the servers used to develop and distribute Fedora and Red Hat were accessed by a person with criminal intent. The perpetrator created trap-door versions of the SSH (remote login program) packages that would compromise the security of Red Hat's customers, and signed them with Fedora's cryptographic key. These packages were made available via Fedora archive and they may (I've not proof) have reached some number of Fedora customers. Obviously they were intended to be widely distributed and to compromise the security of all Red Hat and Fedora systems. Red Hat issued a script that users can run to detect the compromised packages.

But there are continuing problems with Red Hat's handling of the situation.

Best practice of computer security professionals is to fully disclose what went wrong and how you're preventing it from happening again. This tells customer security officers what they need to audit the security practices of their vendor, and to secure their own facilities. The worst practice, for which Microsoft is the prototype, is to stay mum and not admit any problems.

Red Hat's being mum. Fedora's being forced to be mum, because their own board has not been given full details and of course they are mostly controlled by Red Hat.

Full Post




Also:

Security breaches bring out the proprietary attitude in all of us. When security is breached we instinctively hide the details, and build a metaphorical police line around it, telling onlookers to move along.

The security attitude runs counter to the open source attitude. Open source demands that bugs be seen and lessons shared. The security attitude fears this release of information because the evil doers might get it.

With that in mind let’s move to the umbrage of Bruce Byfield during what Slashdot termed last month’s Fedora-Red Hat crisis.

Fedora and our security attitude


More in Tux Machines

Games and Emulation

Linux Devices

Koozali SME Server 8.2 Reaches End of Life on March 31, Upgrade to Koozali SME 9

Koozali Foundation, through Terry Fage, announced the availability of a final set of updates for the Koozali SME Server 8.2 operating system, which will reach end of life this week. Patching some of the reported bugs, the new packages released today for Koozali SME Server 8.2 are e-smith-ibays-2.2.0-16.el5.sme.noarch.rpm, e-smith-manager-2.2.0-14.el5.sme.noarch.rpm, smeserver-clamav-2.2.0-15.el5.sme.noarch.rpm, smeserver-locale-*-2.2.0-56.el5.sme.noarch.rpm, and smeserver-yum-2.2.0-26.el5.sme.noarch.rpm. Read more

Development News

  • GCC for New Contributors
    I’m a relative newcomer to GCC, so I thought it was worth documenting some of the hurdles I ran into when I started working on GCC, to try to make it easier for others to start hacking on GCC. Hence this guide.
  • #1: Easy Package Registration
    Last month, Brian Ripley announced on r-devel that registration of routines would now be tested for by R CMD check in r-devel (which by next month will become R 3.4.0). A NOTE will be issued now, this will presumably turn into a WARNING at some point. Writing R Extensions has an updated introduction) of the topic.
  • Emacs as C IDE and JHBuild
    Although Builder clearly is The Future as GNOME IDE, I still all my coding in Emacs, mostly because I have been using it for such a long time that my brain is to all the shortcuts and workflows. But Emacs can be a good IDE too. The most obvious everyday features that I want from an IDE are good source code navigation and active assistance while editing. In the first category are tasks like jumping to symbol's definition, find all callers of a function and such things. For editing, auto-completion, immediate warnings and error reporting, semantic-aware re-factoring are a must. Specifically for GNOME related development, I need all this to also work with JHBuild.