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