Unwanted namespace added in stanzas

Hi all,

I’m having a weird issue when receiving message stanzas with custom extensions. Basically I’m adding a Signature to my messages as an extension, but when I inspect the receiving client I’m seeing the same namespace added everywhere in the extension (xmlns:stream="http://etherx.jabber.org/streams")

Here are some examples :

  • Message sent:
<message xmlns="jabber:client" to="admin@..." id="wDCIQ-100" type="chat">
<thread>IztSV7</thread>
<body>df</body>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
        <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
        <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
        <Reference URI="">
            <Transforms>
                <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
                    <XPath>ancestor-or-self::*[local-name() = 'body']</XPath>
                </Transform>
                <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
            </Transforms>
            <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
            <DigestValue>...</DigestValue>
        </Reference>
    </SignedInfo>
    <SignatureValue>
      ...
    </SignatureValue>
    <KeyInfo Id="idb0d8dd8e-bf19-4361-8755-aab1b4186d51">
        <X509Data>
            <X509Certificate>
              ...
            </X509Certificate>
        </X509Data>
    </KeyInfo>
</Signature>
<x xmlns="jabber:x:event">
    <offline/>
    <composing/>
</x>
<active xmlns="http://jabber.org/protocol/chatstates"/>
</message>
  • Message received (note the xmlns:stream="http://etherx.jabber.org/streams" everywhere in the Signature extension):
<message xmlns="jabber:client" to="admin@..."
         from="admin@.../Spark 2.9.0" id="wDCIQ-100" type="chat">
    <thread>IztSV7</thread>
    <body>df</body>
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#" xmlns:stream="http://etherx.jabber.org/streams">
        <SignedInfo xmlns:stream="http://etherx.jabber.org/streams">
            <CanonicalizationMethod xmlns:stream="http://etherx.jabber.org/streams"
                                    Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
            <SignatureMethod xmlns:stream="http://etherx.jabber.org/streams"
                             Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <Reference xmlns:stream="http://etherx.jabber.org/streams" URI="">
                <Transforms xmlns:stream="http://etherx.jabber.org/streams">
                    <Transform xmlns:stream="http://etherx.jabber.org/streams"
                               Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
                        <XPath xmlns:stream="http://etherx.jabber.org/streams">ancestor-or-self::*[local-name() =
                            'body']
                        </XPath>
                    </Transform>
                    <Transform xmlns:stream="http://etherx.jabber.org/streams"
                               Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </Transforms>
                <DigestMethod xmlns:stream="http://etherx.jabber.org/streams"
                              Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <DigestValue xmlns:stream="http://etherx.jabber.org/streams">
                    ...
                </DigestValue>
            </Reference>
        </SignedInfo>
        <SignatureValue xmlns:stream="http://etherx.jabber.org/streams">
            ...
        </SignatureValue>
        <KeyInfo xmlns:stream="http://etherx.jabber.org/streams" Id="idb0d8dd8e-bf19-4361-8755-aab1b4186d51">
            <X509Data xmlns:stream="http://etherx.jabber.org/streams">
                <X509Certificate xmlns:stream="http://etherx.jabber.org/streams">
                    ...
                </X509Certificate>
            </X509Data>
        </KeyInfo>
    </Signature>
    <x xmlns="jabber:x:event">
        <offline/>
        <composing/>
    </x>
    <active xmlns="http://jabber.org/protocol/chatstates"/>
</message>

My signature core validation fails on reception because the signature itself has changed (the added namespace is everywhere). Any ideas where that comes from ? It’s even weirder to me I did not encouter this earlier in my work, it seems to have appeared out of nowhere (I must’ve done something obviously, but I really can’t figure out what).

I’m going to try and reinstall both Spark and Openfire to see if that fixes it

I can’t immediately explain this. Can you inspect stanzas server-sided (using something like wireshark, or the XML debugger plugin for Openfire)? It would be useful to know if these namespaces are added by Spark (outbound), Openfire, or Spark (inbound).

For info, reinstalling both Spark and Openfire did not fix the issue (I thought it could be some configuration causing it).

I’ll check out Wireshark to find out where this is added and come back to you. As a sidenote, I have another functionality where I’m adding a security label as an extension (XEP 0258), and it doesn’t meet the same issue. There must be something different I’m doing but I’m missing it

Are you using some kind of custom XML parser that’s misconfigured, namespace-handling wise?

Ok so I just inspected stanzas going through the network, and Openfire is definitely not adding the namespace, so it must be the Spark client on the receiving end. We are using XML parsers on reception, but they come into play in our implementation of the org.jivesoftware.spark.ui.MessageFilter.filterIncoming method, so that should not modify the stanza I see in the Smack debugger right ?

I’m not able to conclusively tell you that. I expect not.

Update: in the “Raw Received Packets”, I’m seeing a message stanza without the namespace added, when I still see it in the “All packets” tab in Smack, so there must be something going on here.

I must say, my experience fiddling with the Message message in the org.jivesoftware.spark.ui.MessageFilter.filterIncoming and org.jivesoftware.spark.ui.MessageFilter.filterOutgoing methods has been rather unpleasant so far, it feels like the only thing I can modify on that object for the latter is the extension I add to it. I tried to change the body of incoming messages in the former for instance with the setBody method, and I couldn’t get to do that somehow (it felt like it wasn’t really changed in my following code)

In the last release, Spark was updated to use a new version of the Smack library, that is significantly different from the version it was using up until that time. It is not unthinkable that the Spark API is more geared towards the older version - or it might simply have been a bit clunky all the time.

If you have suggestions, we’d definitely be open to changes to the API.

May this have to do with how I define my ExtensionElementProvider/ExtensionElement when I register it in Spark ? Maybe Spark uses those to try and parse incoming messages extensions to render them in the basecode… but then how could external Spark clients not declaring my provider use the extensions ?

Can you share a bit of example code that exposes the problem?

Ok I found the culprit, my ExtensionElement Providers were not defined correctly. I think Spark tries to parse extensions on reception based on the Providers it’s been registered on on init: this parsing seems to occur between Smack’s debugger raw received packet and “all packets” displays, so that’s where my diff came from.

I still have to figure out how Spark will react to unknown extensions (what if I send a message with an extension I registered on the sender client, but not on the receiver ?). If someone could chime in on that and confirm what I think is happening I’d really appreciate it :slight_smile:

That should be silently ignored, as that’s what the XMPP standard dictates.