It is possible - You would probably want to implement your own
FileBackend subclass -
. I am not aware of anyone else doing something like this.
However, conceptually you need to consider your threat model carefully
here. As with most "encryption at rest" schemes, the sticking point is
where is the key stored. To do something like this, you would probably
put your encryption key in LocalSettings.php (Even if you do something
more complex, MediaWiki would have to have access to the key at some
point in order to decrypt the files to send them to your users). If
you don't have control to the host, the attacker could just read the
key out of your LocalSettings.php (or in more complex schemes, PHP's
memory), and thus defeat the encryption.
The type of system where this sort of thing makes more sense, is if
you are storing files on a different server then your main web server
(Say amazon S3 or whatever). If you don't trust the file server, but
do trust your web server, then encrypting the files could make sense
as long as the key stays only on the server you trust.
On Mon, May 28, 2018 at 2:08 PM, Stephan Gambke <s7eph4n(a)protonmail.com> wrote:
To prevent unauthorized access I may have to ensure
that uploaded files are stored encrypted. Wiki pages themselves are less critical, and may
remain in clear text.
The scenario is a relatively small wiki (30,000 pages, 10,000 files, but only 27 users)
on a virtual server where I have full remote root access. The host of the virtual machine
is not under my control.
- Is there any obvious problem that makes this conceptionally impossible?
- Is anybody already doing this or working in that direction?
- What could be viable approaches and what limitations would there be?
I know, it's a rather broad topic. Still, any pointers would be welcome.
MediaWiki-l mailing list
To unsubscribe, go to: