Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RPMs created can't be used on an AIX machine #7

Closed
rohit-lshift opened this issue Nov 17, 2019 · 23 comments
Closed

RPMs created can't be used on an AIX machine #7

rohit-lshift opened this issue Nov 17, 2019 · 23 comments

Comments

@rohit-lshift
Copy link

rohit-lshift commented Nov 17, 2019

Hello,
I am using this library to create RPMs for a Linux machine and an AIX machine. The AIX machine is somewhat old.

I noticed when I generated the RPMS after this commit: 2ae1880, I am unable to use the RPMs produced on the AIX box. I get a really unhelpful error:

root@somemachine:/tmp> rpm -Uvh somerpm.aix7.1.noarch.rpm
error: somerpm.aix7.1.noarch.rpm cannot be installed

Any help debugging this would be really helpful.

RPM version being used:

root@somemachine:/tmp> rpm --version
RPM version 3.0.5

I am using this library through ctron/rpm-builder

@rohit-lshift rohit-lshift changed the title RPMS created can't be used on an AIX machine RPMs created can't be used on an AIX machine Nov 17, 2019
@dwalluck
Copy link
Contributor

You're using a version of RPM over 20 years old, but I guess version 3.0.5 has some compatibility with v4 packages. I am responsible for that commit and I don't think it was supposed to change any headers by default. In other words, it added some options, but the default behavior should have remained the same.

Do you think you can produce the exact same RPM using the previous version so that we can compare the two files and see what as changed?

@rohit-lshift
Copy link
Author

@dwalluck, I know its 20 years old. :(

I can produce RPMs from before and after that commit.

I tried to use pkgdiff to "diff" the two rpms but the tool didn't report any differences.

How else can I check whats different?

Thanks for your help.

@dwalluck
Copy link
Contributor

So it did not show any changes in the Changes In "Requires" Dependencies? That would have been my first guess. I don't have access to the script producing your packages, but I'll try comparing the RPMs produced by the tests. If you have hexdump you could dump both files to compare them byte for byte.

@rohit-lshift
Copy link
Author

It doesn't show any changes in Changes In "Requires" Dependencies.
Screenshot 2019-11-17 at 20 32 39

The files sizes are different. Before: 1516992. After 1488742

@rohit-lshift
Copy link
Author

rohit-lshift commented Nov 17, 2019

Finally found one difference:

Old:

$ rpm -Kv old.rpm
old.rpm:
    Header SHA1 digest: OK
    MD5 digest: OK

New:

$ rpm -Kv new.rpm
new.rpm:
    Header SHA256 digest: OK
    Header SHA1 digest: OK
    MD5 digest: OK

So looks like Header SHA256 digest is added by that commit.

Edit: I commented out that line which adds the new header but the rpm still doesn't work. So its not that.

Edit2: The outputs where produced on a "modern" machine. If I run rpm -Kv new.rpm on the AIX box, I get the error: rpmReadSignature failed.

@dwalluck
Copy link
Contributor

Great, so if you use the current master and remove the line at

addSignatureProcessor ( SignatureProcessors.sha256Header () );
it should hopefully work for you again. Can you try?

I can make a pull request to make this optional, but I am not sure yet how we should decide to handle it. The API only currently seems to allow you to remove all signature processors, not remove just a single (existing) one. However, you can currently add one if it doesn't already exist. Maybe we should wait for @ctron to comment.

I have had this idea that the builder should take an API compatibility level and then it would enable or disable features automatically based on that. Presumably, you are using https://github.com/ctron/rpm-builder so maybe something should be done here instead to allow this feature to be changed on the fly.

@dwalluck
Copy link
Contributor

Oh, I should have read your comment where you said you tried this already.

@rohit-lshift
Copy link
Author

rohit-lshift commented Nov 17, 2019

What surprises me is the file size difference between the two. The new rpm is 28250 bytes less than the old one - roughly 1.86%.

@dwalluck
Copy link
Contributor

I think that the gzip compression may be responsible for (most) of the size reduction in the new file payload. Before the RPM header indicated 9 = BEST_COMPRESSION, but it was actually set to DEFAULT_COMPRESSION which is somewhat lower.

@dwalluck
Copy link
Contributor

The tests use this Dumper.dumpAll ( in ) to dump the RPM in some readable format.

@rohit-lshift
Copy link
Author

Thanks. I'll give it a shot. btw, its not the compression. On your suggestion, I changed compression level to DEFAULT_COMPRESSION with no effect.

@rohit-lshift
Copy link
Author

I ran Dumper.dumpAll on the two RPMs. The old PAYLOAD has PAYLOAD_FLAGS whereas the new one doesn't.

@rohit-lshift
Copy link
Author

No luck. I added the PAYLOAD_FLAGS and still no effect.

So with all my changes - old file size: 1516992. New file size: 1516972. Getting close.

@rohit-lshift
Copy link
Author

I've figured it out. addSignatureProcessor ( SignatureProcessors.md5 () ); needs to be before addSignatureProcessor ( SignatureProcessors.sha1Header () );.

🙀

rohit-lshift pushed a commit to rohit-lshift/packager that referenced this issue Nov 17, 2019
@dwalluck
Copy link
Contributor

dwalluck commented Nov 17, 2019

Unless I am reading the code wrong, I thought the official RPM puts the headers in the order that is it there: SHA256, SHA1, MD5:

https://github.com/rpm-software-management/rpm/blob/d320a1c67ca53496bd190ed6d5586e796c2b19af/lib/signature.c#L112

In any case, I would think we should try to match the exact order in the official RPM if we can.

Of course, it may be the case that RPM itself is no longer backwards compatible with the SHA256 header added and would suffer the same issue.

I don't suppose you're willing to check the order of the headers and whether or not it installs under v3 if built with official RPM?

@rohit-lshift
Copy link
Author

rohit-lshift commented Nov 17, 2019

I created the same rpm for linux and inspected it.

$ rpm --version
RPM version 4.15.0

When I ran rpmkeys -Kv name.rpm, I got:

    Header SHA256 digest: OK
    Header SHA1 digest: OK
    MD5 digest: OK

I don't think I can update the rpm binary on the AIX box as that would be require quite a lot of change in our prod servers as well. 😢

@dwalluck
Copy link
Contributor

Does RPM 4.15.0 create RPMs that you can install with RPM 3.0.5?

@rohit-lshift
Copy link
Author

@dwalluck: What I did was create the RPM for Linux and not AIX. Then I installed it on a Linux box. The underlying packager library was the same.

Hope I am clearer this time around.

@dwalluck
Copy link
Contributor

I have not tested it, but I think that upstream RPM has broken backwards compatibility with this change. That is why I asked if someone wanted to build on official RPM 4.x and see if it installs with 3.0.5.

They seem to provide no way to disable SHA256 signatures via macros the way you may be able to disable some other newer features to keep backwards compatibility.

ctron added a commit to ctron/rpm-builder that referenced this issue Nov 22, 2019
This change allows specifying a custom provider for signature
configurations. By default it will support "default" and "md5-only".
@ctron
Copy link
Contributor

ctron commented Nov 22, 2019

@rohit-lshift I created a PR in the Maven Plugin repository, see: ctron/rpm-builder@cb5def3

I would kindly ask you to test, if that works for you, then I would merge the PR and do a new release in a few days.

@rohit-lshift
Copy link
Author

@ctron: that does indeed work. Thanks!

ctron added a commit to ctron/rpm-builder that referenced this issue Nov 25, 2019
This change allows specifying a custom provider for signature
configurations. By default it will support "default" and "md5-only".
@ctron
Copy link
Contributor

ctron commented Nov 27, 2019

Is it ok to close this issue?

@rohit-lshift
Copy link
Author

Thanks a lot @ctron!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants