Check downloaded files with GPG before using them.

[ypid]

Refer to:

• [security] Ensure to retrieve the correct PGP public keys by importing by there fingerprint. owncloud-archive/vm#45
• Check downloaded archive with GPG. jchaney/owncloud#12

[enoch85]

I saw you made a PR for this before, could you please add one here as well?

[enoch85]

Btw, this is not done with packages.

[ypid]

I saw you made a PR for this before, could you please add one here as well?

I think I did not submit a PR for this yet. I will be happy to review your PR 😉

[enoch85]

@ypid Done: c38e0c3

[ypid]

@enoch85 Thanks very much for your work. That means a lot to me because this
will ensure that tempering with the build process will become more difficult.

However, I am afraid that you completely missed the point of checking the GPG
signature in the first place.

I refer you to this comment: jchaney/owncloud#12 (comment)
to which I already referred to in my opening comment in case it is unclear what the use case of GPG is here.

As it seems that the public key of NextCloud is currently not available on public key servers, you can do this little trick:

gpg --homedir /tmp/gpg --import nextcloud.asc
gpg --homedir /tmp/gpg --export 28806A878AE423A28372792ED75899B9A724937A | gpg --import -

to enforce the correct key fingerprint of the public key.

[enoch85]

I used the docs, and according to them my fix is valid: https://docs.nextcloud.org/server/9/admin_manual/installation/source_installation.html?highlight=asc#example-installation-on-ubuntu-14-04-lts-server

https://github.com/nextcloud/vm/blob/master/nextcloud_install_production.sh#L249-L264

[ypid]

Your fix is valid but as I said, does only get you very little compared to if you enforce the fingerprint in your build scripts, that will give you (and all users) a whole lot more. In my opinion both the NextCloud documentation and the ownCloud documentation about checking GPG signatures are a bit unmindful and need to be fixed. But note that setting up NextCloud or ownCloud one time as a typical admin vs. writing scripts to build a template VM has a different threat model: https://www.qubes-os.org/news/2016/05/30/build-security/

Refer to On Digital Signatures and Key Verification to learn why your current approach does not fully resolve this issue.

However, for digital signatures to make any sense, we must ensure that the public keys we use for signature verification are indeed the original ones.

Sysadmins and devs must know that.

Let paste in my linked example:

Not including the signing key from (NextCloud|ownCloud) or at least specifying the fingerprint does destroy the whole purpose of checking the signature in the first place. What would happen when in the (Dockerfile|build script) all three files are downloaded over https and someone compromised there website? Right, the adversary would create a new public/private key, sign the archive with it and upload the public key … When we remove the public key from this repo, there is no benefit in security …

In the case of NextCloud, the public key and the archives are hosted on different servers from what it appears but that is nothing that will stop a skilled adversary.

The gain in security enforcing the fingerprint in the build script will get us is that even when *nextcloud.org* would get compromised and your build environment is still trusted, the VM template could not be compromised that easy.

BTW, thanks for referring to your implementation again:

echo "$?"
if [[ $? > 0 ]]
then
        echo "Package NOT OK! Installation is aborted..."
        exit 1
else
        echo "Package OK!"
fi

$? only contains the exit code of the last command (and that is echo which is very unlikely to return anything else than 0). Good that you put an set -e at the top 😉

Disclaimer: I don’t want to be offensive in any way. I just care about security.

Please reconsider.

[enoch85]

Thank you for your long post. How would the GPG key be useful after the build is done? I don't see any usecase for it. Even you deleted the whole folder in you code.

Regarding the code, that's already fixed, but not merged. Just used it in testing purposes. ;)

Btw, this is open source - instead of writing about it, you can actually make a PR. It's an easy fix. :D In the same amount of time you've spent on writing that post, you could simply just write the piece of code instead. Now it seems like you just want to show off.

[ypid]

In the same amount of time you've spent on writing that post, you could simply just write the piece of code instead.

I did/do that often. The problem was when the maintainers don’t understand what the purpose of it is it might get broken. Seen that happen. So excuse me for that.
Can you enforce the public key as suggested now that you understand the background?

How would the GPG key be useful after the build is done?

I guess NextCloud updates happen via NextCloud’s update mechanism? If not, a new archive might need to be downloaded again. Anyway, I think it makes sense to ship the GPG key with the VM.

[enoch85]

Can you enforce the public key as suggested now that you understand the background?

I guess that's just a flag that need to be set?

I guess NextCloud updates happen via NextCloud’s update mechanism?

They don't use package managers like apt-get, so every new version has a new key.

[ypid]

I guess that's just a flag that need to be set?

I have not found one yet. If you do let me know 😉

They don't use package managers like apt-get, so every new version has a new key.

You sure? The whole purpose of a public key is that people can use it to verify signed releases.
Also looks like NextCloud git release tags are signed now which is awesome: https://github.com/nextcloud/server/releases

[ypid]

@enoch85 Can you maybe reopen?

[enoch85]

If someone else wants to work on this, sure.