Element, Security, mTLS, Dolt, Isolation, Matrix
There's a clear bug in the Element Android client, it shows room with only one user in the room as untrusted, but if there are two trusted members then then room is trusted. But on the desktop and in web-client, room with only one trusted member is shown as trusted. And by the only one trusted member, I of course mean my-self.
I think I'll deeply hate the Thunderbird OpenPGP implementation, it breaks so many security concepts essential to the PGP. Private Key Encryption, Key Trust, who needs those. It's clear that it's very simplified solution, but at the same time it inherently sabotages security. Yuck! So, never use your real keys with Thunderbird, only use some temporary throwaway "daily email key", because the Thunderbird doesn't handle the keys in any sane way. Actually this is not a new problem, public key crypto itself is great, but many applications and people handle the private keys in such a bleeping way, encryption security gets really badly tarnished. You'll need to have the long term master keys separately, which you'll then use to manage ephemeral per device / per software keys. - By default Web of Trust isn't being used nor private keys are encrypted. - Sigh, deep sigh.
Secured some server backends using Mutual TLS (mTLS) with Cloudflare as well as the Cloudflare API itself using client certificates with shield. + Authenticated origin pull + firewall rules to allow traffic only from CF network.
Worth of mentioning: Dolt (@ DoltHub.com) "Git for data" - and Zero Data App (@ 0data.app) this is as concept something I really like. Because so many apps and services seem to be practically spyware nowadays.
Built and configured a triple layer tamper protection system for one environment. Finally a solution to the age old problem of encryption keys leaking during physical unauthorized access. - This pretty much guarantees that the keys won't get recovered, unless the system is first hacked. - Yet Whonix makes is hard to gain access to the host even if the application services would be breached. Blocking the classic way of accessing the console and physical access, copying RAM content, cold boot attacks etc. In case of trigger the volumes are emergency dismounted, encryption keys (in ram) and volume header (on block storage) are wiped and system is shutdown in less than a second. Restoring access to the encrypted volumes requires first restoring the volume encryption header, and then booting the system with key file + password which means that having the password alone isn't enough.
Some vulnerability coordination stuff, Chatham House, Traffic Light Protocol, CVE (Common Vulnerabilities and Exposures) (@ Wikipedia), CVSS. - Yup, nothing new naturally, using neutral intermediator.
Watched a very bad movie with left eye. It's was so bad. They used onion addresses, which were syntactically invalid. Also they had very strange character set which was kind of randomized, yet they claimed it Caesar cipher, and so on.
Interesting article about laser based fast random bit generation. (@ schneier.com)
Some performance issues with Matrix and S3 object storage. Data needs to be relocated but ... I'm just wondering if the code base supports multiple locations for smooth migration. Primary location, store and fetch first and the secondary location which is used to fetch in the case where the primary location doesn't contain the required data. It would allow a very smooth migration by just changing the primary location and thus wouldn't require immediate transfer of old data to new storage location / platform. - Because that's how I would make the transition without downtime or massive data transfers.
Nice technical post about Scaleway Object Storage (@ Scaleway Blog). Also remember to check the previous two posts.