#!/bin/blog

April 26, 2014

Microsoft und Oracle könnten wir für sowas wie Heartbleed in Regress nehmen

Filed under: Open Source — Tags: , , , , , — martin @ 3:36 pm

heartbleedEin Satz, gesprochen von einem Kunden, der es besser wissen müsste, als das Heartbleed-Debakel bereits seinen Höhepunkt überschritten hatte:

“Microsoft und Oracle könnten wir für sowas wie Heartbleed in Regress nehmen.”

Obwohl der Ausspruch sich für jeden mit mehr als 4 Wochen Erfahrung in der EDV schon von selbst ins richtige Licht setzt, habe ich heute Zeit, etwas darüber zu schreiben.

Warum kann man ein Open-Source-Projekt wie OpenSSL nicht haftbar machen für schwerwiegende Fehler, die für erheblichen personellen Aufwand und Vertrauensverlust bei den Kunden sorgen?

Na, das weiß doch jeder. Das ist ganz einfach nachzulesen in der Lizenz, wie bei jedem Open-Source-Projekt. OpenSSL steht unter der OpenSSL-Lizenz. Dort heißt es:

openssl

Das wäre also erwartungsgemäß geklärt. Jede Gewährleistung wird ausgeschlossen. Ihr kennt das. So ist das eben bei Frickelsoftware von unbezahlten Bastlern aus dem Hobbykeller.

Mit vernünftiger kommerzieller Software müsste man sich sowas nicht antun. Oder vielleicht doch?

RedHat

Bevor wir zu Microsoft und Oracle gehen, schauen wir mal nach dem Linux-Distributor, über den mein Kunde sein OpenSSL-Paket installiert hatte. RedHat hat ein “Enterprise Agreement” oder zu deutsch “Geschäftskundenvertrag”:

redhat

In Punkt 8.1 wird dort die Haftungsobergrenze zunächst auf 45000 Euro festgelegt. In den folgenden Punkten wird dann festgelegt, dass RedHat außer bei Vorsatz für keinerlei Schäden haften wird. Gefolgt wird das ganze vom gezeigten Punkt 10.2, in dem jegliche Gewährleistung ausdrücklich ausgeschlossen wird.

Microsoft

Weiter zu Microsoft. Hier habe ich mir die Lizenbestimmungen für Windows 2012 Server in der “Datacenter Edition” angeschaut:

microsoft

Ähnlich wie Redhat setzt Microsoft in Punkt 23 eine Haftungsobergrenze. Diese erstreckt sich maximal auf den Betrag, der für die Software bezahlt wurde. Eine weitere Haftung für Schäden jeder Art wird ausgeschlossen. In den folgenden Garantiebestimmungen wird zugesichert, dass die Software im wesentlichen wie beschrieben funktionieren und bei Bedarf kostenlos nachgebessert werden wird. Für den Fall, dass sie nicht nachgebessert werden kann, wird die Rückgabe des Kaufpreises zugesagt, selbstverständlich nicht ohne die Bedingung, dass die Software in diesem Fall deinstalliert werden muss. “Dies sind Ihre einzigen Ansprüche.” Es gibt also de-facto überhaupt keine Ansprüche.

Oracle

Für Java gilt das “Oracle Binary Code License Agreement for the Java SE Platform Products and JavaFX”:

oraclejava

Oracle gibt in Punkt 4, ähnlich wie das die meisten Open-Source-Lizenzen tun, überhaupt keine Garantie für Java und setzt in Punkt 5 pro forma eine Haftungsobergrenze von 1000 US-Dollar und schließt vor allem jegliche Haftung aus.

Egal, wieviel gutes man über Oracle sagen will oder nicht, zumindest sind sie hier so nah an den Open-Source-Lizenzen dran, dass ihre Formulierungen klar auf den Punkt kommen.

Fazit

Wir sehen, dass nicht nur lächerlich geringe Haftungshöchstgrenzen zum Geschäft gehören, sondern dass selbstverständlich jede Gewährleistung grundsätzlich ausgeschlossen wird. Das hier ist kein Märchen von Fanatikern aus der Open-Source-Szene, sondern die simple Wahrheit, die jeder einfach selbst nachlesen kann.

February 27, 2009

Packaging OpenSSH on CentOS

Filed under: Security, UNIX & Linux — Tags: , , , , — martin @ 8:29 am

March 30, 2010: It was pointed out to me that Redhat has backported chroot functionality into its OpenSSH 4.3 packages, so these directions may not be neccessary anymore.

My article on chrooted SFTP has turned out to be the most popular article on this blog. What a pity that its “companion article” on building current OpenSSH on CentOS 5 is such a bloody hell of a mess.

Fortunately, reader Simon pointed out a really simple method for building RPMs from current OpenSSH sources in a comment. We had the chance to try this out in a production deployment of chrooted SFTP the other day, and what can I say? It just works(tm)! Thanks a lot, dude! 🙂

# yum install gcc
# yum install openssl-devel
# yum install pam-devel
# yum install rpm-build

It certainly doesn’t hurt to make the GPG check a habit:

# wget http://ftp.bit.nl/mirror/openssh/openssh-5.2p1.tar.gz
# wget http://ftp.bit.nl/mirror/openssh/openssh-5.2p1.tar.gz.asc
# wget -O- http://ftp.bit.nl/mirror/openssh/DJM-GPG-KEY.asc | gpg –-import
# gpg openssh-5.2p1.tar.gz.asc
gpg: Signature made Mon 23 Feb 2009 01:18:28 AM CET using DSA key ID 86FF9C48
gpg: Good signature from "Damien Miller (Personal Key) "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 3981 992A 1523 ABA0 79DB FC66 CE8E CB03 86FF 9C48

Prepare, build and install the RPM. Disable the building of GUI components in the spec file. We don’t need these on a server:

# tar zxvf openssh-5.2p1.tar.gz
# cp openssh-5.2p1/contrib/redhat/openssh.spec /usr/src/redhat/SPECS/
# cp openssh-5.2p1.tar.gz /usr/src/redhat/SOURCES/
# cd /usr/src/redhat/SPECS
# perl -i.bak -pe 's/^(%define no_(gnome|x11)_askpass)\s+0$/$1 1/' openssh.spec
# rpmbuild -bb openssh.spec
# cd /usr/src/redhat/RPMS/`uname -i`
# ls -l
-rw-r--r-- 1 root root 275808 Feb 27 08:08 openssh-5.2p1-1.x86_64.rpm
-rw-r--r-- 1 root root 439875 Feb 27 08:08 openssh-clients-5.2p1-1.x86_64.rpm
-rw-r--r-- 1 root root 277714 Feb 27 08:08 openssh-server-5.2p1-1.x86_64.rpm
# rpm -Uvh openssh*rpm
Preparing... ########################################### [100%]
1:openssh ########################################### [ 33%]
2:openssh-clients ########################################### [ 67%]
3:openssh-server ########################################### [100%]
# service sshd restart

The RPM should install cleanly on CentOS 4. On CentOS 5, after installation, service ssh restart throws a warning that initlog is obsolete. I work around this by keeping a copy of the old /etc/init.d/sshd and restoring it after RPM installation.

Blog at WordPress.com.