Bug 900453 (JBPAPP6-1014)

Link: Added: This issue is a dependency of JBPAPP-9044

How deeply this issue impacts tps-rpmtest (formally defined Errata Tool's *must pass* test) you can see in the attached log output of its run.

Attachment: Added: tps-rpmtest.log

Every rpm packages both the signed and un-signed version of the jar under /usr/share/java and /usr/share/java-signed
ex: https://brewweb.devel.redhat.com/rpminfo?rpmID=2278950
When we decided to ship an unsigned version, we should have completely removed the signed version of the jars. 
The tps tools also show the same.

If we could do that we'd also unsign the full MEAD repo.  All these things require a full rebuild of 300+ packages (or for the above the 222 we ship).  Just not possible for GA.
So the only solution with the change to unsigned happening so late in the game is to
switch the symlinks to the unsigned JARs.

Note that signed and unsigned JARs have been shipped together (as RHEL's request) since EAP 5 times on RHEL-6, so this is not something new. 

Release Notes Text: Added: We agreed that there was no time for a full rebuild and that we'd have to unsign after the fact.  This is the equivalent for the RPMs of what we do for the ZIPs.

What the reason behind RHEL's request for duplicate jars?

The asked us to keep the unsigned JARs and we need the signed.  SO our packages had both, the unsigned RHEL ones and the signed EAP ones.

When we got this last minute request to unsign everything and we had no time to rebuild the 222 packages (plus probably some dependencies) we just changed the symlinks to point to the unsigned (RHEL) JARs instead.

Removal of the signed JARs (which cause no harm but a few bytes in disk) requires rebuilding the world which is what we will have to do to create an unsigned MEAD maven repo anyway.  But of course this is more to the 6.0.1 or 6.1 timeframe due to the massive number of rebuilds needed.
 

I would like to keep this issue open as this is a no-ship for rpm's from a QE perspective. Though the signed versions of the jars are not (sym)linked we have not planned to test them in any way. 
Hence the only ways to resolve this JIRA is to 1. remove the signed jars 2. declare them as un-supported. 

As we cannot remove them I added the component "Documentation".

I would like to clarify that the TPS results seem to be about RPM signing, and not at all about JAR signing. TPS seems intent on comparing a fictional prior release of EAP6 with what is in the errata. Unfortunately it is doing so with a list of unsigned RPMs vs. a list of the signed copies of the same RPMs.

RPM signing and JAR signing are not related.

The conversation in this thread appears to be confusing the two. It's true that there are both signed and unsigned copies of each JAR in the builds, but this is not related to the TPS output at the beginning of this JIRA.

To collaborate what Chris said, the EAP 5 RPMs also had the signed and unsigned JARs and QE has used TPS with them.  So the TPS issue is totally unrelated to this discussion.

Fernando is right in the statement there were signed/unsigned JAR in EAP5, but only(!) on RHEL6. I think the first a such shipped version of EAP5 was 5.1.2, but maybe I'm wrong now... (as I heart it was a customer driven request) Other RHELs (= 4 and 5) doesn't include both versions. QA was not happy with this situation (based on his test plan and testing effort) and takes it only as a customer driven exception.

Maybe the original complaint about "TPS tests won't work" (especially tps-make-list fails) comes from the fact, that this Errata (2012-12461) is the *first* content of the new created RHN channel. I've heart a note from  Ivo Studensky that with first RPM set (= first Errata) of EAP5 there was at least very similar issue as well - how it was solved I don't know because I've joined with Red Hat later.

I'm sure that a such issue can't come from the fact of existence the new package in RHN system because this situation were around us in the past too - the earliest example in the past is HornetQ RPM package(-s) (separate Errata of it for EAP-5.1.2) and a such problem with tps-make-list didn't exist.

Also RHEL distribution itself creates new channel in every major version, can you say me that this issue is occurred on RHEL QA side in every new major version of RHEL? Come on! Errata tools are used widely in Red Hat for a long time, I can't believe if a such issue persists for a such long time, nobody is aware of it and it wasn't fixed far in the past...

Fernando is right in the next statement as well - in this JIRA are combined two separate problems:
# Errata RHEA-2012:12461 content viewable by Errata Tools stuffs - issue with tps-make-list (-> tps-tpmtest or tps-rhnqa fails as well)
# multiple version of the same JAR (signed and unsigned) -> different content compared to ZIP bundle

I'm not the author of idea that #2 causes #1, but I not sure, maybe it is the root of cause... - is this the question for rel-eng as the best authority?

@Pavel, #1 and #2 are completely unrelated. RPM signing and JAR signing are separate in every conceivable way. The issues from #1 are due to RPM signing and first release confusions for TPS. #2 has absolutely zero to do with this, and vice-verse.

Also to clarify, RHEL initial (major) releases don't go out via the errata tool; they typically only involve the errata tool for updates. Whether using the tool for an initial release is correct is still up in the air, and the consensus in rel-eng is that it is correct in this case. But as you can see much of the behaviour is predicated on an initial non-errata release. This is facilitated with the use of the compose tool, which EAP doesn't utilize.

The description of this issue is completely outdated.

It talks about a TPS issue that is unrrelated.

If that was the reason it was marked as Blocker it should have its priority lowered now.

Please split this into two issues. 
1. Both signed and unsigned JARs are in the RPMs for RHEL 6
2. TPS cannot be used for the initial release for EAP6, since there is nothing previous to compare to (this would be an enhancement request on TPS, I would think).
Thanks

Updated JIRA to just refer to the presence of the signed jars issue. Moved the TPS issue to JBPAPP-9158

This has been documented as a known issue in the EAP 6 GA release notes.

Release Notes Docs Status: Added: Documented as Known Issue

Security: Removed: JBoss Internal Added: Public

After discussions with Fernando, this issue has been resolved in the 6.0.1 ER2 build. All builds were redone and there should not be signed version on any jars.

Verified during 6.0.1-ER2 test cycle, fixed, closing...

Release Notes Text: Removed: We agreed that there was no time for a full rebuild and that we'd have to unsign after the fact.  This is the equivalent for the RPMs of what we do for the ZIPs. Added: Previously, the JBoss Enterprise Application Platform 6 RPM packages included both signed and unsigned JARs although the signed JARs were not supported.  The signed JARs have been removed from the RPM packages in this release.  The RPMs now only include the supported unsigned JARs.

Release Notes Docs Status: Removed: Documented as Known Issue Added: Documented as Resolved Issue

Writer: Added: Darrin
Affects: Added: Release Notes

Release Notes Docs Status: Removed: Documented as Resolved Issue 
Writer: Removed: Darrin 
Release Notes Text: Removed: Previously, the JBoss Enterprise Application Platform 6 RPM packages included both signed and unsigned JARs although the signed JARs were not supported.  The signed JARs have been removed from the RPM packages in this release.  The RPMs now only include the supported unsigned JARs. 
Docs QE Status: Removed: NEW