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

CVS/ subdirs in Debian source tar files?

 I'm thinking of setting up the Debian build system for the
 `xemacs-packages' so that it can run from a CVS checkout of the
 sources.  When you build a Debian package, the source is shipped as
 an .orig.tar.gz file along with a .diff.gz that contains a patch
 against the "upstream" version.  That diff often contains only the
 debian/* subdirectory...  I certify by signing with `pgp/gpg' that
 the binary I'm uploading was built from the source I upload with it,
 and those source files must match an md5 sum in a source control file
 or `dpkg-source -x' will complain when someone tries to build the
 package themselves.

 My question is: Should the .orig.tar that I ship contain the CVS/
 control information so that someone could run a `cvs status' or `cvs
 diff' as an auditting method, to verify that the .orig.tar.gz I
 upload is authentic and not modified outside of the .diff.gz shipped
 with it?  (and then I will also document that as a source audit
 procedure.)  Or will that potentially put too much strain on
 `cvs.xemacs.org'?[1] I have no clue how many people would run that
 audit...  I know there are certainly adminstrators out there who are
 concerned about trojan horses, cookie monsters, and Gnu knows what
 other patch got backed out before the source was shipped ten days
 ahead of the Millenium Foof 199-200 Day.  (I'm told that some folks
 want to run only stuff they build themselves, from code they can
 validate in some fashion.  Most of us trust the maintainer and just
 use the binary packages.)  (I plan to remain trustworthy, unless I
 get too broke and too hungry and you own a large grocery store.)

 I'll pull down a pristine checkout, then using a local cvs repository
 for version control, (at least until I have it fairly well developed
 and worth commiting to the xemacs CVS repository...), I'll create an
 xemacs-packages/debian subdirectory with the debian/rules makefile
 and suchlike.  My diffs will be visible in the .diff.gz file that
 `dpkg-buildpackage' creates, the .orig.tar.gz file will be
 "pristine", and there will be a simple way to audit the authenticity
 of the up-to-the-minute source.

 The alternative might be to download the src.tar.gz files... but I
 would rather work toward getting the debian packaging control stuff
 committed to the repository at some point, and think that starting
 with a CVS checkout is simpler.  Either way, I think that any
 monkey-business with the codes on my part would be fairly visible to
 an auditer anyway... that being the security concern I've been made
 aware of.  Are there other concerns?

set -e

# This assumes that an initial checkout has been done of
# `xemacs-packages/' from cvs.xemacs.org, and that a `cp -a' has been
# made of it, the original to be kept pristine, named with the iso
# formatted date and .orig/, the other, a work copy, name extended
# with only the iso date.  Packaging will take place within the work
# copy's directories.

# first update the pristine `.orig' sources.
mv xemacs-packages-*.orig/ xemacs-packages-$(date +%Y.%m.%d.orig)/
cd xemacs-packages-$(date +%Y.%m.%d.orig)/
cvs -z3 update
cd ../
# Don't compress tar, and sign it uncompressed leaving option for .bz2 or .gz later... perhaps.
tar cf xemacs-packages-$(date +%Y.%m.%d.orig).tar xemacs-packages-$(date +%Y.%m.%d.orig)/
# sign it here with my `gpg' key, perhaps.

# That is the tar file that `dpkg-buildpackage' will use to create the .diff.gz from.

# Now update the work copy.
mv xemacs-packages-[12][90][0-9][0-9].[01][0-9].[0-3][0-9]/ xemacs-packages-$(date +%Y.%m.%d)/
cd xemacs-packages-$(date +%Y.%m.%d)/
cvs -z3 update
cd ../

[1]  Perhaps there is room on one of the Debian project's CVS servers
     for a mirror of the XEmacs repository?  I will ask if yous think
     that would be useful and helpful.

Reply to: