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

Re: New Source Formats and Source Package Verification



Excellent write-up, Klee.  Thanks for doing it.

Since I've been attacking this topic lately, I'll try to post some (hopefully)
constructive criticisms.  But, overall, I agree with what you said.

> * [1.1]  It must be possible to reconstruct exactly the construction
>   of a Debian-format source package directly from upstream sources,
>   possibly with the addition of Debian-specific patches or source
>   files.  Where bit-for-bit archive equivalence of upstream sources is
>   not practical (because of troublesome upstream source formats),
>   file-for-file equivalence must be provided.  

What's an example of a situation where bit-for-bit upstream archive 
equivalence cannot be maintained?  I can't think of any situations 
where this might happen.  Are there archive formats that need to be 
used that don't have utilities to unpack them available in Debian? 

> * [1.4]  The end-user of a Debian system must be able to unpack and
>   examine a Debian source package without executing any code other
>   than the Debian source unpacking tool.

Please clarify - unpacking a Debian source package is different
than unpacking an upstream source package (which may require tar,
unzip, zoo, lha, jar, etc.).  Right?

> * [1.5]  Users of arbitrary UNIX distributions should be able to 
>   unpack and examine a Debian source package with a minimum of 
>   complexity, and must be able to unpack it without any non-standard
>   tools, and without executing any arbitrary code.

Same thing as my previous comment.  I just want to make sure that 
you're not suggesting that we impose conditions on the format of the 
packages that come from upstream sources.
 
> * [2.7]  It should be possible to build a Debian-format source package
>   in a controlled build environment, without the need for root privileges.
>   Source packages should provide a mechanism to specify the tools (and
>   versions thereof) necessary to build that package, so that automated
>   building tools can construct a minimal and stable environment for
>   building each package.

In other words: "dependencies on binary packages".
 
> * [3.3]  It should be independent of dpkg and the binary packaging
>   system --- those are complex enough already.

Why?  I think it would be a good idea to re-use the new cryptographically
signed binary format you are going to have to create to also package
the source packages.  Red Hat does this.

It just makes sense.  You will also want to reuse the "dependencies
on binary packages" from out of dpkg.

An easy way to do this would be to modify dpkg to consider source packages
as just a special type of binary package.  Again, Red Hat already
does this.  It would only add another 2-3% more complexity to dpkg,
if done right.  That's a lot less complexity than writing a whole new
source package handling system.
 
> * [3.4]  It should require only moderate changes to dpkg-dev and to
>   the FTP installation tools.  I don't like to make work for myself, 
>   and I especially don't like to make work for Guy Maor.  Any proposed
>   changes should be able to be implemented by a single person by
>   July first.

If source packages were just a specialized format of the binary package
format - they could be handled the same way, and using the same tools.
Ask Guy which part of the tree is more consistant and easier to handle 
- the source code part or the binary packages part?
 
> * [5.1]  Binary package verification (the issues here are substantially
>    similar to those of source package verification).

We should use the same package format for binary and source packages,
so they could both be signed the same way.  Red Hat does.
 
> * [5.3] Issues of developer/distributor liability for bad/malicious
>   packages (This is a giant can of worms, and I'd rather just avoid 
>   it completely for now).

"Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law."

In summary:

I realize that much of what I am advocating creates more work for the 
maintainers and developers of dpkg.  However, I feel that it makes
good sense to have dpkg handle source packages in an almost identical
manner to the way it handles binary packages.  If I'm off-base,
please tell me so.  I would be willing to assist in any changes to
dpkg that are necessary.

Again, thanks for the excellent write-up.  :-)

Cheers,

 - Jim



Attachment: pgpLyTfEZme0K.pgp
Description: PGP signature


Reply to: