Michael Silk wrote:
> The "verifier" is enabled via the commandline. It is either on or off.
I'm not sure that's true. See:
http://securecoding.org/pipermail/sc-l/2006/000262.html
Summary: there are *three* comandline options: -verify, -noverify, and
-verifyremote. It is -verifyremote that
Tim Hollebeek wrote:
> The fact that editing the .class file allows you to produce one that
> causes the JVM to crash is pretty strong evidence the verifier was
> NOT used to validate the file.
>
Right. What follows is a summary of what we know so far, and what I
think is going on. The detail
Dinis Cruz wrote:
> Ok, I just did some further tests and I think I can say that Java
> (version 1.5.0_06) has similar verification issues to the ones I
> discovered on the .Net Framework (see links in my previous post).
[...]
> This should prove that the verifier is not enabled by default on java
Wall, Kevin wrote:
>> same intuition about the verifier, but have just tested
>> this and it is not the case. It seems that the -noverify is the
>> default setting! If you want to verify classes loaded from the local
>> filesystem, then you need to explicitly add -verify to the cmd line.
>>
Ron Forrester wrote:
On 12/13/05, Kenneth R. van Wyk <[EMAIL PROTECTED]> wrote:
The detection mechanism seems to primarily be looking primarily for non-OS
software modifying OS inhabited memory blocks. Wonder how they're definining
(and maintaining the definition) of each... I also wonder h
der Mouse wrote:
>All that a "better" language will bring you in this regard is that it
>will (a) push the sloppiness into places the compiler can't check and
>(b) change the ways things break when confronted with input beyond the
>design underlying their code.
>
>
My car has a tether connected
