Skip to content
This repository has been archived by the owner on Sep 21, 2022. It is now read-only.

File responses should allow signed files #31

Open
leper opened this issue Nov 21, 2017 · 2 comments
Open

File responses should allow signed files #31

leper opened this issue Nov 21, 2017 · 2 comments

Comments

@leper
Copy link

leper commented Nov 21, 2017

(Since in parts this API is trying to provide similar things as some package managers, learning some lessons from those is a good thing to do.)

It would be nice if one could optionally sign (most likely GPG (at least that is what most *nix package managers or related tools use, I'll still point towards OpenBSDs signify to indicate that there are alternatives)) mod files, so users of the API could verify that the files are actually the same as the mod creator provided. This removes some need to trust the actual API endpoint too much.

@intenscia
Copy link
Member

We shall investigate the best practices here, but is this signing the file, or the request / response payload? As discussed in another thread we do supply file MD5s

@leper
Copy link
Author

leper commented Nov 22, 2017

This is the author of the file signing it, and providing a digital signature (.asc files for gpg/pgp) with the file that you just distribute. (The signatures are roughly speaking (read up on some literature for more details) encrypting a pair of file length and cryptographic hash with the authors private key.)

This allows a user to verify that the file he got from the API (including the signature) is actually something the author published. The user will have to obtain the public key of the author via some other means (keyservers most likely, key signing parties, whatever).

This is not about making sure that the server handed you the file the API indicated[1][2], but that the file you got handed is one the author published at some point.

[1] Since we assume that the API and the server are controlled by the same party, and if not[2] you should be able to check that the server handed you something wrong with proper hashes #30 and file length.
[2] Since we connect directly to the API and that is done with HTTPS (thus TLS)[3] only we can assume that the data we get from it is whatever the API wants to hand us.
[3] If someone hijacks DNS to give the user another endpoint, and has a valid certificate for that domain (assumes the CA system is broken, or a quite powerful actor, which is really just the CA system being broken), then we are back to not really trusting the API which is what we are trying to prevent with signatures.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants