Difference between revisions of "User:Moparisthebest/Council Candidacy 2023"
(Created page with "== Contact == * Name: Travis Burtrum * Nickname: moparisthebest * github: [https://github.com/moparisthebest moparisthebest] * fediverse: [https://moparisthe.best/moparisthebest moparisthebest@moparisthe.best] * XMPP address: [xmpp:travis@burtrum.org travis@burtrum.org] * Email address: [mailto:travis@burtrum.org travis@burtrum.org] == About Me == I'm just your average programmer interested in open source, federation, e2e encryption, and running my own services to avoid...") |
|||
| Line 15: | Line 15: | ||
If I had to pick a goal/passion when it comes to XMPP, it would have to be connectivity. After all, if a user is faced with a "cannot connect" error, nothing else matters. A very close second is security, I won't accept any XEP with "Security Considerations" of "todo", not all XEPs require them, but all XEPs require they are at least considered. | If I had to pick a goal/passion when it comes to XMPP, it would have to be connectivity. After all, if a user is faced with a "cannot connect" error, nothing else matters. A very close second is security, I won't accept any XEP with "Security Considerations" of "todo", not all XEPs require them, but all XEPs require they are at least considered. | ||
[https://www.moparisthebest.com/slides/xmpp-connectivity-security-13JUL2023.html here] is a slides and a video of a talk I did on XMPP security and connectivity at FOSSY this year. | |||
== Security == | == Security == | ||
Latest revision as of 02:53, 25 October 2023
Contact
- Name: Travis Burtrum
- Nickname: moparisthebest
- github: moparisthebest
- fediverse: moparisthebest@moparisthe.best
- XMPP address: travis@burtrum.org
- Email address: travis@burtrum.org
About Me
I'm just your average programmer interested in open source, federation, e2e encryption, and running my own services to avoid reliance on 3rd parties.
I've served two terms on the council so far.
I've written 4 XEPs that were accepted, XEP-0368, XEP-0418, XEP-0467, XEP-0468 and one that was not HACX.
If I had to pick a goal/passion when it comes to XMPP, it would have to be connectivity. After all, if a user is faced with a "cannot connect" error, nothing else matters. A very close second is security, I won't accept any XEP with "Security Considerations" of "todo", not all XEPs require them, but all XEPs require they are at least considered.
here is a slides and a video of a talk I did on XMPP security and connectivity at FOSSY this year.
Security
I sometimes find security problems in XMPP protocols or implementations:
- eatxmempp: CVE-2021-32918, and wrote xmpp-proxy to both mitigate that, and experiment with various XMPP transports, including QUIC, S2S-over-WebSocket, and more
- httppppppppppp-upload: Full drive exploit - affecting most HTTP-upload capable clients
- XEP-0156 _xmppconnect is vulnerable to MITM - affecting all websocket clients that used _xmppconnect, some had CVEs CVE-2022-26491 etc
Council Goals
Accept Early Accept Often: ProtoXEPs should be accepted as experimental if they solve a problem and are clearly written (ie, someone can read this and implement it). It doesn't matter if they solve a problem another XEP has already attempted to solve but in a different way. It's not council's job to decide which way is better, that decision should be left up to "running code" (ie implementations).
What follows from that is XEPs that have stood the test of time and are widely implemented need moved to Stable aggressively, and XEPs that have been abandoned need Deferred/Deprecated as appropriate.