Es gibt nach Monaten mal wieder ein MiniUpdate für MediaWiki, genauer gesagt ein SecurityUpdate. Das Problem mit den extern einbinbaren Bildern via CSS ist tatsächlich nicht ganz unkritisch, denn es gibt immernoch Browser da draussen, die auf Dateien, die wie ein Bild aussehen aber Schadcode enthalten hereinfallen. Würde jemand im Wiki per CSS ein solches Schadcode-Bild fremdeinbinden, so würde das scheinbar durch das Wiki passieren.
Das Problem mit externen IP-Trackern ist dagegen “nur” ein Privacyproblem, allerdings muss man sich vergegenwärtigen, dass fast alle “legalen” Systeme draußen im Feld Techniken wie Spy-Pixel o.ä. einsetzen, um Benutzerverhalten zu tracken.

Das zweite Problem mit privaten Bildern dürfte in den meisten Standardinstallationen keine große Rolle spielen (img_auth.php, thumb.php). Man sollte grundsätzlich Daten, die keinen externen etwas angehen hinter einem *richtigen* Passwortschutz verstecken, d.h. http-Authentifiziert und nicht rein Formular/Cookie-Authentifiziert.

Der Unterschied besteht darin, dass bei ersterem der Webserver über den Zugriff auf eine Datei entscheidet *bevor* Code ausgeführt wird, d.h. auch beim direkten Zugriff auf Bilder etc. Bei Cookie-Authentifizierung entscheidet das aufgerufene Programm selbst (eigene Prüflogik, Sessioncookie etc). Das Problem dabei ist, dass eben nur Zugriffe auf Programmcode diese Sperre enthalten können, Zugriffe direkt auf Bilder jedoch sind idR unkontrolliert.

Um das Problem zu beheben, *kann* man die Auslieferung von Bildern ebenfalls durch ein PHP-Script duchleiten, welches dann vor der Auslieferung der Bilddaten prüft: “Darf der das?”. Und scheinbar bei einem dieser Mechanismen gibt es wohl eine Sicherheitslücke.

Ich werde 1.15.2 in den divesen Wikis einspielen soweit ich da entsprechend inder Rolle bin das zu entscheiden und empfehle allen anderen ebenfalls auf 1.15.2 zu gehen, insbesondere wenn schon eine etwas angegraute Version läuft.

Viele Grüße
Raphael

Tim Starling <tstarling@wikimedia.org> schreibt: [MediaWiki-announce] MediaWiki security update: 1.15.2:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is a security and bugfix release of MediaWiki 1.15.2.

Two security issues were discovered:

A CSS validation issue was discovered which allows editors to display
external images in wiki pages. This is a privacy concern on public
wikis, since a malicious user may link to an image on a server they
control, which would allow that attacker to gather IP addresses and
other information from users of the public wiki. All sites running
publicly-editable MediaWiki installations are advised to upgrade. All
versions of MediaWiki (prior to this one) are affected.

A data leakage vulnerability was discovered in thumb.php which affects
wikis which restrict access to private files using img_auth.php, or
some similar scheme. All versions of MediaWiki since 1.5 are affected.

Deleting thumb.php is a suitable workaround for private wikis which do
not use $wgThumbnailScriptPath or $wgLocalRepo['thumbScriptUrl'].
Alternatively, you can upgrade to MediaWiki 1.15.2 or backport the
patch below to whatever version of MediaWiki you are using.

MediaWiki is not compatible with PHP 5.3.1 due to a bug in that
release, which is fixed in PHP 5.3.2. This release of MediaWiki will
refuse to upgrade if an affected version of PHP is present. Note that
local or distribution-specific backports of the PHP bug fix are
supported. See http://bugs.php.net/50394 for details.

Full release notes:

http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_15_2/phase3/RELEASE-NOTES

**********************************************************************
Download:

http://download.wikimedia.org/mediawiki/1.15/mediawiki-1.15.2.tar.gz

Patch to previous version (1.15.1), without interface text:

http://download.wikimedia.org/mediawiki/1.15/mediawiki-1.15.2.patch.gz

Interface text changes:

http://download.wikimedia.org/mediawiki/1.15/mediawiki-i18n-1.15.2.patch.gz

GPG signatures:

http://download.wikimedia.org/mediawiki/1.15/mediawiki-1.15.2.tar.gz.sig

http://download.wikimedia.org/mediawiki/1.15/mediawiki-1.15.2.patch.gz.sig

http://download.wikimedia.org/mediawiki/1.15/mediawiki-i18n-1.15.2.patch.gz.sig

Public keys:

https://secure.wikimedia.org/keys.html

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuVjQcACgkQgkA+Wfn4zXkYqACfRXMeQdbHT2ep+xEbkgPpz+BA
5pgAoMhuJQ6UJrW8Wdh/Ji9VA/h8MRH0
=CDe6
-----END PGP SIGNATURE-----

Have fun!

Raphael

Zuvor gab es eine Diskussion darum, ob man einen Verein (“auf der Grünen Wiese”) neu gründen will oder NoName e.V. als bestehenden Verein (und wie ich heute gelernt habe: NoName e.V. <> CCC-HD … auch wenn beim CCC auf www.noname-ev.de als ChaosTreff Heidelberg verlinkt) als RaumZeitLabor e.V. (oder unter welchem Namen auch immer) umwidmen will. Davon abgesehen ob die AG Verein das gut findet oder nicht muss das in erster Linie die Mitgliederversammlung des  NoName e.V. beschließen, ob sie das will und durch vermutlich erhebliche Änderungen an ihrer Satzung dieses dann auch in die Tat umsetzt.

Ich persönlich gehöre dabei zu den Bedenkenträgern und denjenigen, die dabei ein gewisses Unwohlsein verspüren. Ich denke es wird für alle besser, wenn wir einen “altlasten-freien” Verein gründen für dieses Projekt, auch wenn es kurzfristig scheinbar mehr Aufwand bedeutet.

Gute Nacht!

Ein Stimmungsbild hat ergeben, dass die meisten wohl einen offenen und gemeinnützig anerkannten Trägerverein für das Projekt haben wollen. Ob und in welcher Konstellation man dann noch eine gGmbH oder soetwas drumherum etabliert ist noch nicht entschieden und wäre ggf. zu einem späteren Zeitpunkt noch zu ergänzen. Die von mir favorisierte Neugründung eines Vereins aus einer pro-eingestellten Schnittmenge an Mitgliedern aller beteiligter Vereine steht dabei zur Diskussion (und es gibt schließlich Gute Gründe[tm] dafür), es gibt aber auch weitere Alternativen, die ohne eine echte Neugründung auskommen. Ob das allgemein Akzeptanz finden wird muss sich noch zeigen. Es wurde zu mindest beschlossen eine Arbeitsgruppe zu gründen, die alle Optionen zusammen fasst und entsprechend beschlussfähig ausarbeitet.

Die Abstimmung um einen Namen für das ganze Projekt war wie erwartet zwar emotional, aber nicht wirklich “emotional geladen”. Es gab mehrere Abstimmungsrunden, Alternativvorschläge, Meinungsbilder. Zum Schluss hatten sich RaumZeitLabor und Raum 404 herauskristalisiert, aber niemand hat sich getraut auch die letzte Abstimmung zu führen. Es wurde also nochmal viel für und wider diskutiert. Die Diskussion war sachlich geprägt und es wuren sehr viele Aspekte diskutiert wie “Der Name ist zu lang“, “muss man am Telefon buchstabieren“, “Domain ist nicht frei“, “s/Zeit/$whatever/“, “Außenwahrnehmung” etc. pp. Die Abstimung, ob man die Abstimmung vertagen möchte (zwecks Ausarbeitung neuer Vorschläge) ging negativ aus und so wurde es um ca. 22:20 Uhr herum letztendlich kurz und schmerzlos abgestimmt: RaumZeitLabor.

Mich persönlich freut diese Entscheidung, aber ich hätte auch damit leben können, wäre sie anders ausgegangen (und es stand ja zwischenzeitlich sehr knapp). Ich hoffe dass auch alle, die Raum 404 favorisiert haben mit der jetzigen Entscheidung gut leben und sich auch damit identifizieren/anfreunden können.

Wichtig ist, dass es jetzt gemeinsam weitergehen muss. Die nächsten großen Punkte in den kommenden Wochen sind der Mietvertrag und die Vorbereitung für die Vereinsgründung.

Das Allerwichtigste ist aber, dass das Projekt finanziell handlungsfähig werden muss! Derzeit ist oqlt e.V. Träger für das RaumZeitLabor und nimmt jegliche Spenden entgegen, frei oder zweckgebunden für das RaumZeitLabor. Für dauerhafte Sicherstellung der Finanzierung sind regelmäßige und dauerhafte Einnahmen sehr wichtig. Ich empfehle daher *ALLEN* einen Dauerauftrag einzurichten. Wieviel das sein kann, muss natürlich jeder für sich selbst wissen, aber ich werbe dafür, dass jeder zwischen 1% und 2% seines Nettoeinkommens dafür aufwenden sollte, das kommt dann für die meisten irgendwo zwischen 5€/Mnt und 30€/Mnt raus, natürlich darf es auch mehr sein.

Gute Nacht!

Die Tagesordnung

1. Begrüßung
2. Aktueller Stand der Arbeiten
3. Finanzielles
4. Organisationsform des Hackerspace
5. Beschluss des Namens
6. Sonstiges

Künftige Organisationsform?

Insbesondere die Diskussion um die Organisationsform für den Hackerspace halte ich für besonders wichtig und auch entscheidend für die Art und Weise, mit der künftig eine finanzielle aber auch organisatorische Handlungssicherheit für dieses Projekt geschaffen wird. Aktuell befindet sich der Hackerspace in der Verantwortung von oqlt e.V., diese haben aber von vorn herein klargestellt, dass sie das Konzept für andere Vereine und Mitglieder öffnen wollen. oqlt e.V. hat nur einfach den Anfang geschaffen und – so finde ich – ist das bisher ziemlich gut gelaufen!

Die Namensfindung – pro RaumZeitLabor

Der vermutlich emotionalere Teil ist natürlich der Name, den das Kind später einmal tragen soll. Denn klar ist, dass der Begriff RaumZeitLabor nicht von den jetzigen Initiatoren selbst stammt sondern auf eine frühere Initiative durch einzelne Mitglieder von UUGRN e.V. und NoName e.V. zurückgeht. Wir (die kleine Gruppe) hatten uns ja ursprünglich auf den Begriff “RaumLabor” verständigt, jedoch ist dieser Begriff bereits mehrfach durch Architekten etc. besetzt, sodass ich (persönlich) das Risiko nicht eingehen wollte hier Namens- oder Markenrechte zu verletzen. Mein Ersatzvorschlag war damals der Name RaumZeitLabor, um dem Marken- und Namensproblem aus dem Weg zu gehen (und außerdem eine freie Domain zu bekommen).

Das derzeitige Hackerspace-Projekt hat den Namen der ursprünglichen Initiative aus rein pragmatischen Gründen geerbt: unter der Domain raumzeitlabor.de hatte ich bereits ein Wiki und einen Mailman mit der Mailingliste eingerichtet und dieses kurzerhand beim ersten Besichtigungstermin als Plattform für alle weiteren Aktivitäten um den Hackerspace Mannheim herum angeboten. Es wurde allgemein akzeptiert, die Mailingliste wird seither sehr aktiv für die interne Organisation verwendet. Ebenso der Blog auf der Webseite und das Wiki.

Natürlich plädiere ich dafür, diesen Namen weiterhin zu verwenden, denn ich denke der Name drückt aus, worum es geht: Es soll Raum für Projekte geschaffen werden. Zur RaumZeit wurde es schlichtweg deswegen, weil ich zwecks Vermeidung einer Namenskollision eine zusätzliche Dimension zugefügt habe. Das Labor steht für alle technik-kreativen Aktivitäten, die der Raum anbieten soll, wie zum Beispiel das viel zitierte “Ätzbad für Platinen” oder weitere Möglichkeiten für den kreativen Umgang mit Technik. Das Labor findet sich auch – hier leider als Anglizismus – im Wiener MetaLab und es gibt viele andere Hackerspaces, die sich in irgendeiner Form “Labor” nennen, siehe z.B.

$ lynx -dump http://hackerspaces.org/wiki/List_of_Hacker_Spaces | grep -i “lab” | cut -c7- | grep ^http | grep -v hackerspaces.org | sort | uniq

• 207.210.106.23/appalab/
• as220.org/labs
• asturlab.xwiki.com/
• betalab01.org/
• bootlab.org/
• buglabs.net/testkitchen
• computerlabor.kire.ch/
• exploratorylaboratory.blogspot.com/
• familab.org/
• foulab.org/
• fubarlabs.com/
• hacklab.cl/
• hacklab.moravice.com/
• hacklab.planetax.org.ar/
• hacklab.to/
• hacklabs-fi.referata.com/wiki/Helsinki_Hacklab
• initlab.org/
• islandlabs.org/
• kernelpanic.hacklabs.org/
• lab.prototypen.com/
• lab4fab.com/
• mail.lists.2600nl.net/mailman/listinfo/labs_lists.2600nl.net
• metalab.at/
• mundurat.net/getxokohacklab/
• nembe.hacklabs.org/
• nextlab.hu/
• nicelab.org/
• null-lab.hacklabs.org/
• patiomaravillas.net/hamlab
• quelab.net/wiki/
• raumzeitlabor.de/
• sevilla.hacklabs.org/
• slobodensoftver.org.mk/hacklab
• stratolab.com/
• tetalab.org/
• trebelab.arkipelagos.net/
• txrxlabs.org/
• uptownlabs.net/
• www.0x0lab.org/
• www.757labs.com/
• www.actlab.utexas.edu/
• www.alphaonelabs.com/
• www.altlablx.org/
• www.buffalolab.org/
• www.gumbolabs.org/
• www.hacklab.org.uk/
• www.happylab.at/
• www.heatsynclabs.org/
• www.kaslab.net/
• www.kwartzlab.ca/
• www.labomedia.net/
• www.labor23.org/
• www.posttenebraslab.ch/
• www.projektlabor.ch/
• www.slacklab.org/
• www.sublab.org/
• www.tmplab.org/
• labitat.dk/
• www.das-labor.org/

Ich persönlich finde daher, dass der Begriff RaumZeitLabor sehr gut in dieses Schema passt!

Auf die häufig verwendete Silbe Hack verzichtet der Name ganz bewusst. Auch wenn jeder aufgeklärte Mensch der Neuzeit längst weiß, dass die Hacker nicht die Bösen sind, in der öffentlichen Wahrnehmung ist dieser Begriff viel zu negativ besetzt und wirkt darüber hinaus vielleicht sogar anziehend auf jene "Möchtegernhacker", die wir eigentlich als "ScriptKiddies" verspotten. RaumZeitLabor finde ich zudem geekiger. Es ist und bleibt in seiner Natur ein "Hackerspace", aber im Eigenname halte ich das einfach für ungeeignet.

Ich plädiere daher für die Beibehaltung des Interims-Namens und werde weiterhin aktiv dafür werben.

Der Name und die Domain

Außerdem nochmal der Hinweis, dass ich die Domain raumzeitlabor.de unentgeltlich an die Organisation übergeben werde, die sich diesen Namen selbst gibt (an dem ich außer vielleicht der Idee keine weiteren Ansprüche festmache) oder zu mindest das Projekt unter diesem Namen öffentlich laufen lässt unter der Maßgabe, dass diese Domain später nicht verkauft oder für (ausschließlich) fremde Projekte und Inhalte verwendet werden darf.

Ich biete außerdem an, die Domain und die bisherige Infrastruktur auch weiter auf meiner eigenen Infrastruktur zu betreiben solange kein eigener und besserer Ersatz geschaffen ist oder anderweitig seitens der neu geschaffenen Organisation der Wunsch aufkommt, dieses Projekt woanders zu hosten. Das Angebot gilt unbefristet solange ich das technisch leisten kann.

Sollte der Name RaumZeitLabor künftig nicht weiter verwendet werden, werde ich die Domain behalten und ggf. als Redirect auf die neue Projekthomepage mit den bisherigen Inhalten beibehalten, um broken Links zu vermeiden. Selbstverständlich würde ich den Umzug von Blog, Wiki und Mailman auf eine neue Domain und einen neuen Server aktiv unterstützen, denn ich will ja nicht, dass es kaputt geht!

Wir sehen uns hoffentlich alle sehr zahlreich am kommenden Sonntag, den 14. Februar in den neuen Räumen des RaumZeitLabors des noch zu benennenden HackerSpace in Mannheim.

Raphael
Updates: div. Formulierungen, Typos, Grammatik, Links Markup ...

Ich habe einen Dauerauftrag dafür eingerichtet und hoffe, dass mein Beitrag sinnvoll verwendet wird. Das Projekt entwickelt sich im Moment sehr vielversprechend.

Einfach mal hingehen und eine oder zwei Mate dort trinken.

Weiter so!
Raphael

About …

Worum es geht ist eigentlich schnell gesagt: Wir finden, dass die Metropolregion Rhein-Neckar ihren eigenen Linuxtag bekomen soll. Der Weg dahin ist noch weit, aber sicher nicht unerreichbar.

Zeit / Termin

Hier einen Konsens widerzugeben ist nicht einfach, weil es keine formalen Abstimmungen hab. Einig sind wir uns wohl, dass “Ende September 2010 plus minus vier Wochen” mal ein Wunschtermin ist, den sich wohl die meisten vorstellen können, also im Grunde in etwa einem Jahr. Aber das ist mal nicht mehr als eine Hausnummer, die von vielen Faktoren abhängen wird, die da sein werden:

• Event-Location
• Veranstalter

Veranstalter und Standort

Es gab wohl auch einen Konsens, dass ein Event mit dem Ziel 500 Besucher ansprechen zu können gründlich vorbereitet werden muss, dazu soll geprüft werden, ob sich als Veranstalter eine Firma oder ein Technologiepark oder eine andere Einrichtung anbieten könnte oder ob man das als gemeinnützigen Verein gründet, der das Projekt dann umsetzt und koodiniert, also auch finanziell. Idealerweise ist der Veranstalter selbst auch Sponsor für die Event-Location. Die Location soll in Mannheim liegen, das Konzept ist aber nicht auf Mannheim fixiert, d.h. grundsätzlich wären z.B. auch Ludwigshafen oder Heidelberg gute Standorte.

Charakter

Die Frage nach dem Charakter der Veranstaltung wurde sehr breit diskutiert. Es ist wohl jedem klar, dass so ein Event Geld kostet und dass man dazu Sponsoren braucht, die auf die ein oder andere Art und Weise sich auch mit ganz kommerziellen Interessen auf so ein Projekt einlassen werden. Und entsprechend auch eine Gegenleistung beanspruchen werden.

Mitwirkende

Ich sehe hier insgesamt folgende Zielgruppen für Mitwirkende

Community …

… Projekte (OpenSource, OpenContent, OpenMind, … ), jeweils vertreten durch Stände und/oder Referenten. Beispielweise allen voran natürlich die Communities und Firmen der “großen” Linux-Distributionen und Desktop-Environments, alternative (unixartige,offene) Betriebssysteme, aber auch beliebige OpenSource-Projekte im weitesten Sinne.

Referenten, die …

…im Auftrag ihres Arbeitgebers ein Produkt oder eine Technologie vortragen und vertreten, zum Beispiel Migrations-Success-Stories, …

Firmen, die …

… durch einen Messestand vertreten sind, d.h. Produkte, Dienstleistungen etc. präsentieren, zum Beispiel Consulting oder Appliances.

Firmen, die …

… speziell für das Besucherpublikum ein abgestimmtes Verkaufsangebot bereithalten, etwa Fachliteratur, Hardware, Gadgets, … also z.B. Computerläden aus der Region

Zielgruppe

Die Zielgruppe der Besucher ist entsprechend dem Angebot angepasst und umgekehrt. Ich nehme wohl nicht zuviel vorweg, dass Community, Linux, OpenSource den definitiven Focus haben soll und das im Rahmen von Vorträgen und Workshops laufen soll. Es soll aber nicht verheimlicht werden, dass Linux nicht nur Hippie-Blümchenwiese ist sondern auch handfestes Business. Linux und OpenSource hat eine hohe wirtschaftliche Bedeutung im Technologieumfeld. Und eben auch das gehört zum Charakter, den der Event IMHO passend repräsentieren sollte.

Next Steps

Monikas Notizzettel waren am Ende des Abends eng vollgeschrieben. Es geht in der nächsten Runde darum, diese ganzen Informationen, das Brainstorming in die passenden Kanäle zu leiten, zu bewerten, zu prüfen und zu priorisieren. Dabei wird das Wiki wohl intensiver genutzt werden.

Das kommende Treffen haben wir noch nicht vereinbart, wird aber wohl noch vor Weihnachten stattfinden. In welchem Rahmen, ob als Workshop-Wochenende / tagsüber oder wieder abends in einer Gaststätte ist noch nicht ganz raus.

Ressourcen

Alle Ankündigungen und Neuigkeiten findet man im Blog, bei
twitter/lxrn, im öffentlichen Projekt-Wiki oder auf der öffentlichen Mailingliste.

Man liest sich! Bestimmt!
Raphael

Postscriptum

Die Unix User Group Rhein-Neckar e.v. ist derzeit als Technologiesponsor im Projekt vertreten, d.h. stellt die Domain und den vServer (Jail) und unterstützt das Projekt so bei der Öffentlichkeitsarbeit und bei der internen Koordination. Die UUGRN tritt bewusst nicht als Veranstalter auf, da es in der Metropolregion Rhein-Neckar viele verschiedene kleine LUGs und Computerstammtische gibt, die eingeladen und angesprochen werden sollen. Der heutige Abend wurde von Leuten besucht, die aus den Gruppen und Vereinen Ubuntu-Users Mannheim, oqlt e.V., UUGRN e.V. und NoName e.V. kommen aber jeweils privat anwesend waren, d.h. nicht als Vertreter der jeweiligen Vereine gesprochen haben.