Ich habe heute mal wieder ein Commit für eagle gemacht. Ein paar Implementierungen für Bookmarks, GnuPG Notations und ein Log Windows in der einigen Presence und Messages von XMPP protokolliert werden.

Bookmarks

eagle fragt die Bookmarks vom XMPP Account ab und wird ein Autojoin machen in die MUCs machen. Sonst ist es aber auch nicht so viel, da ich noch ein Fenster für Gruppenchats gemacht habe.

GnuPG Notations

Es wurde vorgeschlagen das Konzept von Keyoxide zu übernehmen. Deswegen frage ich jetzt bei einem mind. vollkommenen Gültigkeit des OpenPGP Keys die Notations an. Diese werde dann - noch etwas unschön - in der Liste der UIDs angezeigt.

Log Window

Ein Reiter in dem die Presence und Messages angezeigt werden. Die TextView scrollt automatisch und mit der Maus kann man einen Marker setzen.

Ich habe mich die letzten Monate mehr mit C und libstrophe beschäftige.

Der Prototyp von eagle ist in C mit libstrophe geschrieben. Das funktioniert schon mal ganz gut.

Allerdings würde ich mir jetzt schon gerne noch mal C++ im Vergleich ansehen. Ich hatte vor längerer Zeit mal ein XMPP Bot angefangen zu schreiben, den Hawkbit Bot. Es gab aber dann ein Problem mit TLS und ich habe es dann nicht mehr weiter verfolgt.

Aktuell geht es auch wieder mit Debian GNU/Linux Buster. Die Verbindung mit dem Server funktioniert.

Also,... nächster Versuch,...

Sparrow ein XMPP Client für XEP-0060: Publish-Subscribe - was ich schon die ganze Zeit schreiben wollte. Ich habe jetzt erst mal das Projekt setup erstellt. Automake, etwas boost sowie gtkmm und gloox eingebunden.

Demnächst einfach mal drauf los programmieren,...

#xmpp #libstrophe #gtkmm #cpp #gloox

Gajim 1.2.0 wurde veröffentlicht.

Nachdem ich mich jetzt einige Zeit mit C und XMPP beschäftige, sollte man mal überlegen von den "Sandbox" Projekten mal auf etwas sinnvollere Projekte umzusteigen.

Ich habe angefangen etwas OX zu implementieren. Dies habe ich erst in xmppc umgesetzt, dann in einem meiner eigenen Clients und jetzt will ich es in profanity implementieren. 3x die gleiche Arbeit für mehr oder weniger umsonst.

Ich habe jetzt mit einer lib für C angefangen.

Die Idee

libstrophe als normale XMPP lib verwenden (eigentlich die Kommunikation mit dem Server und die Umsetzung der Grundfunktionen von XMPP). Da drauf dann eine lib (libcxmppx) für die Implementierungen der XEPs.

Beispiel

stanza_id_t cxmppx_ox_signcrypt_message( xmpp_stanza_t **stanza, xmpp_conn_t *conn, xmpp_adr_t xmpp_adr, char* message);

In der Funktion wird die stanza für eine signcrypt erzeugt. Die Funktion übernimmt alle Aufgaben wie key-lookup / openpgp sign / openpgp crypt / base64.

void fire_and_handle(xmpp_conn_t *const conn,stanza_id_t id, xmpp_stanza_t *stanza, cxmppx_stanza_result_cb_t callback, void *const userdata);

Danach werden die stanza abgefeuert und über das callback und userdata können die Antworten verarbeitet werden.

Eine Implementierung kann dann so aussehen:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <cxmppx.h>

static char* to_adr = NULL;
static xmpp_conn_t *conn = NULL;

void handle(xmpp_stanza_t *stanza, void *const obj, void *const userdata ) {
  printf("%s %s\n", userdata, obj);
  xmpp_disconnect(conn);
}

void conn_handler(xmpp_conn_t *const conn, const xmpp_conn_event_t status,
                  const int error, xmpp_stream_error_t *const stream_error,
                  void *const userdata) {
  switch (status) {
    case XMPP_CONN_CONNECT:
      printf("Connected!\n");
      xmpp_stanza_t* message = NULL;
      stanza_id_t id = cxmppx_ox_signcrypt_message(&message, conn, to_adr, "Das ist ein Test");

      fire_and_handle(conn, id, message, handle, "Anfrage 1" );

      break;
    case XMPP_CONN_DISCONNECT:
    case XMPP_CONN_FAIL:
      xmpp_stop(xmpp_conn_get_context(conn));
      break;
  }

}

int main(int argc, char* argv[]) {
  xmpp_log_t *log = NULL;
  log = xmpp_get_default_logger(XMPP_LEVEL_DEBUG);
  xmpp_ctx_t *ctx = xmpp_ctx_new(NULL, log);
  conn = xmpp_conn_new(ctx);
  xmpp_conn_set_jid(conn, argv[1]);
  xmpp_conn_set_pass(conn, argv[2]);

  to_adr = strdup(argv[3]);

  int e =  xmpp_connect_client(conn, NULL, 0, conn_handler, NULL);
  if(XMPP_EOK != e ) {
    printf("xmpp_connect_client failed");
  }

  xmpp_run(ctx);
  xmpp_conn_release(conn);
  xmpp_ctx_free(ctx);
  xmpp_shutdown();

  return EXIT_SUCCESS;
}

Der Code ist auf Codeberg https://codeberg.org/xmpp-messenger/libcxmppx und ein Spiegel auf gitlab https://gitlab.com/xmpp-messenger/libcxmppx

Vorwort

Brainstorming zur Implementierung von XMPP OX (XEP-0373: OpenPGP for XMPP). Es gibt verschiedene Arten wie man die Verwendung von OpenPGP in XMPP implementieren kann. In diesem Dokument soll das Thema diskutiert werden.

Grundlage ist XEP-0373: OpenPGP for XMPP Version 0.4.0 (2018-07-30)

GnuPG Home und Keyring

In GnuPG ist es möglich einen eigenen Home Directory zu verwenden oder einen eigenen Keyring zu definieren. Eine Änderung würde bewirken, dass der XMPP Client und der eigene Keyring / GnuPG Instanz unabhängig von einander verwendet werden. Es ist zu klären welche Vor- oder Nachteile die Verwendung eines eigen Keyring oder Homedir hat.

Für Anwender die schon einen Key besitzen und diesen auch für XMPP nutzen wollen, sehe ich hier einen komplexeren Ablauf, wenn die Schlüssel auf mehrere Keyrings verteilt sind.

Aus Sicht für der Anwender sehe ich einen Key mehr als eine Eigenschaft eines Kontakts in einem Adressbuch. So ist vom Anwendungsdesign eine Überlegung die "Kontakte" in einem Adressbuch darzustellen und diese auch individuell zu nutzen.

Eine Aufteilung der Kontakte in noch mehr Quellen macht die Verwendung und Verwaltung nur komplexer. Ferner ist die Zertifizierung und die Bildung des Trust-DB aufwendiger.

Für Nutzer, die ohnehin OpenPGP nur für XMPP verwenden, würde der Ort keine Rolle spielen. Die Verwendung eines Keyring auch mit unterschiedlichen Account sehe ich nicht als Problem.

Verwaltung des eigenen Schlüssel

Beim Verwenden von OpenPGP in XMPP sehe ich die folgenden Anwendungsfälle:

• Der Benutzer hat noch keinen privaten OpenPGP Schlüssel
• Der Benutzer hat einen privaten Schlüssel, jedoch noch kein Zuordnung zu XMPP
• Der Benutzer hat einen privaten Schlüssel und eine Zuordnung zu XMPP

Wenn der Benutzer noch keinen privaten Schlüssel hat, sollte die Anwendung einen OpenPGP Key erzeugen. Ein Experten-Modus für die Angabe von Schlüsseltyp und Schlüssellänge, sowie Verfallsdatum. In einem "normalen" Modus wird der Schlüssel automatisch generiert: rsa3072 / 2 Jahre. In beiden Fällen wird die XMPP Adresse (JID) im URI Format als UID eingetragen:

sec   rsa3072 2020-05-16 [SC] [verfällt: 2022-05-16]
      A8431A0170B3EBB564CE294D0C1CE873ED588C2B
uid        [ ultimativ ] xmpp:alice@domain.tld
ssb   rsa3072 2020-05-16 [E] [verfällt: 2022-05-16]

Sind im Keyring private Schlüssel vorhanden, kann der Benutzer auswählen, ob er einen neuen Key erzeugen will (siehe oben) oder einen der Schlüssel verwenden will. Hat der Benutzer sich für einen Schlüssel entschieden, wird für diesen Schlüssel eine UID angelegt mit der JID angelegt.

Existiert ein Key mit der JID als UID wird diese verwenden. Wenn jedoch mehrere existieren, ist die Verwendung des Schlüssels nicht eindeutig. Zu klären ist, was in diesem Fall passieren soll?

Damit ist der Punkt 8.5 "OpenPGP User IDs" in XEP-0373 erfüllt.

Synchronisieren der privaten Schlüssel

In Kapitel 5 wird das synchronisieren de privaten Schlüssel via PEP Node beschriebe.

Meiner Meinung nach sollte die Synchronisation niemals automatisch erfolgen und immer eine bewusste Entscheidung des Benutzer sein. Es gibt keinen Bedarf für die Synchronisation eines privaten Schlüssels, wenn

• der private Schlüssel auf einer Smartcard / Token ist
• der Benutzer nur ein Endgerät benutzt
• der Benutzer dies nicht möchte

Was passiert, wenn der Key auf eine Smartcard ist? Wird dann der Stub synchronisiert?

Schlüssel Validierung

Die Herausforderung ist die Validierung der Schlüssel. Das trust-model pgp verwendet WoT in dem der Schlüssel einer anderen Person via Fingerprint geprüft werden muss. Danach wird öffentliche Schlüssel des Kommunikationspartners signiert. Durch die Eintragung einer owner-trust ist es möglich das WoT abzubilden.

Der Nachteil bei diesem Konzept ist, dass es einfach keiner macht. Für diejenigen, die schon mit OpenPGP arbeiten, sollt das Modell kein Problem sein. Eine Kommunikation mit einem Kommunikationspartner kann in diesem Fall nur statt finden, werde der Schlüssel des Kommunikationspartner zertifiziert wurde.

Für die Benutzer, die mit der Schlüsselverwaltung nicht zu tun haben wollen, könnt man versuchen dies über ein eigenes trust-model abzubilden. Ich habe dies jedoch selber noch nicht ausprobiert, und müsste man erst einmal validieren.

Annahme: Gehen wir mal davon aus, dass wir das gleiche Homedir und die gleichen Keyrings verwenden können, jedoch einen andere trustdb. Wir nehmen die pgp TrustDB und verwenden diese mit dem trust-model pgp, wie man dies kennt. In einem "Nicht-Experten-Modus" wir man nun eine eigene Trust-Db verwenden, welche mit tofu oder tofu+pgp läuft.

Denkfehler: Ob man ToFu oder gpg verwenden, ist abhängig vom Anwender und nicht von der Anwendung. Wir gehen jetzt einfach mal davon aus, dass der Benutzer einfach gpg oder tofu+pgp benutzt.

Entweder der Anwender verwendet trust-model tofu+pgp oder trust-model pgp.

Beispiel

Ich versuche ein Text zu verschlüsseln:

echo "Test" | gpg --homedir /tmp/testpgp --trust-model pgp -r 66C40DE0782393BA65D23E6C8459A4A77CAFA894 --encrypt -a 

In diesem Fall kommt ein Meldung

gpg: 90ED0F38F201CF29: Es gibt keine Garantie, daß dieser Schlüssel wirklich dem angegebenen Besitzer gehört.

sub  rsa3072/90ED0F38F201CF29 2020-05-19 Name Name <rtfm@domain.tld>
 Haupt-Fingerabdruck  = 66C4 0DE0 7823 93BA 65D2  3E6C 8459 A4A7 7CAF A894
 Unter-Fingerabdruck  = 2A75 B79D 46E1 5655 39E4  CEC9 90ED 0F38 F201 CF29

Es ist NICHT sicher, daß der Schlüssel zu dem in der User-ID
Genannten gehört. Wenn Sie *wirklich* wissen, was Sie tun,
können Sie die nächste Frage mit ja beantworten

Diesen Schlüssel trotzdem benutzen? (j/N) 

Der Grund ist, dass der Schlüssel nicht signiert wurde.

Nutze ich jedoch ToFu:

echo "Test" | gpg --homedir /tmp/testpgp --trust-model tofu+pgp -r 66C40DE0782393BA65D23E6C8459A4A77CAFA894 --encrypt -a 

so ist die Verschlüsselung möglich.

Im Vergleich

gpg --homedir /tmp/testpgp --trust-model tofu+pgp -k 66C40DE0782393BA65D23E6C8459A4A77CAFA894 
gpg: WARNUNG: Unsichere Zugriffsrechte des Home-Verzeichnis `/tmp/testpgp'
pub   rsa3072 2020-05-19 [SC] [verfällt: 2022-05-19]
      66C40DE0782393BA65D23E6C8459A4A77CAFA894
uid        [  marginal ] Name Name <rtfm@domain.tld>
sub   rsa3072 2020-05-19 [E] [verfällt: 2022-05-19]

gpg --homedir /tmp/testpgp --trust-model pgp -k 66C40DE0782393BA65D23E6C8459A4A77CAFA894 
gpg: WARNUNG: Unsichere Zugriffsrechte des Home-Verzeichnis `/tmp/testpgp'
pub   rsa3072 2020-05-19 [SC] [verfällt: 2022-05-19]
      66C40DE0782393BA65D23E6C8459A4A77CAFA894
uid        [ unbekannt ] Name Name <rtfm@domain.tld>
sub   rsa3072 2020-05-19 [E] [verfällt: 2022-05-19]

Ich habe gestern einen ersten Prototyp von eagle auf codeberg hochgeladen.

Der Prototyp hat aktuell eine sehr einfache Implementierung von

• Lesen der Adressen von abook
• Lesen von VCard Dateien aus einem Verzeichnis
• Lesen der Informationen aus einem GnuPG Keyring
• Lesen der Kontakte aus einem XMPP Roster
• Schreiben einer signierten und verschlüsselten Nachricht via XEP-0373: OpenPGP for XMPP

Mehr Informationen und Screenshots sind im Wiki: https://codeberg.org/xmpp-messenger/eagle/wiki

#XMPP #eagle #OpenPGP #gnupg

Wir haben heute morgen Pre-Release 0.0.5 veröffentlicht. Hier sind ein paar Informationen und Screenshots Wiki - Usage

Wir haben das Programm in das Repository von Anoxinon e.V. verschoben. Das Programm findet ihr also hier: https://codeberg.org/Anoxinon_e.V./xmppc.

In der Version 0.0.4 hatten wir folgende Erweiterungen.

• Unterstützung einer Konfigurationsdatei, um verschiedene Accounts zu nutzen
• Änderungen im Format für die OMEMO device list / fingerprints (QR Code)
• Bugfixes

In der Version 0.0.5 haben wir jetzt folgende Erweiterungen:

• Abfrage von MAM (XEP-0313: Message Archive Management)
• Liste der Bookmarks (XEP-0048: Bookmarks)
• Abfrage von Discovery info und item (XEP-0030: Service Discovery)

#XMPP #xmppc #Linux

Hallo zusammen,

ich habe in xmppc zwei neue Funktionen eingebaut. Die Version ist mit 0.0.3 auf codeberg getagged.

• Implementation for XEP-0373: OpenPGP for XMPP.
• Module for XMPP Monitoring

XEP-0373: OpenPGP for XMPP

Mit dem Mode openpgp und dem Befehl signcrypt sollte es jetzt möglich sein, verschlüsselte und signierte XMPP Nachrichten via XEP-0373 zu verschicken.

XMPP Monitoring

Mit dem Mode monitor und dem Befehl stanza bekommt man die XML Daten angezeigt.

xmppc 0.0.3

Die aktuelle Version hat somit die folgenden Befehle:

xmppc --jid user@domain.tld --pwd "password" --mode roster list
xmppc -j user@domain.tld -p "password" -m roster list
xmppc -j user@domain.tld -p "password" -m roster export
xmppc -j user@domain.tld -p "password" -m message chat friend@domain.tld "Message"
xmppc -j user@domain.tld -p "password" -m pgp chat friend@domain.tld "Message"
xmppc -j user@domain.tld -p "password" -m openpgp signcrypt friend@domain.tld "Message"
xmppc -j user@domain.tld -p "password" -m omemo list
xmppc -j user@domain.tld -p "password" -m monitor stanza

xmppc 0.0.3
Usage: xmppc --jid <jid> --pwd <pwd> --mode <mode> <command> <parameters>
Options:
  -h / --help             Display this information.
  -j / --jid <jid>        Jabber ID
  -p / --pwd <password>   Passwort
  -m / --mode <mode>      xmppc mode

Modes:
  -m --mode roster      xmppc roster mode
    list                  List all contacts
    export                Exports all contacts

  -m --mode message     xmppc message mode
    chat <jid> <message>  Sending unencrypted message to jid

  -m --mode pgp         xmppc pgp mode (XEP-0027) 
    chat <jid> <message>  Sending pgp encrypted message to jid

  -m --mode omemo       xmppc omemo mode
    list                  List the device IDs and fingerprints

  -m --mode openpgp          xmppc openpgp mode (XEP-0373)
    signcrypt <jid> <message>  Sending pgp signed and encrypted message to jid

  -m --mode monitor     Monitot mode    stanza              Stanza Monitor
    monitor             microblog Monitor microblog (XEP-0277: Microblogging over XMPP)


Examples:
  Usage: xmppc --jid user@domain.tld --pwd "secret" --mode roster list
  Usage: xmppc --jid user@domain.tld --pwd "secret" --mode pgp chat friend@domain.tld "Hello"

Feedback (Verbesserungen, Fragen, Fehler) sind willkommen: Issue Tracker.

#XMPP #xmppc #OpenPGP #GnuPG

Ich habe ein Pre-Release für xmppc erstellt - Version 0.0.2. Leider hatte ich noch einen Fehler in der README.md, weshalb man am besten master nimmt.

Die Version ist auf Codeberg.

Die aktuelle Version sollte die folgenden Befehle können:

xmppc --jid user@domain.tld --pwd "password" --mode roster list
xmppc -j user@domain.tld -p "password" -m roster list
xmppc -j user@domain.tld -p "password" -m roster export
xmppc -j user@domain.tld -p "password" -m message chat friend@domain.tld "Message"
xmppc -j user@domain.tld -p "password" -m pgp chat friend@domain.tld "Message"
xmppc -j user@domain.tld -p "password" -m omemo list

Mode roster

Man kann sich mit dem Befehl list sich die aktuellen Kontakte anzeigen lassen, mit der Information über das Abonnement. Die export Funktion gibt nur die JIDs aus.

Mode message

Mit dem Befehl chat kann man eine Nachricht an ein Kontakt schicken.

Mode pgp

Mit dem Befehl chat kann meine eine Nachricht via OpenPGP (XEP 0027) verschlüsselt an einer Person verschicken. Die JID muss jedoch im lokalen Keyring sein.

Mode omemo

Mit dem Befehl list kann man seine Device ID Liste und Fingerprints anzeigen lassen.

#XMPP #xmmpc