package-get-base.el issues (was Re: [patch] enhancements to package-ui.el)
Pete Ware <ware(a)cis.ohio-state.edu> writes in xemacs-beta(a)xemacs.org:
greg(a)alphatech.com (Greg Klanderman) writes:
> All this package-get-base.el stuff is such a pain. Now there's the
> incremental updates to deal with... blech. I wish we could just
> reliably and automagically snarf the current one off ftp.xemacs.org.
O.K.
> Suggestions anyone?
When I originally wrote the code, one thing I was concerned about
was
XEmacs being easily exploited for trojan horse attacks. In
particular, a talented hacker could intercept ftp requests to
ftp.xemacs.org and substitude their own versions of packages -- hence
the md5 checksum for each package.
I consider these to be valid concerns.
But then the problem becomes grabing package-get-base.el -- if that
gets intercepted then there is a problem. Bogus md5sum's can be
substituted, host names changed, package locations, etc.
Right.
I pictured two distribution methods for package-get-base.el. It
either gets sent with the entire distribution (which are signed). If
that is corrupted, well you have bigger problems anyway.
Distributing with the core isn't working and I've removed it from the
core. I am willing to revisit this decision if there is some
assurance of reliability.
The second was a periodic posting to a newsgroup/mailing list.
Presumably, such an article would be PGP signed and could be
verified as being from the poster.
That's a reasonable idea. We need to revisit the issue of signing
anyway. I'm currently signing with PGP 2.6, but it is incompatible
with GNUPG, which I am informed conforms to what will become the
OpenPGP standard about to be created.
I'm not signing the individual packages because of time constraints --
the passphrase must be typed for each signature. This isn't much of
an issue when signing distributions, but it doesn't scale up into
dozens of files. Signing package-get-base.el isn't a problem and
sounds like a good idea.
Automatic access to package-get-base.el is dangerous.
Yup.
What we need is some utility code for manipulating
package-get-base.el. I've modified the format somewhat to make it
easier to process with very little specialized support like the
autoloads generation requires. It now looks like:
;; Package Index file -- Do not edit manually.
(setq package-get-base '(
;;;＠＠＠
(zenirc
(standards-version 1.0
version "1.03"
author-version "2.112"
date "1998-08-15"
build-date "1998-10-12"
maintainer "XEmacs Development Team <xemacs-beta(a)xemacs.org>"
distribution stable
priority medium
category "comm"
dump nil
description "ZENIRC IRC Client."
filename "zenirc-1.03-pkg.tar.gz"
md5sum "cf85b0358688c286d2ce16ab7f4cc95b"
size 276114
provides (zenirc)
requires (zenirc)
type regular
))
;;;＠＠＠
(w3
(standards-version 1.0
version "1.10"
author-version "4.0pre23"
date "1998-07-18"
build-date "1998-10-12"
maintainer "XEmacs Development Team <xemacs-beta(a)xemacs.org>"
distribution experimental
priority high
category "comm"
dump nil
description "A Web browser."
filename "w3-1.10-pkg.tar.gz"
md5sum "6113b455f82c5903b8bd6f4ca48afb00"
size 612442
provides (w3 url)
requires (w3 mail-lib xemacs-base)
type regular
))
;;;＠＠＠
(vm
...
The rudimentary support I'm using to make updates is attached. There are
plenty of possible enhancements.
In terms of needed features, we need the following:
QA code to loop over each entry in a package-index file and verify
that the md5sum in the index matches the tarball in the same
directory.
Code to merge multiple entries.
It would also be nice if we could add as a fetch interface something
MIMEish where one can create a MIME multipart entry that contains a
package-info file that can be clicked on to retrieve/verify/install
the associated package.
Attachments:
- hack-package-index.el (text/plain — 2.4 KB)