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?
8<-------------------------------------------------------------->8
#!/bin/bash
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 ../
8<-------------------------------------------------------------->8
Footnotes:
[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: