From 17b5a38d0041fdebdeb000c35b52e7992a0f384d Mon Sep 17 00:00:00 2001 From: Harald Pfeiffer Date: Sat, 7 Mar 2026 11:04:48 +0100 Subject: wording --- README.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index ec2368a..fadf9ec 100644 --- a/README.md +++ b/README.md @@ -8,12 +8,14 @@ updater.phar is useless. that _is_ reliable and I see no need to rely on "blackboxes".) 2. It THEN proceeds to the download which may be hilariously slow (Version 31.x.x: the servers delivered a 255MiB file in over 15 minutes to a machine with download speeds of 30+MiB/sec) - so the backup may already be dated when we proceed + so the backup may already be dated when we proceed. + We are just using `curl`, and we are backupping afterwards. 3. It then does stuff with nextcloud in an undocumented [^1] manner. Given that some utterly stupid - morons decided that within Nextcloud (nice software) everything needs to be writable by - the web server user (utterly insane), we don't want to rely on such a construct too much. + morons decided that within Nextcloud (nice software by itself) everything needs to be writable + by the web server user (utterly insane!), we don't want to rely on such a construct too much. (Nextcloud don't give a fuck about security principles that are aaaaages old? Fuck your meta - layers, then, we don't trust you anymore, because fuck you.) + layers, then, we don't trust you anymore, because fuck that. Security fucked once, security + fucked always.) 4. Solution? Create own scripts which take over downloads, download verification, and then execute occ commands (well, they're still occ commands, but more granular and potentially less fucked by imbecile decisions). -- cgit v1.2.3