Necmettin, I may be wrong, here is my comment; Assume you have a package sum and you want to verify it from a database. Don't forget the unsecurity of the communication channels. You use an unsecure channel in order to get trusted md5 from database. Some eavesdropper can change the md5 value on air and send you the md5 of the file you get. And thus you verify the wrong package. I think public key cryptography still needed. Because packager signs the package with his/her private key, and sign can not be changed on air. Because corresponding public key verifes the sign, any changed sign can be detected.. yavuz.... <div>On 18/04/2008, Necmettin Begiter <<a href="mailto:necmettin.begiter@gmail.com">necmettin.begiter@gmail.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 2008/4/18, Serdar Dalgic <<a href="mailto:serdar@cclub.metu.edu.tr">serdar@cclub.metu.edu.tr</a>>: As far as I know, packages in Pardus do not include themselves' SHA1 or MD5 sums. Included in the pspec.xml is the SHA1 sum of the .tar.gz/.zip/.whatever (the actual package, not the container (the .pisi file)), and the pisi-index.xml file is basically a container for all the pspec.xml files in the repository, which means it does not include SHA1 or MD5 sums of the .pisi files either. The .pisi file is a container for the pspec.xml, translations.xml, files/*, and the actual package, which makes it just a shell AFAIK. When the user tries to install a .pisi file (either manually or through the 200x or contrib repositories), PiSi could easily get a MD5-or-SHA1 sum of the .pisi file and check it against the value in the database table if the system is online. On the database side, package maintainers (of the 200x and contrib repositories or of any other repository) would not have to do anything for this system to work. The system would add/update the MD5 or SHA1 sum of the new/updated .pisi packages automatically, once it learns that any one of the repositories has updated its index. > >  So when somebody tries to install a package, pisi will check whether the > release files match and signed with distribution key; otherwise tell the > user that the packages s/he is trying to install may harm his/her system, > but also pisi gives the chance to continue.. User may have the chance to > keep on installing the "unsigned" package, but pisi freaks out on every step > (or one in two steps =) ) that's a little bit "fork" of debian's apt-secure > system as stated here[1]. The mechanism that's going to be implemented to > PiSi would evolve in terms of needs and PiSi structure.. > >  and that's my proposal for the situation. > >  any comments and reviews are welcomed. > >  serdar > >  [1] <a href="http://wiki.debian.org/SecureApt">http://wiki.debian.org/SecureApt</a> Here is a short criticism of Debian's SecureApt system (I am not a security professional but I will not confide in it just because Debian said so, and I believe the package signing mechanism of Debian is a little bit too limited): 1. Keeping the MD5 sums in the Release file is logical as long as all the repositories and packages are in your reach/control. The Release file is updated whenever a package is updated, and once developers start creating packages outside the "accepted" sources (devel-200x-contrib repositories in our case), the Release file, thus the MD5 sums and gpg keys, is/are out of reach for anybody but the packager/developer/repository owner. 2. The package management system not asking anything (because the definitions needed are already installed to the local system) to the official package signatures center (that would be the database table in my proposal) decreases the "amount" of security if I may say so. 3. In Debian's SecureApt system, a developer can have his/her own secure apt repository; all the signatures and sums are provided by that very developer, which means the distribution "authorities" have no control whatsoever over what that developer provides (both as a package and as a control mechanism (signatures/keys/sums)). The disadvantage this creates comes from the fact that being signed and being secure are two *very* different things. Apt the application is secure, the package is signed, but that's all, the packages are not secure. 4. SecureApt, in its current form, tries only to make sure that there has been no intervention in the process of package download; it is simply like using the HTTPS protocol in place of the HTTP protocol. Long story short: I believe Pardus project will in a near future encourage (at least not discourage) .pisi packages not in the current repositories (200x and contrib). Debian's SecureApt assumes safety as long as the maintainer of a repository or package knows how to take md5 sums and how to gpg-sign something. This is not the way to security. IMHO, a "secure package" is secure as long as it is approved by both users/ developers/ maintainers/ packagers. Debian's current mechanism makes "safe to download" packages, not "safe to install" packages. That is why I propose of a database table that is controlled by official Pardus developers or someone who has authority either officially or not. Even shorter: MD5 sums and signatures/ keys must be controllable officially, not locally. So, it appears to me, what we need might be not a package signing mechanism but a package verification mechanism. Necmettin _______________________________________________ Gsoc mailing list <a href="mailto:Gsoc@pardus.org.tr">Gsoc@pardus.org.tr</a> <a href="http://liste.pardus.org.tr/mailman/listinfo/gsoc">http://liste.pardus.org.tr/mailman/listinfo/gsoc</a> </blockquote></div>