[ANNOUNCEMENT] CSS4J 3.1, 2.2 and 1.1

[admin]

New versions 3.1, 2.2 and 1.1 are available from the usual places:

https://css4j.github.io/#downloads

Release Highlights

• Previous versions were vulnerable to DoS attacks, and the new protections use the new CSSDocument.isAuthorizedOrigin(URL) method.
• The method ErrorHandler.hasErrors() now returns true if there are I/O errors. Those errors were previously considered transient, and therefore weren't appearing there.
• DOM: on attribute nodes, getTextContent() now returns the attribute value instead of the empty string.
  
• [3.1] DOM: DOMDocument.getDomConfig() was undeprecated, and the DOMConfiguration can be used to control the normalisation of the document.
  
• [3.1] DOM: DOM nodes now implement java.io.Serializable.
• [3.1] DefaultEntityResolver.resolveEntity(DocumentTypeDeclaration) is deprecated.

("DOM:" means that the change applies to "Native DOM implementation").

These new behaviours mean that the new releases are not fully backwards-compatible with the latest releases from their branches, so the minor versions were bumped to 3.1, 2.2 and 1.1.

Additionally, the following are important fixes/improvements:

• [3.1] Case sensitivity fixes: Native DOM correctly matched the selector [Foo] to the attribute foo="bar" in HTML documents, but neither the XML-oriented DOM implementations in the DOM wrapper nor the DOM4J back-end did. Now they both do, and a few other smaller case sensitivity fixes were applied as well.
• [3.1] DOM: indented serialisation of inline-block elements in DOMWriter.
• DOM: normalisation of element-content whitespace is now based on the value of the whitespace CSS property, and so does DOMWriter serialisation (note: 1.0.9 already had this fix, and only 3.1 has configurable normalisation).
• Due to the security fixes, all users that process untrusted HTML or CSS with css4j should upgrade.
  

[admin]

I re-deployed 3.1, 2.2 and 1.1 (together with other older releases) to the temporary Maven repository. In Github Pages (which that repository uses), git is used to deploy the files to the web site and I did not realize that the POM files were being converted to Unix line endings at the server, which means that the SHA-1 and MD-5 digest files (which were computed and created locally on a Windows machine) did not match the files that were being served through the website.

This situation was causing digest validation errors in Maven (the well-known "checksum validation failed") for POM files. Now the POMs are converted to Unix line endings before computing the digests, and I've added a .gitattributes file to the Github Pages repository, which includes the following:

*.txt text eol=crlf
*.pom text eol=lf
*.xml text eol=lf

The eol=crlf for *.txt files is basically for the Release Notes, and the other two are for the Maven repository.

These are the kind of glitches that one finds while trying to serve Maven artifacts with a minimal infrastructure, but doing that is necessary to ease things for developers using the library. In that line, I created two scripts that can be used to directly download and deploy CSS4J and JCLF to a local Maven repository, without the need to download the ZIP archive:

https://raw.githubusercontent.com/css4j/css4j-dist/master/install-jclf.sh

https://raw.githubusercontent.com/css4j/css4j-dist/master/install-css4j.sh

It is unfortunate that Maven is refractory to non-centralised distribution of artifacts, at least it should be possible to do something like this:

<dependency>
  <groupId>io.sf.jclf</groupId>
  <artifactId>jclf</artifactId>
  <version>[4.0.4,4.999]</version>
  <type>jar</type>
  <scope>compile</scope>
  <remoteRepositories>https://css4j.github.io/maven/</remoteRepositories>
</dependency>

to indicate from which repository you want to try downloading the artifact first.

[admin]

I failed to mention a notable change in the css4j-dom4j module: now the Document.setDocumentURI(String) and Document.getDocumentURI() methods are supported.

You no longer have to call setBaseURL() to tell the document how to resolve relative URIs, which was a bit weird but probably better for upstream compatibility. Now setDocumentURI() can do the trick (much as it does for the other back-ends). The change was made for security reasons (preventing dangerous values in the base URL), and existing code which calls setBaseURL() should continue to work just fine.

Despite this improvement to the dom4j module, developers are discouraged from using that library for new projects; the upstream dom4j code base is very old and is showing its age. We are lucky that the current maintainer picked up the project after being abandoned, but in recent years is lagging behind: for example, an XML injection vulnerability was reported two months ago and is unpatched yet.