[QA] Missing GPG fingerprint/Key on the homepage, so INSTALL.sh does not check the correctness of the GPG keys

[proofy]

Pre-submission Checks

• I checked for similar issues, but could not find any. I also checked the closed issues. I could not contribute additional information to any existing issue.
• I will take the time to fill in all the required fields. I know that the bug report may be dismissed otherwise due to lack of information.

Describe the QA issue

It is not possible to check the correctness of the GPG keys used for signing Linux packages.
If a hacker takes over the server, he can also change the keys and upload them to keyservers.
There is no way for the user to check whether the GPG keys used come from the team.

Steps to reproduce the issue

go to https://download.owncloud.com/desktop/ownCloud/stable/latest/linux/Debian_11/
INSTALL.sh does not check the correctness of the GPG signatures

Screenshots

no screenshot

Expected behavior

INSTALL.sh checks the signatures of the packages to be installed using the public GPG key stored on the homepage.
A user can check the correctness of the signatures using the fingerprint for the e-mail address/GPG key from [email protected] on the homepage

Actual behavior

No response

See also

#owncloud/docs-client-desktop#540

[proofy]

Here is my comment in the other error ticket, which was marked as off-topic there:

I'm not a GPG expert, but the more I read into the problem, the more I understand why it's so difficult for open source projects.

On the one hand, it should be as easy as possible to carry out an update. Especially for users of the desktop client, you can't assume that they will use any scripts and probably don't understand the problem when the error message appears during the update.
Teamviewer has made it easy for itself here with the simple reference to a keyring installed by the package in the source.list of teamviewer.

user@debian11pc /e/a/sources.list.d> cat teamviewer.list
###   TeamViewer DEB repository list

### NOTE: Manual changes to this file
###        - prevent it from being updated by TeamViewer package updates
###        - will be lost after using the 'teamviewer repo' command
###       The original file can be restored with this command:
###       cp /opt/teamviewer/tv_bin/script/teamviewer.list /etc/apt/sources.list.d/teamviewer.list
###       which has the same effect as 'teamviewer repo default'

### NOTE: It is preferred to use the following commands to edit this file:
###       teamviewer repo                - show current repository configuration
###       teamviewer repo default        - restore default configuration
###       teamviewer repo disable        - disable the repository
###       teamviewer repo stable         - make all regular TeamViewer packages available (default)
###       teamviewer repo preview        - additionally, make feature preview packages available
###       teamviewer repo development    - additionally, make the latest development packages available

deb [signed-by=/usr/share/keyrings/teamviewer-keyring.gpg] https://linux.teamviewer.com/deb stable main

On the other hand, you need to have an instance to check that the keys have not been overwritten by hackers in case the server is hacked (this has happened before with other projects)

This is where the homepage would come in handy.
I would use https://electrum.org/#download
as a model.

In the case of an open source project, an additional complication is that at least two core developers should sign the key whose key is published on all major key servers. Welcome to the European data protection hell ;)

BTW, the new key is only valid for one year. The subkey is valid for one year longer. Looks like a contingency plan ....

The first step you could take now would be to put the fingerprint of the key on the homepage in the imprint next to the e-mail address.

For further improvements in user-friendliness and security, there is certainly still a lot to be done.

[fmoc]

INSTALL.sh installs/updates the key every time it is executed. Why would it want to additionally check the signatures if the key is downloaded and imported anyway?

[fmoc]

BTW, the new key is only valid for one year. The subkey is valid for one year longer. Looks like a contingency plan ....

This is by design. We extend the expiry date upon every release.

[proofy]

installs/updates the key every time it is executed. Why would it want to additionally check the signatures if the key is downloaded and imported anyway?

If the check fails, the script should abort and issue a corresponding warning.
However, the script is not the most important thing for me, but that I as a user can check the signatures.

[proofy]

The server documentation (https://doc.owncloud.com/server/10.13/admin_manual/installation/manual_installation/manual_installation.html#download-owncloud) describes how to check the GPG signature. Unfortunately, it does not work because at least my GPG reports:

gpg: Signature from Tue 21 Nov 2023 18:28:13 EAT
gpg: using RSA key E3036906AD9F30807351FAC32D5D5E97F6978A26
gpg: Signature cannot be verified: No public key

Please publish the fingerprint of the current GPG key somewhere.

How can I help to solve this problem?

[fmoc]

See owncloud/docs-client-desktop#540. The fingerprint is documented there as well.

[TheOneRing]

Looks like this was solved...

[proofy]

Just to explain it as an assumption.

As a hacker, I could perhaps gain access to the server that offers Owncloud for download.
I replace the current owncloud with a version with a backdoor, put my own GPG key on the download server and re-sign all packages.

Since all admins and users are already used to having to install a new key with every major version of Owncloud, they all install the hacker's key and install / update the hacker's Owncloud version on their system, which has the backdoor, unnoticed.
This gives the hacker access to any number of installations.