Latest version JRE 1.7 requirement about java-html-sanitizer HOT 15 CLOSED

Which version is compatible with jre1.6? without the java.lang.autoclosable impl.

from java-html-sanitizer.

Autocloseable has been added in commit 42e7d5f which is weird since commit comment is "IDE warning cleanup".

from java-html-sanitizer.

We were using 20150501.1 and since the issue we have changed the pom to force that version an it is working fine with JRE 1.6

from java-html-sanitizer.

I think this is now resolved. I am going to close this but if I closed it improperly please say something and I'll fix. Thanks folks.

from java-html-sanitizer.

@jmanico I'm sorry to say I've encountered this problem again in version 20160614.1. The AutoCloseableHtmlStreamRenderer is present again, but oddly enough, it only makes the code fail at run-time. Also I'm surprised how the owasp-java-html-sanitizer dependency made it through our project's Maven bytecode enforcer rule, which explicitly forbids any dependencies that were compiled to a bytecode higher than version 50 (Java 6). I guess it's a source-only dependency? It apparently compiles fine with a Java 6 compiler, and generates proper Java 6 bytecode, even though it has a source code dependency on AutoCloseable??? What kind of voodoo is this? :-O I saw something about a "horrible hack" in your project's POM. Are you actually compiling the entire java.lang library from Java 7 to a 1.6 target bytecode? Is that how it works?

Anyway, I'm going to try an older version to see if the problem persists, or if it's even the same problem. I'll let you know if I find out anything more. Thanks in advance for looking into this.

P.S.: I know it sucks how Java 6 doesn't yet support AutoCloseable, but would it be an idea to use something like IOUtils.closeQuietly() from Apache Commons IO instead?

Alternatively, might it be an idea to restructure the POM so that it can generate a separate Java-6-specific artifact and a Java7+ artifact and then offer both artifacts separately in the Maven Central Repository?

from java-html-sanitizer.

@volkertb, do you have a stack trace handy?

from java-html-sanitizer.

@mikesamuel @jmanico I get the stacktrace below in a unit test at the point when it invokes the sanitize method on a PolicyFactory instance. I've tested this with the following versions, starting with the version mentioned by @dgonsan:

• 20150501.1 -> Tests pass fine on JDK 6.
• 20151202.2 -> Tests fail on JDK 6 with the stacktrace below.
• 20160203.1 -> Tests fail on JDK 6 with the stacktrace below.
• 20160614.1 -> Tests fail on JDK 6 with the stacktrace below.

The stacktrace in question (leaving out our application-specific parts at the bottom):

java.lang.NoClassDefFoundError: java/lang/AutoCloseable
        at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClassCond(ClassLoader.java:637)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:281)
        at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
        at org.owasp.html.PolicyFactory.sanitize(PolicyFactory.java:123)
        at org.owasp.html.PolicyFactory.sanitize(PolicyFactory.java:101)

from java-html-sanitizer.

Thanks. Will look into it tomorrow AM (US EST).

from java-html-sanitizer.

@mikesamuel I suspect that the reason why this issue was missed both by you and by my colleague is because the problem only manifests itself when the code is run (not just compiled) on an actual Java 6 JVM. As it is, the code builds fine on JDK 6, and it also runs fine on JDK 7, even when compiled to a 1.6 (bytecode version 50) target. A proper way to test this theory and to create an automated regression test for this issue going forward may be the following:

1. Introduce the use of Maven Toolchains in the POM of java-html-sanitizer. The Toolchains feature allows you to make a distinction between the JDK version on which you are running Maven itself and the JDK version that you actually compile and test the code with. This will also allow you to build the code and run the unit tests on an older JDK version, while ensuring compatibility with newer Maven versions that require at least a Java 7 JVM to run on. For details on this feature, see https://maven.apache.org/guides/mini/guide-using-toolchains.html
2. Add a Maven profile that demands a JDK 6 (1.6) toolchain (which will then automatically be used by both the Maven Compiler Plugin and the Maven Surefire and Failsafe Plugins when that profile is enabled) and add a separate job on your CI server that both builds the project and, very crucially, also runs the unit tests using this profile. Label this CI job something like "java-html-sanitizer with Java 6".
3. If you want to be even more future-proof, do the same for JDK 7 and JDK 8, so you have separate Maven profiles for each major Java version. That way, the CI server will always actually both compile the code and run the unit tests using all three separate major JDK versions.

Please note that introducing the use of Maven Toolchains in the java-html-sanitizer project will also require the existence of a well-defined toolchains.xml file in the ~/.m2 or %USERPROFILE%.m2 folder (depending on OS) in any environment on which the code is to be built and unit-tested. This goes for both the CI server and for everyone working on this project. For more info, see the link to the official Maven Toolchains documentation that I mentioned further above.

This way, you should be able to catch compatibility errors (both compile-time and run-time) early from now on.

Please let me know if you need any help in setting this up. I happen to have some experience with this and I would be glad to help out. :-)

from java-html-sanitizer.

Please let me know if you need any help in setting this up. I happen
to have some experience with this and I would be glad to help out. :-)

Bring It On! :) Thanks for this excellent advice.

Aloha, Jim

On 6/26/16 10:32 PM, Volkert de Buisonjé wrote:

@mikesamuel https://github.com/mikesamuel I suspect that the reason
why this issue was missed both by you and by my colleague is because
the problem only manifests itself when the code is run (not just
compiled) on an actual Java 6 JVM. As it is, the code builds fine on
JDK 6, and it also runs fine on JDK 7. A proper way to test this
theory and to create an automated regression test for this issue going
forward may be the following:

Introduce the use of Maven Toolchains in the POM of
java-html-sanitizer. The Toolchains feature allows you to make a
distinction between the JDK version on which you are running Maven
itself and the JDK version that you actually compile the code with.
This will also allow you to build the code and run the unit tests on
an older JDK version even with newer Maven versions that do no longer
work on JDK 6. For details on this feature, see
https://maven.apache.org/guides/mini/guide-using-toolchains.html
Add a Maven profile that demands a JDK 6 (1.6) toolchain (which will
then automatically be used byboth the Maven Compiler Plugin and the
Maven Surefire and Failsafe Plugins) and add a separate job on your CI
server that both builds the project and, very crucially, also runs the
unit tests using this profile. Label this CI job something like
"java-html-sanitizer with Java 6".
If you want to be even more future proof, do the same for JDK 7 and
JDK 8, so you have separate Maven profiles for each major Java
version. That way, you actually both compile the code and run the unit
tests using all three JDK versions.

Note that introducing the use of Maven Toolchains will also require
the existence of a well-defined toolchains.xml file in the ~/.m2 or
%USERPROFILE%.m2 folder (depending on OS) in any environment on which
the code is to be built and unit-tested. This goes for both the CI
server and for everyone working on this project. For more info, see
the link to the official Maven Toolchains documentation that I
mentioned further above.

This way, you should be able to catch compatibility errors (both
compile-time and run-time) early from now on.

Please let me know if you need any help in setting this up. I happen
to have some experience with this and I would be glad to help out. :-)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#50 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAgcCRdTnT7-pz1oV99iGjJfKyGTm-QRks5qP4qUgaJpZM4Gt-I1.

Jim Manico
Manicode Security
https://www.manicode.com

from java-html-sanitizer.

@jmanico And thank you all for this very useful and important library! 👍 :-) If you'd like, I could try to have a go at it and offer you a pull request, but to be honest, it will be at least a month before I can get around to it (if that). I'm swamped in work right now... No promises on how long it will take, but I'll see what I can do. It would be great if I could contribute something to this project.

from java-html-sanitizer.

74c6dd0 should address this.

I'm used to environments where one builds all ones dependencies for the local architecture, so my first attempt forked architectures made sure that building on Java1.8 would produce classes that ran well on Java1.8 and building on Java1.6 would similarly work.
I build on Java1.8 for maven central pushes, so forking on architecture didn't helped.

I got over my reluctance to resort to reflection, so on JVMs where java.io.Closeable has java.lang.AutoCloseable as a super-interface, then certain wrapper classes will use reflection to close AutoCloseables that are not Closeables, and when that is not the case, only Closeable chaining will work.

from java-html-sanitizer.

I committed changes which I think fix this issue. If you're in a position
to test snapshot builds, go ahead and do that. If not, I'll push to
central since I'm reasonably confident the issue is finally laid to rest.

On Mon, Jun 27, 2016 at 8:14 AM, Volkert de Buisonjé <
[email protected]> wrote:

@jmanico https://github.com/jmanico And thank you all for this very
useful and important library! 👍 :-) If you'd like, I could try to have a
go at it and offer you a pull request, but to be honest, it will be at
least a month before I can get around to it (if that). I'm swamped in work
right now... No promises, but I'll see what I can do. It would be great if
I could contribute something to this project.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#50 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAWg9mmIal12CfwRqyYjeOjgx7ePG59Lks5qP76LgaJpZM4Gt-I1
.

from java-html-sanitizer.

No problem at all, thanks for giving us good input. That alone is good
contribution. :)

Aloha, Jim

On 6/27/16 2:14 PM, Volkert de Buisonjé wrote:

@jmanico https://github.com/jmanico And thank you all for this very
useful and important library! 👍 :-) If you'd like, I could try to
have a go at it and offer you a pull request, but to be honest, it
will be at least a month before I can get around to it (if that). I'm
swamped in work right now... No promises, but I'll see what I can do.
It would be great if I could contribute something to this project.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#50 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAgcCczphc4-4xi_oCZsb6AXqXkEm0-Jks5qP76LgaJpZM4Gt-I1.

from java-html-sanitizer.

This seems like a fully resolved issue with fixes committed to master. Nice work Mike! If this is still a problem please re-open. Thank you!

from java-html-sanitizer.