On Sat, 2007-11-03 at 21:48 +0100, Manfred Tremmel wrote: > Am Samstag, 3. November 2007 schrieb Andreas Schneider: > > Aniruddha wrote: > > > Actually this is even more easy then it sounds (and I am not a > > > programmer). It only requires to document some simple rules for > > > package handling (e.g. that packager should check for malware, and > > > the monitoring of some standard security bulletins). > > > > It is easy? Ok. > > > > How should we check a new version of an application/program for > > malware? > > At the moment we do have only 3.8 GByte in our 10.3 SRPM-directory, so > it shouldn't be a problem to check the sources line by line. > Next packages will be available in the year 2350 ;-) > It's all a question of (wo)manpower and the number of packages. We do > have more then thousand packages and only a view sparetime packages. We > can trust the programers, and go on like now, or review every tarball > and reduce the number of packages to three or four for every packager. >
Pleas check my mail to Andreas Schneider for answers to your questions: Let's first define the context 1 We trust the author of the original package. 2 Checking for malware is only to prevent the (very slight chance) that $upstream get's hacked and it's packages are modified to provide a backdoor (rootkit, trojan). 3 We do not want to do a complete source audit, since it's too time consuming and probably not necessary. Now on the the question how to check a new version of an application/program for malware. Since I am not a programmer I do not not know a lot of screening sourcecode. I did understand however (from (people who do know how to program) that a malicious modification should be easy to spot. Can you confirm this? Here are some general ideas -How can we make sure $upstream arrives untampered? I do think that md5 of shasum checking is essential in order to verify that a package arrives exactly as $upstream provides it. -Put some kind of scanning (f-prot, kaspersky) software on the Packman repo's. -The expertise and experience of the packagers is also an important factor. This experience makes that packagers could potentially see faster when something is out of the ordinary. -Set up a testing branch that people like me can use. I use rkhunter and chrootkit and therefor I should be able to spot problems beforehand. When no problems have been reported for some while the rpm's can be moved to stable. -Set up a security announcement mailing list and recruit people who can monitor predefined channels for security issues. -- Regards, Aniruddha _______________________________________________ Packman mailing list [email protected] http://212.112.227.138/cgi-bin/mailman/listinfo/packman
