Re: Bug#540215: Introduce dh_checksums

[Goswin von Brederlow <goswin-v-b@web.de>]

Raphael Hertzog <hertzog@debian.org> writes:

> Hi Wouter,
>
> I followed somewhat the discussion and I'm sorry for the delay
> answering but package signatures are quite low in priority
> in our roadmap currently:
> http://wiki.debian.org/Teams/Dpkg/RoadMap
>
> We would be glad however if someone would lead this project. I think this
> project would benefit from a DEP so that we have a spec to refer to and so
> that we can get buy-in from all other involved parties before going too far
> in the implementation.
>
> Otherwise it will be one more thread without clear outcome...
>
> On Tue, 23 Mar 2010, Wouter Verhelst wrote:
>> The idea would be to provide a path from a binary on disk to a GPG
>> signature for installed packages of which the user no longer has the
>> .deb file from which it was originally installed, nor the Packages
>> and/or Release.gpg file that was used to download it.
>
> Ok, it looks like a good goal.
>
>> The proposal as it currently stands would be that:
>> - md5sums are phased out in favour of a more generic 'checksums' file
>>   that would use a more secure hash algorithm than MD5 (one of the SHA*
>>   family of hashes would probably do at the moment).
>> - When asked to sign a .deb file, dpkg(-deb) would extract the checksums
>>   data member from control.tar.gz, create a detached signature for that
>>   file, and store it as an additional data member in that .deb.
>
> OK, but additional data members in .deb are ignored by dpkg like you
> noted, this also means that it doesn't end up on the disk after unpack.
>
> I assume your proposal is to modify dpkg to extract those and store them
> somewhere. Is that true? In that case, where and under which format?
>
> You have mentioned multiple signatures per package, would they be stored
> in multiple ar member or in a single one?
>
> My only wish at this point is to avoid exploding the number of
> small administrative files in /var/lib/dpkg/info/ due to this new feature.

The introduction of multiarch will need to change the way metadata is
stored there. Since some change is needed anyway it might be a good time
to adapt to the increase in files stored there and use some subdirs.
Maybe even have one dir per package.

> The biggest downside in your approach is that it's somewhat painful to
> ensure that all the content of the package is signed. If the checksums
> files is incomplete, what is supposed to happen? Is that something that
> dpkg should take care of or should that be outside the scope of dpkg?

Yes, dpkg should create the checksum file.

The checksum file could be attached as additional member in the
.deb. And a signature could be a signed file containing the checksum
size and name of all members of a .deb preceeding the signature. That
way the signature can verify the deb itself or individual members, like
the checksum file, in the .deb. Just a thought.

>> The benefits of this method as opposed to storing the signature in the
>> control.tar.gz file would be:
>> - Autobuilders would not need to be modified to support signed packages.
>> - Adding a member to an ar file and removing it again later can be done
>>   in a way which is idempotent; the same is not true for modifying a tar
>>   file. As such, it is trivially possible to remove signatures from a
>>   .deb file to allow its verification against the original .changes file
>>   that was used for its upload, should this at any point be necessary
>> - If adding multiple signatures is possible in a way which does not
>>   modify the contents of the .deb file itself, then the archive-wide key
>>   could in theory be used to sign individual .deb files. While a massive
>>   increase of CPU power on ftp-master.d.o would be needed to support
>>   this, it would allow for easier key management on the end-user end.
>> - It would not break backwards compatibility. I tried this, by manually
>>   adding a file "signature_01.asc" to a .deb file; dpkg was still able
>>   to install this package, it just ignored the unknown file.
>
> The biggest concern I have with modifying the .deb multiple times along
> the path is the fact that we're changing the checksum of the whole file
> and we're not changing its name. Changing this invariant will lead to
> problems. On the other hand, adding a signature should not require
> changing the filename either.
>
> Did ftpmaster (and buildd maintainers) comment on this problem?
>
>> the metadata and maintainer scripts in the control.tar.gz file. Doing
>> this would require some way to clarify the difference between data in
>> control.tar.gz and data in data.tar.gz; current suggestions are to
>> either use a prefix (something like CONTROL:preinst, for instance) or to
>> use the path of the binary-as-installed (wherein the above would become
>> "/var/lib/dpkg/info/<package>.preinst"). There aren't any strong
>> feelings towards one or the other, however.
>
> I prefer the prefix approach because the other one is hardcoding internal
> information that is not guaranteed to be stable between the dpkg that
> generates the .deb and the one that is used to unpack it.
>
> If any tool outside of dpkg needs to map this to a real file, it should
> use the appropriate interface (currently it's "dpkg-query --control-path
> <package> <controlfile>").

Or a checksum_control and checksum_data member in the .deb. Or two
blocks of checksums seperated by an empty line. Or relative paths (just
the filename) for metadata and absolute for normal data. Lots  of
possibilities.

> As you see there are quite some questions that still need to be cleared up
> and again I think the DEP process would allow us to answer them
> progressively and end up with a clear agreed-upon plan.
>
> Cheers,

MfG
        Goswin