Re: 1.0 issues: Packaging (esp. source)

[Ian Jackson <ian@chiark.chu.cam.ac.uk>]

J. H. M. Dassen writes:
> [Ian Jackson writes:]
> > 7. Unpacking a source package should not require one to execute parts
> > of it (ie, source packages should contain only data, not code used
> > during the extraction).  This is important for security reasons.
> 
> If you don't trust the packaging parts, why should you trust the 
> claim of unmodified source?

Supposing I don't trust anything.  How am I to examine the source
package ?  For example, I might like to unpack it and do a diff
against a source tree I have checked more thoroughly.

It is unacceptable to create a data format for source packages that
requires the user to trust the creator of the source package with
their account just to see what's inside it.

(Shell archives have this problem, and it has long been bemoaned.)

Putting arbitrary-execution facilities into data formats may seem like
a really neat idea, but look where it got Microsoft Word, for
example.

> Taking the paranoid stance here, leads to nothing IMHO. 
> For me, it would be enough to know that a certain package indeed came
> from  a known maintainer (e.g. the PGP way), and have a known developer
> do an eyeball check of a first time maintainer's code.
> I have more trust in "common sense" than in a complex paranoid
> scheme.

But, don't you see that what you're advocating is precisely the use of
a complex paranoid scheme instead of common sense ?

If I have a packaging format that I can extract using a standard tool
that I know doesn't `execute' the contents of the archive then common
sense says that I'm not putting much more at risk than the target
directory of the unpack.

I shouldn't need to get into verifying the authenticity of packages
and using PGP keys and what not just to *unpack* an archive !
Likewise, I shouldn't need to drag half a dozen people into my trust
envelope just to look at a pile of source code.

I'm therefore very strongly opposed to any scheme that involves
putting shell scripts or other kinds of arbitrary program into package
archives.

Inventing a proprietery language with operations like `untar this' and
`ungzip this' and `apply this patch' would not be a problem, if you
were a little careful when you designed it, but I there seems to be
quite a bit of resistance to a format that requires a special tool to
manipulate it (and I'd be inclined to agree with that).

> Ian, please take a look at Red Hat's packaging scheme.

I have read several pieces of documentation about it, but none of them
were particularly enlightening.  (I even have a paper copy of the Red
Hat manual, though it's a little old now - Red Hat kindly sent me a
free copy because of my work on the Linux FAQ.)

Perhaps I've been reading the wrong bits.  Unfortunately my CD-ROM
drive is broken at the moment so I can't get the Red Hat source
package documentation off the CD-ROM they sent me.

Andrew D. Fernandes writes ("Re: Source packages"):
> [ regarding Bruce's proposal, which includes, amongst other things,
>   a Debianisation patch which he called DELTA. ]
> 
> I like this, but perhaps there should be two DELTA files, or one DELTA
> file with the patch program taking arguments... remember some patches
> will be debian-specific-platform-independent, while other patches
> will be debian-independent-platform-specific. We *do* hope to get
> debian ready for alphas and powerpcs some time in the far
> future... :-)

I don't think this is the job of a special patch in the source
archive.  The same unpacked source tree should build on all
architectures.

If the package needs special actions for some architectures then the
debian.rules should deal with it.

Maintaining several different patches would become quite difficult, I
think: every time you edited the source you'd have to wonder which
patch you wanted your edits to go into.

Bill Mitchell writes ("Re: Debian for Linux/{non-i386} / source packaging"):
> If we concede that the upstream sources might be unpacked and then
> repacked without modification, it's not a big step to say that they're
> not repacked into a vanilla .tar.gz file but instead into some
> other format -- probably a .<whatever> archive which contains the
> upstream sources as a .tar.gz file, debianizing diffs as a .diff.gz
> file, and probably some other items as well.  So, we don't have
> to have an "other" file.

Right.  If we make a single big archive (probably a tar), then we can
provide a tool to unpack it debianised or undebianised and to build
newer versioons, &c, but people without the tool will still be able
to manipulate the file.

Bill Mitchell writes ("Re: Source packages"):
> We operated successfully for some time as a benevelolent dictatorship.
> Ian M. has been dictator, with a rarely-used power to rule by decree.
> On a question like this, there's usually been some period of discussion,
> followed either near-consensus and dissenters throwing it the towel.
> cases where consensus didn't come out of discussion have sometimes
> been decided by decree.
> 
> Lately, we seem to have a troika (Ian M., Bruce P., Ian J.), with
> firm and sometimes conflicting pronouncements by individual troika
> members.

Ian M. is still dictator, as far as I'm concerned.  However, this
power has indeed been rarely used (and it's a good sign for the
Project that this is so), and I find it easier not to qualify every
statement I make along the lines of "dpkg will do this" or "packages
should do that" with a rider saying that Ian M. may disagree.

Ian.