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

[zerkms]

I have disabled signing using

"gpgDisableSign": true

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

What do you think?

[smira]

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]

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]

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]

@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]

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:

• the API should take everything in the config files as defaults (instead of the aptly-supplied defaults)
• some things should not be able to be overridden by the API. I'm not sure if this should be a set list of things that cannot be overridable, or if there could be some way of tagging important directives in the config itself