OpenFire (XMPP server)

[robi]

@guusdk Actually, I am being much more general than this specific issue.

I have no stake in it, as I don't use OpenFire yet, however reading about how any plugin can create files and folders in the home dir, that is as you agreed, less than optimal and a potential security issue via overwriting core files.

If that is not a concern, I'm sure a code audit would bring up other useful architectural changes.

If you're familiar with Wordpress, these are the categories of things they needed to address early on in their popularity, which still remains today.

[potemkin_ai]

@guusdk if I may ask, do you do/have or plan to make OpenFire containerized?

From what it seems, the issue is caused by a requirement that comes from container-based app development (i.e. Docker in our case).

[potemkin_ai]

@LoudLemur thank you, it's nice of you for mentioning that

[potemkin_ai]

@girish , @nebulon , what's your thoughts on that? Could you possibly accept the app under a beta status, so that we could check the approach implemented in my package?

[nebulon]

I took another look now at the repo, is https://git.cloudron.io/cloudron/openfire-app still the one? Is there any specific reason why there are these patch files?
Also is that README still current? I don't think we will publish a package which relies on other docker hub accounts as we had issues with such dependencies a long time ago and thus decided that we will always put images in our account to ensure users can install and restore apps even if that 3rdparty is gone.

[potemkin_ai]

@nebulon thank you.

The patches make OpenFire more Docker-friendly by separating code, configs, and data.

On the docker file - I don't know the way it works, in my head, it was that you would adjust all of the things and will push docker image into some Cloudron registry.

I don't mind any changes required to be done with the code to make it a proper Cloudron citizen

[nebulon]

@potemkin_ai to be honest this package is not even based on our base image for apps.

Given that I don't have any background info on the other patch files, it might be better if you could copy and paste the relevant Dockerfile lines into a Dockerfile based of the base image and we start working out entrypoint scripts for Cloudron from that on.
Based on our experience sharing package related things like Dockerfile and start scripts always creates more work on all sides and is much less robust.

Especially patching upstream code will cause a lot of headache further down the road when we have to provide working updates.

[nebulon]

Oh since we have the/an upstream author here maybe there is a chance to workout why that upstream patch is required and what the implications would be. If the app works fine with that patch, maybe it should be first changed upstream?

[potemkin_ai]

@nebulon I'm sorry to hear that...

You mentioned Cloudron Dockerfile, but I can't recall I have seen any reference to the 'Cloudron Dockerfile', that shall be used, if someone wants to package an app for the AppStore with you.

I'm not a fan of patching myself, but I can't see how this specific app could work some other way here - please, see the discussion above.

[potemkin_ai]

@nebulon @guusdk answer seems to be quite pessimistic about that:

For me, the cost vs. weight doesn't balance.