Posts on tag: source

Bei Propublica ist ein Artikel über Werner Koch, dem GNUPG Entwickler erschienen, weil er pleite ist. Dem Artikel ist zu entnehmen, dass der Mann offensichtlich keinen Job hat und nur von den GNUPG Spenden lebt, seine Frau hat auch keine Arbeit.

Ich muss Fefe vollumfänglich Recht geben: mein Mitleid hält sich in Grenzen. Was mich am meisten daran stört ist diese unsägliche Weltanschauung, dass man für so etwas bezahlt werden müsse. Das ist Unsinn. Warum sollte der Mann für GNUPG bezahlt werden? Er hat es als Opensource und kostenlos veröffentlicht und damit hat sich Thema Bezahlung erledigt. Ja, zufälligerweise wird die Software von Hunderttausenden Menschen weltweit verwendet. Aber das ändert nichts an der Tatsache, dass es Opensource ist. Daraus ergibt sich kein "Recht auf Bezahlung".

Ich mache das so, wie Fefe es auch beschreibt: ich habe einen Job, von dem ich gut leben kann. Opensource Entwicklung mache ich in meiner Freizeit und ich WILL dafür kein Geld haben. Was viele nämlich nicht sehen, ist dass ich als Entwickler nämlich derjenige bin, der bezahlt. Ich benutze eine Menge Opensource: FreeBSD, OpenSSH, OpenSSL, Emacs, Bash, GCC, Postfix, Apache, PostgreSQL, Django, Perl, Python, FFmpeg, Xmonad, Firefox und so weiter und so fort. In jedem einzelnen dieser Projekte stecken zum Teil zig Tausende Manntage Entwicklerarbeit. Musste ich dafür was bezahlen? Nein. Aber indem ich ebenfalls Opensource Software veröffentliche, gebe ich etwas zurück. Ich leiste sozusagen meinen Beitrag. Der mag angesichts der erwähnten Giganten bescheiden sein, ja. Aber ich tue das ja primär, weil es mir Spass macht.

Das ist bei Werner Koch auch nicht anders. Er nutzt ebenfalls Opensource Software, sonst könnte er gar nicht an GNUPG arbeiten. Mit seinem Projekt leistet er seinen Beitrag, die Welt zu einem besseren Ort zu machen. Dafür gebührt ihm Dank und Ehre, ohne Zweifel. Aber Geld? Nein, auf keinen Fall.

Hinzu kommt, dass Koch schon diverse Male von hoher Seite unterstützt wurde, unter anderem von der Bundesregierung. Welcher Opensourcler kann das schon von sich behaupten. Aber weil er keinen Job hat, reicht das natürlich nicht. Dass Propublica ihn bei dem Gejammer unterstützt ist eher traurig. Laut dem Artikel hat er inzwischen diverse Sponsoren gefunden: Facebook (von denen würde ich keinen Cent annehmen) und Stripe. Bemerkenswerte Konversation mit Stripe:

Kenn White:
@stripe @gnupg no strings attached? (serious question)

Stripe:
@kennwhite @gnupg Nope.

Klar.

Auf ein Detail in dem Artikel möchte ich noch eingehen, das den zugrundeliegenden Denkfehler sehr schön veranschaulicht:

The fact that so much of the Internet's security software is underfunded is becoming increasingly problematic. Last year, in the wake of the Heartbleed bug, I wrote that while the U.S. spends more than $50 billion per year on spying and intelligence, pennies go to Internet security.

Auch in den Kommentaren zum Artikel gibt es viele Leute, die sich darüber beklagen, dass die US Regierung kaum Geld für Opensource Crypto ausgibt. Liebe Leute, Software wie GNUPG, OpenSSL oder OpenSSH hat vor allem einen Zweck: uns vor der Regierung zu schützen. Wieso sollten wir also von irgendeiner Regierung Geld dafür verlangen, damit wir vor ihr geschützt werden können? Das ist doch absurd.

Opensource ist eine Idee, kein Geschäftsmodell. Die Idee ist, mit den Mitteln, die man hat, zu versuchen die Welt zu verbessern. Seit wann müssen Leute, die die Welt verbessern, dafür bezahlt werden? Wenn man das will, muss man in die Wirtschaft gehen, ein Unternehmen gründen und seine Software verkaufen. Oder eben den Schritt wagen, seine Zeit, Nerven und Resourcen zu opfern für eine grössere Sache. Wovon man während dieser Zeit lebt, ist jedoch eine ganz andere Frage, mit der die Nutzer der Software nichts zu schaffen haben. Ja, die Welt ist hart und gemein. Ja, es wäre schöner, wenn man einfach machen könnte, was man gerne mag und irgendwie automatisch davon leben könnte. Aber so ist die Welt nicht und nicht nur Werner Koch ist davon betroffen, sondern wir alle.

Das heisst: es ist mir scheissegal, wovon Werner Koch's Mittagessen bezahlt wird. Das ist sein eigenes Problem, um das er sich verdammt nochmal selber kümmern muss. Um mein Mittagessen muss ich mich auch selber kümmern. Wie kann man sich nur auf diese Weise selbst erniedrigen, unmöglich.

Update 2015-02-08:

Es gibt noch einen Nachtrag bei Fefe::

Und dann schmeißt Werner Koch die geschenkten $100k den Patch weg und ich pflege 9 Jahre lang meinen Patch parallel weiter. Und Werner Koch winselt dann herum, dass er nicht versteht, wieso ihm keiner Geld nachwirft.

Das liegt daran, dass Werner Koch das Problem ist, nicht die Lösung. Werner Koch macht mit dem Code keine Wartung, eher eine Geiselnahme. Denn wer will schon gnupg forken. Wir kriegen ja schon ohne Fork die Leute nicht in signifikanter Größenordnung dazu, das zu benutzen. Das wäre noch übler, wenn es da auch noch Marktfragmentierung gäbe. Deshalb hat noch niemand gnupg geforkt. Nötig gewesen wäre es seit Jahren. Ich persönlich hoffe seit Jahren, dass Werner endlich hinwirft, und dann jemand die Wartung übernehmen kann, der auch ein Interesse daran hat, daraus ein ordentliches Projekt zu machen. Aber das wird ja jetzt nicht mehr stattfinden. Jetzt wo nicht mehr nur sein Ego sondern auch sein Lebensunterhalt direkt davon abhängt, dass er weiterhin Diktator von gnupg bleibt.
[..]
Ich sollte der Sicherheit halber dazu sagen, dass das nicht bloß meine Eintschätzung ist, dass Werner Koch das Problem ist, sondern ziemlich breiter Konsens. Ich habe diverse Mails von anderen Leuten gekriegt, die mit Werner vergeblich zu kooperieren versucht haben.

Finally I made a new release of Pretty Curved Privacy: 0.2.4. There are no new features,but lots of fixes and enhancements. Also there's a python API available as well (enable with --enable-python-binding).

Netanel Rubin held a talk about an alleged 20 year old vulnerability in perl named "The Perl Jam: Exploiting a 20 Year-old Vulnerability" at 31C3 [PDF].

Basically he claims that this is a problem:

my @a = qw(8 foo 666);
my %h = (foo => 100,
	 bar => 333,
	 san => @a);
print Dumper(\%h);

$VAR1 = {
          'san' => 8,
          'bar' => 333,
          'foo' => 666
        };

As you can see, the array @a is assigned as a value to the key 'san' of the hash %h. But since it's not assigned as a array reference, the array dissolves into the hash and its values overwrite the keys 'foo' and 'san'.

The "vulnerability" Netanel found, is in the CGI module. The method 'param()' of this module returns an array if a CGI parameter occurs more than once. If the output of that method is being used unchecked in a hash assignment as shown above, then it is possible to overwrite certain values of that hash. This leaded for example to the vulnerability CVE-2014-1572 in Bugzilla.

Netanel's conclusion: perl is broken, horrible, hazardous, bizarre and should not be used anymore.

Wow.

He is wrong on multiple levels. Arrays dissolving into hashes is not a bug and not bad, but intended behavior and very well documented. In fact, I use it alot. I even love it! If you take a look into the function new() of about 80% of all perl modules on CPAN, you'll find, that they support hash arguments, and feed @_ into a hash. Pretty standard for perl people. Others might find it ugly or weird, but hey, it's a free world (mostly), choose another language if you don't like the concept.

Then Netanel has been asked if he knows about references and in response complained about using a backslash in order to assign a reference to a hash (or array) to a variable. He called it "escaping", but that's utter nonsense. \%hash ist pure perl syntax, not escaping.

The talk sounds funny in the first place, but is unsubstancial. Yes there are flaws in perl code which uses CGI.pm in the wrong way. But that's not a perl problem, it's a CGI.pm problem. And it's solved since a long time. Modern web stuff written in perl uses Dancer, Mojolicious or Catalyst and not CGI.pm.

Ich bin gerade auf Dienstreise, die Internetanbindung ist dürftig und ich habe Zeit. Daher überarbeite ich gerade pcp mit Valgrind.

Man lässt ein Programm mit Valgrind laufen und es zeigt einem nachher Memoryleaks, Buffer Overflows und vieles mehr an. Da ich in letzter Zeit eine Menge am Code hinzugefügt habe, haben sich da leider einige solcher Probleme angesammelt. Und die arbeite ich momentan systematisch ab.

Eigentlich ist die Ausgabe von Valgrind erschütternd und deprimierend. Und doch hilft es mir enorm, dutzende subtiler und fieser Bugs zu finden und zu fixen. Im aktuellen Durchlauf (Import eines Secret Keys, der fehlschlägt) hatte ich am Anfang seitenweise Leaks. Schlimm. Jetzt bin ich durch und das hier ist die Ausgabe, wenn Valgrind happy ist:

scip@io: % valgrind --leak-check=full --show-reachable=yes src/pcp1 \
           -V tests/va -K -I tests/key-alicia-sec -x a
==35083== Memcheck, a memory error detector
==35083== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==35083== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==35083== Command: src/pcp1 -V tests/va -K -I tests/key-alicia-sec -x a
==35083== 
Secretkey sanity check: there already exists a key with the id 0x437A76EDE40D67EC
==35083== 
==35083== HEAP SUMMARY:
==35083==     in use at exit: 0 bytes in 0 blocks
==35083==   total heap usage: 95 allocs, 95 frees, 146,878 bytes allocated
==35083== 
==35083== All heap blocks were freed -- no leaks are possible
==35083== 
==35083== For counts of detected and suppressed errors, rerun with: -v
==35083== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Was soll ich sagen? Valgrind ist echt geil. Gar nicht auszudenken, was ich täte, wenn es das nicht gäbe.

If you're condemned to use sudo for systems administration on a daily basis you know the problem: working all the time with sudo is annoying. It's ok if you've got to enter sudo only here and there. But on some systems almost everything is only reachable via sudo.

At least it annoyed me, so I put the nightmare to an end. Autosudo consists of a couple of bash functions which - once enabled - learn each entered sudo command and create a temporary wrapper function for it so that you can leave "sudo" the next time you use the command. An example session:

[16.Jul 09:48:22] --- [~] ---
me@machine: % autosudo ena
[16.Jul 09:49:14] — [~][autosudo]  —
me@machine: % sudo less /var/log/splunk/ticket.log
[..]
+++ autosudo: added “less” to auto sudo commands +++
[16.Jul 09:50:32] — [~][autosudo+1]  —
me@machine: % less /var/log/splunk/ticket.log
[16.Jul 09:50:50] — [~][autosudo+1]  —
me@machine: % autosudo sh
+++ auto sudo enabled for:  less +++
[16.Jul 09:50:52] — [~][autosudo+1]  —
me@machine: % autosudo dis
+++ disabling auto sudo commands +++
disabling less
[16.Jul 09:50:58] — [~] —
me@machine: % less /var/log/splunk/ticket.log
/var/log/splunk/ticket.log: Permission denied

What happens here? First, I enabled the feat with "autosudo ena". Next I called a sudo command "sudo less". Once completed the autosudo facility adds "less" as an autosudo wrapper and notifies me about it. From now on I can just use "less" instead of "sudo less" while achieving the same functionality. Finally I let it display a list of currently autosudo'ed commands ("autosudo sh") and then I disable it with "autosudo dis". Note that the plain "less" call in the end doesn't work anymore since after disabling autosudo "less" was not sudo wrapped anymore. Easy enough.

Here's the code:

autosudo () {
    # enable auto sudo
    case $1 in
        e|ena|enable)
            export AUTOSUDO=1
            export SUDOCMD=`type -p sudo`
            alias sudo=sudoexec
            ;;
        d|dis|disable)
            unset AUTOSUDO
            unalias sudo
            echo "+++ disabling auto sudo commands +++"
            for cmd in $AUTOSUDOCMDS; do
                echo "    disabling $cmd"
                unset $cmd
            done
            ;;
        s|sh|show|status)
            if test -n "$AUTOSUDO"; then
                echo "+++ auto sudo enabled for: $AUTOSUDOCMDS +++"
            else
                echo "+++ auto sudo disabled +++"
            fi
            ;;
        *)
            echo "Usage: autosudo <enable|disable|show>"
            ;;
        esac
}
sudoexec () {
# determine sudo cmd and if successfull, alias it away
if test -n “$AUTOSUDO”; then
if $SUDOCMD $; then
cmd=echo "$*" | awk '{ print $1}'
if echo “$cmd” | egrep -v “^-” > /dev/null 2>&1; then
lambda="/tmp/.lambda.bash.$$"
cmd=basename $cmd
cat <<EOF > $lambda
unalias $cmd
function        $cmd () {
$SUDOCMD $cmd $
}
EOF
export LAMBDA=$lambda
AUTOSUDOCMDS="$AUTOSUDOCMDS $cmd"
echo
echo “+++ autosudo: added "$cmd" to auto sudo commands +++”
echo
fi
fi
fi
}
cleanlambda() {
if test -n “$LAMBDA”; then
rm -f $LAMBDA
LAMBDA=""
unset LAMBDA
fi
}
PROMPT_COMMAND=“if test -n "$LAMBDA"; then source $LAMBDA; cleanlambda; fi; PS1=’[\033]0;\u@$host:\w\007]
$(DATE) — [\w]$(SHAUTOSUDO)$(JOBS) —
\u@$host: $CURSOR ‘”

Some words about it: If you call "autosudo ena", then "sudo" will be made an alias to "sudoexec", one of the functions above. "sudoexec" then executes the sudo command as usual and if it returns success it extracts the command and puts it into a wrapper function which it writes into a temporary file. The filename gets exported into the variable $LAMBDA. The most important part is the extension to $PROMPT_COMMAND. I precede it with a little bit of code which looks for an environment variable $LAMBDA. If set it assumes it is a file and sources it. This makes the wrapper function available to the current bash environment.