Bug#318630: Design TRUSTED support
Julian Andres Klode <jak@debian.org> writes:
> On Mi, 2010-06-02 at 11:26 +0200, Goswin von Brederlow wrote:
>> Any objections to the proposed design for this feature?
>>
>> - deb [key=0x1AB52325534,0x3475BDF478] ...
>> Only accept signatures by one of the listed fingerprints
> Sounds good.
>
>>
>> - deb [keyring=foobar.gpg] ...
>> Use foobar.gpg to verify the signatures and only foobar.gpg.
> What kinds of file names are supported:
> a) absolute paths
Not sure if that is needed. But it should be simple to support.
> b) files relative to /usr/share/keyrings/
Relative to Dir::Keyrings or something. Definetly must be configurable
by users/scripts so they can use their own keyring directory.
> Do we want to do permission checks on those files (i.e. only accept
> files not writeable by normal users)?
Are there permissions checks on the current default keyring? Writeable
by user if user is calling apt is definetly OK. So the check has to be
somewhat intelligent. Not sure if it is worth it.
>> deb [trust=always|never] ....
>> Ignore the Release signature and just always or never trust the
>> source. "always" would be for file:// or sources on the local
>> network where you don't care if it is unsigned. "never" would be for
>> repositories you want to always be asked before they are used and
>> which should not replace packages from more trusted repositories.
> Let's add trust=moo, which let's a cow ask you whether you trust this source...
>
>
> BTW, Wasn't this all part of vendors.list sometime ago (I don't know
> whether it was, it's not used anymore; and was not in use when I started
> using Debian).
[xxx] was the vendor field but it was never used. The parser just parsed
it and threw it away. It is quite possible that is was ment to reference
entries in another file (vendors.list) but probably never got finished.
MfG
Goswin
Reply to: