__download: pgp/gpg signature verification

ungleich-gitea commented

2021-11-20 11:24:53 +00:00

Owner

as discussed in chat. dumping notes for future.

make --sum optional and make it very clear in manual that it's then user's responsibility to verify integrity of downloaded file.
add two new parameters: --gpg-pubkey and --gpg-signature or --pgp-pubkey and --pgp-signature.

both can be path to file or url. if url then key and signature must be downloaded. can we call type inside type itself?. extra effort must go into avoiding code duplication, because now multiple downloads may happen with one run. also __download can operate both locally and in target (remote).

--gpg-pubkey can also be path to local keyring (e.g --gpg-pubkey "$HOME/.gnupg/pubring.gpg") because dearmored pubkey is keyring already (just one key inside). at least this is how gnupg takes it.

if --gpg-pubkey is not given, then existing local or remote gnupghome will be used (option/envvar for gnupg not set). otherwise temporary gnupghome will be created both locally or remotely, depending where download happens. for example if user already have pubkey in local pubring or keys are deployed to remote using different method.

should we support other PGP implementations?
should we implement this feature as separate type to keep __download simple? not sure yet how much complexity it adds.

what else? @matze, please add your thoughts.

as discussed in chat. dumping notes for future. 1. make `--sum` optional and make it very clear in manual that it's then user's responsibility to verify integrity of downloaded file. 2. add two new parameters: `--gpg-pubkey` and `--gpg-signature` or `--pgp-pubkey` and `--pgp-signature`. both can be path to file or url. if url then key and signature must be downloaded. can we call type inside type itself?. extra effort must go into avoiding code duplication, because now multiple downloads may happen with one run. also `__download` can operate both locally and in target (remote). `--gpg-pubkey` can also be path to local keyring (e.g `--gpg-pubkey "$HOME/.gnupg/pubring.gpg"`) because dearmored pubkey is keyring already (just one key inside). at least this is how gnupg takes it. if `--gpg-pubkey` is not given, then existing local or remote gnupghome will be used (option/envvar for gnupg not set). otherwise temporary gnupghome will be created both locally or remotely, depending where download happens. for example if user already have pubkey in local pubring or keys are deployed to remote using different method. 3. should we support other PGP implementations? 4. should we implement this feature as separate type to keep `__download` simple? not sure yet how much complexity it adds. what else? @matze, please add your thoughts.

ungleich-gitea commented

2021-11-20 15:26:20 +00:00

Author

Owner

Writing here the thoughts and concerns from @ssrq from chat:

<manis:matrix.org> * Oh wow. After reading this discussion I'm kinda wondering if adding more parameters to __download is such a good idea.
Adding more parameters is the first step to build another __line, eek!

Ander: do you think it would make sense to split checksum verification and/or GPG verification into separate types that could be orchestrated using messages?

An advantage would be that they are reusable for other use cases.
On the other hand we create more objects which make things more complex to the user (maybe also more flexible?)

I would say yes to separate types like __gpg_verify and __checksum_verify which could be used from other types or the user directly. But I think __download should provide a short-hand way to utilize these types, too.

Writing here the thoughts and concerns from @ssrq from chat: > \<manis:matrix.org\> * Oh wow. After reading this discussion I'm kinda wondering if adding more parameters to `__download` is such a good idea. > Adding more parameters is the first step to build another `__line`, eek! > > Ander: do you think it would make sense to split checksum verification and/or GPG verification into separate types that could be orchestrated using messages? > > An advantage would be that they are reusable for other use cases. > On the other hand we create more objects which make things more complex to the user (maybe also more flexible?) I would say yes to separate types like `__gpg_verify` and `__checksum_verify` which could be used from other types or the user directly. But I think `__download` should provide a short-hand way to utilize these types, too.

ungleich-gitea commented

2021-11-20 15:26:21 +00:00

Author

Owner

My current need is to set an extra url for the type (like this: https://download.nextcloud.com/server/releases/nextcloud-20.0.0.tar.bz2.asc) which contains a signature. With this signature and and a valid/trusted pubkey, which would be at best be trusted from the config host instance (which doesn't work if will be downloaded on the target), the type should validate the downloaded content.

Because a type which utilize __download (it's __nextcloud for my case) may be used from users without trusting that signature, it might be problematic doing that. Should the key rather be provided by that type (e.g. via argument) or simply skip if the user doesn't want it? then, how the user opt in/out? Not all users want to handle the signature/checksum stuff, rather to just install it via the type.

I mean, we need to think how the type __download can be utilized by other types. Should we completely pass everything up to the user or how? I mean it's a bit different if you call this type via your initial manifest or if you let your type depend on a version number passed down by a parameter.

My current need is to set an extra url for the type (*like this:* https://download.nextcloud.com/server/releases/nextcloud-20.0.0.tar.bz2.asc) which contains a signature. With this signature and and a valid/trusted pubkey, which would be at best be trusted from the config host instance (which doesn't work if will be downloaded on the target), the type should validate the downloaded content. Because a type which utilize `__download` (it's `__nextcloud` for my case) may be used from users without trusting that signature, it might be problematic doing that. Should the key rather be provided by that type (e.g. via argument) or simply skip if the user doesn't want it? then, how the user opt in/out? Not all users want to handle the signature/checksum stuff, rather to just install it via the type. I mean, we need to think how the type `__download` can be utilized by other types. Should we completely pass everything up to the user or how? I mean it's a bit different if you call this type via your initial manifest or if you let your type depend on a version number passed down by a parameter.

ungleich-gitea commented

2021-11-20 15:26:23 +00:00

Author

Owner

changed the description