Code integrity errors after upgrade to 12.0.4

[willink2]

Hello!

I’ve got a minor code signing issue after the upgrade to nextcloud 12.0.4.

Nextcloud version: 12.0.4 (now, previous: 12.0.3)
Operating system and version: debian 9
Apache/2.4.25 (Debian)
PHP version (eg, 5.6): PHP 7.0.26-1~dotdeb+8.2
Is this the first time you’ve seen this error?: yes, I have done multiple upgrade in the past.

Can you reliably replicate it? (If so, please outline steps): yes, I’ve upgraded according to manual (https://docs.nextcloud.com/server/12/admin_manual/maintenance/manual_upgrade.html)

The issue you are facing:
After the upgrade I get code signing errors for files in 3rdparty/aws-sdk-php and

Logging (example, all files in aws-sdk-php are marked)

• files_texteditor
  • EXTRA_FILE
    • l10n/ka_GE.php
    • l10n/eu.php
• files_external
  • EXTRA_FILE
    • 3rdparty/aws-sdk-php/Guzzle/Plugin/ErrorResponse/Exception/ErrorResponseException.php
    • 3rdparty/aws-sdk-php/Guzzle/Plugin/ErrorResponse/ErrorResponseExceptionInterface.php
    • 3rdparty/aws-sdk-php/Guzzle/Plugin/ErrorResponse/composer.json
    • 3rdparty/aws-sdk-php/Guzzle/Plugin/ErrorResponse/ErrorResponsePlugin.php
    • 3rdparty/aws-sdk-php/Guzzle/Plugin/Md5/composer.json
    • 3rdparty/aws-sdk-php/Guzzle/Plugin/Md5/CommandContentMd5Plugin.php
    • 3rdparty/aws-sdk-php/Guzzle/Plugin/Md5/Md5ValidatorPlugin.php
    • 3rdparty/aws-sdk-php/Guzzle/Plugin/composer.json
    • 3rdparty/aws-sdk-php/Guzzle/Plugin/Oauth/composer.json
    • 3rdparty/aws-sdk-php/Guzzle/Plugin/Oauth/OauthPlugin.php
    • 3rdparty/aws-sdk-php/Guzzle/Plugin/Async/composer.json
    • 3rdparty/aws-sdk-php/Guzzle/Plugin/Async/AsyncPlugin.php
    • 3rdparty/aws-sdk-php/Guzzle/Plugin/History/HistoryPlugin.php
    • 3rdparty/aws-sdk-php/Guzzle/Plugin/History/composer.json
    • 3rdparty/aws-sdk-php/Guzzle/Plugin/CurlAuth/composer.json
    • 3rdparty/aws-sdk-php/Guzzle/Plugin/CurlAuth/CurlAuthPlugin.php
    • 3rdparty/aws-sdk-php/Guzzle/Plugin/Cookie/CookieJar/FileCookieJar.php
    • 3rdparty/aws-sdk-php/Guzzle/Plugin/Cookie/CookieJar/ArrayCookieJar.php
    • 3rdparty/aws-sdk-php/Guzzle/Plugin/Cookie/CookieJar/CookieJarInterface.php
    • 3rdparty/aws-sdk-php/Guzzle/Plugin/Cookie/Cookie.php
      … and so on
    • 3rdparty/aws-sdk-php/Symfony/Component/EventDispatcher/ImmutableEventDispatcher.php
    • 3rdparty/aws-sdk-php/Symfony/Component/EventDispatcher/EventSubscriberInterface.php
    • 3rdparty/aws-sdk-php/Symfony/Component/EventDispatcher/Event.php
    • 3rdparty/aws-sdk-php/Symfony/Component/EventDispatcher/EventDispatcher.php
• gallery
  • EXTRA_FILE
    • l10n/es_CL.php

Raw output

Array
(
[files_texteditor] => Array
(
[EXTRA_FILE] => Array
(
[l10n/ka_GE.php] => Array
(
[expected] =>
[current] => d00162557896cdb62d09b4e6e22571653b3c174e7912c18f234d0a0a697cdf531fd9618709b373f3798a75d5c7faa69c4a40f6048be2bcc603dda19106bbd545
)

                [l10n/eu.php] => Array
                    (
                        [expected] => 
                        [current] => 8e928678b25f6626f0ae9fac1a7eed4c068ab017d5b67788fdc7fc4a643fb5ddc26bdc1d48093921cf430641578fe652925b7c758867c8cc109e5c9ae5f13f56
                    )

            )

    )

[files_external] => Array
    (
        [EXTRA_FILE] => Array
            (
                [3rdparty/aws-sdk-php/Guzzle/Plugin/ErrorResponse/Exception/ErrorResponseException.php] => Array
                    (
                        [expected] => 
                        [current] => 10c7849dc2a7757914b991864e61ce02b576115534e5eae245c243cee9b5149e26c74df00c5b0edcd0de386cc7fa93c30073dccb163c1f7252ee84b68e93621e
                    )

                [3rdparty/aws-sdk-php/Guzzle/Plugin/ErrorResponse/ErrorResponseExceptionInterface.php] => Array
                    (
                        [expected] => 
                        [current] => 4cd12e5870185b314658518cc798a47de8ce534443756f81cbde7f36ed0086ec90769ebc6c1a1f09c040b1dd05af9e038b211f4f51ccff0a6bcb1c141f6557f6
                    )

                [3rdparty/aws-sdk-php/Guzzle/Plugin/ErrorResponse/composer.json] => Array
                    (

… and so on

                [3rdparty/aws-sdk-php/Symfony/Component/EventDispatcher/EventDispatcher.php] => Array
                    (
                        [expected] => 
                        [current] => 96211d2e46a1b6ced8d126e1c2a2732feb467c5418836aa8305a149932b0842d825e31f36accccd0458609a87087ace69453dc13d5240b5a8a1bd9a142ed36d7
                    )
            )
    )

[gallery] => Array
    (
        [EXTRA_FILE] => Array
            (
                [l10n/es_CL.php] => Array
                    (
                        [expected] => 
                        [current] => daa117985c2bce1f85c85628ee23483feb0f3401af8e1ced57d89815774475efa8aa92862b4a7dc8e3ddbe3def351965f4cae2fa433d36c710f1e05d616d85a5
                    )
            )
    )

)

There where no errors prior to the upgrade. I’ve gotten no errors during the upgrade.

I’ve tried so far:

• Checked manually if these files exist in de backup of the webdirectory, they don’t;
• Checked if they existed in the tar file i’ve downloaded;
• removed the original directory in /var/www and replaced with a fresh extracted version from the tar file;
• checked (sha256sum) and compared the /core/signatures.json;
• read this document and did a rescan: https://docs.nextcloud.com/server/12/admin_manual/issues/code_signing.html?highlight=integrity
• rebooted the server

What did I miss or can I do to resolve this issue (without disabling the integrity check all together in the configuration file)?

[linucksrox]

You mentioned that you checked if those files existed in the tar file you downloaded. Did you find them in there?

Can you try a slight variation? Instead of removing the old directory and placing the new files back there, rename the old directory, extract the new files to a brand new directory, copy the old config to the new location, move the data directory to the new location, then rename the new directory to the original name. That would rule out problems with not all files being removed.

If you still see this issue, can you please share exactly what commands you are using to remove files and then to extract and move the new files into the cloud directory?

As a last resort (besides disabling the integrity check) you can try removing the “extra” files, but I have a feeling there’s something else wrong with your directory structure so only removing files might not completely fix the problem.

[willink2]

Hi, thnx for your reaction!

Maybe I’ve not been completely clear: the extra files the log claims don’t exist in de the backup, the current directory or the source .tar/.zip file. So the log claims files I can’t find even on file level. Searching with find at the root of the /var/www for some of the files mentioned in the log give no results.

This is my usual upgrade procedure, which is almost exactly as you proposed:

1. Downloaded en extracted nextcloud: tar -xjf nextcloud-12.0.4.tar.bz2 -C ~/nextcloud1204/
2. Put Nextcloud in maintenance mode: sudo -u www-data php occ maintenance:mode --on
3. Renamed old dir: mv /var/www/extranet /var/www/extranet.old
4. Created a dir: mkdir /var/www/extranet
5. Copied the source files to the new dir: cp -rf ~/nextcloud1204/nextcloud/* /var/www/extranet/ && cp -rf ~/nextcloud1204/nextcloud/.* /var/www/extranet/
6. Copied the apps from the previous version(n for no-clobber, I just want the missing apps): cp -rfnu ./extranet.old/apps/* ./extranet/apps/
7. Copied the configuration files from the previous version (incl. mimetypes.json): cp ./extranet.old/config/* ./extranet/config/
8. Run a script to secure the new dir: ~/secure_swv.sh
9. Run upgrade script: sudo -u www-data php occ upgrade
10. On no errors exit maintenance mode: sudo -u www-data php occ maintenance:mode --off

I’ve copied the commands from my bash history.
The data is stored in a separate directory and mountpoint so I don’t bother with that.

This procedure has always worked for me until now… What did I do wrong or can be done to fix this?

The secure_sw.sh script:

find ${ocpath}/ -type f -print0 | xargs -0 chmod 0640
find ${ocpath}/ -type d -print0 | xargs -0 chmod 0750
chown -R root:${htuser} ${ocpath}/
chown -R ${htuser}:${htgroup} ${ocpath}/apps/
chown -R ${htuser}:${htgroup} ${ocpath}/config/
chown -R ${htuser}:${htgroup} ${ocdata}/
chown -R ${htuser}:${htgroup} ${ocpath}/themes/
chown root:${htuser} ${ocpath}/.htaccess
chown root:${htuser} ${ocdata}/.htaccess
chmod 0644 ${ocpath}/.htaccess
chmod 0644 ${ocdata}/.htaccess

[linucksrox]

To me it looks like some of the apps were copied to the wrong directory. Those files do exist elsewhere. For example, the extra file found in the files_external app “3rdparty/aws-sdk-php/Guzzle/Plugin/ErrorResponse/ErrorResponseExceptionInterface.php” is actually located in the source tarball “3rdparty\guzzle\guzzle\src\Guzzle\Plugin\ErrorResponse” and probably got mistakenly moved or copied (possibly it’s in both places at the same time).

You specifically should look in your nextcloud directory “/var/www/nextcloud/apps/files_external/3rdparty/” and recursively remove aws-sdk-php from there.
Then remove “/var/www/nextcloud/apps/files_texteditor/l10n/ka_GE.php”, “/var/www/nextcloud/apps/files_texteditor/l10n/eu.php”, and “/var/www/nextcloud/apps/gallery/l10n/es_CL.php”

If you are sure the files aren’t there but Nextcloud is still seeing them, make sure you’re running the correct instance of NC (not running from the old directory, etc.) and even try rebooting the server.

[willink2]

@linucksrox: Thnx that did the trick. I remove the directory & seperate files and did a rescan.

That leaves me with the question how should I upgrade when using not standard apps?

The way I used to do it, copy the contents of the old apps directory, only updating not existing files doesn’t work any more apparently. The files that caused this problem where installed at least during 12.0.3

What is the best way to automate this, so without manually enabling every single app or copying it manually from old to new?

[linucksrox]

Theoretically your method should work fine, although in this case it seems like something was accidentally copied where it shouldn’t have been.
As far as automating this, set your file/folder permissions according to the new guidelines and use the auto updater going forward.

[willink2]

Thanks for your support and patience!

@linucksrox

As far as automating this, set your file/folder permissions according to the new guidelines and use the auto updater going forward.

Maybe I’m looking in the wrong places but I’ve searched the admin manual and the forums for this but I can’t find the new guidelines. Could you, as a last request, point me in the right direction?

[linucksrox]

Sure. Permissions are not easy to find in my opinion, but you can find the commands hidden in the manual upgrade page on step 9:
https://docs.nextcloud.com/server/12/admin_manual/maintenance/manual_upgrade.html?highlight=manual%20upgrade

@willink2

The data is stored in a separate directory and mountpoint so I don’t bother with that.

So the permissions here need to match above, and the web user (probably www-data in your case) should be the owner/group of all files and folders, including the root of your data directory.

After setting that, the web updater should be usable for you, and from my experience I’ve been using it without any problems since 10.x