you've got a few questions there ... i'll answer the first one.
i might copy the suggestion from someone [i can't remember who at the
moment] who suggested the next step in programming in-general is more
parallel programs [in order to increase speed]. this is obviously
complicated and will create
On 6/7/07, McGovern, James F (HTSC, IT) [EMAIL PROTECTED] wrote:
I really hope that this email doesn't generate a ton of offline emails and
hope that folks will
talk publicly. It has been my latest thinking that the value of tools in this
space are not really
targeted at developers but
Awesome.
---
http://en.epochtimes.com/tools/printer.asp?id=50336
The Epoch Times
Home Science Technology
Chinese Professor Cracks Fifth Data Security Algorithm
SHA-1 added to list of accomplishments
Central News Agency
Jan 11, 2007
Associate professor Wang
On 3/14/07, Gary McGraw [EMAIL PROTECTED] wrote:
Once again i'll ask. Which vertical is the kind of company where you're
seeing this awful behavior in?
well, fwiw, i've noticed it in finance/investment, and the entertainment
industries. but i honestly don't think the industry type makes a
On 3/13/07, Gary McGraw [EMAIL PROTECTED] wrote:
hi sc-l,
this month's darkreading column is about compliance. my own belief is
that compliance has really helped move software security forward. in
particular, sox and pci have been a boon:
On 3/9/07, McGovern, James F (HTSC, IT) [EMAIL PROTECTED]
wrote:
Traditionally InfoSec folks defined themselves as being knowledgable in
firewalls, policies, etc. Lately, many enterprises are starting to recognize
the importance of security within the software development lifecycle where
even
On 2/27/07, Kenneth Van Wyk [EMAIL PROTECTED] wrote:
Here's an interesting article from Dark Reading about web fuzzers. Web
fuzzing seems to be gaining some traction these days as a popular means of
testing web apps and web services.
On 2/28/07, Gary McGraw [EMAIL PROTECTED] wrote:
Hi all,
The neverending debate over disclosure continued at RSA this year with a
panel featuring Chris Wysopl and others rehashing old ground. There are
points on both sides, with radicals on one side (say marcus ranum)
calling the disclosure
(Main.java:26)
Java Result: 1
This error is thrown irrespective of the -verify flag. So it looks
like using a classloader causes the VM to perform verification,
whether or not the verifier was enabled. Michael Silk made a
similar statement earlier in this thread. Would you agree?
PoC code below
On 5/12/06, Dinis Cruz [EMAIL PROTECTED] wrote:
Michael Silk wrote:
What is the point of the verifier?' , 'Why use it? and 'What are the
real security advantages of enabling the verifier if the code is
executed in an environment with the security manager disabled?'
Huh? You can find what
The verifier is enabled via the commandline. It is either on or off.
the VM does other forms of verification though.
http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#79383
...
-- Michael
On 5/11/06, Jeff Williams [EMAIL PROTECTED] wrote:
Stephen de Vries wrote:
On 5/9/06, Dinis Cruz [EMAIL PROTECTED] wrote:
Stephen de Vries wrote:
Java has implemented this a bit differently, in that the byte code
verifier and the security manager are independent. So you could for
example, run an application with an airtight security policy (equiv to
partial
Two important clarifications for Java (based on my experiments):
1) The verifier IS enabled for the classes that come with the Java
platform, such as those in rt.jar. So, for example, if you create a class
that tries to set System.security (the private variable that points to the
On 5/4/06, Dinis Cruz [EMAIL PROTECTED] wrote:
Wall, Kevin wrote:
Also, from the results of your test, it seems to indicate that SOME TYPE
of verification is taking place, but if all you did was change a few
ARBITRARY bytes in the .class file, I don't think that proves the
byte code
Verifier in 1.5 is definately OFF by default:
to confirm this do the following:
1. Create this class:
==
public class Foo {
public static int k = 23;
static {
System.out.println(initially k: + k);
}
public static void m(){
System.out.println(m()
If you are just talking about a password to access a db, the 'typical'
approach (at least the approach I use) is just to store that password
in the code/config file. You may like to add a layer to that by
encrypting it in some config file, and requiring a 'decryption'
(initialisation) of the
I don't think that analogy quite fits :) If the 'grunts' aren't doing
their job, then yes - let's blame them. Or at least help them find
ways to do it better.
-- Michael
[Ed. Let's consider this the end of the thread, please. Unless someone
wants to say something that is directly relevant to
On 4/13/05, der Mouse [EMAIL PROTECTED] wrote:
I would question you if you suggested to me that you always assume
to _NOT_ include 'security' and only _DO_ include security if
someone asks.
Security is not a single thing that is included or omitted.
Again, in my experience that is not
Dave,
On Apr 11, 2005 9:58 PM, Dave Paris [EMAIL PROTECTED] wrote:
The programmer is neither the application architect nor the system
engineer.
In some cases he is. Either way, it doesn't matter. I'm not asking the
programmer to re-design the application, I'm asking them to just
program the
On Apr 7, 2005 12:43 PM, Blue Boar [EMAIL PROTECTED] wrote:
Michael Silk wrote:
See, you are considering 'security' as something extra again. This is
not right.
It is extra. It's extra time and effort. And extra testing. And extra
backtracking and schedule slipping when you realize you
Quoting from the article:
''You can't really blame the developers,''
I couldn't disagree more with that ...
It's completely the developers fault (and managers). 'Security' isn't
something that should be thought of as an 'extra' or an 'added bonus'
in an application. Typically it's just about
On Apr 7, 2005 3:12 AM, Kenneth R. van Wyk [EMAIL PROTECTED] wrote:
On Wednesday 06 April 2005 09:26, Michael Silk wrote:
The last thing I want is my mobile phone updating itself. I imagine
that sort of operation would take up battery power, and possibly cause
other interruptions ... (can
-
From: Michael Silk [EMAIL PROTECTED]
To: Kenneth R. van Wyk [EMAIL PROTECTED]
Cc: Secure Coding Mailing List SC-L@securecoding.org
Sent: Wednesday, April 06, 2005 9:40 AM
Subject: Re: [SC-L] Application Insecurity --- Who is at Fault?
Quoting from the article:
''You can't really
]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael Silk
Sent: Wednesday, April 06, 2005 9:40 AM
To: Kenneth R. van Wyk
Cc: Secure Coding Mailing List
Subject: Re: [SC-L] Application Insecurity --- Who is at Fault?
Quoting from
be given upfront
Agreed.
-- Michael
Michael Silk wrote:
Quoting from the article:
''You can't really blame the developers,''
I couldn't disagree more with that ...
It's completely the developers fault (and managers). 'Security' isn't
something that should be thought of as an 'extra
25 matches
Mail list logo
