How SHA1 in signature header is calculated?

[Max Lapshin]

On Thu, Jan 9, 2014 at 6:38 PM, Panu Matilainen <pmatilai at laiskiainen.org>wrote:

>
>> There are problems building rpm4 on mac os x and rpm5 is not compatible
>> with rpm4 specs, so I'm writing right now implementation of simple rpm
>> packer:  directory -> rpm.
>>
>
> I suspect getting rpm 4.x to build on OS X would be far less of a trouble
> than rolling your own, but...



Well, I've spent equal time on trying to build nspr+nss+all other
requisites  and on trying to rewrite rpm packing format =)

Right now I think that I'm _almost_ finished rewriting own =)



> The header SHA1 digest (aka "signature" in rpm jargon) is calculated from
> the header only, but the header needs to be in on-disk format for that.
> Here are a couple of examples of that with librpm, but reimplementing all
> the immutable region fun might be ... fun:
>
> http://rpm.org/gitweb?p=rpm.git;a=blob;f=lib/signature.c;h=
> f17e47fcefb19762c4754e66addc2d4d4a8638c7;hb=HEAD#l287
> http://rpm.org/gitweb?p=rpm.git;a=blob;f=lib/rpmts.c;h=
> a3b4ed26cf8097fa8c901b278a3a4eda44172fa1;hb=HEAD#l415
>
>
I've already got this fun with negative offsets, etc =)   Thanks, will try
it again.



>
>
>> If I don't put sha1 then vanilla rpm on Centos6 says that:
>>
>> headerRead failed: Header sanity check: OK
>>
>> When I compile rpm from source it can install package without sha1 header.
>>
>
> Yup, SHA1 "signature" should not be required by rpm.
>
> Could be a bug in rpm 4.8.x or something else subtly wrong with your
> package. If its rpm 4.8.x you're compiling from source, the Centos version
> will have various security fixes related to header handling that are not
> present in the no longer maintained upstream 4.8.x version.


Maybe it is really about Centos fixes. Vanilla rpm doesn't require anything
except md5, it is clear from sources.



> it happens in fsmSetup function. This cpio.xz file is starting from
>> bytes: 253,55,122,88,90,0,0,10,225
>>
>> Why can it be bad magic?
>>
>
> Are you adding RPMTAG_PAYLOADCOMPRESSOR to the header you create? Rpm
> doesn't try to detect the compression from the file itself, it relies on
> the header telling what kind of compression is being used and IIRC defaults
> to gzip if not specified. Trying to decompress xz-compressed payload with
> gzip is unlikely to work :)
>


It happened to be my fault.
1) I've added compressor flag xz, but haven't compressed it
2) I've used MacosX cpio that generates 070707 header, but rpm requires
070701 format.


I've moved forward and now I have next problem:

# ./rpm -i /vagrant/flussonic-4.1.11.x86_64.rpm
error: unpacking of archive failed on file ./deploy/stock_files.txt: cpio:
Archive file not in header

cpio file has files that look like ./deploy/stock_files.txt  (with leading
./ )
rpm header has directories /deploy and filenames  stock_files.

There is something about CPIO_MAP_ADDDOT and CPIO_MAP_ABSOLUTE in fsm.c,
but I don't know how should I properly set directory names.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-list/attachments/20140110/7d664250/attachment.html>