Bug 576842 – app-arch/rpm2targz: rpmoffset fails in some cases

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description Vanni Della Ricca 2016-03-09 11:48:38 UTC]

Hi,

I have some bugs with rpm2tar, used on ebuild process, in particular whit rpmoffset command.

1) the heuristic detection fail if RPM binary contains strings there are equal at the magic string for gzip, bzip2 or xz.
For example in this rpm http://download.opensuse.org/distribution/leap/42.1/repo/oss/suse/x86_64/389-ds-1.3.4.4-1.6.x86_64.rpm rpmoffest match an arbitrary "BZh" string  inside file and return an incorrect offset.

2) in one other case, for example in this RPM http://rpm.avast.com/lin/repo/dists/suse/release/x86_64/avast-suse-2.1.1-1.x86_64.rpm , rpmoffset match an incorrect sequence. In this case i tired to change rpmoffset source changing function "is_magic_lzma" (on line 52) in this way

return (ubuf[0] == 0x5d && ubuf[4] < 0x20) &&

with

return (ubuf[0] == 0x5d && ubuf[1] == 0x00 && ubuf[4] < 0x20) &&

and it seem to work correctly. This don't fix bug at the first point.
I'did some test re-enabling rpm2cpio on rpm2tar command, it was disabled for fix bugs #249769 and #292057, and it seems to work whit new RPM, in my system i have app-arch/rpm-4.11.0.1 package 

Many Tanks
Vanni

[Comment 1 SpanKY 2016-04-03 01:52:40 UTC]

the lzma magic is inherently buggy because the format doesn't have a dedicated magic string.  it's one of the reasons xz was created.

doing a scan of arbitrary data for arbitrary magic strings is also inherently buggy.  i don't think tweaking the scan logic will really fix this.  the only choice is to actually parse & understand the RPM file format.  that way we'd know for sure where the datafile lives and wouldn't need any magic string logic.

[Comment 2 SpanKY 2021-03-16 23:23:30 UTC]

*** Bug 682798 has been marked as a duplicate of this bug. ***