Quoting Martin Paul <[email protected]>:
Very strange. You could try PCA's --nocache option, which will set "cache=off" for wget. A web proxy should then ignore locally cached files and get the file from Oracle.
Didn't change a thing. I also tried from IE on the same box (Linux is running in a VM), the same happens.
Yes. I'd really be interested to know what's going on. Incidentially, I just wanted to remove the whole file detection for patches downloaded from Oracle, as one should only get ZIP files from that source anyway. Your example just showed that this is not true, although this is not normal behaviour and most probably just a local, one-time error. So I will put my change into the next development release anyway. Just be aware that it your case you'll then end up with a .zip file which is actually a JAR. At the end it probably won't matter anyway.
I've pushed the issue to the admins of the proxy, I'll let you know what they find.
However, I believe we are hitting a fundamental flaw of the Oracle patch download system here:
If you go back to my previous email with the debug run, the request for the patch is secure: https://updates.oracle.com/all_unsigned/121118-19.zip
If the patch were *really* downloaded as httpS, then the proxy would not be able to tamper with it. BUT that https link then redirects to an http one, and the actual download is clear-text.
So the question is, what is the level of trust we can have in those unsigned patches? A funky antivirus is bad enough, but if there were DNS poisoning, the redirect could send us about anywhere and download anything, it'd be unnoticeable.
Laurent
