[tlug] Dealing with software with wide attack surface

[Christian Horn <chorn@example.com>]

Hoi tlug,

I am wondering how you deal with software with a big
attack surface, or to which degree you care.

Since years I use scripts/software to make images available 
over the internet.  Currently I use fgallery, which creates a
static gallery of images I provide, and uses a bit Javascript
in the users browser.

I'm in the market for alternatives, and looked at 2 of them:
https://pixelfed.org/ and https://github.com/LycheeOrg/Lychee .
Especially Lychee seems good, I like the style of presentation
more than what fgallery (from 2016, no longer developed) does.

The thing which I do not like:
components PHP, nginx and Postgresql which Lychee uses are ok, 
and I can rely on the Linux distribution that security fixes 
become available if issues in the upstream projects get known.
But a further thing is happening when setting up both Lychee 
and pixelfed: they install further php modules for Lychee the
command 'composer install --no-dev' is run, and pulling on 
113 further modules:
~~~
Installing dependencies from lock file
Verifying lock file contents can be installed on current platform.
Package operations: 113 installs, 0 updates, 0 removals
  - Downloading voku/portable-ascii (1.5.6)
  - Downloading symfony/polyfill-php80 (v1.22.1)
  - Downloading symfony/polyfill-mbstring (v1.22.1)
[..]
~~~

I considered following options to deal with that, and 
I do not like any of these.

- Just do not care about issues in these php modules.
  Move away the Lychee installation into
  - an extra KVM guest (but that would mean I need an additional
    instance, so pay and maintain it).  If the installation gets
    opened then via security issues, at least just the pictures
    are lost.
  - a container.  Means I need no extra KVM instance, but 
    container separation is not meant to be for security.
- Or I write code which constantly checks if there are
  updates for these php modules.  I do that for the host Linux
  distro - but security issues and security errata are rare
  there.  I'm not sure how well such php modules are maintained.

If I was running the code just for an intranet, I could con-
sider to trust the users.  But for the internet.. what are 
tlug members doing?  Do you consider attack surface when 
setting up internet services?

cheers,
Christian

Attachment: signature.asc
Description: PGP signature