As of a few minutes ago, the old weblog on christoph-egger.org is past. I've added redirects for all the entries to the new one at weblog.siccegge.de.if you find any dead links please contact me so I can fix it up.

Note that comments are gone. I'll try to include the already present comments on the new blog some time in the future. Not sure if I will ever add a comment function again (though chronicle seems to have some support for that)

The problem

One problem to solve when doing web authentication has always been one identity provider, so you don't have to remember which username (or email address) you used for that bugtracker you used three years ago or that website. And tie it to one login ideally. Five years ago this problem seemed to be basically solved. There was OpenID and while it may not have been great it worked. You could have your own provider, your institution (university, company, foss project, ..) could have one and you could use your university-provided ID for all university stuff.

Today's state

Looking at the problem again today and the situation seems to have changed. To the worse. A lot. People are actively removing OpenID support. There seemed to be a replacement with, at least, proper design goals: Mozilla's persona. However this seems to be a dead end, no-one (almost) actually supports it.

Then there is what people call OAuth2. However there does not seem to be such a thing as OAuth2 at all, at least not for logging into websites. So for example phabricator supports 12 different OAuth2 systems. That includes Google, Facebook, Twitter, Amazon Github and a whole bunch of other services. Each with a different implementation in the webapp of course. And of course you can not just have your university/company/.. provide an OAuth2 service for you to use -- you would need to write yet another adapter on the (foreign) website to talk to your implementation and your provider.

And the strange thing, people seem to still consider OAuth2 a replacement for OpenID while it does not even provide the core functionality of the older system. Plus there does not seem to be any awareness of that all together.

Other features

Now of course, OpenID is not (and never was) the ultimate answer to the web authentication problem. The most obvious problem being user tracking. Your identity provider will see every website you log into, will see when you log into it and even be able to log into that website with your credentials.

Of course, this problem is fully inherited by OAuth2. And in contrast to OpenID you can no longer run your own provider whom you can fully trust and who already knows about your surfing habits (because it's actually you already). Mozilla's persona might have solved that, they at least intended to. But, again, persona seems quite dead.

TinyTiny-RSS has some nice failure modes. And upstream support forums aren't really helpfull so when you search for your current problem, chances are that there is one mention of it on the web, in the forum, and the only thing happening there is people making fun of the reporter.

Anyway. This installation has seen lots of error messages from the updater in the last several months:

Warning: Fatal error, unknown preferences key: ALLOW_DUPLICATE_POSTS (owner: 3) in /srv/www/tt-rss.faui2k9.de/root/classes/db/prefs.php on line 108

Warning: Fatal error, unknown preferences key: ALLOW_DUPLICATE_POSTS (owner: 3) in /srv/www/tt-rss.faui2k9.de/root/classes/db/prefs.php on line 108

Warning: Fatal error, unknown preferences key: ALLOW_DUPLICATE_POSTS (owner: 3) in /srv/www/tt-rss.faui2k9.de/root/classes/db/prefs.php on line 108

Warning: Fatal error, unknown preferences key: ALLOW_DUPLICATE_POSTS (owner: 3) in /srv/www/tt-rss.faui2k9.de/root/classes/db/prefs.php on line 108
  

And, more recently, the android app stopped working with ERROR:JSON Parse failed.. Turns out both things are related.

First thing I noticed was changing preferences in the web panel stopped working until you use the reset to Defaults option and then changed settings. Plugging wireshark in between showed what was going on (Note: API was displayed as enabled in Preferences/Preferences):

HTTP/1.1 200 OK
Server: nginx/1.8.0
Date: Thu, 06 Aug 2015 11:00:31 GMT
Content-Type: text/json
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.4.43
Content-Language: auto
Set-Cookie: [...]
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Api-Content-Length: 234

ea


Warning:  Fatal error, unknown preferences key: ENABLE_API_ACCESS (owner: 2) in /srv/www/tt-rss.faui2k9.de/root/classes/db/prefs.php on line 108

{"seq":0,"status":1,"content":{"error":"API_DISABLED"}}
0
  

Solution for fixing the Android app (and the logspam on the way as well) seems to be to reset the preferences and then configure tt-rss again (In the webapp, not in the android thing!). Also silences tt-rss update_daemon as well, yay! One last thing: someone out there who wants to explain to me how to fix

Fatal error: Query INSERT INTO ttrss_enclosures
                                                        (content_url, content_type, title, duration, post_id, width, height) VALUES
                                                        ('https://2.gravatar.com/avatar/e6d6ceb7764252af8da058e30cd8cb5f?s=96&d=identicon&r=G', '', '', '', '0', 0, 0) failed: ERROR:  insert or update on table "ttrss_enclosures" violates foreign key constraint "ttrss_enclosures_post_id_fkey"
DETAIL:  Key (post_id)=(0) is not present in table "ttrss_entries". in /srv/www/tt-rss.faui2k9.de/root/classes/db/pgsql.php on line 46

  

Mostly a mental note as I've reinvented this the second time now. If you just quickly want to share some org-mode notes with some non-Emacs-users the built-in HTML export comes handy. However it has one Problem: All source syntax highlighting is derived from your current theme. Which of course is a bad idea if your editor has a dark background (say Emacs.reverseVideo: on). The same if your terminal's background color is dark.

Running Emacs in batch mode and still getting colorful code formatting seems to be an unsolved problem. All that can be found on the Internet suggests adding a dark background to your HTML export (at least to the code blocks). Or maybe use an external style-sheet. Both not exactly the thing if you just want to scp snippets of HTML somewhere to share. However there's a working hack:

#!/usr/bin/make -f

%.html: %.org
	xvfb-run urxvt +rv -e emacs -nw --visit $< --funcall org-html-export-to-html --kill >/dev/null

So use a terminal you can easily force into light-background-mode (like urxvt +rv) so the emacs -nw runs in light-background-mode and wrap the thing in xvfb-run so you can properly run this over ssh (and don't get annoying windows pop up and disappear again when typing make)

Writing this because there seems to be no correct documentation on the relevant google websites and it turns out to be non-trivial. Our goal here is to unsubscribe from a ordinary google group.

Mails from the google group contain the quoted footer:

--
You received this message because you are subscribed to the Google
Groups "FOO" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to FOO+unsubscribe@googlegroups.com.
Visit this group at http://groups.google.com/group/FOO
For more options, visit https://groups.google.com/groups/opt_out.

Seems easy enough, so let's send a Mail to this FOO+unsubscribe address. Back comes a E-Mail:

From: FOO <FOO+unsubconfirm@googlegroups.com>
Subject: Unsubscribe request for FOO [{EJzZjpgFhDHd9seTdRA0}]
To: Christoph Egger <christoph@example.com>
Date: Tue, 18 Feb 2014 18:55:24 +0000 (38 minutes, 53 seconds ago)

 [Leave This Group]

Visit Go

[Start] your own group, [visit] the help center, or [report]
abuse.

So click on the [Leave This Group] link and be done? Unfortunately not. Looking at the link you notice it's called http://groups.google.com/group/FOO/subscribe -- no token and "subscribe"? I actually want to unsubscribe! And indeed, clicking gets an Interface that offers to "Enter the email address to subscribe:" + Captcha. And whatever it does, it -- of course -- doesn't unsubscribe. (My guess is, it would actually work if you had a real google account associated with that email address and were logged in to that account but there's no way of verifying this as already the first condition is false in this case)

Now if you disable HTML completely for the email, a totally different content emerges:

Hello christoph@example.com,

We have received your request to unsubscribe from FOO. In order for us to complete the request, please reply to this email or visit the following confirmation URL:

http://groups.google.com/group/FOO/subscribe

If you have questions related to this or any other Google Group, visit the Help Center at http://groups.google.com/support/.

Thanks,

Google Groups

Still the non-functional link, however it also mentions a different solution: "please reply to this email" which was not present in the HTML mail at all. And it works.

As you might have noticed, the original source of Web-Of-Trust Graph information went offline and probably won't come back. As a result also pathfinders like the one of Henk P. Penning are stuck in February 2012.

As I always found this kind of statistics interesting I've hacked the pks2wot python script that is part of the wotsap package to use normal hkp instead of the pks client and running it against my own sks keyserver which seems to work good enough to do a weekly dump of the current web-of-trust which can be found at http://wot.christoph-egger.org/download/. I'd be happy to hear if this is useful to anyone besides myself.

Migrating a mediawiki instance from the old server to a new box. Of course it does not work (returns an empty 500 Error page). Of course there is no entry in error.log. Of course there is no obvious match of verbose/debug in a grep over the config files. Lovin' it

Looking around old files I have put online ages ago I stumbled upon a Unknown Horizons Code Swarm Video I have created back in September 2009. Feeling more than a bit sad this piece of software died soon after being released. Searching the web for "Code Swarm" still finds lots of old Videos created back then.

From the java point of view

Recently I had to get some Scala Tool working correctly. Unfortunately there are basically no packages in the Debian Archive at all so I had to use maven to install these (or download + install manually). Being a highly paranoid person downloading and executing code from the internet without any cryptographic verification at all one after the other practically drove me nuts. Looking a bit deeper I noticed that some of the software in maven's repository have some signatures next to them -- signed by the author or release manager of this specific project.

Why secure sources matters

With my experience in mind I got some Input from other people. One of the things I was told is that some scala tools just aren't security critical -- they're only installed and used as the current user. In my opinion this is, for my desktop system, totally wrong. The important things on my private Computers are my GPG and SSH keys as well as my private data. For messing with these no super user access is needed at all.

Comparing to the Common Lisp situation

Being a Common Lisp fan of course I noticed basically the same problem for installing Common Lisp libraries. Here the situation in Debian is quite a bit better -- and I'm working in the pkg-common-lisp Team to improve this even more. Common Lisp has some maven-alike tool for downloading and installing dependency trees called quicklisp -- without any cryptographic verification as well. However there's light at the end of this tunnel: There are plans to add GPG verification of the package lists really soon.

Comparing the maven and the quicklisp model

So there are basically two different approaches to be seen here. In maven the software author confirms with his signature the integrity of his software while in quicklisp the distributor confirms all users get the same software that he downloaded. Now the quicklisp author can't and won't check all the software that is downloadable using quicklisp. This won't be doable anyway as there's way to much software or a single person to check.

Now in some kind of perfect World the maven way would be vastly superior as there's a End-To-End verification and verification of the full way the software takes. However there's a big problem: I don't know any of these Authors personally and there's no reason I should just trust any of them.

Now comparing this to the Distribution / quicklisp model. Here I would just have to trust one person or group -- here the quicklisp team -- to benefit from the crypto which might be possible based on karma inside the using community. However here I don't gain the possibility that the software is integer.

However idealized if some of these pieces of software was forged between upstream and the quicklisp team and attacker would also intercept me downloading the software from the same address so I get the source from upstream matching the checksum from quicklisp -- assuming the quicklisp team does indeed know the correct website. Additionally I get the confirmation that all other quicklisp users get the same source (if the quicklisp guys are fine of course) so no-one inside the community complaining is a good indication the software is fine. For this to work there's of course a relevant user-base of the distributor (quicklisp) necessary.

Relevance for Debian

So how do conventional Linux Distributions like Debian fit in here. Ideally we would have maintainers understanding and checking the software and confirming the integrity using their private key or at least know their upstreams and having at least a secured way getting the software from upstream and a trust relationship with them. Of course that's just illusionary thinking of complex and important software (think libreoffice, gcc or firefox for example). Maintainers won't fully understand a lot simpler pieces of software. And loads of upstream projects don't provide a verified way of getting the correct source code though that's a bit better on the real high-impact projects where checksums signed by the Release Manager are more common than in small projects.

A misguided thought at the end

As I'm a heavy emacs user I like to have snapshots from current emacs development available. Fortunately binary packages with this are available from a Debian guy I tend to trust who is also involved upstream so adding the key from his repository to the keyring apt trusts. Now my first thoughts were along the lines "It would be really nice if I could pin that key to only the emacs snapshot packages" so this guy can't just put libc packages in his repository and my apt would trust them. Now thinking of it again a bogus upload of the emacs snapshot package could just as well put some binary or library on the system at some place in front of the real on in the system path which would be rather similar bad.

b

Open Game Art is a newly started site for exchanging free Artwork. While one can easily get the impression that there are loads of such sites around, Open Game Art is one of the very few that actually is done right.

As a Member of the Debian Games Team and the Unknown Horizons Project I was way too often in the need for good artwork searching around the web. I've also already reported once about my trouble.

There are quite some sites like Free Sounds around offering free artwork -- but only free as in beer as the saying goes, not as in speech which of course is really unhelpfull for FOSS projects. And even most of the sites that have free content often only tell you the license on some special pice of arts details page.

Open Game Art is quite different from that. All the license you may choose as a contributor are free (both in Debian and in FSF terms) and the license is available through a search filter so you can find stuff that fits you project's licensing policy. This list, and that's another thing I really like about that site, is the availability of choice among common licenses including, next to the copyleft class of licenses a fair share of more liberal licenses like my personal favourite, the zlib License.

And because such a site is just as good as it's amount and quality of data I've started sharing some recordings. I'm currently really new to audio recording so I guess it'll take some time for me to become really good. I'm considering putting some of my experiences and stuff I've learned here.

Für alle, denen die Stasi 2.0 Tasen und Zensur-Ursula Shirts zu langweilig sind gibt's jetzt das neue, ultimative Gadget. Nachdem ich darauf verwiesen wurde muss ich das natürlich gleich weitergeben!

Passend dazu, aber leider nicht verfügbar ist dann folgendes Produkt der Telekom

Um Unknown Horizons weiter zu verbreiten habe ich jetzt ein ohloh.net Projekt angelegt und gleich noch einen Account für mich angelegt.

Ohloh lobt dann auch gleich das Projekt für ein aktives, großes Entwicklerteam und gute Dokumentation, kann also gar nicht so schlecht sein.

Ganz überrascht bin ich auch, wie weit ich es mit meinen bisherigen Projekten bereits geschafft habe ...

TODO: Einträge über NM und Debconf

Nachdem der Unknopwn Horizons Server in letzter Zeit immer wieder Probleme gezeigt hat, ist das Projekt wenigstens vorübergehend hier einquartiert worden.

Das heißt natürlich, dass dieser Server deutlich höhere Lasten bewältigen muss (Unknown Horizons hat ungefär so viele Besucher, wie die andere Ladung Domains hier). Sieht aber aktuell so aus, als ob wir das bewältigen können.

Markdown ist eine wunderbare Möglichkeit, gedanken, technische Vorschläge oder ähnliches schnell in ein halbwegs ordentlich darstellbares Format zu bringen. Das ganze lässt sich statisch in XHTML umwandeln oder per PanDOC in eine vielzahl anderer Formate. Wenn man will, kann man das auch dynamisch den Webserver erledigen lassen.

Genau das geschieht schon seit einiger Zeit auf meinem Scratchboard http://mdn.christoph-egger.org/. Das schöne daran ist die Verwaltung über Versionskontrolle (die Markdown Files werden einfach per hg push auf den Server übertragen und sind dann dort abrufbar.

Aus lauter Langeweile habe ich jetzt den Verwendeten Python Script von mod_python auf mod_wsgi portiert und aufgeräumt, sodass das ganze jetzt veröffentlicht werden kann: WSGI Script, Beispieltemplate

Viel Spass!

Selbst wer meinen Weblog näher verfolgt, mag es nicht gemerkt haben. Die Kommentarfunktion wird in letzter Zeit immer mehr von Spammern verwendet um ihre URLs anzubringen, während sich ernsthafte Kommentare noch selten blicken lassen.

Allerdings werde ich deshalb die Kommentarfunktion jetzt nicht einfach abschalten sondern die Kommentare ersteinmal via BlogSPAM filtern lassen. Das erfordert dann auch, dass ich endlich die Datenschutz Seite schreibe (immerhin gehen die Daten ja dann an einen Webservice).

Da die Kommentare hier auf Djangos contrib.comment basieren, bietet es sich an, die Integration in einer Weise zu erstellen, die diese allgemein verwendbar macht.

Allerdings habe ich bei meiner Recherce festgestellt, dass dies in der (hoffentlich) bald verfügbaren Version 1.1 deutlich leichter sein wird, sodass ich die allgemein Nutzbare Version wohl bis dahin verschieben werde.

Freite Texturen finden kann ja nicht so schwer sein oder? Blender Nation hat ja regelmäßig neue Blogeinträge mit neuen Quellen für freie Texturen, es gibt hunderte Seiten online, ...

Wirklich freie Texturen (frei wie in DFSG zu finden ist aber in wirklichkeit viel schwerer. Denn: Was mache ich mit Texturen, die frei für kommerzielle und nicht-kommerzielle Verwendung sind (ohne weitere Erklärung)? Viele texturseiten bieten die Textur an, schließen aber Weitergabe (mit außnahme von Druckwerken) aus.

Sollte tatsächlich ein OpenSource Künstler auf diese Seite stoßen, bitte gebt uns eure Links ;)

Server konfigurieren ist keine einfache Angelegenheit. Soweit klar. Allerdings kann es doch immer wieder überraschend sein wie schwer es manchmal sein kann.

Dieser Server lief lange Zeit mit SuSE 10.2 -- verhältnismäßig alt, es ist schwer irgendetwas neues zu installieren und die alte Administrationssoftware für unsere Webkunden war auch nicht das wahre. Ein Update kam nicht in Frage, niemand im Team hat die Erfahrung mit SuSE im generellen und die Konfiguration war vom Anbieter voreingestellt.

Da bald Debian Lenny released wird und immerhin ich einige Erfahrung mit Debian gesammelt habe stand dann fest, dass dieser Server mit eben jenem System betrieben werden wird.

Am 22.12. war es dann soweit. Ich mobil mit meinem Notebook beim zweiten Admin eingetroffen, die letzten Backups abgeschlossen, reset beantragt. Um 10 Uhr der Server dann mit etch einsatzbereit (Lenny gibt's nicht im Angebot aber ein update eines frischen Etch ist ja kein Problem).

Natürlich läuft nincht alles so, wie es soll. In diesem Fall der MTA, exim4. Wärend die Grundlegende Konfiguration auf den Einstellungen von SysCP eigentlich ganz gut funktionieren, ist beim MTA nacharbeit angesagt.

Für einen neuen Anlauf ein rm -rf /etc/exim4 + neuinstallation des Paketes war dann irgendwie keine gute Idee, sodass nach 14 Stunden Arbeit der Mailserver immer noch nicht lief.

Immerhin läuft jetzt alles, wie es soll, und das neue System war die Arbeit sicherlich wert!

Der normale Weg, neue Änderungen einer Website auf den Production-Server zu übertragen führt wohl über (S)FTP oder SCP. Jedenfalls war das bei mir bis vor kurzem so.

Mit der Zeit habe ich dann angefangen, meine Arbeiten am Website Code per Versionsverwaltung zu dokumentieren. Und als dann plötzlich eine Website nicht nur von mir erstellt wurde gibg das Repos natürlich auf den Server. Da lag es dann natürlich nahe, die Serverversion einfach zu «hg clone»n.

Tja, das hat sich irgendwie verselbstständigt und eine der ersten Aktionen bei einem neuen Webprojekt ist ein HG Repos auf dem Server. Und ich muss sagen, das Ergebniss ist sehr angenehm. Geändertes wird automatisch übertragen, gleiches nicht ohne dass man sich darum kümmert