* Fix attachments getting processed despite failing content-type validation
* Add a restrictive ImageMagick security policy tailored for Mastodon
* Fix misdetection of MP3 files with large cover art
* Reject unprocessable audio/video files instead of keeping them unchanged
When storing files in S3, paperclip is configured with a Cache-Control header
indicating the file is immutable, however no such header was added when using
OpenStack storage.
Luckily Paperclip's fog integration makes this trivial, with a simple
`fog_file` `Cache-Control` default doing the trick.
Some "S3 Compatible" storage providers (Cloudflare R2 is one such example) don't support setting ACLs on individual uploads with the `x-amz-acl` header, and instead just have a visibility for the whole bucket. To support uploads to such providers without getting unsupported errors back, lets use a black `S3_PERMISSION` env var to indicate that these headers shouldn't be sent.
This is tested as working with Cloudflare R2.
Nginx can be configured to bypass proxy cache when a special header
is in the request. If the response is cacheable, it will replace
the cache for that request. Proxy caching of media files is
desirable when using object storage as a way of minimizing bandwidth
costs, but has the drawback of leaving deleted media files for
a configured amount of cache time. A cache buster can make those
media files immediately unavailable. This especially makes sense
when suspending and unsuspending an account.
Change the behaviour of remotable concern. Previously, it would skip
downloading an attachment if the stored remote URL is identical to
the new one. Now it would not be skipped if the attachment is not
actually currently stored by Paperclip.
The default limit of 10 retries with exponential backoff meant
that if the S3 server was timing out, you would be stuck with it
for much, much longer than the 5 second read timeout we expect.
The uploading happens within a database transaction, which means
a failing S3 server could negatively affect database performance
I also added "public" here, as I can't think of a good reason not to add it. Perhaps it has some marginal benefit in that ISPs (or other proxies) can cache it for all users. The assets are certainly publicly available and the same for all users.
* Fix uncaching worker
* Revert to using Paperclip's filesystem backend instead of fog-local
fog-local has lots of concurrency issues, causing failure to delete files,
dangling file records, and spurious errors UncacheMediaWorker
* Revert "Bump version to 2.3.2rc1"
This reverts commit cdf8b92fea.
* Revert "Downgrade Dockerfile to Ruby 2.4.3 on Alpine 3.6 (#6806)"
This reverts commit 0074cad44f.
* Revert "Handle Mastodon::HostValidationError when pulling remoteable assets (#6782)"
This reverts commit 4a0a19fe54.
* Revert "Correct the reference to user's password in mastodon:add_user task (#6800)"
This reverts commit 338bff8b93.
* Revert "Upgrade Paperclip to version 6.0.0 (#6754)"
This reverts commit b88fcd53f7.
Keystone V2 is deprecated in favour of V3. This adds the necessary
connection parameters for establishing a V3 connection. Connections
to V2 endpoints are still possible and the configuration should
remain compatible.
This also introduces a SWIFT_REGION variable for multi-region
OpenStack environments and a SWIFT_CACHE_TTL that controls how long
tokens and other meta-data is cached for. Caching tokens avoids
rate-limiting errors that would result in media uploads becoming
unavailable during high load or when using tasks like
media:remove_remote. fog-openstack only supports token caching for
V3 endpoints, so a recommendation for using V3 was added.
Claire