Core: Verifiable releases based on strong cryptography

[ypid]

Could you please consider doing the following steps to improve authenticity and security for the users and the development process of ownCloud:

• [ ] Sign git tags, GitHub also supports this and shows nice "Verified" badges then. Example: https://github.com/opening-hours/opening_hours.js/releases
  This allows devs and users to ensure that no one tampered with the release as the platform where you host your source code is not under your control (and even if it where …)
• [ ] Upload the release public key(s) on https://sks-keyservers.net/ Currently only found on: https://download.owncloud.org/download/repositories/9.0/Debian_8.0/
  This ensures that the public keys are available for everyone
• [ ] Mention how to get the public key pinned by it’s fingerprint on the website instead of downloading both files from the same origin.
• Additional for the developers consider to signed and verify git commits

Refs:

• https://github.com/debops/ansible-owncloud/pull/44#discussion_r73707876

[ghost]

Mhhh, whats the benefit of signed git tags? The hoster still could modify files between two tags and then you're signing a tampered release.

Furthermore the packages of the official releases from https://owncloud.org/install/#instructions-server are signed as well as the code within them itself (code signing).

Probablyb the only good thing would be to sign each commit?

[ypid]

I agree with you :+1: That would be ideal when the whole commit chain can be verified (ref: https://github.com/debops/debops-keyring). But that would require that every developer does that. So to get started, I would suggest that the person who signs the releases and tags checks as good as possible what they sign.

whats the benefit of signed git tags?

They would be a cryptographically proof that for example your other singed release forms (like the tar balls and internal code singing) corresponds to this particular development version. Ref: https://groups.google.com/d/msg/qubes-devel/vBbLCYDpXjg/EZMSra3oCAAJ

[PVince81]

@danimo what do you think ?

[danimo]

@PVince81 The OBS key is not controlled by us. that being said we do have a PGP key for the server afaik, and yes that could sign the release tags, as is common practice on the desktop repo already.

[danimo]

@RealRancor

Mhhh, whats the benefit of signed git tags? The hoster still could modify files between two tags and then you're signing a tampered release.

They can't, unless they are able to create a practical sha1 collision, which is extremely unlikely in git, even considering that sha1 is generally considered to be weak.

Also, we already only allow very few people to force push in core, so inconsistencies coming from github would be noticed immediately.

[ypid]

They can't, unless they are able to create a practical sha1 collision, which is extremely unlikely in git, even considering that sha1 is generally considered to be weak.

Also, we already only allow very few people to force push in core, so inconsistencies coming from github would be noticed immediately.

Seems you are assuming that your hoster (GitHub) is trustworthy. If it is not, the hoster could do other more nasty things because currently, there is no end-to-end authentication of every commit. One example would be that GitHub could present a different git history to the people who signing the tags then everybody else sees. This can only be really solved with strong, end-to-end crypto. I agree that the SHA1 preimage attack you mentioned is still unpractical but it is not even needed in this case as GitHub could transparently rewrite the things different people see.

For stage two of this issue, check Cryptographically strong code signing against the Qubes OS project which is already doing all the code singing properly and is at a stage where the SHA1 preimage attack could be the weakest links. ownCloud is not quite there yet.

we do have a PGP key for the server afaik, and yes that could sign the release tags, as is common practice on the desktop repo already.

That would be good then.

[danimo]

One example would be that GitHub could present a different git history to the people who signing the tags then everybody else sees.

That assumes that whoever does the signing only signed "the HEAD". I only sign what I work with on a daily basis (looking at the SHA). I also think that signing every commit is impractical if we want to stick with GitHub. How would merges (think pull-requests) through GitHub's web interface work?

[ypid]

That assumes that whoever does the signing only signed "the HEAD". I only sign what I work with on a daily basis (looking at the SHA).

Not really. Such an attack could be long term. How would you notice it? It would only be noticed if one finds a backdoor in a signed release and you start to compare the SHA1 sums :wink:

How would merges (think pull-requests) through GitHub's web interface work?

Easy. Just merge locally. Ref: https://github.com/micahflee/onionshare/issues/221#issuecomment-220317661

[danimo]

Sorry, I don't see that the benefit outweighs the limitations this would impose. In essence, this throws us back to 2008 git usage.

[ypid]

Depends on your work flow. You can automate this on the command line so that you just pull the changes and merge. Check: https://help.github.com/articles/checking-out-pull-requests-locally/#modifying-an-inactive-pull-request-locally

[DeepDiver1975]

I guess we can close this.

[ypid]

Ah ok. Seems ownCloud is not so focused on security anymore compared to NextCloud. Security is not easy, we all know that.

Sorry, I don't see that the benefit outweighs the limitations this would impose. In essence, this throws us back to 2008 git usage.

Please note that this is only required for signing merge commits which I did not ask for when opening the issue. It just came up in the discussion and goes beyond my initial proposal. @DeepDiver1975 So closing the issue because of this misses the actual part of the issue. Please reconsider.

[danimo]

No, we cannot close this as we want signed tags.

[danimo]

Actually, we want all the things in the original report, however the OBS signing is a bit more complicated, as some packages build on OpenSUSE's build infrastructure, not ours (esp. the clients). So we have to communicate that clearly to allow the best judgement (Note: I have no reason to doubt in openSUSE's abilities, but it seems not everyone understands that a different domain means that the effective infrastructure provider is not us).

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.

[PVince81]

We already sign commits since a while.

The tags are not signed AFAIK, we could add this to the new build script @patrickjahns

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[PVince81]

We could adjust the tagger script to also sign tags using the already known ownCloud key.

Something to think about when writing new release scripts @patrickjahns

[patrickjahns]

Added it to the list - question however remains - wether or not we only sign the tag/HEAD or if we want to enforce a full signed chain (every commit needs to be signed)

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.