[prev in list] [next in list] [prev in thread] [next in thread] 

List:       osdl-lsb-discuss
Subject:    Re: [lsb-discuss] [Webdevel] Key for signing downloadable printer
From:       Till Kamppeter <till.kamppeter () gmail ! com>
Date:       2008-11-06 15:47:18
Message-ID: 49131186.4080003 () gmail ! com
[Download RAW message or body]

I think we should proceed with the set up of keys for signing the 
downloadable driver packages. For the distributions to accept them we 
should look at what is common practice there, so that we have more or 
less the same level of security.

I have renamed the packages and made them installable and usable 
independent of whether the same driver is already installed as a package 
from the distro or not.

If it is easier for the signing to make only one repository for all 
packages (instead of one for each driver) I can switch the query 
interface to return package manager config info with the one main 
repository.

    Till


Till Kamppeter wrote:
> Theodore Tso wrote:
>> Maybe I don't understand, but if you use the combined repository, it
>> doesn't follow that you must install all of the packages in the
>> combined repository; so I'm not sure why the only way to suppressed
>> undesired updates is to use a driver-specific repository?
>>
> 
> Imagine a distro has splix-1.1.1-1 installed which is used for a 
> printer. Now the user needs the newest gutenprint 5.2.0 and installs it 
> from OpenPrinting. To keep his OpenPrintiung-installed Gutenprint up 
> -to-date, he adds the OpenPrinting repository to /etc/apt/sources.list. 
> Now SpliX 2.0.0 gets uploaded to OpenPrinting. With one repository for 
> all drivers, the next auto update of our user would update SpliX, what 
> the user really doe not want to happen.
> 
> This was the reason why I introduced per-driver repositories. I will 
> rename the packages soon (see other mail). Then I can drop the 
> per-driver repos.
> 
>> True; which means the bad guy would have to add an extra hard link and
>> add a few lines to each the repository's index file.  I'm not sure the
>> extra effort required is large enough that we could honestly call that
>> a significant barrier for the attacker.  :-)
>>
>>
>> In any case, if we get back to the topic of the signing key for
>> OpenPrinting, who would need to have access to the signing key, and
>> how often will it need to be used --- i.e., how frequently do you
>> expect new printer drivers to be added or updated?  Is this something
>> that would be done every day?  Every week?  Would it be batched to
>> once a every month or two?  Etc.
> 
> The procedure I was thinking about is that manufacturers/driver 
> developers upload into a hot folder (or via a web app). If they are 
> trusted, a script should put the LSB RPM package into the public 
> download area, generate the corresponding Debian package, update the 
> indices, and finally sign the packages or indices appropriate to the 
> needs of the package manager tools of the distros, and in the end 
> auto-post an announcement in the announcements forum.
> 
> For uploaders not trusted, the uploads stay in a queue and one will be 
> able to browse this queue with a web app. Admins will then be able to 
> download the package for testing and pass it through to get into the 
> public download area, using the script mentioned above.
> 
> With such a procedure the key with which the packages/indices get 
> actually signed needs to be without password, as a script will do the 
> signing. So this key probably needs to get changed regularly.
> 
> Package uploads which would get treated by such a script would happen 
> perhaps once in 2 weeks, dependent on the number of manufacturers who 
> will contribute drivers.
> 
> The master key needs to get accessed perhaps twice a year, to sign the 
> new package key.
> 
>    Till
> 

_______________________________________________
lsb-discuss mailing list
lsb-discuss@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic