Code-Signing and individual deployment

Dear all,
the “code-signing” feature is a nice security additon, however it causes a few issues, if you are customizing your instance to fit your own environment.

this starts with the .htaccess file, which probably in most instances needs a few additional settings. Therefore this file will show up in the list of “invalid files”. also if you remove the default “skeleton” files and replace them with your own, that will create such warnings.

As said before, I like the feature, but there should be a possibility to “update” the signatures of files once the individual deployment is finished - in this case, only those files would trigger a warning, that are not “intentionally changed by the site administrator”.

Of course I tried to update the signatures of in “signature.json”, however this understandably triggers a
"- core
- EXCEPTION
- OC\IntegrityCheck\Exceptions\InvalidSignatureException
- Signature could not get verified."
and stops the whole verification.

Any ideas, how this feature could be made “adaptable to the individual implementation”?

  1. Do simply perform the .htaccess edits after #### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####, which is generated if the .htaccess is writable by your web server on an update. (or even better: use your web server config)
  2. Don’t modify the skeleton files directly, read the documentation for the config file. You’ll find skeletondirectory

That is not possible because the signature is a cryptographic one done with a key only our release server has access to. Also it has the purpose to make it possible for us to see if an user has tampered with a system and is filing a bug report. You can completely disable it though by setting integrity.check.disabled to true in config.php.

However, any issue that you file them we may simply refuse to look into as they may be caused by custom additions which are unsupported :wink:

Also note that only administrators will see a warning of a failed integrity check.

Thank you Lukas,

as per “.htaccess”) I did not notice this - but it works as expected. thanks for pointing this out to me
as per “skeleton”) I did not notice this - but it works as expected. thanks for pointing this out to me

however, I still get a few warnings for other files. I tried to “reupload” them two or three times, which helped with a few of the messages, but not all…

any ideas

  • core
    • INVALID_HASH
      • core/doc/admin/_sources/configuration_files/collaborative_documents_configuration.txt
      • core/doc/admin/_static/img/note_pencil.svg
      • core/doc/admin/_static/img/warning.svg
      • core/doc/admin/_static/style.css
      • core/fonts/LICENSE.txt
      • core/img/logo.png
      • core/vendor/jquery-migrate/jquery-migrate.js
      • core/vendor/jquery-migrate/jquery-migrate.min.js
      • core/vendor/jsTimezoneDetect/jstz.js
  • files_external
    • INVALID_HASH
      • 3rdparty/Dropbox/API.php
  • files_texteditor
    • INVALID_HASH
      • js/vendor/ace/src-noconflict/mode-diff.js

Configure your FTP client to upload the data properly. As in: Binary mode and not ASCII mode. If you use Filezilla: https://wiki.filezilla-project.org/Data_Type

thanks, solved everything!

hi there, i have an additional question.

The .htaccess from NC 10.0 does’t contain such a line.
the only possibility for me to enable HSTS is with a line in .htaccess

Also I have to place a new file in the root dir .php.ini with the same content as .user.ini
There ist nothing that i can do around, that’s preset by my provider.

Is there a way to add this changes in an legal way to not run into this code-signing problems? Maybe an app which can add / modify the hashes?

danke / thanks Micha