Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4420312

Call makers of dasho: add an option which allows classname specification



    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: unknown
    • Fix Version/s: 1.0.3
    • Component/s: security-libs
    • Labels:
    • Subcomponent:
    • Resolved In Build:
    • CPU:
    • OS:



        jdn would like dasho to add an option to allow a specific classname
        specification prefix. For example, instead of aa.class, it would
        be jsse_aa.class.

        This bug will serve as a reminder.

        bradford.wetmore@eng 2001-02-28

        Hi Paul/Bill. I'm following up on some email that was exchanged
        earlier between Maxine and Paul (Feb/March 2001), and Bill Leach and I
        (April/May 2001). I'm finally up to speed on Dasho 2.2, so I can
        finally write about the experiences we had.

        > Paul Tyma wrote:
        >> Maxine wrote:

        >> 1. We need a way added for us to pass in a class name prefix
        >> for use when obfuscated class names are generated.
        >> We need this because we use Dash-O's option to generate
        >> the name-obfuscated classes in their original package name
        >> spaces but we want to prevent name clashes in the case that
        >> someone else does the same thing with the same 3rd-party
        >> toolkit that we use (in our case, Crypto-J from RSA).
        >> Instead of Dash-O generating names like "a.class" we need
        >> to put a prefix in front like "com_sun_" so the name is
        >> generated like "com_sun_a.class".

        > I think since Dasho 1.0 you could specify "RenamePrefix:" in the .dop file.
        > It will do exactly as you require as in:
        > -RenamePrefix:
        > com_sun_
        > In fact, if you trail your prefix with a slash, DashO will generate
        > a package for it. So:
        > -RenamePrefix:
        > com_sun/

        > will actually put your classes all in that package.

        and then:

        > Bill Leach wrote:
        >> Brad Wetmore wrote:
        >> You apparently cannot specify both "Maintain Package Hierarchy" and
        >> "Rename Classes-Prefix". What happens is that all the classes get
        >> placed into the default package, or package specified by the prefix
        >> field:
        >> prefix/*

        > You are correct about renaming. The current version of Dasho won't let
        > you specify "Maintain Package Hierarchy" along with a renaming prefix.
        > You can only induce package membership with the renaming prefix on a
        > global basis. If you tell me why you need to do this I may be able to
        > suggest an alternative.

        Here's our situation. We have contracted with a vendor, and are
        modifying their library, and shipping that modified code in our jar
        file. However, an end user may have already installed the original jar
        into the JRE. If such a scenario were to occur, both jars would
        contain the com.foo.bar.fubar.class. If that's the case, depending on
        load ordering, either our modified code or theirs will get loaded.
        We want to make sure the modified code loads with our jar,
        and their original code when called from the original jar.

        If we use the prefix as suggested above, then it lumps all renamed
        classes from multiple original packages into that one package with the
        given prefix name. For many classes, including ours, this breaks
        things that depend on package private access. All these classes are
        now lumped into one package which gives inappropriate package access
        between the classes lumped into that package and also changes package
        accesses between the renamed classes and any non-renamed classes from
        their original packages. In order to "fix" this, Dash-O changes all the
        access modifiers in the classes to be public by default. This is
        obviously not good for our security sensitive code. If we prevent this
        by using the (previously) undocumented NOMAKEPUBLIC option then it
        leaves the original access modifiers in place but things don't work
        because of illegal access exceptions on package-level access since the
        classes got moved to different packages.

        So, what we really need is a way have maintain package hierarchy
        together with a named prefix so that renamed classes are generated into
        the original package but with a prefix on the renamed class like
        "com.foo.bar.SUNWJSSE_a.class" and "com.foo.bar.SUNWJSSE_b.class"
        instead of just "com.foo.bar.a.class and "com.foo.bar.b.class" which it
        otherwise wants to do. That way we can leave the original access
        modifiers alone since we aren't changing packages, we get to use
        package private access modes, files get renamed and obscured, and
        renamed classes resulting from multiple users obscuring common bundled
        class libraries in one application will not conflict.

        Since we do have source to the vendor's library, we could
        go through and change it by hand, but each update we get would
        have to be similarly updated. Ugh...


        bradford.wetmore@eng 2001-05-21


            Issue Links



                wetmore Bradford Wetmore
                wetmore Bradford Wetmore
                0 Vote for this issue
                0 Start watching this issue