Hi Erich;

Am 19.12.2012 00:47, schrieb Erich Titl:
> Hi KP
> 
> I am writing this in a warm evening breeze on the island of CuraƧao, so 
> if anything is fuzzy blame it on the local rhum.

Sounds good, I've catched a flu instead, so blame the fevered mind :)

> Am 18.12.2012 15:07, schrieb KP Kirchdoerfer:
>> Hi Erich;
>>
>> Am 16.12.2012 19:50, schrieb Erich Titl:
>>> Hi KP
>>>
>>> Am 16.12.2012 11:12, schrieb KP Kirchdoerfer:
>>>> Am 15.12.2012 23:14, schrieb Erich Titl:
>>>>> Hi KP
>>>>>
>>>>> Am 15.12.2012 19:54, schrieb KP Kirchdoerfer:
>>>>>> Hi;
>>>>>>
>>>>>> I did some work on Trac ticket 57 "add gpg signing of packages", and
>>>>>> like to discuss, what I've done so far.
>>>>>
>>>>> Will it still be possible to load unsigned packages?
>>>>
>>>> Yes. Currently verify is not integrated into the install or update 
>>>> commands.
>>>> The user *can* download a gpg signature file for a given lrp and verify
>>>> the package before he installs/updates it. It's recommended, but
>>>> everything else will work as before.
>>>
>>> I have a few more doubts
>>>
>>> If the verify mechanism is built into config.lrp then it is easy to
>>> circumvent it, by just disabling it there. This is even easier than in
>>> in initrd.
>>
>> The idea is to follow this route:
>> http://www.apache.org/dev/release-signing.html
> 
> I have not read it all and probably understood less.
> 
> It depends on what we want to achieve with signing the package
> 
> 1) We want tomake sure, the package has been created by someone in 
> possession of the signing key

Yes, that's the current goal! As a (small) step to improve security.
Maybe a step forward to 2) in the long run, but as you outline, this
will be very hard if not impossible.
E.g. if a hacker get's access to your box, he should be able to add his
own key along with malicious packages...,

There is simply a point where the user has to take responsibility for
his box.

kp

> 2) We want to make sure only signed packages with a known key are loaded
> 
> The first is very easy to achieve, the second IMHO is very hard.
> 
> 1) verifying the signature and thus verifying that packages come from a 
> certified source is easy
> 2) making sure only signed packages can be loaded is hard, as it 
> requires the package loader to be hardened against an attack.
> 
> The actual cryptographic routines are standard and are available on the net.
> 
> The problems come from the format of the packages. As long as they are 
> simple gzipped tar files one can do almost anything with it, the easiest 
> to get around the signing stuff is to use an old config.lrp :-(
> 
> The organizational structure around the trust is important, but IMHO not 
> the most important at this time.
> 
> I have not looked into the recent version of the package loader andd I 
> am not proficient enough to suggest a safe way to make sure only 
> official versions of the package loader would be accepted. It might need 
> compiled_in kernel function to make sure only a qualified package loader 
> can be used.
> 
> But all this is only needed if we want to protect the software against 
> the wiry hacker, just for verifying the packages this is not needed.
> 
> cheers
> 
> Erich
> 
> 
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> 
> _______________________________________________
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel
> 


------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

_______________________________________________
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Reply via email to