jaxen-xpath / jaxen Goto Github PK

PatternParser.navigationStep(step) always returns true

line 289: if ( step.getClass().equals( DefaultStep.class ) )

always returns false, because DefaultStep is abstract class.

So navigationStep(...) always returns true

i guess the implementation of navigationStep(...) is wrong. If not, we can simplify code by removing navigationStep(...) method

animal sniffer?

Old releases, and tags to old releases are missing.
It's a good idea to have it, at least the tags. So someone could quickly compare changes between versions.

https://maven.apache.org/guides/mini/guide-reproducible-builds.html

We are using JDOM2/Jaxen combination in our project and it turns out, that //* xpath query returns all XML nodes if called via XPathExpression.evaluate, but zero results are returned if XPathExpression.evaluateFirst is called with the same argument. More details and CI results at: appium/appium-uiautomator2-server#238

Update docs for Jaxen 2.

We're thinking about replacing our current XPath engine with Jaxen. Is this project still actively maintained? The last commit is from 2019.

remove from pom.xml

http://jaxen.codehaus.org/
the link dident open!

Refiling from codehaus/jaxen#3 on behalf of @htgoebel.

jaxen requires dom4j for compiling. and dom4j requires jaxen for compiling.

This inhibits building both packages from source (read: without basing .jars downloaded
elsewhere). Building software from pure source is important to provide a verifiable path from
source code to binary, see reproducible builds.

Please remove this dependency-cycle. Thanks.

I am also running into this https://github.com/Obsidian-StudiosInc/os-xtoo/issues/71

JAXEN latest build dosen't support JDOM2, Need support for JDOM2.

https://github.com/hunterhacker/jdom/wiki/JDOM2-Migration-Issues

That died when codehaus went down.

Hello,

We uncovered a minor bug when evaluating XPath expressions:
While executing the XPath /nonexistent=false() returns true, executing /nonexistent<=false() returns false, which is wrong.

Tested with jaxen 1.2.0.

Best regards,
Mirko

Hi Team,

Jaxen 1.2.0 has below vulnerabilities.
Refer: https://mvnrepository.com/artifact/jaxen/jaxen/1.2.0

Can you please let us know, If there any plan to upgrade the "jaxen" by removing the above vulnerabilities in future.

It should supersede jaxe:jaxen:1.2.0

Include instructions somewhere (well-known location) about reporting security issues along with warnings about spamming because of naive security scanners.

If it's a real issue you've personally discovered and can explain, feel free to drop me an email.

If it's some security tool logging a warning, that is 95% likely not to be a security issue but rather a bug in the tool. You can file that here after you have investigated if you are willing to vouch that it is a true security issue, but be aware that these tools are almost never correct when analyzing Jaxen.

Things that are NOT security bugs in Jaxen:

1. Anything in your dependency tree whose source code is not in this repo. You control your classpath. Jaxen doesn't. If you don't like what's in the classpath, change it.
2. Properly implementing XML 1.0 according to the specification.
3. Properly implementing XPath 1.0 according to the specification.
4. Being able to load a URL from Java code.

Probably not security bugs in Jaxen:

• Problems that only appear when your code (not Jaxen's) accepts untrusted, unvalidated user input

Possible security bugs in Jaxen (if you can find one, none are currently known to exist):

• XPath expressions that cause infinite loops in the parser or exponential performance problems.

This is primarily for JDK 11, although effects JDKs 9 and 10 as well. Although you can work around the problem in 9+10, you cannot in 11.

java.xml is a built in module with the JDK. It exports among other packages this one

    exports org.w3c.dom;

jaxen, includes the class org.w3c.dom.UserDataHandler, and with Automatic modules this is exported as org.w3c.dom and then clashes with the explicit package declared in java.xml

This results in the errors similar the to following during compilation

Error:java: module java.xml.soap reads package org.w3c.dom from both java.xml and jaxen
Error:java: module java.xml.bind reads package org.w3c.dom from both jaxen and java.xml
Error:java: module java.xml.ws reads package org.w3c.dom from both java.xml and jaxen

I see 2 potential solutions

1. Add a module-info.class that explicitly defines the exported packages.
2. Remove org.w3c.dom.UserDataHandler from the jaxen source and add java.xml as a dependancy.

Specifically, what, if anything, needs to change in the public API.

This is for Jaxen 3 or later.

Pull jaxen off of https://sourceforge.net/projects/jaxen/

It's obsolete and confusing search results.

https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/master/library-best-practices/JLBP-20.md

Figure out how to release a new multimodule site and update RELEASING.md accordingly. See

https://maven.apache.org/plugins/maven-site-plugin/examples/multimodule.html

Hello,

Jaxen 1.1.6 was the 1st release that included a fix for JIRA issue JAXEN-227 (commit 4b67bba).
Unfortunately, I cannot give any more details about this issue since the JIRA instance is not available any more.

Anyway, the commit mentioned above changed several classes dealing with numerical comparison but I guess that one has been missed: org.jaxen.expr.DefaultGreaterThanEqualExpr. It is still using Double#compareTo(Double) for comparison.

Shouldn't it use Java comparison for double primitive values as org.jaxen.expr.DefaultLessThanEqualExpr does?

Thanks,
H

Why does Jaxen set packaging to bundle? Does this still make sense?

E.g. releases only appear on branches and head is always a snapshot of the next planned version.

https://maven.apache.org/plugins-archives/maven-assembly-plugin-2.6/assembly-mojo.html#tarLongFileMode

It's minimal weight with no extra dependencies

Since the codehaus procedures no longer work.

See https://central.sonatype.org/pages/apache-maven.html

At a minimum this requires changes to pom.xml and xdocs/building.xml

Next release should probably jump to 1.2.0. API hasn't changed but it requires a new minimum Java version.

or Optional? or both?

The goal would be to maintain near full API compatibility in the 2.0 release aside from linkage errors.

Hi all,

we have prepared the Initial Integration of jaxen into Google OSS-Fuzz which will provide more security for your project.

Why do you need Fuzzing?
The Code Intelligence JVM fuzzer Jazzer has already found hundreds of bugs in open source projects including for example OpenJDK, Protobuf or jsoup. Fuzzing proved to be very effective having no false positives. It provides a crashing input which helps you to reproduce and debug any finding easily. The integration of your project into the OSS-Fuzz platform will enable continuous fuzzing of your project by Jazzer.

What do you need to do?
The integration requires the maintainer or one established project commiter to deal with the bug reports.

You need to create or provide one email address that is associated with a google account as per here. When a bug is found, you will receive an email that will provide you with access to ClusterFuzz, crash reports, code coverage reports and fuzzer statistics. More than 1 person can be included.

How Code Intelligence can support?
We will continue to add more fuzz targets to improve code coverage over time. Furthermore, we are permanently enhancing fuzzing technologies by developing new fuzzers and more bug detectors.

Please let me know if you have any questions regarding fuzzing or the OSS-Fuzz integration.

This seems to be the official source repo for jaxen. Can some tags be created? I see some fixes since 1.1.6, maybe can start with a new tag/release 1.1.7. Thanks!

There are some issues with the current code base in Java 9 and later. I'm thinking it's time to move forward. Specifically I'm thinking we should push a Jaxen 2.0 release that breaks backwards compatibility. In particular:

1. Remove the org.w3c.dom classes we bundle
2. Set minimum Java version to 5 or later (maybe 6)
3. Split the navigators except for dom into separate submodules.
4. Remove the pattern package which is buggy and unused.

Group ID and package names would rename the same. Artifact ID would change.

This might cause some problems since two jars with different coordinates that bundle the same packages could show up in the class path. Alternatives include keeping artifact ID the same but bumping the version, at least for the core package or repackaging.

Thoughts?

https://circleci.com/blog/triggering-trusted-ci-jobs-on-untrusted-forks/

I am trying to figure out if there are any EOL versions for Jaxen, and if so, when do these versions become EOL?

Thanks

somewhere in the code we reference Java 1.3 javadoc. Update this.

Hi Expert,
I would appreciate if you could share your knowledge related with me? Thanks.

Regards,
Xinmin

probably other plugin upgrades too

Hello,
how can I report a security issue?

Lots of these in the build. maybe something (PMD plugin?) is misconfigured?

[WARNING] Error while parsing /Users/elharo/jaxen/core/src/java/main/org/jaxen/expr/DefaultAdditiveExpr.java: Can't use annotations when running in JDK 1.4 mode!

Hi, jaxen is now using as our xPath engine. However, since the last merge is alreardy two years ago and so does the last comment, we are not sure if the project is still actilvey maintained?

[ERROR] protected Locale getLocale(Object value, Navigator navigator)
[ERROR] ^
[ERROR] /Users/elharo/jaxen/src/java/main/org/jaxen/function/ext/LowerFunction.java:104: warning: no @return
[ERROR] public static String evaluate(Object strArg,
[ERROR] ^
[ERROR] /Users/elharo/jaxen/src/java/main/org/jaxen/function/ext/UpperFunction.java:103: warning: no @return
[ERROR] public static String evaluate(Object strArg,
[ERROR] ^
[ERROR] /Users/elharo/jaxen/src/java/main/org/jaxen/javabean/DocumentNavigator.java:83: warning: no @return
[ERROR] public static Navigator getInstance()
[ERROR]