GPG-pubkeys

[Basil Chupin]

Jeff Johnson wrote:
> 
> On Sep 11, 2006, at 10:50 AM, Basil Chupin wrote:
> 
>> Christoph Thiel wrote:
>>> On Sat, 9 Sep 2006, Basil Chupin wrote:
>>>> Further to the earlier thread, "F**** annoying unavailable keys", 
>>>> but on a slightly different tack, is there a way to make smart to 
>>>> simply *accept* an offered gpg-key when smart is upgrading a package 
>>>> rather than have it sit like a shag on a rock waiting for me (for 
>>>> example) to click on YES so that smart can continue with the 
>>>> download of the package?
>>> This would render any kind of key checking useless, as smart would 
>>> accept any key that's available on the configured keyserver.
>>> I'm currently looking into enabling -y / --yes to work with key 
>>> checking as well, so you could just use "smart upgrade -y" then... 
>>> however, it's just like completly turning of key checking in the end.
>>
>> I am just a bit lost here....
>>
>> I don't remember having to accept a gpg-key from each and every source 
>> of upgrades for my OS (SUSE) but only 2 or possibly 3 sites had to 
>> have their gpgs accepted or rejected (but who in their right mind 
>> would do that anyway?). So, what is the big deal about these gpg-keys 
>> when they are not universally used?
>>
>> Or have I missed something (more than likely!) and the use of gpg-keys 
>> is an integral part of any upgrades from any source and smart just 
>> will not so any upgrades unless the necessary key is accepted?
>>
>> I simply don't know how or why these keys play such a "vital" role in 
>> smart's upgrade process.
>>
> 
> Public keys are a vital part of insuring that a rpm package has not been 
> tampered with.
> 
> Public key management, new in recent smart, basically
>     Is it okay to import this public key (Y/n)?
> requires interaction with the end-user for new public keys.
> 
> Meanwhile, there are other ways to distribute and install public keys that
> do not involve human interaction. E.g. importing the handful of public keys
> for the repository uses will avoid the necessity of answering yes 
> mindlessly.

Which is what I am trying to suggest could be done to avoid uncompleted 
upgrades by using methods which do not involve human intervention.

Cheers.



-- 
This computer is environment-friendly and is running on OpenSuSE 10.1