[Gsoc] A proposal about package signing/verification
serdar at cclub.metu.edu.tr
Fri Apr 18 03:38:14 EEST 2008
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).
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. The mechanism that's going to be implemented to PiSi would evolve in terms of needs and PiSi
and that's my proposal for the situation.
any comments and reviews are welcomed.
> Gsoc mailing list
> Gsoc at pardus.org.tr
More information about the Gsoc