OS X Yosemite: HBCI-Karte geht nicht mehr "unknown card type - ret=-1 response=90 00"

Und als ob das Java-Problem von gestern nicht genug wäre, funktionieren Chipkartenleser scheinbar auch nicht mehr. Es erscheint die Fehlermeldung "unknown card type - ret=-1 response=90 00". Andere Bankingprogramme wie Starmoney oder Pecunia sind ebenfalls betroffen.
Frank von Pecunia schreibt hierzu
Grund ist eine Umstellung der Smartcard-Bibliothek seitens Apple in OS X 10.10. Wir wissen momentan nicht genau was umgestellt wurde und wie darauf zu reagieren ist. Klar ist nur, dass aufgrund der Umstellung Gatekeeper das Laden der Bibiliothek nicht zulässt.

Das klingt für mich nach: In OS X 10.10 wurden irgendwelche Sicherheitsrestriktionen verschärft, die es unsignierten Anwendungen nicht mehr erlauben, Treiber zu laden.

Um diesen Webinhalt sehen zu können, müssen Sie das Java-Runtime-Environment installieren

Die Fehlermeldung "Um diesen Webinhalt sehen zu können, müssen Sie das Java-Runtime-Environment installieren" erhalten neuerlich Benutzer, die ihren Mac auf die neue Version 10.10 "Yosemite" aktualisiert haben. Es liegt an einer falschen/kaputten Java-Version. Installiere diese Java-Version hier: http://support.apple.com/kb/dl1572.

Das Problem ist in den folgenden Foren-Beiträgen näher beschrieben.Ob und wann Apple eine korrigierte Java-Version bereistellen wird, ist mir derzeit nicht bekannt. Ich weiss auch nicht, was genau eigentlich die Ursache des Problems ist. Aber ich stelle fest, dass es mit jeder neuen OSX-Version immer wieder zu solchen Problemen kommt. Bei Windows und Linux passiert das irgendwie nicht.

Update: Jan schreibt in den Kommentaren (siehe unten), dass der verlinkte Workaround nicht wirklich sinnvoll ist, da hierbei eine veraltetes JRE in Version 6 installiert wird. Funktionieren solle wohl stattdessen auch die Installation des JDK (statt JRE) von der Oracle-Webseite. Da ich selbst kein OS X Yosemite habe, kann ich alle beschriebenen Lösungsansätze nicht verifizieren sondern nur so weitergeben.

Auto-Unzip in Safari

Was denken die sich bei Apple eigentlich dauernd bei ihren "Innovationen". Neuerdings schreiben mir regelmäßig User, dass sie es unter OS X nicht hinkriegen, Hibiscus wie beschrieben zu installieren, weil nach dem Download der hibiscus.zip da keine ZIP-Datei auf dem Desktop liegt sondern ein Ordner namens "hibiscus".

Grund: Der Browser "Safari" entpackt ZIP-Dateien nach dem Download automatisch und ungefragt. Und löscht die originale ZIP-Datei. Warum? Das würde mich auch interessieren. Auf den Gedanken, dass der User selbst weiss, wie er eine ZIP-Datei öffnet oder er sie vielleicht gar nicht entpacken sondern z.Bsp. nur per Mail weiterleiten wollte, sind die bei Apple noch nicht gekommen? Mal ehrlich - was soll denn der Quatsch?

Ich habe hier einen Blog-Beitrag gefunden (Link inzwischen leider tot - daher hier der Tipp: Rechtsklick auf den Link mit der ZIP-Datei und "Ziel speichern unter..." wählen), der beschreibt, wie man dieses "Feature" deaktiviert (letzter Absatz). Das scheint im Übrigen nicht nur ZIP-Dateien zu betreffen sondern alles, was irgendwie geöffnet/gestartet werden kann. Ich finde, die Option sollte daher nicht nur wegen der hibiscus.zip deaktiviert werden - automatisches Öffnen von irgendwelchen Downloads erinnert mich doch stark an gruselige MSIE4-Zeiten.

Kein Jameica/Hibiscus mehr auf Apple OS X?

Offensichtlich hat Apple kein Interesse mehr an Java. Liest sich zumindest so, wenn ich http://www.golem.de/1010/78841.html lese. Denn prompt nach der Installation des aktuellen Java-Updates für OS X 10.6 geht Jameica nicht mehr. Im Bugzilla gibts hierzu bereits einen Bug-Report.

Da ich selbst keinen Mac habe, kann ich den Fehler nicht weiter analysieren. Und ich bin auch skeptisch, ob sich das überhaupt beheben lässt. Die im Wiki zusammengetragenen Workarounds scheinen auch nicht mehr zu funktionieren - das aktuelle Nightly-Build lässt sich mit keiner der angegebenen Varianten starten. Falls jemand da draussen einen Mac und etwas Java-Kenntnisse hat, kann er sich gern daran versuchen.

Aktuell befürchte ich aber, dass ich den Support für OS X wohl einstellen muss. Apple hat offensichtlich kein Interesse mehr daran. Wenn Java dann in OS X 10.7 tatsächlich nicht mehr enthalten sein sollte, bliebe nur noch die Hoffnung, dass SUN Oracle die Mac-Version weiterpflegt. Ob das allerdings tatsächlich passiert?

Tschüss Apple?

Update: Die Änderung aus meinem letzten Kommentar scheint tatsächlich funktioniert zu haben. Zumindest habe ich gerade eine Rückmeldung erhalten, dass Jameica jetzt wieder startet. Also, wenn ihr von dem Problem betroffen seid, macht ein Update auf die aktuellen Nightly-Builds.

Jameica und Mac OS 10.6 (Snow Leopard)

Mit MacOS 10.6 wurde offensichtlich eine 64Bit-Plattform eingeführt. Sollte Jameica 1.9 auf diesem Betriebssystem nicht mehr starten, liegt das schlicht daran, dass in dieser Version noch keine passenden SWT-Libs für diese Plattform enthalten. Die Lösung zu diesem Problem findet ihr im Wiki.

Mac: Das Problem mit der Startseite

Auf MacOS wurde beim Start von Jameica nicht die Willkommens-Seite angezeigt. Ob das da generell passierte oder nur auf meinem Testsystem, weiss ich nicht. Wie dem auch sei: Ausgelöst wurde das durch einen fehlenden Focus links in der Navigation. Auf Windows und Linux wird das erste Element (mit dem Label "Jameica") automatisch selektiert. Hierbei wird der zugehörige Listener ausgelöst, welcher die Willkommens-Seite lädt. Auf MacOS ist genau das nicht passiert. Daher wird dieses Element nun explizit von Jameica selektiert, falls noch nicht geschehen. Verfügbar ab morgen im Nightly-Build.

Keyboard und Maus auf dem Mac erträglicher machen

Zwei Dinge nerven mich auf dem Test-Mac ganz besonders:
1) Ich hasse Mauszeigerbeschleunigung. MacOS besitzt keinerlei Bord-Mittel, um das zu ändern. MouseFix hat hier etwas Linderung geschaffen. 2) Schließt man eine deutsche PC-Tastatur an einen Mac an, ist man aufgeschmissen. Nicht etwa nur, weil Mac-Tastaturen ein anderes Layout besitzen, sondern weil MacOS überhaupt kein passendes Layout für eine deutsche Standard-PC-Tastatur (101/102 Tasten) mitbringt. Das half weiter. Nein, ich werde jetzt nicht sagen, dass das unter Linux alles geht ;)

Mac: Das Problem mit dem versteckten Benutzerverzeichnis

Eigentlich hab ich mich ja immer gesträubt, für MacOS 'ne extra Wurst zu machen. Insbesondere beim Benutzerverzeichnis. Dieses Betriebssystem blendet aber grundsätzlich Dateien und Verzeichnisse aus, wenn deren Name mit einem Punkt beginnt. (Was soll der Scheiß eigentlich? MacOS basiert auf FreeBSD. Und dort ist das - wie bei Linux auch - übliche Praxis). Und da im "Finder" (Dateimanager auf applisch) auch keine Option existiert, um eben jene sichtbar zu machen, kriegt MacOS nun ein eigenes Benutzerverzeichnis (innerhalb des Homebereichs):
Library/jameica
Da in "Library" auch eine Reihe anderer Anwendungen ihre Daten reinschreiben, scheint das der passende Ort zu sein. Um eine "sanfte Migration" zu ermöglichen, wird dieses Verzeichnis nur verwendet, wenn nicht bereits "~/.jameica" existiert - und damit also per Default nur bei Neuinstallationen. Ein existierendes Jameica-Verzeichnis kann im Terminal mit
mv ~/.jameica ~/Library/jameica
verschoben werden. Die Änderungen sind ab morgen im Nightly-Build.

Mac: Das Problem mit dem Master-Passwort

Als erstes Problem hab ich mir diese dubiose Sache mit dem Master-Passwort vorgenommen und konnte es just reproduzieren. Ein paar Debug-Ausgaben brachten die Ursache recht schnell zum Vorschein: Beim Start via Desktop-Alias hängt MacOS an den Programm-Aufruf selbständig einen Kommandozeilen-Parameter mit etwa folgendem Aufbau an:
-psn_0_5636097
Der Parameter beginnt immer mit "-psn_0_", die anschließende Nummer variiert jedoch. Das ist dumm, denn Jameica interpretiert beim Start die übergebenen Parameter. Unter anderem ist da auch einer für die explizite Angabe des Masterpasswortes vorgesehen. Und der heisst "-p". Jameica "glaubt" hier also irrtümlich, der User hätte als Passwort "sn_0_5636097" eingegeben. Da sich diese Nummer nun von Start zu Start ändert, erscheint beim nächsten mal eine Fehlermeldung, weil das Passwort nicht mehr stimmt.

Da man dem Betriebssystem sicher nicht abgewöhnen kann, diesen Parameter zu übergeben, werde ich wohl einen Workaround bauen müssen. Wenn mir nichts besseres einfällt, wird es wohl darauf hinauslaufen, Master-Passörter zu ignorieren, wenn sie mit "sn_0_" beginnen und es sich um einen Mac handelt. Hat jemand eine bessere Idee oder weiss, wofür MacOS diesen Parameter übergibt?

Update: Ich hab eine alternative Lösung eingebaut. Es gibt jetzt einen zusätzlichen Kommandozeilen-Parameter "-o" (alternativ "--force-password"), der dazu führt, dass ein via Kommandozeile übergebenes Passwort grundsätzlich ignoriert wird. Im Start-Script für MacOS (jameica-macos.sh) ist dieser nun per Default gesetzt, in den Scripts für die anderen Systeme nicht.
Ich werd noch ein paar weitere Bugfixes vornehmen und dann eine aktualisierte Version von Jameica 1.6 veröffentlichen.