Oneric 0ec62acb9d Always insert Dedupe upload filter ... This actually was already intended before to eradict all future path-traversal-style exploits and to fix issues with some characters like akkoma#610 in 0b2ec0ccee. However, Dedupe and AnonymizeFilename got mixed up. The latter only anonymises the name in Content-Disposition headers GET parameters (with link_name), _not_ the upload path. Even without Dedupe, the upload path is prefixed by an UUID, so it _should_ already be hard to guess for attackers. But now we actually can be sure no path shenanigangs occur, uploads reliably work and save some disk space. While this makes the final path predictable, this prediction is not exploitable. Insertion of a back-reference to the upload itself requires pulling off a successfull preimage attack against SHA-256, which is deemed infeasible for the foreseeable futures. Dedupe was already included in the default list in config.exs since 28cfb2c37a, but this will get overridde by whatever the config generated by the "pleroma.instance gen" task chose. Upload+delete tests running in parallel using Dedupe might be flaky, but this was already true before and needs its own commit to fix eventually.		2024-03-18 22:33:10 -01:00
..
administration	Document live dashboard	2024-02-15 16:04:33 +01:00
configuration	Always insert Dedupe upload filter	2024-03-18 22:33:10 -01:00
css	Documentation updates for stable release (#73)	2022-07-15 12:27:16 +00:00
development	Merge branch 'followback' into develop	2024-02-16 13:27:40 +00:00
fonts	Documentation updates for stable release (#73)	2022-07-15 12:27:16 +00:00
images	Doc branding	2022-12-05 13:45:36 +00:00
installation	More prominently document db migrations in migrations from Pleroma	2024-02-23 23:54:14 +01:00
clients.md	docs: Add Kaiteki to list of clients	2023-05-31 18:19:06 -04:00
index.md	docs: Update Pleroma-FE references to Akkoma-FE	2023-05-26 22:36:27 -04:00
support.include	Documentation updates for stable release (#73)	2022-07-15 12:27:16 +00:00