Warnings in system integrity

[aureq]

Warnings in system integrity

[OnGle]

A fresh installation of matomo on debian 9 stretch still gives warning about /usr/share/matomo/README.md.gz.

In addition matomo complains that piwik.js is not writable. IIR this is bad form, files in /usr subdirectories should be readonly and only be modified by package management. Variable non config should go in subdirectories of /var, see FHS (I think debian currently adhears mostly to the 2.3 version of the FHS but I'm not sure on that.)

[aureq]

@OnGle The README.md.gz relates to the package creation itself. Debian automatically compresses documentation files to save space. I'm not sure yet what's the best way of fixing this.

Regarding piwik.js it's more problematic since it's core to Matomo's functionality and making it Read/Write could lead to security problems being served to visitors. @mattab Rather than having a RW piwik.js, could we have a separate include pointing to a RW location instead?

[OnGle]

@aureq Fwiw I believe it is quite common for README, INSTALL, etc files to be put in /usr/share/doc/<package_name>/ just doing a quick find /usr/share/doc -iname 'README*' shows a large amount of both compressed and uncompressed README files. (Ignore this if moving the files from the project root does not remove the system integrity message)

[mattab]

Regarding piwik.js it's more problematic since it's core to Matomo's functionality and making it Read/Write could lead to security problems being served to visitors. @mattab Rather than having a RW piwik.js, could we have a separate include pointing to a RW location instead?

Actually we now "require" that piwik.js is made writable.
-> So would it be possible to make it writable in the debian package?

(this is needed/important because plugins can now extend the piwik.js tracking code, and it will get overwritten).

[florianjacob]

@mattab The main problem is to separate the writable piwik.js file from all the other read-only files, like @aureq said.

In case the piwik.js is not intended to be shared between installations, a possible solution might be to let Matomo place piwik.js at the always-writable PIWIK_USER_PATH location instead of PIWIK_DOCUMENT_ROOT. PIWIK_USER_PATH could then be pointed to a directory in /var/, while everything else could stay in /usr.

[aureq]

On the README* files... Maybe it would be worth to move them into /usr/share/doc/matomo while keeping the same folder structure and remove these files from the manifest.inc.php

Only useful files would be exposed to the web server and the user would still have access to the README*.

[aureq]

For now, I'm excluding README files located in /usr/share/matomo/ from the manifest.inc.php because:

• README is a broken link anyway because of below (See #82)
• README.md.gz is generated by Debian

[aureq]

@mattab

• Could you describe how the file integrity works please? It feels like it checks the manifest.inc.php but also checks for extra files not present in the manifest.inc.php. Does it read symlinks as well?
• Also, is there a way invoke the integrity checker from the CLI, and providing a new root folder.
• In the past, I used to exclude autoload*.php in the manifest.inc.php, but this seems to have changed...

Files were found in your Matomo but we didn't expect them.
--> Please delete these files to prevent errors. <--

File to delete: README.md.gz
File to delete: vendor/davaxi/sparkline/autoload.php
File to delete: vendor/davaxi/sparkline/src/autoload.php
File to delete: vendor/piwik/device-detector/autoload.php

[mattab]

@aureq

• It checks for all files in the codebase, even those not in manifest. It will ignore quite a few though, see: https://github.com/matomo-org/matomo/blob/6cb6548c19a93b3c9c173d6bb9c1a9f68835f252/config/global.php#L82-L128
• just tested and it seems it does not read symlinks
• there is a way to invoke the checker from CLI, with: ./console diagnostics:run. The root folder has to be the Matomo root folder itself where this command is executed from?
• the autoload issue you're experiencing should now be fixed. it regressed for a while, see: #77

[mattab]

Thanks for your patience, let's continue the discussion in this other issue for now, where we're looking for a new maintainer for the debian package: #131