Fix a memory leak caused by improper usage of
xmpp_stanza_new()/xmpp_stanza_release() by replacing usage with the
simpler xmpp_message_new()/xmpp_message_set_body() API available in
libstrophe 0.9.0, as advised by @pasis.
Fixes https://github.com/msantos/xmppipe/issues/3.
Support chat marker (XEP-0333) stanzas when the "--chat-marker" switch
is provided on the command line. A chat marker is prefixed by 'M':
~~~
M:groupchat:test@conference.example.com/msantos:me@example.com/162315501161646113068402:
~~~
The idea is to allow scripts to react based on whether a message has
been read, for example, escalating via other channels.
An empty string in the type, to and from uses a default value. For
example to send a message to the groupchat specified on the command
line:
~~~
m::::this is a test message
~~~
Rough implementation to allow input to be formatted as colon separated
values in the same way as output:
* percent decoding of the input is not supported yet
* only message stanzas supported
Using formatted input lets the script respond to other users aside from
the default channel assigned to stdout:
~~~
m:chat:to@example.com:from@example.com:message-body
~~~
TODO:
* does the default stdout channel always need to be formatted?
~~~
m:chat:to@example.com:from@example.com:message-body
m:groupchat:default@conference.example.com:from@example.com:message-body
~~~
Otherwise it could be ambiguous.
* support presence and iq stanzas
For example, a bot could respond to groupchat invitations.
* percent decoding: require the input to be percent encoded
Support binary and multiline data.
* format naming: choose better names for the format types
Instead of supplying the output JID as an optional argument:
xmppipe --output foo@conference.example.com
Use the first argument:
xmppipe foo@conference.example.com
The -o/--output switches are still accepted.
Add preliminary support to one to one chats. No XEPs were read in the
preparation of this change:
xmppipe -C example@example.com
TODO
* clean up
* state change is hardcoded
* if (GROUPCHAT) branches
* autodetect MUC
* in chat mode, ctrl-D can cause a loop
libstrophe 0.9.2 supports TLS certificate verification. Tested by:
* valid certificate: verified using strace that xmppipe is reading the
system SSL cert store
* invalid certificate:
sudo chmod 700 /usr/lib/ssl
Verified xmppipe rejected the cert as invalid without the local CA
root.
* valid certificate, invalid domain
Verified a subdomain hosted on the XMPP node but not included in the
TLS certificate is rejected.
Add a sandbox enforced before options are parsed and the connection is
established to the XMPP server. This sandbox will allow network
operations.
The post-connect sandbox is unchanged and restricts operations to stdio.
The commit just adds the infrastructure for the pre-connect sandbox.
The number of file descriptors enforced by setrlimit() can now be set at
compile time using a flag. The flag defaults to 0 on Linux and -1
everywhere else:
XMPPIPE_SANDBOX=XMPPIPE_SANDBOX_RLIMIT \
XMPPIPE_SANDBOX_RLIMIT_NOFILE=-1 \
make
The meaning of the XMPPIPE_SANDBOX_RLIMIT_NOFILE is:
* -1 : set rlim_cur/rlim_max to the lowest allocated file desciptor
* >=0: set rlim_cur/rlim_max to this number
On some platforms, setting rlim_cur below the value of the highest
allocated fd may interfere with polling. See commit a34d5766c5 for
details.
Prepare for sandboxing the xmppipe process by adding a function called
after all file descriptors are allocated.
The intent of the sandbox is to limit the xmppipe process to the role
of a component in a shell pipeline: reading from stdin, reading/writing
to the XMPP socket and writing to stdout. Any activity not involved with
using stdio should force the process to exit.
The sandbox function will vary based on the capabilities of the
platform. The default sandbox function does nothing.
Limitations of the sandbox:
Probably the biggest risk is in session establishment:
* the TLS handshake
* the XML parsing
The sandbox is enforced after the TLS connection is established, i.e.,
after the file descriptor for the XMPP session is allocated and so has no
effect on the TLS handshake or the initial XMPP handshake.
Possibly an initial sandbox could be setup for the connection phase
followed by a stricter sandbox for the stdio phase.
Use uuid_create(3) and uuid_to_string(3) to create the message id on
BSDs. Only tested on FreeBSD but should work on OpenBSD and NetBSD.
Add untested support for compiling on Solaris and Mac OS X:
* SmartOS has libuuid installed by default with rsyslog via pkgsrc
* Mac OS X has libuuid as part of libSystem:
http://lists.apple.com/archives/unix-porting/2009/Aug/msg00006.html