Patrick Schoenfeld <[EMAIL PROTECTED]> writes:
> Hi Goswin,
>
> On Mon, Jun 23, 2008 at 01:07:38AM +0200, Goswin von Brederlow wrote:
>> For example: Each repository puts its keyring into Release.keyring
>> (next to Release and Release.gpg). The Release.keyring could be listed
>> with checksum in Release so frontends know it is there and when it
>> changes.
>
> personally I'm not sure if it is good at all to store the key on the
> server whose integrity is to be checked. In my opinion it would be
> neccessary to get the key from some trusted instance, because if I'm not
> well-integrated into the web of trust myself I cannot rely on the key
> beeing checkable by my own trust-net.
The beauty of signatures is that you do not have to trust the source
of the key, only the signatures. It truely doesn't matter wher you get
the key from.
As for the signature there is no difference between trusting apts key
to safeguard the Release file or a new key. So normal key updates will
not change its trust level with this.
Further, on first install, you probably will have to trust a signature
from the debian keyring for closely debian related repositories. I'm
assuming there will always be some maintainers there to sign the
archive key. But every debian user has the debian keyring from a
trusted source. While you might not be integrated into that web of
trust you already do have to trust it. Those keys do sign every
package upload after all.
Only for 3rd party repositories you would be completly dependent on
the web of trust. But those wouldn't get their keyring into debian
either. So no change in trust there.
Overall having the key on the archive server looses you nothing but
gains you flexibility and transparency. Now if only someone would
write a proof-of-concept implementation...
>> I'm not proposing that just any key should be silently accepted. Just
>> that it should be automatically fetched and independent of debs. I
>> already did run into a case where I could not update the keyring
>> package because the Release signature required the new keyring
>> package.
>
> I now understood. Its an interesting idea, I just think that some factors
> need to be worked out, because there should be a chance for the *average*
> user to understand if a key could possibly be trusted or not. (Not every user
> understands those web of trust thing and this is something that can't
> really be asked for).
I think you are wrong there. I think it is something that must be
asked. You can't have security without understanding. Just think how
many users blindly accept ssl ceritificates and then think https is
save because it is encrypted. It is just a false sense of security.
> Best Regards,
> Patrick
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
