These provide (a) a way to deal with random assortments of certs
and (b) avoid unnecessary error messages and warnings, according
to #1669 anyway, which this fixes.
The other invocations use it that way, and the only listener in trunk
which uses it (in mod_presence) expects it that way.
Passing the username of the JID from the removed entry causes incorrect
unavailable presence stanzas to be sent, allegedly kicking people off
MUCs.
Fixes#1121.
Likely affected rescheduling but have no reports of this.
After readding a timer, it would have been issued a new id. Rescheduling
would use the previous id, thus not working.
POSIX is quite explicit regarding the precedence of AND-OR lists [0]:
> The operators "&&" and "||" shall have equal precedence and shall be
> evaluated with left associativity. For example, both of the following
> commands write solely `bar` to standard output:
> false && echo foo || echo bar
> true || echo foo && echo bar
Given that, `prosody.version` target behaves as
((((((test -f prosody.release && cp ...) ||
test -f ...) &&
sed ...) ||
test -f ...) &&
hexdump ...) ||
echo unknown > $@)
In the case of release tarballs, `prosody.release` does exist, so the
first AND pair is executed. Given that it's successful, then the first
`test -f` in the OR pair is ignored, and instead the `sed` in the AND
pair is executed. `sed` success, as `.hg_archival.txt` exists, making
the second `test -f` in the OR pair ignored, and `hexdump` in the AND
pair is executed. Now, given that `.hg` doesn't exist, it fails, so the
last `echo` is run, overwriting `prosody.version` with `unknown`.
This can be worked around placing `()` around the AND pairs. Decided to use
conditionals instead, as I think they better communicate the intention
of the block.
[0]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_03
This may have mistakenly caused link-local addresses to be considered
global. May have caused mod_s2s and prosodyctl check dns to behave
incorrectly on networks using link-local IPv4 addresses. By my
guesstimate, these are extremely rare. Probably minimal impact beyond
a bit longer to establish s2s and some possible confusion from
prosodyctl check dns results.
Ref RFC 3927
Originally added in 202b9951b037 but util.pubsub gained a better method
in 6c2c2fc4b8dd since then, which mod_pep uses since 9194431b6447 which
should have deleted this.
All these :create calls would have failed with a 'conflict' error, since
the nodes had already been created. This was never noticed because of
missing error handling.
Also note that this code did not restore node configuration.
The goal is to allow module:provides("foo-bar") with a mod_foo_bar_ prefix
being stripped. It will break any existing modules that use a prefix and have
hyphens instead of underscores. No such modules are known.
This may in theory cause multiple disconnect events for the
adminstream client, if the only code using that wasn't calling
os.exit right away.
Hence, this should be a good enough partial fix for #1671. It is
not a full fix, because the shell will only notice the disconnect
after one has hit enter in the input; until then, it is stuck in
a read() call to stdin and completely oblivious to the disconnect.
It could have been resumed without going into hibernation first, i.e.
when the client notices the disconnect before the server, or if it
switches networks etc.
With mod_smacks, a session can outlive the connection, so whether the
event is fired should not hinge on whether the session is connected or
not.
Helps mod_smacks remove some state.
Still having the connection on the session may cause unintentional
behavior, such as the session being treated as if connected, even tho
the connection has been closed.
To ensure that if a session is replaced after it has gone into
hibernation, it does not come back and cause trouble for the new session
(see previous commit).
