Is secure use constants?
I come from Python and it isn’t recommended there.
What do you mean by “secure”? Neither Ruby nor Python are secure from reverse
engineering, because all the source is hanging out visible for all to see!–
Phlip
private static final int 42;
Or something like this…
Kless wrote:
Is secure use constants?
I come from Python and it isn’t recommended there.
Use constants to avoid repeating a literal with the same meaning, such
as ‘42’,
in various locations in your code.
What do you mean by “secure”? Neither Ruby nor Python are secure from
reverse
engineering, because all the source is hanging out visible for all to
see!
On Aug 17, 8:36 pm, Phlip [email protected] wrote:
–
Phlip
How do you come up with this question?
CONSTANTS are perhaps more secure in comparison to loops. 
Be avare of the interations.
“Nobody can ever change it?”
Yes, yes -> i mean, under the java vm security control -> nobody can
change it.
That’s cool for me -> but means nothing for a serious hacker…
peter
“Don’t worry about your constants changing.”
My job is -> be full secure !!!
So, i am worring about this -> “small ruby leak”…
Do you need a case study -> for this “bad” situation, becouse a week
constant guarding (for example in C)?
“Just write clean code, and pay attention to your warnings & test
results, and you will be okay.”
Thanks buddy…you help a lot 
peter
loolek wrote:
“Don’t worry about your constants changing.”
My job is -> be full secure !!!
So, i am worring about this -> “small ruby leak”…
Do you need a case study -> for this “bad” situation, becouse a week
constant guarding (for example in C)?
I admit it, I’m largely ignorant of security issues. What kind of bad
thing can you do with Ruby constants?
loolek wrote:
private static final int 42;
Or something like this…
What is secure about that? Nobody can ever change it?
Even in C, a language designed to compile directly to machine language
with no
questions asked, you can still force a constant to change. You get
“undefined
behavior”, but you can still do it.
Don’t worry about your constants changing. Just write clean code, and
pay
attention to your warnings & test results, and you will be okay.
loolek wrote:
“Don’t worry about your constants changing.”
My job is -> be full secure !!!
Static type checking (constant, private, etc.) only provide negative
reinforcement that code might work as designed. Unit tests provide
positive
reinforcement that your features behave as expected. Code with
wall-to-wall unit
tests is better than any code with all kinds of constants, privates, and
typechecks.
I admit it, I’m largely ignorant of security issues. What kind of
bad thing can you do with Ruby constants?
It depends on the coder in question:
-
matz once single handedly trapped Chuck Norris within a constant void.
-
Lesser ruby coders may utterly fail in doing so, ending up as bloody
BBQ.
Also, there exists believable rumours that one can do time travels with
constants, if used in the right way (full moon, 12 fresh sheep, some old
gold coins and a pirate curse…)
But again beware, only those strong in will may succeed…
“Static”
The JVM do this dynamically, how do you mean “static” ?
“only provide negative reinforcement … wall-to-wall unit tests is
better”
Could you explain this more detailed, i dont get it what are you
thinking about ?
peter
"What kind of bad thing can you do with Ruby constants? "
I think this is not the question of ruby. Imagine this -> there is a
constant that holds the value that triggers the cooler sticks in a
nuclear power plant. Than the bad guy “overwrites” it, what comes
next ?
A BIG CRASH BANG
“I’m largely ignorant”
Are you sure, you will be ingnorant if you where living in the next
city from the plant ?
peter
“Unit tests provide positive reinforcement that your features behave
as expected.”
Yehh, if you know how to write bulletproof unit tests…
peter
On Mon, 2008-08-18 at 12:06 +0900, loolek wrote:
I think this is not the question of ruby. Imagine this -> there is a
constant that holds the value that triggers the cooler sticks in a
nuclear power plant. Than the bad guy “overwrites” it, what comes
next ?
To be blunt, this is a nonissue. If the “bad guy” is in a position to
redefine a Ruby constant, he is capable of doing much worse things with
less trouble.
-mental
“You tell them you will write unit tests for all your code.”
Wrong, i will never work for the goverment -> the job is yours whitout
a BID…
Double wrong, i never write unit tests, becouse i sad it -> unit tests
NEVER discovers all of the security holes (remember FULL security).
“meaning it is a small integer only”
Yeah, this small door will be enough for that clever/fast bad guy ->
BANG AGAIN
“causes a warning”
This is interesting, do you have a rubydoc link to this topic ?
peter
loolek wrote:
"What kind of bad thing can you do with Ruby constants? "
I think this is not the question of ruby. Imagine this -> there is a
constant that holds the value that triggers the cooler sticks in a
nuclear power plant. Than the bad guy “overwrites” it, what comes
next ?
Okay, you and I are bidding for that contract. (In an imaginary,
old-fashioned
world where government contract bids are competitive!
I tell them I will use a constant there.
You tell them you will write unit tests for all your code.
Who should get the contract?
And note that, in Ruby, changing the immediate value of a constant
(“immediate”
meaning it is a small integer only), causes a warning.
“Unit tests provide positive reinforcement that your features behave
as expected.”Yehh, if you know how to write bulletproof unit tests…
You know the difference between negative and positive reinforcement,
right?
“right?”
Nope, PLZ explain it.
peter
““causes a warning””
"This is interesting, do you have a rubydoc link to this topic ? "
And don’t forget this Q.
peter
On Sunday 17 August 2008 22:06:51 loolek wrote:
"What kind of bad thing can you do with Ruby constants? "
I think this is not the question of ruby. Imagine this → there is a
constant that holds the value that triggers the cooler sticks in a
nuclear power plant. Than the bad guy “overwrites” it, what comes
next ?
Ok, first, how does the “bad guy”, whoever they are, get the ability
to “overwrite” it? They shouldn’t even be on the same network, let
alone in
my memory space.
And, for that matter, if they were in my memory space, they can do a
hell of a
lot worse than “overwriting a constant”.
Here, I think XKCD explains this better than I could:
Are you sure, you will be ingnorant if you where living in the next
city from the plant ?
Sorry, but the magnitude of possible failure doesn’t prove your point.
No one is saying that it’s OK to be less secure. What we are saying is
that
you are wrong about how to go about being secure.
In other words, we are saying that your attitude towards security is
more
likely to blow up that hypothetical plant than, say, proper unit
testing.