Posts by mortadelo_de

    Hallo,

    wer von Euch versucht hat, das Bluetooth Audio Streaming aus dem ct-Artikel "Den Raspi als Bluetooth-Empfänger einsetzen" von Heft 21/2016 (https://www.heise.de/ct/ausgabe/201…en-3330683.html) unter Raspbian Stretch zum Laufen zu bekommen, ist wahrscheinlich auf einige Probleme gestoßen. Ich möchte hier ein paar Antworten geben und neue Fragen stellen ;)

    Raspbian Stretch verwendet gegenüber vorher eine etwas veränderte BlueZ- und Sound-Architektur, bei der der BlueZ Bluetooth Stack direkt mit dem ALSA Sound Stack gekoppelt wird. Die im Artikel geschilderte Architektur funktioniert damit nicht mehr ohne Modifikationen. PulseAudio ist zwar hier noch möglich, aber nicht mehr unbedingt sinnvoll, da die A2DP-Empfänger-Funktionalität direkt von ALSA über BlueZ abgebildet werden kann, ohne dass PulseAudio noch nötig ist. Das macht hoffentlich einige Kompatibilitätsprobleme mit PulseAudio hinfällig (z. B. mit ALSA).

    Aber zuerst sehe ich ein kleines Problem mit dem Bluetooth Pairing: Es wird zwar ein Pairing durchgeführt, aber der Pairing-Status wird nicht auf 'Trusted=true' gesetzt. Nach meinem Verständnis von 'simple-agent' sollte das in diesem Skript durchgeführt werden, aber das funktioniert wohl nicht mehr. Ich muss nun nachträglich 'bluetoothctl' aufrufen (als root), und in der 'bluetoothctl' Shell 'trust <Geräteadresse des Senders>' aufrufen, um die Verbindungsaufnahme zu ermöglichen. Möglicherweise würde hier 'simple-agent' unter root noch korrekt funktionieren.

    Hat jemand schon Erfahrung mit 'simple-agent' in Raspbian Stretch gesammelt?

    Desweiteren ist der Eintrag von 'pulseaudio --start' in .profile nicht mehr erforderlich. Dafür muss 'bluealsa-aplay 00:00:00:00:00:00 &' (als root) aufgerufen werden (siehe auch https://github.com/Arkq/bluez-alsa). Ich überlege noch, wo ich den Aufruf am Besten beim Booten einhänge.

    Schließlich hat man wieder die originale Funktionalität, diesmal aber ohne PulseAudio. Lästig ist derzeit noch, dass man jedes Pairing expliziit mit 'bluetoothctl' 'trust <Geräteadresse des Senders>' bestätigen muss.

    Kommentare?

    Hallo,

    wer seinen alt-ehrwürdigen Raspi 1B (aber ohne +, d. h., ohne den 40-poligen GPIO-Verbinder) noch mit einem Hifi-fähigen DA-Wandler ausstatten will, der wird sehr bald feststellen, dass es schwierig geworden ist, ein passendes Board zu bekommen. Sowohl vom Platzhirsch Hifiberry als auch vom Underdog Phat-Dac (gleicher Chip) sind nur (noch) Versionen für den 40-poligen GPIO-Verbinder vom Raspi 1B+ aufwärts erhältlich.

    Das sollte aber zumindest diejenigen Bastler nicht abschrecken, die nicht davor zurückschrecken, einen Lötkolben in die Hand zu nehmen. Der für den DAC erforderliche I2S-Port ist beim Raspi 1B nämlich sogar als eigenes Verbindungsfeld herausgeführt (siehe Foto, Anklicken, um Port in Vergrößerung zu sehen):

    Und von diesem muss man nur ein 5-adriges Kabel zum DAC führen. Der Knackpunkt ist also nur der Verdrahtungsplan. Und der sieht so aus:

    Code
    Raspi 1B     PIN      DAC
        5V     1----2      5V
       BCK     3----12     BCK
      LRCK     4----35     LRCK
      DOUT     6----40     DIN
       GND     8----39     GND

    Bei den Verbindungsfeldern ist jeweils PIN 1 als rechteckiger Lötpunkt markiert, und jede Reihe enthält entweder nur die ungeraden oder nur die geraden PINs (jeweils in aufsteigender Reihenfolge). Beim Raspi ist PIN1 oben links, und PIN8 unten rechts. Beim DAC ist PIN1 unten links, und PIN40 oben rechts (jeweils von der Bauteileseite aus gesehen). Entsprechend werden die PINs verbunden. Der Plan sollte identisch für den Phat-Dac und den Hifiberry gelten.

    Wenn man noch den 26-poligen Steckverbinder aus dem Raspi auslötet, bekommt man ausreichend Platz für den (Phat-)Dac. Ich habe diesen in die obere Gehäusehälfte eingesetzt. Dafür habe ich in diese ein Loch für die Klinkenbuchse des Phat-Dac gebohrt, und die Platine mit der Klinkenbuchse in die Gehäusehälfte eingeklebt (nur die Buchse ist verklebt). Das hält gut (siehe Foto):

    Der Phat-Dac lässt sich gemäß Herstelleranleitung (Konfiguration Phat-Dac) problemlos in Raspbian installieren. In die Klinkenbuchse kann man dann direkt ein Headset einstecken, oder per Adapter ein Cinch-Kabel anschließen. Danach steht dem Hifi-Genuss nichts mehr im Wege (z. B. MP3 mit mpd).

    Der Phat-Dac kostet um die 15 € (z. B. bei Pollin).

    Viel Spaß!

    Es gibt da ein recht subtiles Problem in der libcec-Bibliothek v2.14 (siehe Post # 45 in http://michael.gorven.za.net/raspberrypi/xbmc?page=2). Das hat mich schon halb in den Wahnsinn getrieben, weil die Fernbedienung irgendwann einfach nicht mehr mit XBMC/Raspi mag, und der Effekt ziemlich undeterministisch ist. Ein Austausch der Bibliothek gegen v2.13 schafft Abhilfe (ich erinnere mich allerdings nicht mehr, in welchem Debian Package die libcec drinsteckt).

    Ich hoffe, das hilft!

    Michael

    Hallo,

    ich habe ein Auto-Upgrade ([font="Courier"]apt-get upgrade[/font]) gemacht, ebenfalls mit den Paketquellen von OpenSUSE für Debian. Das Auto-Upgrade ging bei mir schief; Owncloud blieb im Status 'Updating' hängen. Ich weiß nicht, ob das ein generisches Problem ist.

    Letztendlich bin ich dann mit [font="Courier"]apt-get purge owncloud <CR> apt-get install owncloud[/font] wieder zu einem laufenden System (mit Owncloud 7) gekommen, allerdings mit totalem Datenverlust in der DB. Da ich Owncloud praktisch nur für CardDAV verwende, konnte ich die verloren gegangene Daten (praktisch nur das Adressbuch) wieder mittels vcf-Datei (früher weggesichert) restaurieren.

    Ich kann bestätigen, dass sich die Performance der Web-GUI spürbar verbessert hat; sie ist jetzt erträglicher geworden. Allerdings scheint mir das 'Kontakte'-GUI ziemlich herumzuspinnen: Änderungen einer Telefonnummer oder Adresse von z. B. 'Zuhause' auf 'Arbeit' werden schlichtweg ignoriert. So habe ich bei einem neuen Kontakt jetzt halt zwei 'Zuhause'-Telefonnummern und zwei 'Arbeit'-Adressen. Es bestätigt sich mir wieder der schlechte Zustand der GUI, den ich schon in manchen früheren Versionen von Owncloud bekommen habe. Wahrscheinlich muss ich wieder bis Version 7.0x warten, bis die schlimmsten Bugs aus der neuen Hauptversion raus sind...

    Ich hoffe, das hilft ein bisschen.

    Ciao, Michael

    Klingt im Wesentlichen vernünftig.

    Der einzige (kleinere) Aspekt, der mir dazu noch einfällt, ist der, dass evtl. ein böser Nachbar, der sich technisch auskennt, Dein BT-Gerät (iPhone) mittels eines BT-Adapters mit derselben MAC-Adresse spoofen könnte, und damit Deine Steuerung manipulieren könnte (wenn er denn nahe genug am Raspi dran wäre). Die MAC-Adressen einiger Adapter lassen sich (mit Informationen, die im Netz kursieren) frei programmieren. Das ließe sich mit Pairing verhindern.

    Da muss zugegebenermaßen schon Einiges zusammenkommen, dass man darüber besorgt sein müsste:

    • Böser Nachbar mit ausreichenden Technik-/Computer-Kenntnissen, der auch Dein System kennt und versteht.
    • BT-Adapter vom Raspi von der Nachbarswohnung aus erreichbar
    • Du siehst eine mögliche Manipulation als wesentliches Problem an.

    Hallo,

    Bluetooth Class 2 (wie es typischerweise bei mobilen Geräten eingesetzt wird) hat eine Reichweite von ca. 10 m. Würde also passen. Allerdings muss Bluetooth dann bei beiden Geräten permanent eingeschaltet bleiben (wenn es das nicht ohnehin ist), was zusätzlich Energie frisst und ggf. an der Handy-Batterie zehrt.

    Wie Du es auch immer machen willst, ich denke, das wäre ein guter Zeitpunkt, um in die Python-Programmierung einzusteigen (Pi wie Python :-). Obwohl ich es nicht garantieren kann, gehe ich stark davon aus, dass Dir Python alle erforderlichen Bibliotheken zur Verfügung stellt, um Dein Vorhaben zu realisieren. Und Du würdest Dir von vorneherein die nötige Flexibilität sichern, um Deine Heimautomatisierung nach und nach an Deine Wünsche anzupassen.

    Um den Fernseher zu schalten, ist evtl. auch HDMI CEC eine Option: Wenn Du den Pi per HDMI mit einem einigermaßen modernen Fernseher verbunden hast, dann kannst Du ihn auch über das HDMI-Kabel ein- und ausschalten (Stichwort: CEC). Dazu gibt es eine LibCEC für Linux. Auf dem Raspi musst Du sie allerdings selbst kompilieren (z. B. hier: http://nyxi.eu/blog/2013/04/15/raspbian-libcec/).


    Viel Erfolg!

    Michael

    Ich glaube, Roundcube sollte für Deine Zwecke ausreichen, zumindest, wenn Du per IMAP auf Gmail zugreifen kannst (ich glaube, das geht). OpenPGP scheint es dafür auch zu geben (siehe http://lists.roundcube.net/pipermail/dev/…ary/022123.html). Einen Web Server musst Du natürlich dafür aufsetzen. Fetchmail solltest Du dafür gar nicht benötigen.

    Eine gute Zusammenfassung über die Gesamtproblematik (inkl. Roundcube) findest Du im c't-Artikel Briefkästchen aus der c't 17/2013, S. 164ff.

    Viele Grüße, Michael

    Also ich denke auch, dass einfach das Dateisystem etwas abbekommen hat. Wahrscheinlich ist der Webserver aus irgendwelchen Gründen abgestürzt, und dann hat das Ausschalten ohne Shutdown dazu geführt, dass die Dateiallokationstabelle (oder wie auch immer das unter EXT4 heißt) etwas abbekommen hat. Die Einträge für /etc/network/interfaces und /etc/hostname zeigen jetzt anscheinend auf /usr/include/interfaces/vcos/vcos_inittypes.h (ist eine existierende Datei unter Raspbian).

    Ausschalten ohne Shutdown ist bei Dateisystemen mit Schreibcache leider nicht ohne Risiko (auch wenn sich das System 'Journaling Filesystem' nennt).

    Ich glaube nicht, dass ein Angriff konkret dafür verantwortlich ist, auch wenn man sein System natürlich immer gegen Angriffe härten sollte. Dafür gelten eigentlich alle Tutorials im Netz, die sich mit Deinem Webserver (bzw. LAMP-System) unter Linux beschäftigen.

    Ich sehe gerade, dass Owncloud auch einen Video Viewer als App beinhaltet. Der ist allerdings Version 0.1.1, und hat wohl so seine Problemchen (such mal auf Google).

    Letztenendes musst Du die Varianten wahrscheinlich einfach mal selbst ausprobieren.

    Was Dein Skript letztenendes aufruft, kann ich natürlich nicht sagen. Es ist aber unwahrscheinlich, dass eine Lüftersteuerung den Raspi übermäßig beansprucht.

    Also wenn ich mir ansehe, was Dein Fernseher für Anschlüsse hat (LAN, WLAN integriert), und was für Videoformate er unterstützt (http://www.samsung.com/de/consumer/tv…F6270SSXZG-spec), halte ich es für wahrscheinlich, dass Du mit ihm direkt vom LAN die Video-Dateien abspielen kannst (per SMB Share). Mein (3 Jahre alter) Sony kann das problemlos.

    Das ist im Prinzip schon möglich. Du kannst mit Raspbian einen Webserver aufbauen (Tutorials gibt's hier im Forum), und zusätzlich XBMC installieren (z. B. hier: http://michael.gorven.za.net/raspberrypi/xbmc). Owncloud läuft dann als PHP-Anwendung im Kontext des jeweiligen Webservers (z. B. Apache), und XBMC läuft als eigenständiges Programm.

    Nur sind beide Anwendungen fürchterliche Ressourcenfresser. Owncloud läuft allein schon ziemlich träge, und XBMC benötigt gerne mal 50% - 100% der Prozessorlast. Ich habe bei mir beobachtet, dass XBMC schon im "Leerlauf" (d. h., wenn es im Hauptdialog steht) 50% - 70% der Prozessorlast beansprucht. Wenn es Videos über die Raspi-HW-Codecs (MPEG2, VC1) abspielt, braucht es angeblich weniger Ressourcen. Insgesamt kann das aber eine ziemliche Ressourcen-Konkurrenz geben.

    Die Frage ist aber, ob Du überhaupt XBMC benötigst, wenn Du mit dem Fernseher auf MP4s etc. zugreifen willst. Moderne Fernseher sind oft in der Lage, über Ethernet auf entfernte Videodateien zuzugreifen. Das ist dann vielleicht die sinnvollere Lösung.

    Hallo,

    für alle, die - wie ich - vor dem Problem standen (oder stehen), dass sie auf ihren Web Server (hier: NGINX) auf dem Raspberry Pi und auf ihren Fritzbox-Fernzugang über dieselbe IP und (Pseudo-)Domäne (z. B. DSL-Zugang mit Dynamic DNS Provider) zugreifen wollen, hier ein paar Gedanken und eine mögliche Lösung. Ich gehe dabei davon aus, dass der Raspi mit einer internen IP(v4)-Adresse hinter der Fritzbox sitzt, und der Zugriff von außen nur per Port-Weiterleitung der Fritzbox über die öffentliche IP (bzw. dynamische DNS-URL) möglich ist:

    • Der unabhängige Zugriff auf beide Dienste ist möglich, wenn auf derselben IP-Adresse unterschiedliche Ports verwendet werden (z. B. 80 für NGINX und 450 für die Fritzbox).
      Problem: Aus vielen (z. B. Firmen-)Umgebungen ist der Zugriff nur über die Standard-Ports 80 (ungeschützt) und 443 (mit SSL geschützt) möglich. Diese führen hier jedoch unweigerlich zu Konflikten.
    • Der unabhängige Zugriff auf beide Dienste ist möglich, wenn beide Geräte über unterschiedliche IPv6-Adressen verfügen, die von außen sichtbar sind. IPv6-Adressen des Heimnetzes (Fritzbox) können in der Fritzbox explizit mittels IPv6-Freigaben extern bekannt gemacht werden.
      Problem: IPv6 ist nicht überall verfügbar.


    Somit ist eine etwas universellere Lösung erforderlich. Dabei macht man sich die Eigenschaft zunutze, dass NGINX mit sog. 'Virtual Hosts' unterschiedliche Host-URLs (z. B. http://mydomain.dyndns.net und http://fb.mydomain.dyndns.net) selbst bei identischer IP-Adresse individuell auflösen kann, und zudem als Proxy fungieren kann. Voraussetzung für Ersteres ist, dass der Dynamic-DNS-Anbieter Host-Namen zusammen mit Sub-Host-Namen für dieselbe dynamische DNS-Adresse anbietet (wie z. B. mit http://mydomain.dyndns.net und http://fb.mydomain.dyndns.net). Ich habe hier gute Erfahrungen mit dem Gratisangebot von DTDNS (http://www.dtdns.com) gemacht: Dieser erlaubt, dass beliebige Sub-Hosts auf dieselbe IP-Adresse wie der eigentliche Host gemappt werden (sie nennen das 'wildcards'). Eine generelle Einführung in die Virtual Hosts gibt es z. B. hier: http://www.farinspace.com/nginx-virtual-host/.

    Die Proxy-Konfiguration sorgt dann dafür, dass der Zugriff auf die externe IP-Adresse auf die entsprechende interne Adresse umgeleitet wird.

    Meine NGINX-Koniguration sieht so aus:


    Die Fritzbox läuft hier unter 192.168.178.1, und wird über den Proxy unter https://fb.<my-URL> erreicht. NGINX auf dem Raspi wird über die reguläre Port-Weiterleitung (typischerweise http(s)://<my-URL> auf Ports 80 und 443) erreicht.

    Die Konfigurationsdatei für die Fritzbox wurde inspiriert von http://umija.org/20110002. Anstelle von <my-URL> muss natürlich die eigene dynamische Host-Adresse, z. B. mydomain.dyndns.net, stehen. Entgegen dem unteren Beispiel des vorigen Links wird jedoch ein Sub-Host anstelle eines Unterverzeichnisses verwendet. was mit einem NGINX Virtual Host gut funktioniert. Die im obigen Code auskommentierten Zeilen wurden ebenfalls vom vorigen Link inspiriert, scheinen aber unnötig zu sein. Die Variante mit dem Unterverzeichnis (/fb/) habe ich nicht zum Laufen gebracht.

    Die obige Code enthält noch die folgenden zwei Features:

    • Wenn man auf die URL regulär (ohne https) zugreift, wird man automatisch auf https (mit SSL) umgeleitet. Da das Fritzbox-Passwort wahrscheinlich unverschlüsselt übertragen wird, ist das sinnvoll.
    • In den letzten Zeilen ('auth_basic'...) wird noch eine zusätzliche (einmalige) Authentisierung vor dem Zugriff auf die Fritzbox erzwungen. Dies ist eine zusätzliche Vorsichtsmaßnahme, da man jetzt auf die Fritzbox von außen so zugreift, als käme der Zugriff aus dem Heimnetz (die Fritzbox denkt weiterhin, der Zugriff käme aus dem Heimnetz). Die notwendige Konfiguration findet man z. B. unter http://www.howtoforge.com/basic-http-aut…tion-with-nginx.


    Man sollte die Fritzbox auf jeden Fall so konfigurieren, dass sie unbedingt eine Benutzeranmeldung (mit Passwort) erzwingt. Mit der zusätzlichen Authentisierung mit auth_basic hat man dann doppelte Sicherheit.

    Das reguläre Web-Angebot von NGINX läuft als weiterer Virtual Host. Dessen Konfigurationsdatei ist Standard, und wir hier nicht gezeigt. Beide Konfigurationsdateien befinden sich im Verzeichnis /etc/nginx/sites-available, und werden mit symbolischen Datei-Links aus /etc/nginx/sites-enabled verlinkt.

    Ob eine entspr. Konfiguration auch mit anderen Web Servern möglich ist, weiß ich nicht. Das Proxy-Feature von NGINX ist dafür sicherlich sehr hilfreich.

    Der grundlegende Unterschied zwischen OpenVPN und IPSec-basierten Lösungen ist, dass bei OpenVPN die Pakete niedrigerer Schichten (IP bis herunter zu Ethernet) in TCP-bzw. UDP-Pakete eingepackt werden, während bei IPSec IP-Pakete in IP-Pakete (mit neuen Headern) eingepackt werden. In der Praxis hat das die folgenden Konsequenzen:

    OpenVPN:
    - Konfiguration: relativ einfach
    - Performance: eher schlecht, da großer Overhead
    - Kompatibilität mit NAT (Fritzbox mit IPv4): gut

    IPSec:
    - Konfiguration: schwierig
    - Performance: gut, da geringer Overhead
    - Kompatibilität mit NAT (Fritzbox mit IPv4): schlecht bis gar nicht, da der Pi _hinter_ der Fritzbox mit NAT steht. Letzteres lässt sich nur mit IPv6 (kein NAT) umgehen (was in vielen Umgebungen nicht zur Verfügung steht).

    PPP und PPTP sind historisch, und häufig unsicher. L2TP ist eher MS-spezifisch, und auch schon tendenziell historisch. Da hätte ich auch schon eher Sicherheitsbedenken.

    Wenn ich richtig informiert bin, bietet die Fritzbox 7170 auch IPSec VPN (http://www.avm.de/de/Service/Ser…de_schritte.php). Das wäre meiner Meinung nach die beste Lösung: Du hast keine Probleme mit NAT (IPSec _ist_ in diesem Falle das NAT), und um die erforderlichen Portfreigaben kümmert sich auch die Fritzbox. Die Konfiguration auf der Windows-Seite ist zwar etwas hakelig, aber das wird durch die leistungsfähigste VPN-Variante gerechtfertigt, die Du in Deinem Netzwerk-Szenario bekommen kannst.

    Ansosnten, wennn das nicht klappt, würde ich bei OpenVPN bleiben, da Du damit keine IPSec-Probleme mit dem Pi _hinter_ der Fritzbox (NAT!) bekommst. Letzteres kann sehr ekelhaft werden.

    Bzgl. der Sicherheit ist wahrscheinlich auch die integrierte Fritzbox-Lösung die beste, da sowohl das VPN als auch die Box (mit den notwendigen Portfreigaben) von AVM gepflegt werden. Und das VPN sitzt dann direkt hinter der FB-Firewall (vom selben Hersteller), was potenzielle Problem verhindert. AVM hat einen recht guten Ruf in Bezug auf Security. Wenn Du Dich selbst um OpenVPN oder IPSec kümmern musst, wirst Du immer wieder mal die Konfiguration (z. B. Algorithmen) oder den Code (Vulnerabilities) updaten müssen, was sehr schnell nerven kann.

    Ich hoffe, das hilft ein bisschen...


    Mails können nur mit dem öffentlichen Schlüssel vom Mailempfänger verschlüsselt werden.
    Daher muss der Mailempfänger PGP installieren und ein Schlüsselpaar erzeugen. Danach muss er den public key verteilen an Leuten die ihm dann verschlüsselte Mails schicken können..

    Wie soll das noch mal genau bei Euch funktionieren?


    Die ganze Idee der Mail-Server und Mail-Clients ist entstanden als die Clients die meiste Zeit nicht Online waren. Das hat sich jetzt geändert. Viele haben eine Fritz!Box oder Speedport ständig online am Netz. Der Raspberry Pi verbraucht 3,5 Watt und könnte ständig am Netz hängen um Mails zu empfangen. Ein Desktop PC mit 100 Watt kostet um die 20 Euro im Monat.

    Wenn die Mailserver und Mailclients umgeschrieben werden könnte das lästige Verschlüsseln vom Mailclient gemacht werden indem er sich zuerst den öffentlichen Schlüssel holt verschlüsselt und die Mail, per TLS 1.2, hin schickt. Das wäre eine End zu End (e2e) Verschlüsselung.
    Da sollte mal drüber nachgedacht werden weil viele Endgeräte ständig online sind.

    Zur Schlüsselverteilung sollten idealerweise die öffentlichen Key Server von PGP verwendet werden. GnuPG (der geplante Unterbau des Relays) kann z. B. automatisch (on demand) fehlende öffentliche Schlüsel von einem Key Server importieren. Befindet sich der öffentliche Schlüssel des gewünschten Adressaten nicht auf einem Key Server, so muss man ihn halt vorab vom Empfänger besorgen und von Hand importieren. Letzteres hat den Vorteil, dass man explizit noch einmal den Fingerprint des Schlüssels überprüfen kann, bevor er zum Einsatz kommt.

    Die von Dir angesprochene Lösung mit TLS-Schlüsseln auf jedem Mail Server/Client ist durchaus plausibel, wenn es ausschließlich um Vertraulichkeit gegenüber Externen (z. B. NSA geht). Das Briefkästchen (IMAP-Server auf dem Pi) aus der c't 17/2013 geht schon in diese Richtung. Problematisch wird es natürlich dann, wenn man vom eigenen Mail Server (SMTP) eine Email nicht direkt auf den Mail Client des Empfängers schicken kann (weil der Empfänger keinen eigenen Mail Client hat). Denn Emails von privaten (nicht-komerziellen) SMTP-Servern werden von den meisten kommerziellen Email-Servern/Gateways (z. B. GMX) nicht angenommen (Spam-Schutz).

    Eine Email-Signatur (als Nachweis der Authentizität des Absenders) ist mit der TLS-Lösung (_maschinenspezifischer_ Schlüssel) natürlich eher absurd, spätestens wenn mehr als ein Benutzer den Mail Server nutzt. Eine dokumentenzentrierte Signatur ist mit TLS ohnehin nicht möglich. Zugegebenermaßen ist der Authentizitätsanspruch bei meiner Lösung (mehrere private Benutzerschlüssel auf dem Pi) auch schon angegriffen, da (mindestens) der Admin vollen Zugriff auf den Pi hat. Macht also nur bei vertrauenswürdigem Admin Sinn.


    Ehrlichgesagt steht das Projekt bis auf Weiteres still, da das Interesse aus der Community sehr gering ist.

    Hm - ich weiß nicht, ob das so ungewöhnlich ist. Ich habe den Eindruck, wenn Firefox 'Verbinden' (bei mir auf Englisch 'Waiting for...') sagt, dann ist darin auch schon ein Teil der Ladezeit enthalten. Zumindest kommt er dann schon mit dem gesamten Text, und nur die Fotos dauern länger.

    Ich habe einen Pi mit NGINX/PHP/MySQL/Wordpress, und komme auf Verbindungs-/Ladezeiten von ca. 3 - 5 Sek. (dauert aber manchmal auch wesentlich länger). Wenn Du willst kannst Du Deinen Server mal mit cuynet.dtdns.net (mein Server) vergleichen.

    Vielleicht kann man mit den diversen Wordpress/PHP-Caching-Stragtegien noch etwas optimieren, aber damit habe ich keine Erfahrungen.


    Die Funktion sollte direkt in den MTA integriert sein, also transparent für den Benutzer.

    Ich würde mich an dem Projekt - in meinem möglichen Rahmen - beteiligen.

    So ist es (weitgehend) mit Thunderbird realisiert (mit Enigma-Plugin). Der MTA (Mail Transfer Agent) _ist_ das Email-Programm.

    Meine Idee ist es aber, die Verschlüsselungsfunktionalität im Raspberry Pi (als Relay) zu implementieren, mit externen (typischerweise Windows-basierten) Email-Clients. Für welche Richtung plädierst Du also?

    Ich benötige Unterstützung in der Perl-Programmierung. Würdest Du das machen wollen?