I'll look into it

First of all I'll add a FAQ entry pointing over here for the macrodef - and add the macro to the javadoc manual page as well.

Porting the Maven patch over should be pretty easy, the DirectoryScanner API looks quite compatible to Ant's DirectoryScanner - I wonder why ;-)

Thanks for the link inside the manual, maybe post the whole macro there?

In my browser, the link does nothing... (Chrome)

Uwe, could you please look over svn revision 1496083 - this is a port of your Maven patch.

The problem with the link seems to be it is opened inside the frame - I'll modify the page to open it in a new window/tab.

manual page should be fixed as well

Are you sure that this works correct on windows?

fixData = FileUtils.readFully(new InputStreamReader(in, "US-ASCII")).trim()
  .replace("\r\n", StringUtils.LINE_SEP)
  .replace("\n", StringUtils.LINE_SEP);

On Windows and if the text file is also windows format this would replace \r\n to \r\n (ok, no change), the second replace would replace the first \n again into \r\n, so you would get \r\r\n.

On Linux it works correctly, maybe this is why you did not get it.

I checked this morning the Replace task, it does it correctly:
fixData = FileUtils.readFully(new InputStreamReader(in, "US-ASCII")).trim()
  .replace("\r\n", "\n")
  .replace("\n", StringUtils.LINE_SEP);

Also please note that String.replace uses a regular expression!!! So its better to also use patchContent() to replace the line feeds.

good catch - should be fixed with svn revision 1496104

Hi Stefan,

works fine. I built the release and ran it on our Lucene checkout. I can confirm, it works fine, it prints the message that it patched 1 file per javadocs run (with vulnerable JDK). With 1.7.0_25 no line was printed.

In both cases, the Lucene-own macro patcher did not find any vulnerability anymore - so it is also compatible with build.xml files that use the quick fix macro.

I also checked the index.html output, the file is patched correctly and the line feeds on windows look correct.

Thanks!
Uwe

One thing:
We have a chicken-egg or also known as bootstrap problem (same applied to the maven javadoc plugin release, I pointed that out on the mailing list): The Javadocs generated for the new ANT version with the internal fixer will have the bug, because ANT does not build the javadocs with the version it currently compiles. So theoretically to prevent buggy javadocs, Ant's build.xml file should contain the macro to fix manually.

In Ant's case the chicken-egg problem is less of a problem as Ant bootstraps itself.  In fact you do build Javadocs with the version you've just compiled - or at least you can and will do so during the release process.

Hi Stefan,

i modified our ANT-based macro that patches Javadocs a little bit:
I removed the <restrict/> and made the <non><contains/></not> be part of the fileset. So it should work with older ANT versions that dont understand <restrict/>.

Here the code, maybe you can update the documentation page of the javadoc task on the ANT website:

  <!--
    Patch frame injection bugs in javadoc generated files - see CVE-2013-1571, http://www.kb.cert.org/vuls/id/225657
    
    Feel free to use this macro in your own Ant build file. This macro works together with the javadoc task on Ant
    and should be invoked directly after its execution to patch broken javadocs, e.g.:
      <patch-javadoc dir="..." docencoding="UTF-8"/>
    Please make sure that the docencoding parameter uses the same charset like javadoc's docencoding. Default
    is the platform default encoding (like the javadoc task).
    The specified dir is the destination directory of the javadoc task.
  -->
  <macrodef name="patch-javadoc">
    <attribute name="dir"/>
    <attribute name="docencoding" default="${file.encoding}"/>
    <sequential>
      <replace encoding="@{docencoding}" summary="true" taskname="patch-javadoc">
        <fileset dir="@{dir}" casesensitive="false" includes="**/index.html,**/index.htm,**/toc.html,**/toc.htm">
          <!-- TODO: add encoding="@{docencoding}" to contains check, when we are on ANT 1.9.0: -->
          <not><contains text="function validURL(url) {" casesensitive="true" /></not>
        </fileset>
        <replacetoken><![CDATA[function loadFrames() {]]></replacetoken>
        <replacevalue expandProperties="false"><![CDATA[if (targetPage != "" && !validURL(targetPage))
        targetPage = "undefined";
    function validURL(url) {
        var pos = url.indexOf(".html");
        if (pos == -1 || pos != url.length - 5)
            return false;
        var allowNumber = false;
        var allowSep = false;
        var seenDot = false;
        for (var i = 0; i < url.length - 5; i++) {
            var ch = url.charAt(i);
            if ('a' <= ch && ch <= 'z' ||
                    'A' <= ch && ch <= 'Z' ||
                    ch == '$' ||
                    ch == '_') {
                allowNumber = true;
                allowSep = true;
            } else if ('0' <= ch && ch <= '9'
                    || ch == '-') {
                if (!allowNumber)
                     return false;
            } else if (ch == '/' || ch == '.') {
                if (!allowSep)
                    return false;
                allowNumber = false;
                allowSep = false;
                if (ch == '.')
                     seenDot = true;
                if (ch == '/' && seenDot)
                     return false;
            } else {
                return false;
            }
        }
        return true;
    }
    function loadFrames() {]]></replacevalue>
      </replace>
    </sequential>
  </macrodef>

yes, done, thanks

Ant 1.9.2 containing your fix has just been released.