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

Re: Bug#132767: debsum support should be mandatory



On Mon, 11 Feb 2002, Manoj Srivastava wrote:

> 	Only if the machine _has_ remained true to a known
>  release. Unfortunately, a large class of machines are selectively
>  upgraded. My contention is that the granularity of a Pavckage is a

There are significant number of security wary people who just run stable
and do not follow unstable. They can derive benifit.

>  filelists, built into the package, offer iwder coverage than the
>  release file mechanism (are daily release files signed yet?)

They are.
 
> 	Look at the granularity of the package. If we have signed
>  filelists for each package, then we can indeed buildup the security
>  picture of the whole machine

How? You don't even know what the version number of a package is by
looking at the filelist. You cannot trust the status file, so you actually
have no idea what version is installed [see below for how to solve that
within the debsigs case].

>  Jason> The file can optionally be re-created and saved by dpkg on
>  Jason> extraction. It does not have to be in the .deb for dpkg to
>  Jason> write it to /var/lib/dpkg/info.
> 
> 	But then it can't be signed, and it can be mandled on the
>  machine, unless we go and store all the packages files and all the
>  corresponding release files.

Of course it can be signed. When using debsigs it will be signed using the
same technique as the global release sigs use. You sign the hash of the
filelist file and store that in the .deb. Anyone can compute the filelist
file from a .deb - so anyone can compute its SHA-1. 

When using debsigs what you need to sign for maximum benfit is a single
file that contains the entire contents of 'control' (most critically the
package name and verision number), the SHA-1 of the control/data.tar.gz
and the SHA-1 of the file list. You store this w/ all sigs on extraction.

When using signed releases you sign the Release file which hashes the
Package file which hashes .deb and the filelist.

Recovery would involve ensuring that the status file and the signed
'control' data match, that the filelist on disk matches and that the
contents of the file list matches the disk. 

Jason



Reply to: