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.
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.
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.
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.
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.
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
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)
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.
Beim Verwenden von OpenPGP in XMPP sehe ich die folgenden Anwendungsfälle:
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.
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
Was passiert, wenn der Key auf eine Smartcard ist? Wird dann der Stub synchronisiert?
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
.
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
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.
In der Version 0.0.5 haben wir jetzt folgende Erweiterungen:
#XMPP #xmppc #Linux
Hallo zusammen,
ich habe in xmppc zwei neue Funktionen eingebaut. Die Version ist mit 0.0.3 auf codeberg getagged.
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.
Mit dem Mode monitor
und dem Befehl stanza
bekommt man die XML Daten angezeigt.
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
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.
Mit dem Befehl chat
kann man eine Nachricht an ein Kontakt schicken.
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.
Mit dem Befehl list
kann man seine Device ID Liste und Fingerprints anzeigen lassen.
#XMPP #xmmpc
Ich habe jetzt den ersten Entwurf für ein OMEMO Mode. Die Implementierung werde ich am Wochenende dann mal hochladen. Die aktuelle Version kann die OMEMO Device Liste und den jeweiligen Fingerprint abfragen.
./xmppc --jid user@domain.tld --pwd $(pass domain.tld/user) --mode omemo
Device List
1153934601
1480538744
Fingerprint: 470fccf344701d5c3d839106780734e5ef26178276bddc82681c0460e0dbe47c
Fingerprint: d6c257137b6f6e4a455806aa50a39edb0722a2f34e79cf141375c14a525a6707
Danach kann man den Befehl in Kombination mit gpg verwenden:
./xmppc --jid user@domain.tld --pwd $(pass domain.tld/user) --mode omemo| gpg --clear-sign --sign-with 123ABCMEINOPENPGPKEY1234 > omemo.asc
In der omemo.asc
sind dann die mit GnuPG signierten Device IDs und der jeweilige Fingerprint.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Device List
1153934601
1480538744
Fingerprint: 470fccf344701d5c3d839106780734e5ef26178276bddc82681c0460e0dbe47c
Fingerprint: d6c257137b6f6e4a455806aa50a39edb0722a2f34e79cf141375c14a525a6707
-----BEGIN PGP SIGNATURE-----
skljadlkasjdlkasjdkasjdkasdj
[....]
jdsakdjkasjdkajsd kasd
-----END PGP SIGNATURE-----
xmppc, vielleicht ein hilfreiches Werkzeug für die Console. Ich hab mal angefangen ein kleines Programm in C zu schreiben. Vielleicht komme ich mal dazu, es nach und nach auszubauen.
Die Idee, ein kleines einfaches Programm zu schreiben, welches man als CLI Client für XMPP verwenden kann. Es verwendet libstrophe, was auch unter anderem von Profanity verwendet wird.
Aktuell kann es nur den roster (Kontaktliste) abfragen. Die Option -m / --mode ist dafür gedacht, die verschieden Funktionen von XMPP anzusprechen.
xmppc - command line interface (CLI) XMPP Client.
xmppc is a XMPP command line interface client. It's written in C and is using the xmpp library libstrophe.
The project is using GNU Automake.
aptitude install libstrophe-dev
./bootstrap.sh
./configure
make
xmppc -j user@domain.tld -p "password" -m roster list
Vielen Dank an die XMPP Entwickler für die großartige Arbeit an dem Protokoll, Clients und Server.
#ilovefs #xmpp
We are thrilled to announce the first release of Dino: Version 0.1. This marks an important milestone of the development process that started three years ago and already combined work of 30 contributors, including 4 summer of code students and multiple development sprints ...
Ich habe einige XMPP Projekte angefangen. Diese werde ich nach und nach ausbauen und erweitern. Die Programme sind in C/C++ geschrieben. Informieren werde ich über Movim, hier habe ich ein paar Gruppen erstellt.
Ein in C++ geschriebenes CGI Programm. Das Programm kann in einen Web-Server integriert werden und bietet dann eine Seite zum Einladen von Personen in XMPP.
Hier suche ich noch jemanden der mir bei CSS/HTML/Design helfen kann.
Die hawkbit Programme sind C++ Programme welche als XMPP lib gloox verwenden.
Hawkbit-Bot - ein XMPP Bot in C++ mit gloox.
hawkbit-info ist in C++ geschriebenes Programm, welches unter anderem gloox und boost verwendet. gloox ist eine C++ Bibliothek für XMPP.
Das Programm gibt einen Informationen zu einem XMPP Server, sowie Informationen zum aktuellen Account.
Nach der Angabe von JID und das Passwort, verbindet sich das Programm zum Server und meldet den Benutzer an. Danach kann der Anwender durch Befehle Information vom Server und Account abfragen.
XMPP basierte Aufgabenliste
RedSnapper soll ein XMPP Client werden. Der Fokus soll mehr auf PubSub liegen.
#XMPP #gloox #Development
Der neue XMPP Newsletter ist da: https://xmpp.org/2020/01/newsletter-14-january/
Ich habe jetzt mal einen Entwurf von meinem XMPP Handbuch hochgeladen.
Das Handbuch werde ich nach und nach erweitern.
Feedback ist willkommen
Der erste GTK Versuche für Task Liste mit XMPP XEP-0060 Publish-Subscribe
hawkbit-info ist ein XMPP Programm basierend auf gloox. Das Programm prüft den Status eines Server (supported XEPs) und gibt Informationen zu dem angegebenen XMPP Account.
Das Programm lässt sich wie eine Shell bedienen. Nach Angabe von Benutzer und Passwort verbindet sich das Programm zum Server. Danach kann der Anwender über die Befehle den XMPP Server / Account prüfen.
Das Projekt soll auch als Hilfestellung für die Programmierung von XMPP Anwendung mit gloox dienen.
Viel Spaß beim programmieren!
% ./hawkbit-info
JID: hawkbit@domain.tld
Passwort:
Connect...
Zertifikat
certificate: OK
Resource bind: HawkbitInfo OK
Server connected: OK
XMPP> help
bookmarks
xep
discover
exit
XMPP> xep
Discovering Information About a Jabber Entity
Identity Prosody (im)server
Identity Prosody (pep)pubsub
XEP-0092: OK
XEP-0050: OK
XEP-0021: OK
XEP-0030: OK
urn:xmpp:blocking: OK
XEP-0049: OK
XEP-0199: OK
XEP-0060: #publish OK
XEP-0077: OK
XEP-0202: OK
XEP-0160: OK
jabber:iq:roster: OK
XEP-0054: OK
Discovering the Items Associated with a Jabber Entity: domain.tld
Item (proxy.domain.tld)
Item (conference.domain.tld)
Item (search.domain.tld)
Item (upload.domain.tld)
Item (pubsub.domain.tld)
XMPP> discover
discoveringService
5
Discovering the Items Associated with a Jabber Entity: proxy.domain.tld
Discovering the Items Associated with a Jabber Entity: conference.domain.tld
Item room1 (room1@conference.domain.tld)
Item room2 (room2@conference.domain.tld)
Item room3 (room3@conference.domain.tld)
Discovering the Items Associated with a Jabber Entity: search.domain.tld
Discovering the Items Associated with a Jabber Entity: uploads.domain.tld
Discovering the Items Associated with a Jabber Entity: pubsub.domain.tld
Item (pubsub.domain.tld)rss_abc3
Item (pubsub.domain.tld)rss_abc2
Item (pubsub.domain.tld)rss_abc1
XMPP> exit
#XMPP #hawkbit
Das Codeberg Webhook Module vom hawkbit-bot.
Codeberg info via Webhook an den Bot. Der Bot schreibt die Info in einen XMPP MUC.