really odd problem with jar signing

[Andreas Leitgeb]

When signing a particular JAR file with jarsigner *one* of the
enclosed .class files does *not* get signed !

So, when signing, then to the original manifest a list of *almost*
all content-files with each's base64'd SHA1-checksum gets added,
just not for that said .class file. Only that one class's name
*doesn't show up* in the MANIFEST.MF and neither in the *.SF .

Using some other zip-utility, that shows me all kinds of internal
attributes for each zip-content, there was nothing special about
that one file, and it is correctly unpacked with both "unzip"
and "jar xf".
Using a separate utility to obtain the base64'd sha1-sum of the
unpacked .class file didn't show anything obviously special about
that file's sha1-sum. (it's: oh3SlsLIlsoFZbS2QhWyV2JuroA= )

I'm really confused by this observed behaviour of jarsigner
just skipping one of the files in one of about 20 JARs.

Ι'll continue trying further tricks from the "shouldn't matter
but maybe does"-category, but maybe someone recognizes the
symptoms already from the description so far, and is able to
point to jarsigner's "lesser known feature".

PS: The signing is actually done by someone else, but they
assured me, they really just run the jarsigner utility.

 

[Roedy Green]

When signing a particular JAR file with jarsigner *one* of the
enclosed .class files does *not* get signed !

What is the name of the file? / vs \, some odd char in name?
It is the file itself a valid class file. Try JarCheck see
http://mindprod.com/products1.html#JARCHECK

Could you post the unsigned jar for us to experiment with?

One idea is DSA/RSA certs are supported by different levels of Java.
Perhaps the file is marked for an old Java version and Jarsigner
things thinks the cert is not valid for it.

 

[Andreas Leitgeb]

What is the name of the file? / vs \, some odd char in name?

Double checked this again. It has forward slashes, and no bogus
characters in the name. I examined a hexdump of the JAR-file to
verify that.

It is the file itself a valid class file. Try JarCheck see
http://mindprod.com/products1.html#JARCHECK

I verified correctness of the .class file with some tool that
we have here for that task, and the file was ok.

Could you post the unsigned jar for us to experiment with?

Not that one, unfortunately. As I'm analyzing this, I'll see
if I find this symptom also with a publically available jar file.

One idea is DSA/RSA certs are supported by different levels of Java.
Perhaps the file is marked for an old Java version and Jarsigner
thinks the cert is not valid for it.

I'm not sure, I'm following you here, but I do have verified that
all class files in that jar are of same class-file version. They
all start with the same "CA FE BA BE 00 03 00 2D" bytes.

Are there other criteria that could make jarsigner see a particular
class file unfit? I'd have expected, that jarsigner could deal with
any file regardless its contents, anyway. All it is supposed to do
with each content file is obtain the sha1-checksum. The certificate
will then only be used to sign the Name+Checksum-entries of the
MANIFEST.MF, so the actual contents do not even get in touch with
the signing certificate.

PS: I've now binary patched that one class file (changed some
String literal within it), and sent the resulting jar file to
those who sign it (though I don't expect it back before Monday).
I hope I'll know more, then.

Thank you for answering!

 

[Roedy Green]

*one* of the
enclosed .class files does *not* get signed !

does that file have an embedded, lead, trail space in the name?

 

[Andreas Leitgeb]

does that file have an embedded, lead, trail space in the name?

I've checked that, too, both in the unzip -l output and in the hexdump of
the jar: No, it definitely didn't.
Just ascii-letters (that implies: not even umlauts or accented letters),
digits, forward-slashes ('/') and one dot "." between class name and the
filename extension "class".

 

[Roedy Green]

All it is supposed to do
with each content file is obtain the sha1-checksum

It signs resources too so it really has no right to discriminate. This
may be a bug. It is singling out your member improperly. Is it
abnormally huge? Can you rename it. Perhaps you accidentally used
some name it considers reserved? Can you reorder the jar? Are there
"duplicates" in the jar, perhaps differing only in case.

 

[Roedy Green]

It signs resources too so it really has no right to discriminate. This
may be a bug. It is singling out your member improperly. Is it
abnormally huge? Can you rename it. Perhaps you accidentally used
some name it considers reserved? Can you reorder the jar? Are there
"duplicates" in the jar, perhaps differing only in case.

The contents of the class may be proprietary, but is the list of jar
members secret? a hex dump of the start of the member?

 

[Joerg Meier]

I've checked that, too, both in the unzip -l output and in the hexdump of
the jar: No, it definitely didn't.
Just ascii-letters (that implies: not even umlauts or accented letters),

I think you mean ASCII-7.

digits, forward-slashes ('/') and one dot "." between class name and the
filename extension "class".

It would be helpful if you could just tell us the actual name. You should
also try signing it yourself, to see if you can reproduce the issue, and if
not, to contact the signer and see what he does differently.

Liebe Gruesse,
Joerg

 

[Lars Enderin]

2013-01-13 10:49, Joerg Meier skrev:

I think you mean ASCII-7.

Unqualified "ascii" is seven-bit.

 

[Andreas Leitgeb]

The ignored class-file is less than 5k in size, and there is no
other file with (up to capitalization) same name in the archive.

I do have a couple of further plans on my list to try next week.
(And I've just added "renaming the class file" to that list, even
if it's only for further narrowing down the problem.)

At this time, my reason for posting was to trigger responses of
people who may have experienced the same problem themselves and
maybe even solved it. Since no one came up with the words "Yes,
I've seen that..." so far, I tend to believe that the problem is
at least not all that common. This will help me focus my further
analysis.

Once I get to reproduce it with a self-signed certificate and
some opensource jar file, I'll be sure to come back here.

Thanks to all participating so far!

 

[Arne Vajhøj]

I think you mean ASCII-7.

There is really only one ASCII.

Defined in ANSI X3.4-yyyy and ISO 646.

And it is pure 7 bit.

Extended ASCII, 8 bit ASCII etc. are "creative terms".

Arne

 

[Roedy Green]

Thanks to all participating so far!

I would certainly help to have a look. I hope my ideas did not
trigger too much of a goose chase.

There is the old reliable technique. What did I change just before it
stopped working?. The chain of causality may be bizarre, but that is
where to look. Try putting it back the way it was until the problem
goes away, then incrementally change and test till you out precisely
what triggers the failure. With that in hand, others may be of more
help.

Murphy could be after you. The digest comes out 0.
--
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time.
~ Tom Cargill Ninety-ninety Law

 

[Andreas Leitgeb]

There is the old reliable technique. What did I change just before it
stopped working?.

It didn't really "stop" working. It worked well(*) unsigned,
and it never really started to work signed, due to said problem.

(*): for some definition of "well", that ceased to apply for
some non-technical reasons.

Murphy could be after you. The digest comes out 0.

He definitely is!

 

[Andreas Leitgeb]

Murphy could be after you. The digest comes out 0.

It took me a second read to grasp what you mean.
Actually, I did calculate the sha-1 sum of that file with
a separate tool, and it didn't appear suspicious. It was
definitely non-zero, altough even if it were 0 then it still
shouldn't have mattered.

Anyway, I've now received the results of my last two
test-cases (just repacking, and repacking with that one
file modified), and both still lack the Manifest entry
for that one file. Thus, it does NOT depend on the exact
digest.

Next test case will be renaming that one file, and copying
some other class file already in the archive onto the "bad"
name. Also I made a copy of that file into a different folder,
to see if the fully qualified name matters, or the bare class
name itself.

 

[Roedy Green]

It took me a second read to grasp what you mean.

That was intended as a joke. The odds of the SHA coming out 0 are
vanishingly small. Add to that the odds of code treating 0 as a
special case... If that were the actual trouble, it would be evidence
for the existence of supernatural maliciousness.
--
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time.
~ Tom Cargill Ninety-ninety Law

 

[Gene Wirchenko]

That was intended as a joke. The odds of the SHA coming out 0 are
vanishingly small. Add to that the odds of code treating 0 as a
special case... If that were the actual trouble, it would be evidence
for the existence of supernatural maliciousness.

Well, that explains C then:

#include <stdio.h>
...
int SpecialCaseWhenZero;
...
SpecialCaseWhenZero=0;
...
if (SpecialCaseWhenZero)
/* does not print so no friend for Roedy */
printf("Hey, Roedy!");

Sincerely,

Gene Wirchenko

 

[Andreas Leitgeb]

That was intended as a joke.

Yeah, but even a joke deserved to be understood

The odds of the SHA coming out 0 are vanishingly small.

That would have been a perfect explanation why no one else
had encountered this, yet, wouldn't it? Unfortunately,
it wasn't really the reason. (Or I'd already know how to
workaround it.)

 

[Andreas Leitgeb]

You should also try signing it yourself, to see if you can reproduce the issue,
and if not, to contact the signer and see what he does differently.

I finally did that, and I could *not* reproduce it with my
self-signed cert.

As it seems, the problem is on signer's side, and I'll
have to resolve it with them, making my environment as
similar as possible to theirs...

Thanks for assistance!

 

[Roedy Green]

I finally did that, and I could *not* reproduce it with my
self-signed cert.

An idea. Look at the expiry/issue date of your cert. Look at the
date of the recalcitrant member.

--
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time.
~ Tom Cargill Ninety-ninety Law

 

[Andreas Leitgeb]

An idea. Look at the expiry/issue date of your cert. Look at the
date of the recalcitrant member.

Finally I got the result for my last experiment (a modified version
of the original jar file where the recalcitrant member was copied
to same basename in another folder and to a different name in same
folder plus a different file copied onto the recalcitrant's name).

Once again, just that same one pathname was ignored. That means,
whatever triggers this specific ignoring, doesn't go for plain
filename attributes, timestamps or contents, but for the complete
path name inside the zip-file.
Perhaps it's internally taking some hash of the full pathname, and
suffers from a collision or in-band special value of that. Murphy...

I also got some extra information this time. The signing happens on
a machine I have (user-)access to (I had always assumed it would be
on signer's personal PC), and so I copied the keystore with my own
self-signed certificate to that machine, and signed that last version
of the jar file with my self-signed certificate, and again that single
file didn't show up in MANIFEST.MF.

So, I guess I cornered it to a problem in the particular version of
jarsigner on that machine (it is part of a jdk1.5.0_17 installation
on Solaris). Ok, I know, that's ages old and no longer supported...

The next step will be suggesting them to do the signing on a different
machine with a newer java installation, and I hope that will solve
the actual problem (namely that we simply need a completely signed
jar file, no matter where it is actually created).

PS:
Just out of curiosity, I'd like to read, if the specified symptom in
connection with java 1.5 now rings bells of recognition for anyone here.