search

aptly-dev / aptly

aptly - Debian repository management tool
https://www.aptly.info/
MIT License
2.55k stars 369 forks source link

Why does not API use signing options specified in `aptly.conf`? #211

Open zerkms opened 9 years ago

zerkms commented 9 years ago

I have disabled signing using

"gpgDisableSign": true

but it's still required to set {"Signing": {"Skip": true}} explicitly.

What do you think?

smira commented 9 years ago

It's a good question: should API version depend on configuration at all. I believe it should not, to make API action more reproducible.

I would leave this question here.

E.g. right now API is using Architectures from configuration when calculating dependencies, which is not quite good.

zerkms commented 9 years ago

I actually like google-politics when reason about CLI commands/servers --- their configuration must be passed as command line arguments or environment variables entirely, without any config files.

At the moment the aptly api serve relies on config file - it takes at least a path to db/package files from there. Keeping that in mind it should be all-or-nothing applied: it's confusing to see some parameters to be taken into account, but not the others.

Commod0re commented 9 years ago

Keeping that in mind it should be all-or-nothing applied: it's confusing to see some parameters to be taken into account, but not the others.

When you consider the idea that two of the options determine where files are to be written, allowing (or indeed requiring) API calls to dictate that introduces potentially significant security implications that are avoided if those come from the configuration instead.

zerkms commented 9 years ago

@Commod0re I actually suggested the opposite: client cannot dictate anything: if in the config I specified that the repository must be signed - then a client should not be able to ignore that using {"Signing": {"Skip": true}}

Commod0re commented 9 years ago

You also suggested that it must be all or nothing (I assume for the sake of purity). I am pointing out that there could be security implications to going that route.

However, as to your point: I agree, and I'll expand a little: