[Standards] The Nasal Demons of MUC Avatars (XEP-0045 + XEP-0153 = Null Pointer Exception)
Hi,
a recent upgrade of some large ejabberd deployment made yaxim crash with
a Null Pointer Exception when opening the participant list of a MUC.
Further analysis has shown that the misbehavior is caused by the legacy
XMPP library I'm using interpreting the following stanza as a
participant presence from a nameless participant, and later crashing on
its namelessness:
87e8d7389eda7cbc0c095e101bee7564eeab9e62
http://jabber.org/protocol/caps"; hash="sha-1"
node="http://www.process-one.net/en/ejabberd/";
ver="eREyFCXd9aWVtXD7yPXJuVsFbKo="/>
In the context of XEP-0045, presence-from-the-MUC-bare-JID is undefined
behavior, so it is causing nasal demons [0] here.
While technically, this stanza does not contain the participant-tagging
`x{http://jabber.org/protocol/muc#user}` element, it *can* be
interpreted as a valid GC1.0 participant presence originating from a
nameless participant by a client supporting legacy GC1.0 protocol [1].
This is probably the interpretation taken both by yaxim[2] and by
poezio, which helpfully shows the nameless participant at the end of
the participant list.
To solve this misconception, I suggest two specific action items to be
taken:
- make[3] whoever is responsible for this write a short XEP / update
0045 / update 0153 to reflect this new use case.
- burn GC1.0 with fire and dance around the pyre.
Georg
[0] http://www.catb.org/jargon/html/N/nasal-demons.html
[1]
https://web.archive.org/web/2919185743/http://docs.jabber.org:80/jpg/x273.html
[2] a.k.a. I don't want to admit that my codebase is rotten.
[3] make = kindly ask.
signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
[Standards] Fwd: [new-work] WG Review: Messaging Layer Security (mls)
Hi all, Please take a look at the charter for this proposed IETF working group and consider getting involved! The XMPP community's experience with end-to-end encryption is extremely relevant here. Peter Forwarded Message Subject: [new-work] WG Review: Messaging Layer Security (mls) Date: Mon, 14 May 2018 07:04:18 -0700 From: The IESG To: new-w...@ietf.org A new IETF WG has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by 2018-05-23. Messaging Layer Security (mls) --- Current status: Proposed WG Chairs: Nick Sullivan Sean Turner Assigned Area Director: Benjamin Kaduk Security Area Directors: Eric Rescorla Benjamin Kaduk Mailing list: Address: m...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/mls Archive: https://mailarchive.ietf.org/arch/browse/mls/ Group page: https://datatracker.ietf.org/group/mls/ Charter: https://datatracker.ietf.org/doc/charter-ietf-mls/ Several Internet applications have a need for group key establishment and message protection protocols with the following properties: o Message Confidentiality - Messages can only be read by members of the group o Message Integrity and Authentication - Each message has been sent by an authenticated sender, and has not been tampered with o Membership Authentication - Each participant can verify the set of members in the group o Asynchronicity - Keys can be established without any two participants being online at the same time o Forward secrecy - Full compromise of a node at a point in time does not reveal past messages sent within the group o Post-compromise security - Full compromise of a node at a point in time does not reveal future messages sent within the group o Scalability - Resource requirements have good scaling in the size of the group (preferably sub-linear) Several widely-deployed applications have developed their own protocols to meet these needs. While these protocols are similar, no two are close enough to interoperate. As a result, each application vendor has had to maintain their own protocol stack and independently build trust in the quality of the protocol. The primary goal of this working group is to develop a standard messaging security protocol so that applications can share code, and so that there can be shared validation of the protocol (as there has been with TLS 1.3). It is not a goal of this group to enable interoperability/federation between messaging applications beyond the key establishment, authentication, and confidentiality services. Full interoperability would require alignment at many different layers beyond security, e.g., standard message transport and application semantics. The focus of this work is to develop a messaging security layer that different applications can adapt to their own needs. While authentication is a key goal of this working group, it is not the objective of this working group to develop new authentication technologies. Rather, the security protocol developed by this group will provide a way to leverage existing authentication technologies to associate identities with keys used in the protocol, just as TLS does with X.509. In developing this protocol, we will draw on lessons learned from several prior message-oriented security protocols, in addition to the proprietary messaging security protocols deployed within existing applications: o S/MIME - https://tools.ietf.org/html/rfc5751 o OpenPGP - https://tools.ietf.org/html/rfc4880 o Off the Record - https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html o Signal - https://signal.org/docs/ The intent of this working group is to follow the pattern of TLS 1.3, with specification, implementation, and verification proceeding in parallel. By the time we arrive at RFC, we hope to have several interoperable implementations as well as a thorough security analysis. The specifications developed by this working group will be based on pre-standardization implementation and deployment experience, generalizing the design described in: o draft-omara-mls-architecture o draft-barnes-mls-protocol Note that consensus is required both for changes to the current protocol mechanisms and retention of current mechanisms. In particular, because something is in the initial document set does not imply that there is consensus around the feature or around how it is specified. Milestones: May 2018 - Initial working group documents for architecture and key management Sep 2018 - Initial working group document adopted for message protection Jan 2019 - Submit architecture document to IESG as Informational Jun 2019 - Submit key management protocol to IESG as Proposed Standard Sep 2019 - Submit message protection protoc
Re: [Standards] Maintaining a list of ongoing conversations
> OK, is it based on PEP? No. > Why do you store message counters instead of the MAM ID of the last read message or a last read date? We store both. Counters are good to display number of read messages when you didn't load all the archive on that particular device. Like you missed a couple of hours of chat in busy groupchat and you certainly don't want to load all 9000 messages that were sent while you were away. But you do want to know how much you missed. -- Ненахов Андрей Директор ООО "Редсолюшн" (Челябинск) (351) 750-50-04 http://www.redsolution.ru ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Thoughts on MIX adoption (and will MIX ever happen?)
Le jeudi 10 mai 2018, 10:36:17 CEST Steve Kille a écrit : > Having made the latest round of MIX edits, I felt it was time to share > some thoughts on MIX. > > It has been a number of years since work was started on MIX, and > implementations are thin on the ground. It seems sensible consider when > and if this will change. > [SNIP] Interested in implementing MIX in SàT, but not a priority (and lacking resources). We have already blogging, comments, shared files and pictures based on pubsub/jingle. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Maintaining a list of ongoing conversations
Am 14. Mai 2018 12:40:31 MESZ schrieb "Ненахов Андрей" : >We are working on extension that we call by provisional name >'conversation >metadata' which is basically a list of all conversations with unread >messages counters and read/delivered markers. I believe that should >provide >functionality that does what you intend to. OK, is it based on PEP? Why do you store message counters instead of the MAM ID of the last read message or a last read date? -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Maintaining a list of ongoing conversations
Hi JC, This the topic I raised during last XMPP Summit in Brussels. I though I could create a protXEP about this, but I was too busy with commercial assignments. In MongooseIM we have such "inbox" almost implemented and delivered to one of our customers. The code which will soon be merged with MongooseIM's master branch is here: https://github.com/esl/MongooseIM/pull/1783/ Short examples are shown on https://github.com/esl/MongooseIM/blob/inbox/doc/modules/mod_inbox.md#example-request I know this is far from a protoXEP and is not based on PEP. I think this is good starting point for further discussion which we are open to! Best regards Michal Piotrowski michal.piotrow...@erlang-solutions.com On 14 May 2018 at 12:28, JC Brand wrote: > Hi folks > > I'm interested in finding a way to keep track of ongoing conversations and > whether any new messages were added to them since the user was last online. > > I think this is the so-called "Inbox" feature that was brought up at the > 2018 > summit. > > At the summit the suggested approach was a private PEP node with a list of > JIDs. > > Besides that, in order to know whether new messages were added to these > conversations (while the user was offline), we'll also need to store the > date of the last seen message. > > I imagine, if done right, that this functionality might in many cases > remove > the need for bookmarks as currently used. > > Is anyone already working on something like this? I'm not aware of a > relevant > protoXEP being created already. > > If not, I'm willing to create it. > > Regards > JC > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Maintaining a list of ongoing conversations
On Montag, 14. Mai 2018 12:28:17 CEST JC Brand wrote: > I'm interested in finding a way to keep track of ongoing conversations and > whether any new messages were added to them since the user was last online. > > I think this is the so-called "Inbox" feature that was brought up at the > 2018 summit. > > At the summit the suggested approach was a private PEP node with a list of > JIDs. > > Besides that, in order to know whether new messages were added to these > conversations (while the user was offline), we'll also need to store the > date of the last seen message. I’d prefer the MAM stanza-id, because that’s what should be used to sync anyways. Adding a date may be good if you want to show an overview though. > I imagine, if done right, that this functionality might in many cases remove > the need for bookmarks as currently used. > > Is anyone already working on something like this? I'm not aware of a > relevant protoXEP being created already. Not that I knew. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Maintaining a list of ongoing conversations
We are working on extension that we call by provisional name 'conversation metadata' which is basically a list of all conversations with unread messages counters and read/delivered markers. I believe that should provide functionality that does what you intend to. -- Ненахов Андрей Директор ООО "Редсолюшн" (Челябинск) (351) 750-50-04 http://www.redsolution.ru ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Maintaining a list of ongoing conversations
On 14 May 2018, at 11:28, JC Brand wrote: > > Hi folks > > I'm interested in finding a way to keep track of ongoing conversations and > whether any new messages were added to them since the user was last online. > > I think this is the so-called "Inbox" feature that was brought up at the 2018 > summit. > > At the summit the suggested approach was a private PEP node with a list of > JIDs. > > Besides that, in order to know whether new messages were added to these > conversations (while the user was offline), we'll also need to store the > date of the last seen message. > > I imagine, if done right, that this functionality might in many cases remove > the need for bookmarks as currently used. > > Is anyone already working on something like this? I'm not aware of a relevant > protoXEP being created already. > > If not, I'm willing to create it. I think this is around the same topic as Bind 2’s unread sync isn’t it? Part of the same thing, anywho. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Maintaining a list of ongoing conversations
Hi folks I'm interested in finding a way to keep track of ongoing conversations and whether any new messages were added to them since the user was last online. I think this is the so-called "Inbox" feature that was brought up at the 2018 summit. At the summit the suggested approach was a private PEP node with a list of JIDs. Besides that, in order to know whether new messages were added to these conversations (while the user was offline), we'll also need to store the date of the last seen message. I imagine, if done right, that this functionality might in many cases remove the need for bookmarks as currently used. Is anyone already working on something like this? I'm not aware of a relevant protoXEP being created already. If not, I'm willing to create it. Regards JC ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
