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.
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 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