Security in use of contants

Is secure use constants?

I come from Python and it isn't recommended there.

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!

···

--
   Phlip

Ops! I was wrong! I mean global variables instead of constants. Sorry!

···

On Aug 17, 7:00 pm, Kless <jonas....@googlemail.com> wrote:

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...

How do you come up with this question?

CONSTANTS are perhaps more secure in comparison to loops. :slight_smile:
Be avare of the interations.

···

On Aug 17, 8:36 pm, Phlip <phlip2...@gmail.com> wrote:

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!

--
Phlip

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.

···

--
   Phlip

"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 :stuck_out_tongue:

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?

···

--
RMagick: http://rmagick.rubyforge.org/

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.

···

--
   Phlip

"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

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...

···

--
Posted via http://www.ruby-forum.com/\.

"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

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

···

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 ?

"Unit tests provide positive reinforcement that your features behave
as expected."

Yehh, if you know how to write bulletproof unit tests......

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!:wink:

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.

···

--
   Phlip

"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.

···

On Sunday 17 August 2008 22:06:51 loolek wrote:

"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

"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?

"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".

This topic turned to interesting "ruby hacker" lessons. But first let
me answare your Qs ->

"Ok, first ... whoever they are"

a. May be ter*rist or whatever, don' really matter. But they are only
one guy.

"get the ability to "overwrite" it?"

Secound, play that -> i am the bad guy...

a. I was won the ruby programmer job at the plant -> I'm in!

b. I hacked the box of the security guy of the plant (home machine).
Why? Becouse he/she is got connection to the inner plant network
(SSH). So i am in again! (idea from Kevin)

c. I gave a really cool video game CD to my "new friend Joe", who is
working at the plant. Why? Becouse he will install it on the inner
box, just for fun. The game will install me among the cool game. So i
am in again!

d. Maybe in the plant, there is some "hard but alive" way -> between
the local and public lan.

e. Should i continue?

"let alone in my memory space."

Hmm, how do you mean this? The ruby code will guard the memory/
hardware/io/etc. I really don't get you?

But anyway -> i was first hacked the unpatched Linux kernel... Should
i continue the "how"?

a. I thought only only the CPU's protected mode can do this kind of
job. Or i am wrong?

"WE are saying is that you are wrong about how to go about being
secure."

I think "hypotheticaly" -> i am right. In other words, you STILL don't
see the DANGER that the week coding language cousing?

"hell of a lot worse than "overwriting a constant""

Oh yes, i see now -> you don't smell the dager still, becouse you
asking this silly Q. But okay, what worse could happen?

a. You are dead.
b. Your home city is dead too.
c. You mom is dead too.
d. The water in your area is posioned for a long time.
e. etc.

peter