Document signing key change for Linux repositories

[fmoc]

With desktop client release v5.0.0 (well, actually with v5.1.2, which brought back Linux packages), we changed our signing key for the Linux packages from the old ones to ownCloud Client Team (Signing Key) <info@owncloud.com> with the fingerprint F05F7DD7953A07DF36579DAA498C45EBE94E7B37.

Users started to notice this change and reported this to us. It turned out that we didn't even mention this change in our documentation. We should change that. Could you please add a short section in the installation instructions that the new key is the one to be used? We could add some more instructions on how to fetch the new key.

CC @michaelstingl

[mmattel]

Also see: https://chrisjean.com/fix-apt-get-update-the-following-signatures-couldnt-be-verified-because-the-public-key-is-not-available/

[michaelstingl]

We could add some more instructions on how to fetch the new key.

@fmoc those key update instructions not sufficient?

• https://download.owncloud.com/desktop/ownCloud/stable/latest/linux/download/

[fmoc]

They do not emphasize that the key actually has changed. This is what surprised some people. The fingerprint is not expected to ever change, really. We need to communicate actively that the key (fingerprint) is a new one now and that this is expected and safe.

Edit: but yes, the instruction to download and import the key are correct of course, and we recommend people to run these with any upgrade. However, many people use the "latest" alias and get the new releases automatically. They may even just fetch the updated key from the keyservers using gpg once it expires. So, for them, a change is very unexpected.

[phil-davis]

For example, I have Ubuntu 20 and usually updates happen automagically when I am doing routine sudo apt update sudo apt upgrade - the updates come along with whatever other software updates are available across the system.

Because it is pretty automatic, I may not look in detail at the output for a while (which is reporting some key error/not found...). And so I don't even realize that I have missed out on updates.

As well as documenting when the key has changed, it would be really good not to change the key again (for as long as possible).

[michaelstingl]

Related:

• https://twitter.com/proofy/status/1725803381812289607
• https://central.owncloud.org/t/problem-again-with-new-gpg-key-during-update-upgrade/45991

[proofy]

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]

Please open another issue with the desktop client in https://github.com/owncloud/client/issues/new to propose your changes. These are off topic here. We have a concrete change (unified signing key) and need to document it.

[fmoc]

As well as documenting when the key has changed, it would be really good not to change the key again (for as long as possible).

That's the idea. Having a unified signing key for all platforms. The old keys (yes, plural) were really, really old and would have had to be replaced for security reasons at some point anyway. We'll be keeping the current one for as long as possible (probably until security wise a key algorithm change is needed again, from RSA to EdDSA for instance).