No support for unsigned package-repositories

[Robie Basak]

My use case is the same as in bug 1918968. I have a local apt repository (file:/// URL) that I'd like to make available via package-repositories. snapcraft currently demands a key-id and a corresponding key (whether available locally in snap/keys/ or from a keyserver). So to use package-repositories in "local mode", I am forced to sign it with a temporary key and provide that to snapcraft.

This seems unnecessary because apt supports a [trusted=yes] option in the sources.list entry.

Expected: snapcraft exposes an option to set [trusted=yes] to pass through to apt.

In the back of my mind I think [trusted=yes] might have recently become the default for file:/// anyway, so it might be sufficient to just stop assuming that a public key always has to be provided. I'm not sure though; if this isn't the case, then I'd like a "trusted: yes" type option under the package-repositories key please.

[Chris Patterson (cjp256)]

I talked with Gustavo and we agreed that support for this can be added by introducing a new property `insecure: true` that would be required when key-id is not present. Initial support would be limited to file:/// repos.