[Gsoc] A proposal about package signing/verification

[Serdar Dalgic]

Hi to all

Necmettin Begiter wrote On 18-04-2008 01:04:
> First, if I'm mistaken or if failed to understand the aim behind this
> idea, forgive my limited knowledge and understanding of the issue.
>
> Here is what I understand of "a package verification system": We want
> to track if we are "acknowledged" of a package's existence/acceptance.
> We don't want pisi to install packages that we don't know of.
>
>   
I think we can extend this issue to a "chain of trust" mechanism from 
the maintainer of the package to the end-user. It would include 
maintainer's signature for uploading the file to the database, maybe an 
archive key for the distribution, and several more security/trust 
mechanisms. At the end, pisi should be aware of installing packages that 
are claimed to be "not changed" on road =)

> And here is my proposal as a solution to this issue: A database table
> that holds package names, versions and md5 sums. When the user wants
> to install a package, pisi would ask the database for the md5 sum of
> that package, if the sums don't match, that means we don't know of
> this package, it should not be installed or the user should be
> informed that the package is not in the database and to install the
> package may harm the system; which I believe would make it unnecessary
> to "sign" any package (I might be wrong about this last part).
>
> Comments?
>
>   

I agree with your proposal. It seems exact, however the md5sums may be altered while the files are being transmitted. Several changes would be 
beneficial for this signing mechanism proposal. 

Your "database-table" structure may be extended to a "release" file. This release file would possess the md5sums of the packages (and maybe 
SHA1sums of the packages as files.xml of every package has SHA1sum of the package) . And also this file would be signed with Distribution Key. 
(signing with OpenGPG would be sufficient). This release file should be updated as any of the packages in the archive change.. The user should 
enter this key to his/her own keyring for success.

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] http://wiki.debian.org/SecureApt

> Necmettin
> _______________________________________________
> Gsoc mailing list
> Gsoc at pardus.org.tr
> http://liste.pardus.org.tr/mailman/listinfo/gsoc
>