Re: How SHA1 in signature header is calculated?

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

 



On 01/09/2014 01:28 PM, Max Lapshin wrote:
I want to pack linux 64bit rpm on macos x.  To do this I make tmproot
folder with all binaries in it and need to pack contents of this folder to
package.

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...


I can pack lead, signature (with 4 bytes padding), header, but I have
several problems later:

1) how do I need to calculate sha1 header in signature?  md5 is calculated
from header+cpio_payload, but sha1 is more complex.

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


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.


2) I'm packing files with cpio and then call xz on this cpio file, but
still rpm claims that:

unpacking of archive failed: cpio: Bad magic

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 :)

	- Panu -


_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list




[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux