Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #21326 > unrolled thread

really odd problem with jar signing

Back to article view | Back to comp.lang.java.programmer

Contents

  really odd problem with jar signing Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-01-11 13:38 +0000
    Re: really odd problem with jar signing Roedy Green <see_website@mindprod.com.invalid> - 2013-01-11 08:45 -0800
      Re: really odd problem with jar signing Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-01-11 17:39 +0000
        Re: really odd problem with jar signing Roedy Green <see_website@mindprod.com.invalid> - 2013-01-11 14:02 -0800
          Re: really odd problem with jar signing Roedy Green <see_website@mindprod.com.invalid> - 2013-01-11 14:14 -0800
            Re: really odd problem with jar signing Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-01-13 16:44 +0000
              Re: really odd problem with jar signing Roedy Green <see_website@mindprod.com.invalid> - 2013-01-13 20:08 -0800
                Re: really odd problem with jar signing Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-01-14 09:59 +0000
                Re: really odd problem with jar signing Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-01-14 12:30 +0000
                  Re: really odd problem with jar signing Roedy Green <see_website@mindprod.com.invalid> - 2013-01-14 15:10 -0800
                    Re: really odd problem with jar signing Gene Wirchenko <genew@telus.net> - 2013-01-14 16:16 -0800
                    Re: really odd problem with jar signing Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-01-15 09:42 +0000
    Re: really odd problem with jar signing Roedy Green <see_website@mindprod.com.invalid> - 2013-01-11 10:01 -0800
      Re: really odd problem with jar signing Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-01-11 18:41 +0000
        Re: really odd problem with jar signing Joerg Meier <joergmmeier@arcor.de> - 2013-01-13 10:49 +0100
          Re: really odd problem with jar signing Lars Enderin <lars.enderin@telia.com> - 2013-01-13 11:35 +0100
          Re: really odd problem with jar signing Arne Vajhøj <arne@vajhoej.dk> - 2013-01-13 22:56 -0500
          Re: really odd problem with jar signing Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-01-16 09:12 +0000
            Re: really odd problem with jar signing Roedy Green <see_website@mindprod.com.invalid> - 2013-01-16 20:58 -0800
              Re: really odd problem with jar signing Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-01-17 15:16 +0000
                Re: really odd problem with jar signing Roedy Green <see_website@mindprod.com.invalid> - 2013-01-17 14:36 -0800
                  Re: really odd problem with jar signing Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-01-18 15:24 +0000
                    Re: really odd problem with jar signing Roedy Green <see_website@mindprod.com.invalid> - 2013-01-18 23:32 -0800
                      Re: really odd problem with jar signing Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-01-24 12:46 +0000

Page 1 of 2  [1] 2  Next page →

#21326 — really odd problem with jar signing

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.

[toc] | [next] | [standalone]

#21328

On Fri, 11 Jan 2013 13:38:11 +0000 (UTC), Andreas Leitgeb
<avl@gamma.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
someone who said :

>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.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Students who hire or con others to do their homework are as foolish 
as couch potatoes who hire others to go to the gym for them. 

[toc] | [prev] | [next] | [standalone]

#21329

Roedy Green <see_website@mindprod.com.invalid> wrote:
> On Fri, 11 Jan 2013 13:38:11 +0000 (UTC), Andreas Leitgeb
> <avl@gamma.logic.tuwien.ac.at> wrote:
>> 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?

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!

[toc] | [prev] | [next] | [standalone]

#21339

On Fri, 11 Jan 2013 17:39:50 +0000 (UTC), Andreas Leitgeb
<avl@gamma.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
someone who said :

>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 Canadian Mind Products http://mindprod.com
Students who hire or con others to do their homework are as foolish 
as couch potatoes who hire others to go to the gym for them. 

[toc] | [prev] | [next] | [standalone]

#21341

On Fri, 11 Jan 2013 14:02:47 -0800, Roedy Green
<see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :

>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?
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Students who hire or con others to do their homework are as foolish 
as couch potatoes who hire others to go to the gym for them. 

[toc] | [prev] | [next] | [standalone]

#21380

Roedy Green <see_website@mindprod.com.invalid> wrote:
> On Fri, 11 Jan 2013 14:02:47 -0800, 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 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!

[toc] | [prev] | [next] | [standalone]

#21394

On Sun, 13 Jan 2013 16:44:55 +0000 (UTC), Andreas Leitgeb
<avl@gamma.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
someone who said :

>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 

[toc] | [prev] | [next] | [standalone]

#21397

Roedy Green <see_website@mindprod.com.invalid> wrote:
> 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!

[toc] | [prev] | [next] | [standalone]

#21398

Roedy Green <see_website@mindprod.com.invalid> wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#21401

On Mon, 14 Jan 2013 12:30:20 +0000 (UTC), Andreas Leitgeb
<avl@gamma.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
someone who said :

>> Murphy could be after you. The digest comes out 0. :-)
>
>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 

[toc] | [prev] | [next] | [standalone]

#21403

On Mon, 14 Jan 2013 15:10:00 -0800, Roedy Green
<see_website@mindprod.com.invalid> wrote:

>On Mon, 14 Jan 2013 12:30:20 +0000 (UTC), Andreas Leitgeb
><avl@gamma.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
>someone who said :
>
>>> Murphy could be after you. The digest comes out 0. :-)
>>
>>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.

     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

[toc] | [prev] | [next] | [standalone]

#21411

Roedy Green <see_website@mindprod.com.invalid> wrote:
> On Mon, 14 Jan 2013 12:30:20 +0000 (UTC), Andreas Leitgeb wrote:
>>> Murphy could be after you. The digest comes out 0. :-)
>> It took me a second read to grasp what you mean.
> 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.)

[toc] | [prev] | [next] | [standalone]

#21330

On Fri, 11 Jan 2013 13:38:11 +0000 (UTC), Andreas Leitgeb
<avl@gamma.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
someone who said :

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

does that file have an embedded, lead, trail space in the name?
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Students who hire or con others to do their homework are as foolish 
as couch potatoes who hire others to go to the gym for them. 

[toc] | [prev] | [next] | [standalone]

#21331

Roedy Green <see_website@mindprod.com.invalid> wrote:
> On Fri, 11 Jan 2013 13:38:11 +0000 (UTC), Andreas Leitgeb
><avl@gamma.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
> someone who said :
>> *one* of the 
>> enclosed .class files does *not* get signed !
> 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".

[toc] | [prev] | [next] | [standalone]

#21374

On Fri, 11 Jan 2013 18:41:36 +0000 (UTC), Andreas Leitgeb wrote:

> Roedy Green <see_website@mindprod.com.invalid> wrote:
>> On Fri, 11 Jan 2013 13:38:11 +0000 (UTC), Andreas Leitgeb
>><avl@gamma.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
>> someone who said :
>>> *one* of the 
>>> enclosed .class files does *not* get signed !
>> 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),

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

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#21375

2013-01-13 10:49, Joerg Meier skrev:
> On Fri, 11 Jan 2013 18:41:36 +0000 (UTC), Andreas Leitgeb wrote:
> 
>> Just ascii-letters (that implies: not even umlauts or accented letters),
> 
> I think you mean ASCII-7.

Unqualified "ascii" is seven-bit.

-- 
Lars Enderin

[toc] | [prev] | [next] | [standalone]

#21392

On 1/13/2013 4:49 AM, Joerg Meier wrote:
> On Fri, 11 Jan 2013 18:41:36 +0000 (UTC), Andreas Leitgeb wrote:
>> Just ascii-letters (that implies: not even umlauts or accented letters),
>
> 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

[toc] | [prev] | [next] | [standalone]

#21430

Joerg Meier <joergmmeier@arcor.de> wrote:
> 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!

[toc] | [prev] | [next] | [standalone]

#21466

On Wed, 16 Jan 2013 09:12:37 +0000 (UTC), Andreas Leitgeb
<avl@gamma.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
someone who said :

>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 

[toc] | [prev] | [next] | [standalone]

#21477

Roedy Green <see_website@mindprod.com.invalid> wrote:
> On Wed, 16 Jan 2013 09:12:37 +0000 (UTC), Andreas Leitgeb wrote:
>> 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.

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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web