Cloudron Forum

Hi James,

yes! Following all the steps I outlined in the original post, I can see that the warnings are still produced in Mautic 7.1.3.

I'm afraid it's unavoidable. I remember that we wanted to use deSEC as our primary DNS provider, but ran into their rate limits fairly quickly a while ago when we were restoring a whole Cloudron instance. They are a non-profit registered association and are fully dependent on donations, so their limits are pretty low-ish. They won't adapt them for specific users (which is why we stopped using deSEC for SLA-critical domains), but you can ask them nicely and they can reset your limits - that helped us back then but that obviously isn't a feasible solution in your case.

I ran into an issue while packaging a Django app that performs strict certificate validation on the hostname when sending emails, installed on a Cloudron instance that uses an external SMTP relay (another Cloudron) for outgoing mail.

When requiresValidCertificate is set to true in the app manifest, Cloudron replaces the value of CLOUDRON_MAIL_SMTP_SERVER with the FQDN of the mail server, as described in the docs. The problem is that when the domain's mailing settings are configured to relay through an external SMTP server, Cloudron doesn't seem expose any mailing ports, so the app ends up trying to connect to a host that simply doesn't accept SMTP connections.

Steps to reproduce:

1. Configure a domain on Cloudron to relay outgoing mail through an external SMTP server
2. Install ntfy using that domain
3. Log in to the admin account and add an email address to it
4. The verification email will never be sent

ntfy doesn't appear to log an error in this case, the connection attempt to the SMTP server most likely just times out silently in the background.

Here's the security advisories for anyone interested:
https://github.com/metabase/metabase/security/advisories/GHSA-vwf4-m7j8-wcjf
https://github.com/metabase/metabase/security/advisories/GHSA-8hmm-hrhg-ppqp
https://github.com/metabase/metabase/security/advisories/GHSA-r8h2-qpfx-mx59

Interestingly, the GitHub Advisory Database includes links to the patched versions while GitHub Releases do not even show these (as of today). There must be a lot of chaos going on behind the scenes since their cloud offering was also breached and has affected fairly big customers (e.g. Framework): https://community.frame.work/t/framework-data-breach-discussion/83939

This app is a great candidate for the VPN Protection coming with Cloudron 10

HTMLPurifier appears to be trying to write into a directory that isn't writable on Cloudron's read-only fs:

PHP Warning - Directory /app/code/vendor/ezyang/htmlpurifier/library/HTMLPurifier/DefinitionCache/Serializer not writable.  - in file /app/code/vendor/ezyang/htmlpurifier/library/HTMLPurifier/DefinitionCache/Serializer.php - at line 295 []

It's only a warning so I'm not sure it actually breaks anything, but this does not look like an upstream bug. Writing into that directory seems to be standard HTMLPurifier behavior and their documentation covers it. There's also a report of the same issue in another Cloudron app: https://forum.cloudron.io/topic/15476/repeated-htmlprurifier-warnings

Steps to reproduce:

1. Install Mautic 7.1.2 (Package version 6.1.1)
2. Log in
3. Create a form
4. In the "Fields" tab, add a new "Number" field, keeping default settings by immediately clicking "Add" in the modal
5. Save the form
6. Open the terminal for the Cloudron app
7. Run cat /var/run/mautic/var/logs/mautic_prod-*.php

The error shows up in Mautic's error log a couple of times.

For a lot of configurations in LimeSurvey, their own documentation suggests editing the config.php file directly. Right now, this is copied to /run/limesurvey from /app/pkg on each restart - it would be great if we could place a config.php in /app/data/ so changes persist across restarts.

The quickest way would probably be an edit to start.sh:

if [[ -f /app/data/config.php ]]; then
    cp /app/data/config.php /run/limesurvey/config.php
else
    cp /app/pkg/config.php /run/limesurvey/config.php
fi

This could potentially break on app updates, so it might make sense to document it as an "at your own risk" feature.

I would absolutely advocate for re-adding X-Content-Type-Options: nosniff as long as we don't have a way to set headers directly in the Security Settings of Cloudron Apps (like we can with CSP headers). That header still provides meaningful protection against MIME-sniffing attacks and has widespread browser support.

Afaik, X-Permitted-Cross-Domain-Policies is still used by Acrobat (which is unfortunately far from dead), but I agree it's fair to remove it from the default configuration since it's an edge-case.

I just saw that you also removed X-Content-Type-Options as well as X-Permitted-Cross-Domain-Policies.

OWASP 1, 2 still recommends these headers so maybe it was a bit hasty to also remove them?

Thank you!

Cloudron currently sets X-XSS-Protection: 1; mode=block; (https://git.cloudron.io/platform/box/-/blob/master/src/nginxconfig.ejs#L110)

Mozilla's MDN documentation explicitly warns that "in some cases, X-XSS-Protection can create XSS vulnerabilities in otherwise safe websites" and advises to "avoid using it." Chrome removed the feature, and Firefox never implemented it. Only Internet Explorer fully supported it, and I think we're all glad that IE is not a thing anymore.

If I understand it correctly, the recommended approach is to either remove the X-XSS-Protection header entirely or explicitly set it to X-XSS-Protection: 0 to disable the legacy XSS filter in older browsers that might still honor it, then rely on properly configured CSP headers for actual protection.

Given that Cloudron supports CSP, I think there's no justification for keeping a deprecated header that introduces more risk than protection.

Would it be possible to add a status page location (https://nginx.org/en/docs/http/ngx_http_stub_status_module.html) to the default configuration file for Nginx? This would allow us to monitor the Nginx service more easily.

We have already integrated Cloudron into our monitoring system and we would like to be able to monitor Nginx more closely as well and gain access to Nginx metrics to better understand and monitor our server's performance.

In order to use the Nginx status module, you would need to add a new location block under the server section in the default.conf file located at /etc/nginx/applications for the http connection (port 80). You should also include allow and deny statements in this block to protect the page from being accessed outside of your server:

location = /basic_status {
    stub_status;
    allow 127.0.0.1;
    allow ::1;
    deny all;
}

Here is an example of what you will see when you use cURL with the following request: curl 127.0.0.1/basic_status:

Active connections: 291
server accepts handled requests
 16630948 16630948 31070465
Reading: 6 Writing: 179 Waiting: 106

The above request will provide live information on how many requests are being served, requests processed per second, and the number of active connections, as well as the number of connections currently being made. Additionally, if you create a simple calculation after recording these metrics over time, you can also calculate connections accepted per second, connections dropped per second and connections handled per second.

We put the change into place on one of our Cloudron instances and we are seeing that it is working and the data comes through, but we expect that there will be a future point that will cause the change to be wiped out again when updates occur.

Maybe it would be possible to have some of this metric information also showing directly within the dashboard of Cloudron when the status page is activated? It would be an added bonus to be able to provide users of Cloudron better insight into how their server is performing.

Apologies, I got hung up on your point about the 'combination of search and filters' since I'm experiencing only getting the amount of entries that's set in the per_page value even when using only the search box without any additional filters active. I'm really looking forward to the rework then because right now even basic stuff like checking if a specific email was delivered or if a specific user logged in is a bit of a pain since I have to unfold the details of the first entries just to make the scrollbar appear to load more.

@nebulon said in Cloudron 9: UI Issues in the system and email eventlog:

Still working on the refresh, when search changes and results do not fill up the view. Overall we have to rework eventlogs (both system and mail). Currently the pagination does not work well with the fetchMore(), especially when one tries to track down an issue with a combination of search and filters. It is very hard to get context around those events, as the pagination works with the query not the time of the events

I might be misunderstanding you, but the issue happens even without using a combination of search or filters. The email-eventlog has per_page set to 10, which isn't enough to create a scrollbar on a modern monitor with the browser being maximized, so infinite scroll can basically never work when you search for anything. The system-eventlog has the same problem on larger displays despite using per_page of 40. Maybe providing the user with a button to manually trigger the loading of more items is the way to go here? Or maybe you could just load more items "per page"?

I ran into two issues with the eventlog pages (/system-eventlog and /email-eventlog).

When search results don't fill the result element enough to create a scrollbar, infinite scroll breaks. If you search for something that returns only a few results, there's no scrollbar and no way to easily trigger loading more entries. You can technically work around this by expanding detail rows until a scrollbar appears and then scroll down to trigger the process of loading the next entries.

The second issue is a pagination bug in the email-eventlog. If you've scrolled down before searching, the new search keeps the old page number instead of resetting to page 1. You end up missing earlier entries, and the reload button also doesn't fix it. Looks like this is just a simple case of a missing reset of the page value as it is there in system-eventlog but missing in email-eventlog.

As far as I can tell, this only affects the system-eventlog and email-eventlog pages, there might be other pages I missed though.

@nostrdev said in BTCpayserver:

The problem we're having is packaging two containers (NBXplorer + BTCPay Server) inside the same cloudron container. Does anyone have examples where this has been done on other apps?

Without knowing specific technical details: You could install both applications (not as containers but as binaries/from source) into a single package, then use supervisor to start both of them.

There are a lot of examples on cloudron packages with multiple services in them, these two for example:

• https://git.cloudron.io/packages/librechat-app (Librechat & Meilisearch)
• https://git.cloudron.io/packages/gitlab-app (Gitaly, nginx, puma, sidekiq & sshd)

A regulation with the very German name "Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff", abbreviated as GoBD, requires comprehensive archiving of all business communications. I struggled to find good English documentation on this, but Stripe provides a very brief overview here if you're interested: https://stripe.com/en-de/resources/more/gobd-in-germany.

I've been trying to implement compliant email archiving on Cloudron, but whatever I try, I'm running into roadblocks. The main issue is that we need to archive all emails, both incoming and outgoing, especially transactional emails from apps like Invoice Ninja, which handles sending invoices, which are extremely critical in regards to the GoBD.

I know there have been previous requests for an "Always BCC" feature:
https://forum.cloudron.io/topic/4785/bcc-all-outgoing-mail
https://forum.cloudron.io/topic/8836/is-the-always-bcc-now-is-avaiable-from-haraka-now

The suggested workaround in these threads (client-side BCC rules) unfortunately won't work for compliance because:

• Users can accidentally delete or modify the rules
• Users could use the webmailer instead of their email client intermittently, mails sent there wouldn't be archived
• App-generated emails bypass user mailboxes entirely

A few months back, I tried writing a small Haraka plugin that implements a functionality like the always_bcc one from postfix for outgoing emails. I think I can handle incoming emails in a similar way. The plugin worked when I tested it manually, but there's no apparent way to integrate it with Cloudron's mail addon since any changes in the container get lost on the next restart and I then got side-tracked with other projects.

The issue now resurfaced for me and I wanted to ask if it would be possible to add support for custom Haraka plugins in the mail addon? I'm not looking for anything fancy, something like a directory mount into the container where we could place custom plugins that persist across updates would be incredibly helpful.

In combination with a working haraka plugin, this would solve our archiving compliance issue and even open up other customization possibilities for users with specific mailing requirements.

@marcusquinn Does this solution also archive all outgoing emails from inboxes and apps (like InvoiceNinja)?

To comply with local regulations, we really need a way to archive emails. As others pointed out before, the easiest way would be a feature to be able to set a BCC address for all emails.

If you do not want to add this feature, could you provide administators with a way to bind their own haraka plugins into the mail-addon container (without killing/overriding them on the next update) so we could implement the functionality ourself?

EDIT: I figured that this may not be the best place for such a discussion so I added a Feature Request.

+1

It would be really great if we could have a second configuration field in the "Branding" tab that can explicitly set the value of the CLOUDRON_OIDC_PROVIDER_NAME with a fallback to the Cloudron name. Setting the same Cloudron name for all instances that connect to an LDAP just isn't a feasible solution in my opinion and makes administration chaotic. Non-Technical Users could also really benefit from a name like "Login with One-Click" - and naming the whole instance One-Click just feels like a bad idea.