Cloudron Forum

@BenjaminJ you have to use something like https://docs.cloudron.io/packages/dolibarr/#manual-utf8mb4-migration to migrate an existing installation .

Hi @james, thank you very much for the quick implementation and for adding Queue Mode support to the Cloudron n8n package. I have tested it now, and the difference is very noticeable. The n8n UI stays stable and responsive while larger executions are running, and the workload can finally make use of multiple CPU cores through the worker processes. This is exactly the behavior I was hoping for. In my case, it makes larger workflows much more usable and stable compared to running everything in a single n8n process. Especially with workflows that process large amounts of data, Queue Mode helps a lot because the main process no longer gets blocked by all the execution work. So far, the setup works well for me. Being able to configure the number of workers through the Cloudron package is very useful, and I think this is a great improvement for people running heavier n8n workloads on Cloudron. Thanks again Cloudron team for the fast response and implementation!

@jdaviescoates Thanks. I can only confirm. Should have read the right posts. I get the feeling that LAMP-doable apps need their show window as well.

Hello Upstream reported that the issue will be resolved with the next release. https://github.com/ONLYOFFICE/DocumentServer/issues/3686#issuecomment-4631461296

@joseph Perfect

It also does Wireguard AND OpenVPN simultaneously, which is hella convenient

Thanks for the quick reaction!!

@girish Well, if developers like @luckow essentially maintain their own appstore, I fully agree. With all other community apps, you always risk going down the Yunohost way - a plethora of apps, many if not most unmaintained. Your USP is - inter alia! - that people can rely on well maintained apps. IMHO opinion, the goal should always be to maintain a broad-ranging, well maintained appstore. This is also relevant in a commercial scenario, where individuals/companies have to ascertain risks before implementing Cloudron („are those apps maintained and up-to-date?“).

Hello @umnz For context please read https://forum.cloudron.io/topic/14969/enabling-grist-enterprise-does-not-work and https://forum.cloudron.io/topic/14941/grist-is-now-available

@ekevu123 great report. Fixed in https://git.cloudron.io/platform/box/-/commit/c7b2e4d95e3ca00924d3ad11781303b479d787d8

This is fixed now. An error message saying File too large is displayed.

It's perfect. Thank you, @james !

@dark thanks for your report. I looked into them. For transparency, here is our assessment. All the reported issues require the attacker to already have an admin token / compromised admin password. All the issues below are not reproducible as a (compromised) normal user. Also. the issues were reproduced on the demo instance, which of course has the admin username/password displayed in public. We found the report to be thorough and with clear explanation on how to reproduce the problems. From our side, we ack the bugs and have made the following fixes: Problem: Full SSRF via applinks. This is about adding an internal IPs as an applink. Our analysis: Linking to internal apps is a legitimate feature. An applink is fundamentally a bookmark and there's nothing wrong with pointing it at 192.168.1.50 or an internal app. Applinks REST response only returns label and icon not contents of a site. You can't really infiltrate EC2 metadata etc and neither can you make non GET requests. Our fix: We have added a fix now to block server internal IPs like localhost and docker internal network. Problem: SQL injection via dynamic column names. This is about being able to send arbitrary field names in the REST APIs. Our analysis: Indeed, our query builders, should only use field names which are in the db and are part of an allow list. Our fix: We have added allow list to all our model code Problem: 2FA/TOTP BYPASS via skipTotpCheck: true Our analysis: I think this is because the demo instance does not allow you to set a TOTP. It doesn't show an error currently when this happens and leads the user to believe an OTP was set. For the demo server, we can't allow users to set a TOTP because it will make it unsuable for others. Our fix: We will show an error like we show in other places. But also, the password login routes have already been removed in Cloudron 10 (which is yet to be released). That route exists as a backward compat for the CLI. Cloudron only supports OIDC device auth for the CLI from Cloudron 10. Problem: Stored XSS via branding footer Our analysis: right. This issue has been present since ages and our demo instance always has someone putting some alert() or some stupid HTML in there periodically... Our fix: We give in to the non-stop reports about this... We use dompurify now. Thanks for the report again. Very clear and solid notes. I also took the chance to update https://www.cloudron.io/security.html and https://www.cloudron.io/.well-known/security.txt