I was a little disturbed by this diatribe directed against ant and Erik Hatcher. Essentially the user complains that because ant’s filter tasks don’t work well with binary files, Erik’s an arrogant ass.
Erik had something to say about this and I’m impressed by his restraint. So I thought I’d chime in.
I’m a relatively young programmer, I don’t know everything, but one thing I do know is that attempting to do token replacement on binary files is retarded. Think for a moment about what the filter task does, it goes through and looks for group of bytes, say ‘
url’ and replaces it with another group of bytes, say ‘somesite.com’.
Now, the ascii values for that particular pattern are:
- 64, 117, 114, 108, 64
They’ll be replaced with:
- 115, 111, 109, 101, 115, 105, 116, 101, 46, 99, 111, 109
Now for your jsps, java files etc you’ll be fine. Odds are that
url is a weird combination and won’t show up. However for any given binary file you have a reasonably good chance that these values will show up. Add in lots of other tokens and you’re almost certainly going to have one of them show up.
So what’s going to happen if those bytes get mangled? Anything. Imagine an application whose format is along the lines of:
- read one byte, that tells you the length of the data in the stream,
- read along the stream till you hit 0xFF, store that in the buffer for the stream,
- repeat until EOF
Now, if your token has replaced 5 bytes with 12 in the middle of a stream you’ve just run the risk of corrupting the heap. Don’t believe me? A vulnerability was found in IE’s handling of PNGs just like this.
So please, fellow programmers, before ranting and raving about how something is crap by design, think about the problem at hand. The ant filterset behaviour is perfectly reasonable, and sure, the documentation was missing this particular piece of information on one page. However a little common sense goes a very long way, and most programmers should be accutely aware of this kind of issue.[