diff options
| author | mail_redacted_for_web | 2026-03-07 11:04:48 +0100 |
|---|---|---|
| committer | mail_redacted_for_web | 2026-03-07 11:04:48 +0100 |
| commit | 17b5a38d0041fdebdeb000c35b52e7992a0f384d (patch) | |
| tree | f3aff0e9e5ce2de100e5da9f2f6fb3ce54df1787 | |
| parent | 26797dc67804f54a05c87ee7ae695f439e656d87 (diff) | |
| download | nextcloud-update-17b5a38d0041fdebdeb000c35b52e7992a0f384d.tar.bz2 | |
wording
| -rw-r--r-- | README.md | 10 |
1 files changed, 6 insertions, 4 deletions
@@ -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). |