skjnldsv
commented
2 days ago Hey!
Unfortunately, this won't happen. We are now REUSE compliant for licenses and stuff, that should be enough to be compliant. I'm afraid that would be a discussion to have on the fedora side. :)
I recently became involved with packaging the Nextcloud rpm for Fedora. As a Fedora packager, sometimes we find ourselves stuck between the Fedora packaging standards we are bound to follow and how the application itself is designed. This is one of those cases.
In order to comply with packaging standards, we manipulate certain files during the build process. As one of the simpler examples, we move license and readme files into dedicated license and documentation folders. There are other modifications we make, but I don't think we need to get into those details for this discussion.
As one might expect, this sets off the integrity checker in a major way. In order to work around the many integrity checker warnings, I’ve tried the following (all tests performed on 28.0.5):
Per the nextcloud forum, set integrity.check.disabled to false, trigger a rescan, then set back to true. This only seems to work for the current login session.
Replace the hash of each offending file in signature.json with the new hash provided by occ. This triggers a signature exception error.
Attempt to resign the core with:
openssl req -nodes -newkey rsa:4096 -keyout nextcloud.key -out nextcloud.csr -subj "/CN=nextcloud"
sudo -u apache ./occ integrity:sign-core \ --path=/usr/share/nextcloud \ --privateKey=/usr/share/nextcloud/nextcloud.key \ --certificate=/usr/share/nextcloud/nextcloud.csr
occ claims this step was successful, but the administration panel now shows a signature exception.
These steps were all performed, using the tarball found on download.nextcloud.com. If I instead start with the tarball from github.com, the administration panel simply says the integrity checker has been disabled. I can’t seem to turn it on, even after generating signature.json. Can the integrity checker only be used with the tarball available on download.nextcloud.com?
If I am doing any of these steps wrong, please let me know.
What I’d like to ask is, would the developers consider the following:
Don’t generate a signature for files that are not used programatically. This would include readme, license files, authors, copying, all .git related files and folders.
Allow a third party to generate new signature.json, using a new private key and certificate
I get it, since this is not a bug or deficiency in Nextcloud, there really is not a big incentive to do this. However, before I ship Nextcloud rpm’s with the integrity checker turned off (and a note to not use this rpm if integrity checker is needed), I thought I’d post here, to describe the problem and discuss a path forward. Thank you for reading.
How to use GitHub