Bug#1003696: prosody: CVE-2022-0217: Unauthenticated Remote Denial of Service Attack in the WebSocket interface

[Matthew Wild]

Hi folks,

This is a link to the upstream patch for our 0.11.x series:
https://hg.prosody.im/0.11/raw-rev/783056b4e448

Let me know if you have any questions!

Regards,
Matthew (Prosody developer)

Bug#827689: prosody: Also search plugins in /usr/local?

[Matthew Wild]

On 25 April 2018 at 14:27, Sergei Golovan  wrote:
> Hi Elrond,
>
> On Sun, Jun 19, 2016 at 8:03 PM, Elrond
>  wrote:
>>

>> So could you add the following to the default
>> prosody.cfg.lua?
>>
>> -- Also search for plugins/modules here:
>> plugin_paths = { "/usr/local/lib/prosody/modules" }
>>
>> You might also want to create that path?
>>
>
> Seems reasonable to me. If there's no objections from the other maintainers,
> I could do that for 0.10.0-2.

I think that's a great idea.

>> While you're at it, could you please remove the example.com
>> section from the main prosody.cfg.lua? It was moved into
>> the conf.avail/example* file anyway. We don't need the
>> example stuff two times, really.
>
> Again, seems okay to me. We should add a note on where to find the
> example config though (in /etc/prosody/conf.avail/*).

Agreed.

Regards,
Matthew

Bug#851464: suggest/recommend python-bcrypt (provides bcrypt auth backend)

[Matthew Wild]

I can confirm Prosody doesn't do bcrypt. It would be possible to make
such a backend as a plugin, and someone possibly already has, but it's
not in the prosody package, and we don't depend on any bcrypt library.

On 10 October 2017 at 12:31, Victor Seva
 wrote:
> I don't see any reference of bcrypt at [0]
>
> [0] https://prosody.im/doc/modules/mod_auth_internal_hashed
>
> And I would assume you meant lua bcrypt [1] witch is not even packaged
>
> [1] https://github.com/mikejsavage/lua-bcrypt

Bug#846470: prosody: fails to check incoming certificates valididy

[Matthew Wild]

Thanks for the report. This is an upstream bug in 0.9.11 when used
with LuaSec 0.6. Patch is here:
https://hg.prosody.im/0.9/rev/2a7b52437167

We're working on a 0.9.12 release with the fix.

Bug#842963: Please provide 0.10 (future) in experimental

[Matthew Wild]

On 3 November 2016 at 09:20, Daniel Scharon
 wrote:
> maybe as a separate package 'prosody-0.10' like upstream does?
> http://packages.prosody.im/debian/pool/main/p/prosody-0.10/
> that way an eventual upload to unstable could be possible as well.

With my upstream hat on, I'd prefer not having package name collisions
with our upstream repository. Our repository provides automated
nightly builds, and when people install 'prosody-0.10' that's what
they believe they are getting.

A prosody-0.10 package in Debian would require manual updates to keep
up with upstream, so people who thought they had the latest automated
build may actually have an outdated build. This would make user
support harder for us.

I'm not against packaging 0.10, however. We are aiming to release the
first beta this month.

Regards,
Matthew

Bug#836236: prosody: doesn't try IPv4 when IPv6 fails

[Matthew Wild]

On 31 August 2016 at 23:25, Cyril Brulebois  wrote:
> So it looks to me like it could be an initial DNS issue (partial and/or
> no resolution depending on the domain) which happened at start-up time,
> and failed/incomplete resolutions weren't attempted again later on.
>
> Would this seem even remotely plausible?

Yes, this is plausible. I've seen this issue before on some servers,
but I haven't been able to track it down to a cause. One theory is
that if you log into a freshly-started server, and you have a lot of
contacts on remote domains, it triggers a burst of DNS requests. DNS
being UDP, which is lossy, some of the DNS requests fail due to packet
loss caused by temporary network congestion.

Whether that theory is plausible I'm not sure - it doesn't seem like
it would be *that* much traffic to deal with. Perhaps there are some
queue sizes or something we could tweak if that is the problem though.

Eventually the failed s2s connections do establish - they will be
retried as soon as you change status for example, or if any of your
remote contacts change status or try to send you a message.

Bug#836236: prosody: doesn't try IPv4 when IPv6 fails

[Matthew Wild]

Hi Cyril,

Thanks for the report. Can you please bump your log level up to
'debug' (there should be comments in your config file explaining how
to do this), and include those logs? The 'info' level logs tend to
give a high-level approximate view of issues, but only the debug logs
can be relied upon when debugging the low-level individual connection
attempts.

Thanks!

On 31 August 2016 at 22:16, Cyril Brulebois  wrote:
> Package: prosody
> Version: 0.9.7-2+deb8u3
> Severity: normal
>
> Hi,
>
> My server is trying to initiate a connection to crans.org, which has the
> following DNS bits set up:
> | _xmpp-server._tcp.crans.org. 466 IN   SRV 5 0 5269 xmpp.crans.org.
> |
> | xmpp.crans.org.   466 IN  A   138.231.136.66
> | xmpp.crans.org.   466 IN  
> 2a01:240:fe3d:4:200:42ff:fe42:4204
>
> Logs say:
> | Aug 31 23:02:18 s2soute11b40infoBeginning new connection attempt to 
> crans.org ([2a01:240:fe3d:4:200:42ff:fe42:4204]:5269)
> | Aug 31 23:02:18 s2soute11b40infoOut of connection options, can't 
> connect to crans.org
> | Aug 31 23:02:18 s2soute11b40infoSending error replies for 1 queued 
> stanzas because of failed outgoing connection to crans.org
>
> which is fair enough because:
>  - trying IPv6 first is the right thing to do;
>  - this port appears closed on IPv6 at the time of writing.
>
> But prosody should move to trying a connection on IPv4 instead of simply
> giving up and trying again a moment later.
>
> Thanks for your time.
>
>
> KiBi.

Bug#803396: [Debian-rtc-admin] Bug#803396: options for developers who don't want to use debian.org XMPP

[Matthew Wild]

On 6 November 2015 at 09:48, Rhonda D'Vine  wrote:
>  Hi,
>
> * Daniel Pocock  [2015-10-29 17:09:36 CET]:
>> If a developer has their own XMPP account elsewhere or simply doesn't
>> want to use it, any requests to be in their roster will simply not be
>> responded to.  Should we provide an option to automatically reject
>> requests sent to accounts that are not used or automatically give some
>> reply scripted by the developer?
>
>  I think a forward possibility would be useful.  The LDAP already has a
> field for Jabber ID.  I guess it might make sense to forward things to
> there; I'm not sure if it's possible to send stuff back somehow then
> though.

You're basically right. Forwarding could be done, but XMPP is not
email - it's not possible to forward with the same 'from' address, so
it would be a bit unintuitive. Likewise there's no way they could
reply back via debian.org to use the address as an alias.

There is a 'redirect' error we could use, however I don't know of
anyone using it in practice, which is a shame (it's a bit of a
chicken-and-egg problem). There were also some security concerns about
XMPP servers automatically following redirects on behalf of users.

Regards,
Matthew

Bug#743836: Breaks Tigase Messenger on Android

[Matthew Wild]

It would be helpful if you could test the following patch with Tigase
Messenger: https://hg.prosody.im/0.8/raw-rev/278489ee6e34

I have confirmed that it fixes Psi, so I'm pretty confident it will work.

Regards,
Matthew


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#743836: prosody: Login fails with 'Unhandled c2s_unauthed stream element: compress' although package lua-zlib is installed

[Matthew Wild]

Hi Oliver,

On 7 April 2014 08:27, Oliver Ladner waste+debian...@lugh.ch wrote:
 Package: prosody
 Version: 0.8.2-4+deb7u1
 Severity: normal

 Dear Maintainer,

* What led up to the situation?

  After updating to 0.8.2-4+deb7u1 (because of DSA-2895-1), client
  logins fail with the above error when compression is active.

What client are you using? Are you able to get an XML log from it up
to the point of failure?

Regards,
Matthew


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#656579: attempt to index field 'conn' (a nil value)

[Matthew Wild]

Hi Piotr,

On 20 January 2012 09:25, Piotr Ożarowski pi...@debian.org wrote:
 Package: prosody
 Version: 0.8.2-1~bpo60+1
 Severity: normal

 my /var/log/prosody/prosody.err contains (few times a day max) tracebacks like
 this one:

 | Jan 20 04:44:10 general error   Top-level error, please report:
 | /usr/lib/prosody/net/xmppserver_listener.lua:105: attempt to index field 
 'conn' (a nil value)

Thanks for the report.

If there are any useful lines immediately preceding the error in the
log, that would be useful. Look for messages related to closing an s2s
connection. If the messages are always about a particular remote
domain, or if there are no messages about closing an s2s connection,
that's useful information also. Enabling debug logging for a while
would also be helpful.

Many thanks,
Matthew



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#622638: more information

[Matthew Wild]

On 13 April 2011 16:18, Antoine Beaupre anar...@koumbit.org wrote:
 Here are some good tips for the update:

 http://prosody.im/doc/packagers


Thanks, I wrote the tips and they have already been incorporated into
the package ;)

I believe the 0.8 package is ready for upload, however LuaDBI is not
packaged yet (and annoyingly the author may be MIA, I was hoping for a
new release).

Regards,
Matthew



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#620882: prosody: incomplete filetransfer with mod_proxy65

[Matthew Wild]

Hi Michael,

On 4 April 2011 21:27, Michael Trunner mich...@trunner.de wrote:
 Package: prosody
 Version: 0.7.0-1~bpo50+1
 Severity: important


 What steps will reproduce the problem?
 1. transfer a file with the help of mod_proxy65
 2. sender said successful
 3. receiver says sender aborts


 What is the expected output? What do you see instead?
 Receiver should receive complete file.

 Additional information below:
  * Some bytes were missing (less then 1k).
  * Without mod_proxy65 file transfer is complete
  * tested with different xmppl-cients (Adium, PSI, Gajim, Pidgin) all the same
  * Upstream Version _works_ for me ( 
 http://prosody-modules.googlecode.com/hg/mod_proxy65/mod_proxy65.lua )


See my response to your issue on http://prosody.im/bugs/230 - the
issue (and a bunch of others) should be fixed as soon as we upload
0.8.0, which I'm currently working on.

Also note that the mod_proxy65 in the prosody-modules repository is an
older version than the one that is shipped with Prosody. It is much
less efficient than the included one, but is kept available for older
Prosody versions that did not include it yet. It works because it
bypasses the problematic code in Prosody 0.7.

Regards,
Matthew



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#614175: Can't run after install

[Matthew Wild]

On 20 February 2011 09:33, Julien PUYDT julien.pu...@laposte.net wrote:
 Hi,

 Le 20/02/2011 10:19, Matthew Wild a écrit :


 I did try to dpkg --purge, check there was nothing left then apt-get install
 again -- always for the same result.


Ok, changing tack a little. It seems liblua5.1-filesystem0 was updated
in sid a few days ago, and isn't entirely backwards compatible as the
changelog suggests. Granted, what changed would probably be classed as
a private API.

The code that breaks in Prosody is an adopted 3rd-party library. It's
already been removed in the next version which is currently in RC. I
suspect an upload of that is the best fix for this.

Thanks!
Matthew



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#614175: Can't run after install

[Matthew Wild]

Hi Julien,

On 20 February 2011 08:01, Julien PUYDT julien.pu...@laposte.net wrote:
 Package: prosody
 Version: 0.7.0-1
 Severity: grave

 apt-get install prosody leads to :

  * Starting Prosody XMPP Server prosody

 **
 A problem occured while reading the config file /etc/prosody/prosody.cfg.lua
 Error: /usr/share/lua/5.1/prosody/util/ztact.lua:34: bad argument #1 to 'it'
 (directory metatable expected, got no value)

 More help on configuring Prosody can be found at
 http://prosody.im/doc/configure
 Good luck!
 **


What is the output of `ls -la /etc/prosody` ?


 Which means the package is unusable as-is -- hence setting severity to
 grave. I don't knwo lua enough to know how bad that error is :-/


Generally the packages just work, I've only encountered one case
before where they didn't, and if I recall that was because someone had
been playing round with custom installations of Prosody before
installing them.

Thanks,
Matthew



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#580185: pid file attack can be used to kill arbitrary processes

[Matthew Wild]

Excerpts from Joey Hess's message of Tue May 04 06:43:01 +0100 2010:
 

 Note that beyond the possibility this could be used as a security
 hole, things go wrong, pid files end up with stale data in them.
 Blindling killing w/o checking is asking for trouble.
 

Valid points. Perhaps a solution would be to switch the init script to
using prosodyctl, which checks that the pidfile is locked before killing -
Prosody (as of 0.6.2) keeps the pidfile locked during running, and removes
it on shutdown.

This would just leave a corner case when Prosody crashes, and leaves a
stale pidfile, or as you suggest, the prosody user is completely compromised.
However since prosodyctl always switches to the prosody user before killing,
this shouldn't be a problem?

On the other hand - wouldn't just passing -exec /usr/bin/prosody to s-s-d
fix everything anyway?

Thoughts?

Thanks,
Matthew



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org