really odd problem with jar signing

Discussion in 'Java' started by Andreas Leitgeb, Jan 11, 2013.

  1. 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.
    Andreas Leitgeb, Jan 11, 2013
    #1
    1. Advertising

  2. Andreas Leitgeb

    Roedy Green Guest

    On Fri, 11 Jan 2013 13:38:11 +0000 (UTC), Andreas Leitgeb
    <> 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.
    Roedy Green, Jan 11, 2013
    #2
    1. Advertising

  3. Roedy Green <> wrote:
    > On Fri, 11 Jan 2013 13:38:11 +0000 (UTC), Andreas Leitgeb
    > <> 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!
    Andreas Leitgeb, Jan 11, 2013
    #3
  4. Andreas Leitgeb

    Roedy Green Guest

    On Fri, 11 Jan 2013 13:38:11 +0000 (UTC), Andreas Leitgeb
    <> 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.
    Roedy Green, Jan 11, 2013
    #4
  5. Roedy Green <> wrote:
    > On Fri, 11 Jan 2013 13:38:11 +0000 (UTC), Andreas Leitgeb
    ><> 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".
    Andreas Leitgeb, Jan 11, 2013
    #5
  6. Andreas Leitgeb

    Roedy Green Guest

    On Fri, 11 Jan 2013 17:39:50 +0000 (UTC), Andreas Leitgeb
    <> 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.
    Roedy Green, Jan 11, 2013
    #6
  7. Andreas Leitgeb

    Roedy Green Guest

    On Fri, 11 Jan 2013 14:02:47 -0800, Roedy Green
    <> 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.
    Roedy Green, Jan 11, 2013
    #7
  8. Andreas Leitgeb

    Joerg Meier Guest

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

    > Roedy Green <> wrote:
    >> On Fri, 11 Jan 2013 13:38:11 +0000 (UTC), Andreas Leitgeb
    >><> 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.
    Joerg Meier, Jan 13, 2013
    #8
  9. Andreas Leitgeb

    Lars Enderin Guest

    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
    Lars Enderin, Jan 13, 2013
    #9
  10. Roedy Green <> 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!
    Andreas Leitgeb, Jan 13, 2013
    #10
  11. Andreas Leitgeb

    Arne Vajhøj Guest

    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
    Arne Vajhøj, Jan 14, 2013
    #11
  12. Andreas Leitgeb

    Roedy Green Guest

    On Sun, 13 Jan 2013 16:44:55 +0000 (UTC), Andreas Leitgeb
    <> 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
    Roedy Green, Jan 14, 2013
    #12
  13. Roedy Green <> 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!
    Andreas Leitgeb, Jan 14, 2013
    #13
  14. Roedy Green <> 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.
    Andreas Leitgeb, Jan 14, 2013
    #14
  15. Andreas Leitgeb

    Roedy Green Guest

    On Mon, 14 Jan 2013 12:30:20 +0000 (UTC), Andreas Leitgeb
    <> 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
    Roedy Green, Jan 14, 2013
    #15
  16. On Mon, 14 Jan 2013 15:10:00 -0800, Roedy Green
    <> wrote:

    >On Mon, 14 Jan 2013 12:30:20 +0000 (UTC), Andreas Leitgeb
    ><> 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
    Gene Wirchenko, Jan 15, 2013
    #16
  17. Roedy Green <> 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.)
    Andreas Leitgeb, Jan 15, 2013
    #17
  18. Joerg Meier <> 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!
    Andreas Leitgeb, Jan 16, 2013
    #18
  19. Andreas Leitgeb

    Roedy Green Guest

    On Wed, 16 Jan 2013 09:12:37 +0000 (UTC), Andreas Leitgeb
    <> 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
    Roedy Green, Jan 17, 2013
    #19
  20. Roedy Green <> 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.
    Andreas Leitgeb, Jan 17, 2013
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Arnold Peters
    Replies:
    0
    Views:
    543
    Arnold Peters
    Jan 5, 2005
  2. muttley
    Replies:
    0
    Views:
    2,677
    muttley
    Oct 20, 2005
  3. cyberco
    Replies:
    4
    Views:
    3,707
    Roedy Green
    Feb 14, 2006
  4. Arnold Peters
    Replies:
    0
    Views:
    631
    Arnold Peters
    Jan 5, 2005
  5. Catherina Svensson
    Replies:
    0
    Views:
    503
    Catherina Svensson
    Apr 28, 2008
Loading...

Share This Page