mariadb not supported

[Torkolis]

Is mariadb support planned in the future for Version 3 or only postgres? I use mariadb because of encryption at rest, which postgres does not offer natively.

[ZeikoFr]

Hi, afaik postgres will be the only DB method supported.

If your threat model include the need to encrypt at rest, I suggest that you simply encrypt the disk with luks or use ZFS/ceph or any filesystem that have encryption natively. There's also Percona Postgres that have the pg_tde extension but I never tried it.

If you're interested on why Postgres will probably never support encryption at rest natively : https://www.pgedge.com/blog/why-postgres-lacks-transparent-data-encryption

[Torkolis]

Hard drive encryption is insufficient; the server administrator should not have access to data in plaintext. I tried pg_tde, but that, too, is inadequate, buggy, and performs poorly.

I am very disappointed about this step backward.

[ZeikoFr]

I think you mis-understand the threat model for encryption at rest, it is to protect data in case of stolen disk, backups, disposal of drives...

If some of your admins should not have access to the postgres data, simply implement the proper right management with restricted accounts.

[Torkolis]

Disk encryption protects against physical theft, but if an attacker gains access while the system is running (which it does 24/7) and steals data at the file level it does not provide any protection. Only encryption at the application or database level can provide a layer of protection. This is my scenario.

[paul1278]

Out of interest, where is the encryption key located in your scenario?

[Torkolis]

It is stored on the disk. Frankly, the certification does not specify that particular aspect; the only relevant requirement is that the data is encrypted. I also think this is somewhat overkill and more of a philosophical discussion, but it is something we have to do and is not up for discussion.

[NGPixel]

Wiki.js 3.x requires PostgreSQL. MariaDB is not and will not be supported. PostgreSQL has many features that MariaDB simply do not support (pub/sub, pg_tgrm, etc.). Features that would severely limit Wiki.js v3 capabilities.

While you may have a valid use case for TDE, the reality is that it's overkill for almost 100% of deployments. Use disk encryption. If a malicious admin has access to the live storage layer, you have more pressing problems than a wiki IMO. You shouldn't store sensitive secrets in a wiki. Use something like Vault / KMS-managed secret store.

[Torkolis]

The advantage of using wiki software over something like Vault or other secret stores is that it is actually a wiki. It uses HTML content, which allows us to use tables and structure the data however we want, making it much more flexible and pleasant to use.

Maybe Wiki.js could use pgcrypto to encrypt the page content (and attachments)?

[NGPixel]

Could be added on a per-page basis, make a request for it on https://feedback.js.wiki/feedback

However, I still think going through all the trouble of having an encrypted wiki instead of a proper secret store is misguided. Use the right tool for the job.

[Torkolis]

We have information that is not suitable for a secret store—for example, system overviews, manuals, connection matrices, and so on. I will make a request though, thanks.

[Torkolis]

strange, I did make a request but I can't find it anymore. Did it get lost or deleted? I don't know the outcome.

[NGPixel]

Submit a new one on https://feedback.js.wiki

The board was replaced to use the now built-in feedback feature of Wiki.js rather than a 3rd party service.