[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

closure on the changes file format?

A few days ago I posted a new formal package announcement and package
change documentation format that would allow the automation of the FTP
site and the changes list and archive, and could be used to provide
maintainer-to-user protection from package tampering.

To summarize, the user uploads a PGP-signed version of the changes file
along with the source, diff, and binary files for the package. For
example, I would upload sysvinit-2.57b-0.changes with
sysvinit-2.57b-0.deb, sysvinit-2.57b-0.diff.gz, and sysvinit-2.57b-0.tar.gz .
The format of the changes file would be:

	Package: sysvinit
	Version: 2.57b-0
	Date: Sat Aug 26 12:14:32 PDT 1995
	Priority: Install this right away, it fixes a big security hole.
	 (not really, this is just an example). A description of the security
	 hole can be found in CERT bulletin #xxxx .
	Changes: A description of the changes made goes here.
	 The rules for this field are the same as for the Description field
	 in Debian packages.
	# File: <name> <size> <md5checksum> <destination>
	File: sysvinit-2.57b-0.deb.gz 123456 0abcdabcdabcd binary/base
	File: sysvinit-2.57b-0.diff.gz <size> <md5checksum> source/base
	File: sysvinit-2.57b-0.tar.gz <size> <md5checksum> source/base

Changes from my original proposal: I had mis-named the Section field.
I changed "Description" to "Changes" to distinguish it from the
Description field in packages, I split the "Files" field into multiple
"File" fields, and I added the "Priority" field. Having the destination
in the "files" field allows us to split destinations, as in the case
of ncurses-runtime (in the base) and ncurses-developer (in devel).
We would use a shell script to build this file, edit it, and PGP-sign it.
The FTP archive would have a list of package maintainers PGP signatures.

The "Version" and "Section" fields are redundant with those in the
package. Should we use the ones in the package instead?

Have I addressed everyone's issues with the above? Can we come to a
consensus on it?


-- Attention Ham Radio Operators: For information on "Linux for Hams", read
-- the World Wide Web page http://www.hams.com/LinuxForHams, or e-mail to
-- info@hams.com .

Reply to: