Description of problem:
When using podman/buildah on RHEL 7/8 (also CentOS 7/8 and Fedora 29/30), images pushed to the scan registry fail the has_base_rh_image test.

This is believed to be due a difference in the compression step (when pushing the various image layers) between docker v1.13 and podman/buildah 1.3.2+ (the earliest version of either tested).

It is suspected that either a different compression lib/algo is used from docker 1.13, or there is something that's causing a hash instability in the existing compression libs used in podman/buildah.

Version-Release number of selected component (if applicable):

Confirmed in podman v1.3.2 (RHEL/CentOS 7) and all later versions.

How reproducible:

This is reproducible every time.

Steps to Reproduce:
1. Using podman, build any image from a Dockerfile using RHEL or UBI as the base image
2. Tag/push the resulting image to scan.connect.redhat.com (using podman)
3. Wait for the has_base_rh_image check to fail

Actual results:
The has_base_rh_image test fails

Expected results:
The has_base_rh_image should pass

Additional info:
If you do the exact same steps using docker v1.13 (from RHEL/CentOS 7 or Fedora), then the has_base_rh_image test passes as expected.

I've compared the base layers (docker inspect versus podman inspect) of the image, and the sha256 hashes are identical as they should be when uncompressed.

After pushing an image using podman/buildah to scan.connect.redhat.com, inspecting the image layers using API v2 request (using skopeo) yields vastly different sha256 hashes for each layer.