Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 13 RS56

2009-11-24T01:03:51Z

RadioSignal:

''Bertrand Meyer's Principle of Explicit Interfaces states that whenever two modules A and B communicate, this must be obvious from the text of A or B or both. Consider the reasons for this principle, and when it is and is not important to follow it. Because Wikipedia does not have a page on this principle, if you do a good job, you might consider submitting it to Wikipedia.'' 

===Explicit Interfaces===
----
The definition of Bertrand Meyer’s Principle of Explicit Interfaces states that if two modules must interact, the interaction should be plainly visible. Let’s see what can happen if this is not followed. Assume that module A creates global data with two bytes of resolution. Module B accepts that data and processes it. Now, years later, a programmer is given the task of expanding the resolution of the data to 4 bytes but is unaware that Module B even uses the data. All goes well for months until the module A creates the first three byte value and passes it to module B. Depending upon the criticality of the application, the litigation could become interesting.

===Obscure Object Oriented Principle===
One does not hear much about Bertrand Meyer’s Principle of Explicit Interfaces. Modern texts such as Head First Design Patterns do not include it. The originator’s text, Object-Oriented Software Construction, presumably defines and explains the principle. At $102.05 on [http://www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/0136291554/ref=sr_1_3?ie=UTF8&s=books&qid=1258483189&sr=1-3 amazon.com], it will remain for others to research. While it appears that the principle has been absorbed into many other object oriented principles and commercial products such as Eiffel’s Contract by Design, the work does stand on its own merit as we will see in this wiki.

===Documentation===
To create an explicit interface for any language, assembler, FORTRAN, object and non-object oriented alike, one can use a technique as old as data processing itself, documentation. Create a document explicitly stating conditions that each module will accept and will produce. 
Assembler language Self Documentation example:
<pre>
MODULE A:
GLOBVARIN* $RES 2 . A two byte quantity passed from Module A to Module B
MODULE B:
GLOBVAROT* $RES 2 . A two byte quantity returned from Module B to Module A
</pre>

===Strong Typing===
For strongly typed object oriented languages, some changes to the contract between modules may be evident at compile time. Certain modifications can raise a red flag to the developer making an unwitting change. He would have a pleasant surprise if both module A and B are compiled together. Dynamically typed languages would have to wait for run-time to throw an exception. Depending on the level of testing performed in the development environment, this may or may not provide an adequate resolution to the contract being broken.

===Require and Ensure===
Eiffel goes so far to insure explicit interfaces that a language [http://www.eiffel.com/developers/design_by_contract_in_detail.html construct] exists to facilitate the creation of a well defined and checked interface. 
<pre>
put (x: ELEMENT; key: STRING) is
-- Insert x so that it will be retrievable through key.
require
count <= capacity
not key.empty
do
... Some insertion algorithm ...
ensure
has (x)
item (key) = x
count = old count + 1
end
</pre>

===Conclusion===
----
Bertrand Meyer’s principle of Explicit Interfaces is so simple that it has been incorporated in many other principles and patterns. So profound and yet obscure due to its simplicity. It has attained universal acceptance.

===Glossary===
----
Ensure – An Eiffel language construct to facilitate the principle of Explicit Interfaces used to validate the post-condition of a module. 
Require – An Eiffel language construct to facilitate the principle of Explicit Interfaces used to validate the pre-condition of a module. 
Strongly typed – A technique used in many object oriented programming languages which results in compiler errors when a type mismatch occurs. 

===References===
----
# Eric Freeman and Elisabeth Freeman. ''Head First Design Patterns''. O’Reilly Media, Inc., 2009. ISBN: 978-0-596-00712-6
# http://www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/0136291554/ref=sr_1_3?ie=UTF8&s=books&qid=1258483189&sr=1-3

CSC/ECE 517 Fall 2009/wiki3 13 RS56

2009-11-24T01:02:16Z

RadioSignal: /* Strong Typing */

''Bertrand Meyer's Principle of Explicit Interfaces states that whenever two modules A and B communicate, this must be obvious from the text of A or B or both. Consider the reasons for this principle, and when it is and is not important to follow it. Because Wikipedia does not have a page on this principle, if you do a good job, you might consider submitting it to Wikipedia.'' 

===Explicit Interfaces===
----
The definition of Bertrand Meyer’s Principle of Explicit Interfaces states that if two modules must interact, the interaction should be plainly visible. Let’s see what can happen if this is not followed. Assume that module A creates global data with two bytes of resolution. Module B accepts that data and processes it. Now, years later, a programmer is given the task of expanding the resolution of the data to 4 bytes but is unaware that Module B even uses the data. All goes well for months until the module A creates the first three byte value and passes it to module B. Depending upon the criticality of the application, the litigation could become interesting.

===Obscure Object Oriented Principle===
One does not hear much about Bertrand Meyer’s Principle of Explicit Interfaces. Modern texts such as Head First Design Patterns do not include it. The originator’s text, Object-Oriented Software Construction, presumably defines and explains the principle. At $102.05 on [http://www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/0136291554/ref=sr_1_3?ie=UTF8&s=books&qid=1258483189&sr=1-3 amazon.com], it will remain for others to research. While it appears that the principle has been absorbed into many other object oriented principles and commercial products such as Eiffel’s Contract by Design, the work does stand on its own merit as we will see in this wiki.

===Documentation===
To create an explicit interface for any language, assembler, FORTRAN, object and non-object oriented alike, one can use a technique as old as data processing itself, documentation. Create a document explicitly stating conditions that each module will accept and will produce. 
Assembler language Self Documentation example:
<pre>
MODULE A:
GLOBVARIN* $RES 2 . A two byte quantity passed from Module A to Module B
MODULE B:
GLOBVAROT* $RES 2 . A two byte quantity returned from Module B to Module A
</pre>

===Strong Typing===
For strongly typed object oriented languages, some changes to the contract between modules may be evident at compile time. Certain modifications can raise a red flag to the developer making an unwitting change. He would have a pleasant surprise if both module A and B are compiled together. Dynamically typed languages would have to wait for run-time to throw an exception. Depending upon the level of testing performed in the development environment, this may or may not provide an adequate resolution to the contract being broken.

===Require and Ensure===
Eiffel goes so far to insure explicit interfaces that a language [http://www.eiffel.com/developers/design_by_contract_in_detail.html construct] exists to facilitate the creation of a well defined and checked interface. 
<pre>
put (x: ELEMENT; key: STRING) is
-- Insert x so that it will be retrievable through key.
require
count <= capacity
not key.empty
do
... Some insertion algorithm ...
ensure
has (x)
item (key) = x
count = old count + 1
end
</pre>

===Conclusion===
----
Bertrand Meyer’s principle of Explicit Interfaces is so simple that it has been incorporated in many other principles and patterns. So profound and yet obscure due to its simplicity. It has attained universal acceptance.

===Glossary===
----
Ensure – An Eiffel language construct to facilitate the principle of Explicit Interfaces used to validate the post-condition of a module. 
Require – An Eiffel language construct to facilitate the principle of Explicit Interfaces used to validate the pre-condition of a module. 
Strongly typed – A technique used in many object oriented programming languages which results in compiler errors when a type mismatch occurs. 

===References===
----
# Eric Freeman and Elisabeth Freeman. ''Head First Design Patterns''. O’Reilly Media, Inc., 2009. ISBN: 978-0-596-00712-6
# http://www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/0136291554/ref=sr_1_3?ie=UTF8&s=books&qid=1258483189&sr=1-3

CSC/ECE 517 Fall 2009/wiki3 13 RS56

2009-11-24T00:55:55Z

RadioSignal:

''Bertrand Meyer's Principle of Explicit Interfaces states that whenever two modules A and B communicate, this must be obvious from the text of A or B or both. Consider the reasons for this principle, and when it is and is not important to follow it. Because Wikipedia does not have a page on this principle, if you do a good job, you might consider submitting it to Wikipedia.'' 

===Explicit Interfaces===
----
The definition of Bertrand Meyer’s Principle of Explicit Interfaces states that if two modules must interact, the interaction should be plainly visible. Let’s see what can happen if this is not followed. Assume that module A creates global data with two bytes of resolution. Module B accepts that data and processes it. Now, years later, a programmer is given the task of expanding the resolution of the data to 4 bytes but is unaware that Module B even uses the data. All goes well for months until the module A creates the first three byte value and passes it to module B. Depending upon the criticality of the application, the litigation could become interesting.

===Obscure Object Oriented Principle===
One does not hear much about Bertrand Meyer’s Principle of Explicit Interfaces. Modern texts such as Head First Design Patterns do not include it. The originator’s text, Object-Oriented Software Construction, presumably defines and explains the principle. At $102.05 on [http://www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/0136291554/ref=sr_1_3?ie=UTF8&s=books&qid=1258483189&sr=1-3 amazon.com], it will remain for others to research. While it appears that the principle has been absorbed into many other object oriented principles and commercial products such as Eiffel’s Contract by Design, the work does stand on its own merit as we will see in this wiki.

===Documentation===
To create an explicit interface for any language, assembler, FORTRAN, object and non-object oriented alike, one can use a technique as old as data processing itself, documentation. Create a document explicitly stating conditions that each module will accept and will produce. 
Assembler language Self Documentation example:
<pre>
MODULE A:
GLOBVARIN* $RES 2 . A two byte quantity passed from Module A to Module B
MODULE B:
GLOBVAROT* $RES 2 . A two byte quantity returned from Module B to Module A
</pre>

===Strong Typing===
For strongly typed object oriented languages, some changes to the contract between modules may be evident at compile time. Certain modifications can raise a red flag to the developer making an unwitting change. The developer would have a pleasant surprise if both module A and B are compiled together. Dynamically typed languages would have to wait for run-time to throw an exception. Depending upon the level of testing performed in development, that may or may not provide an adequate resolution to the contract being broken.

===Require and Ensure===
Eiffel goes so far to insure explicit interfaces that a language [http://www.eiffel.com/developers/design_by_contract_in_detail.html construct] exists to facilitate the creation of a well defined and checked interface. 
<pre>
put (x: ELEMENT; key: STRING) is
-- Insert x so that it will be retrievable through key.
require
count <= capacity
not key.empty
do
... Some insertion algorithm ...
ensure
has (x)
item (key) = x
count = old count + 1
end
</pre>

===Conclusion===
----
Bertrand Meyer’s principle of Explicit Interfaces is so simple that it has been incorporated in many other principles and patterns. So profound and yet obscure due to its simplicity. It has attained universal acceptance.

===Glossary===
----
Ensure – An Eiffel language construct to facilitate the principle of Explicit Interfaces used to validate the post-condition of a module. 
Require – An Eiffel language construct to facilitate the principle of Explicit Interfaces used to validate the pre-condition of a module. 
Strongly typed – A technique used in many object oriented programming languages which results in compiler errors when a type mismatch occurs. 

===References===
----
# Eric Freeman and Elisabeth Freeman. ''Head First Design Patterns''. O’Reilly Media, Inc., 2009. ISBN: 978-0-596-00712-6
# http://www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/0136291554/ref=sr_1_3?ie=UTF8&s=books&qid=1258483189&sr=1-3

CSC/ECE 517 Fall 2009/wiki3 13 RS56

2009-11-19T23:20:48Z

RadioSignal:

''Bertrand Meyer's Principle of Explicit Interfaces states that whenever two modules A and B communicate, this must be obvious from the text of A or B or both. Consider the reasons for this principle, and when it is and is not important to follow it. Because Wikipedia does not have a page on this principle, if you do a good job, you might consider submitting it to Wikipedia.'' 

===Explicit Interfaces===
----
The definition of Bertrand Meyer’s Principle of Explicit Interfaces states that if two modules must interact, the interaction should be plainly visible. Let’s see what can happen if this is not followed. Assume that module A creates global data with two bytes of resolution. Module B accepts that data and processes it. Now, years later, a programmer is given the task of expanding the resolution of the data to 4 bytes but is unaware that Module B even uses the data. All goes well for months until the module A creates the first three byte value and passes it to module B. Depending upon the criticality of the application, the litigation could become interesting.

===Obscure Object Oriented Principle===
One does not hear much about Bertrand Meyer’s Principle of Explicit Interfaces. Modern texts such as Head First Design Patterns do not include it. The originator’s text, Object-Oriented Software Construction, presumably defines and explains the principle. At $102.05 on [http://www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/0136291554/ref=sr_1_3?ie=UTF8&s=books&qid=1258483189&sr=1-3 amazon.com], it will remain for others to research. While it appears that the principle has been absorbed into many other object oriented principles and commercial products such as Eiffel’s Contract by Design, the work does stand on its own merit as we will see in this wiki.

===Documentation===
To create an explicit interface for any language, assembler, FORTRAN, object and non-object oriented alike, one can use a technique as old as data processing itself, documentation. Create a document explicitly stating conditions that each module will accept and will produce. 
Assembler language Self Documentation example:
<pre>
MODULE A:
GLOBVARIN* $RES 2 . A two byte quantity passed from Module A to Module B
MODULE B:
GLOBVAROT* $RES 2 . A two byte quantity returned from Module B to Module A
</pre>

===Strong Typing===
For strongly typed object oriented languages, some changes to the contract between modules may be evident at compile time. Certain modifications can raise a red flag to the developer making an unwitting change. The unwitting developer would have a pleasant surprise if both module A and B are compiled together.

===Require and Ensure===
Eiffel goes so far to insure explicit interfaces that a language [http://www.eiffel.com/developers/design_by_contract_in_detail.html construct] exists to facilitate the creation of a well defined and checked interface. 
<pre>
put (x: ELEMENT; key: STRING) is
-- Insert x so that it will be retrievable through key.
require
count <= capacity
not key.empty
do
... Some insertion algorithm ...
ensure
has (x)
item (key) = x
count = old count + 1
end
</pre>

===Conclusion===
----
Bertrand Meyer’s principle of Explicit Interfaces is so simple that it has been incorporated in many other principles and patterns. So profound and yet obscure due to its simplicity. It has attained universal acceptance.

===Glossary===
----
Ensure – An Eiffel language construct to facilitate the principle of Explicit Interfaces used to validate the post-condition of a module. 
Require – An Eiffel language construct to facilitate the principle of Explicit Interfaces used to validate the pre-condition of a module. 
Strongly typed – A technique used in many object oriented programming languages which results in compiler errors when a type mismatch occurs. 

===References===
----
# Eric Freeman and Elisabeth Freeman. ''Head First Design Patterns''. O’Reilly Media, Inc., 2009. ISBN: 978-0-596-00712-6
# http://www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/0136291554/ref=sr_1_3?ie=UTF8&s=books&qid=1258483189&sr=1-3

CSC/ECE 517 Fall 2009/wiki3 13 RS56

2009-11-18T21:05:45Z

RadioSignal:

''Bertrand Meyer's Principle of Explicit Interfaces states that whenever two modules A and B communicate, this must be obvious from the text of A or B or both. Consider the reasons for this principle, and when it is and is not important to follow it. Because Wikipedia does not have a page on this principle, if you do a good job, you might consider submitting it to Wikipedia.'' 

===Explicit Interfaces===
----
The definition of Bertrand Meyer’s Principle of Explicit Interfaces states that if two modules must interact, the interaction should be plainly visible. Let’s see what can happen if this is not followed. Assume that module A creates global data with two bytes of resolution. Module B accepts that data and processes it. Now, years later, a programmer is given the task of expanding the resolution of the data to 4 bytes but is unaware that Module B even uses the data. All goes well for months until the module A creates the first three byte value and passes it to module B. Depending upon the criticality of the application, the litigation could become interesting.

===Obscure Object Oriented Principle===
One does not hear much about Bertrand Meyer’s Principle of Explicit Interfaces. Modern texts such as Head First Design Patterns do not include it. The originator’s text, Object-Oriented Software Construction, presumably defines and explains the principle. At $102.05 on [http://www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/0136291554/ref=sr_1_3?ie=UTF8&s=books&qid=1258483189&sr=1-3 amazon.com], it will remain for others to research. While it appears that the principle has been absorbed into many other object oriented principles and commercial products such as Eiffel’s Contract by Design, the work does stand on its own merit as we will see in this wiki.

===Documentation===
To create an explicit interface for any language, assembler, FORTRAN, object and non-object oriented alike, one can use a technique as old as data processing itself, documentation. Create a document explicitly stating conditions that each module will accept and will produce. 
Assembler language Self Documentation
<pre>
MODULE A:
GLOB* $RES 2 . A two byte quantity passed from Module A to Module B
MODULE B:
GLOB* $RES 2 . A two byte quantity returned from Module B to Module A
</pre>

===Strong Typing===
For strongly typed object oriented languages, some changes to the contract between modules may be evident at compile time. Certain modifications can raise a red flag to the developer making an unwitting change.

===Require and Assure===
Eiffel goes so far to insure explicit interfaces that a language construct exists to facilitate the creation of a well defined and checked interface. 

<pre>
Eiffel example to go here!
</pre>

===Conclusion===
----
Bertrand Meyer’s principle of Explicit Interfaces is so simple that it has been incorporated in many other principles and patterns. So profound and yet obscure due to its simplicity and profound universal acceptance.

===Glossary===
----
Strongly typed – A technique used in many object oriented programming languages which results in compiler errors when a type mismatch occurs.

===References===
----
# Eric Freeman and Elisabeth Freeman. ''Head First Design Patterns''. O’Reilly Media, Inc., 2009. ISBN: 978-0-596-00712-6
# http://www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/0136291554/ref=sr_1_3?ie=UTF8&s=books&qid=1258483189&sr=1-3

CSC/ECE 517 Fall 2009/wiki3 13 RS56

2009-11-18T20:46:16Z

RadioSignal:

''Bertrand Meyer's Principle of Explicit Interfaces states that whenever two modules A and B communicate, this must be obvious from the text of A or B or both. Consider the reasons for this principle, and when it is and is not important to follow it. Because Wikipedia does not have a page on this principle, if you do a good job, you might consider submitting it to Wikipedia.'' 
Bertrand Meyer [[Image:Meyer.jpg]]

===Explicit Interfaces===
----
The definition of Bertrand Meyer’s Principle of Explicit Interfaces states that if two modules must interact, the interaction should be plainly visible. Let’s see what can happen if this is not followed. Assume that module A creates global data with two bytes of resolution. Module B accepts that data and processes it. Now, years later, a programmer is given the task of expanding the resolution of the data to 4 bytes but is unaware that Module B even uses the data. All goes well for months until the module A creates the first three byte value and passes it to module B. Depending upon the criticality of the application, the litigation could become interesting.

===Obscure Object Oriented Principle===
One does not hear much about Bertrand Meyer’s Principle of Explicit Interfaces. Modern texts such as Head First Design Patterns do not include it. The originator’s text, Object-Oriented Software Construction, presumably defines and explains the principle. At $102.05 on [http://www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/0136291554/ref=sr_1_3?ie=UTF8&s=books&qid=1258483189&sr=1-3 amazon.com], it will remain for others to research. While it appears that the principle has been absorbed into many other object oriented principles and commercial products such as Eiffel’s Contract by Design, the work does stand on its own merit as we will see in this wiki.

===Documentation===
To create an explicit interface for any language, assembler, FORTRAN, object and non-object oriented alike, one can use a technique as old as data processing itself, documentation. Create a document explicitly stating conditions that each module will accept and will produce. 
Assembler language Self Documentation
<pre>
MODULE A:
GLOB* $RES 2 . A two byte quantity passed from Module A to Module B
MODULE B:
GLOB* $RES 2 . A two byte quantity returned from Module B to Module A
</pre>

===Strong Typing===
For strongly typed object oriented languages, some changes to the contract between modules may be evident at compile time. Certain modifications can raise a red flag to the developer making an unwitting change.

===Require and Assure===
Eiffel goes so far to insure explicit interfaces that a language construct exists to facilitate the creation of a well defined and checked interface. 

<pre>
Eiffel example to go here!
</pre>

===Conclusion===
----
Bertrand Meyer’s principle of Explicit Interfaces is so simple that it has been incorporated in many other principles and patterns. So profound and yet obscure due to its simplicity and profound universal acceptance.

===Glossary===
----
Strongly typed – A technique used in many object oriented programming languages which results in compiler errors when a type mismatch occurs.

===References===
----
# Eric Freeman and Elisabeth Freeman. ''Head First Design Patterns''. O’Reilly Media, Inc., 2009. ISBN: 978-0-596-00712-6
# http://www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/0136291554/ref=sr_1_3?ie=UTF8&s=books&qid=1258483189&sr=1-3

File:Meyer.jpg

2009-11-18T20:35:10Z

RadioSignal:

CSC/ECE 517 Fall 2009/wiki3 13 RS56

2009-11-18T20:21:34Z

RadioSignal:

''Bertrand Meyer's Principle of Explicit Interfaces states that whenever two modules A and B communicate, this must be obvious from the text of A or B or both. Consider the reasons for this principle, and when it is and is not important to follow it. Because Wikipedia does not have a page on this principle, if you do a good job, you might consider submitting it to Wikipedia.''

===Explicit Interfaces===
----
The definition of Bertrand Meyer’s Principle of Explicit Interfaces states that if two modules must interact, the interaction should be plainly visible. Let’s see what can happen if this is not followed. Assume that module A creates global data with two bytes of resolution. Module B accepts that data and processes it. Now, years later, a programmer is given the task of expanding the resolution of the data to 4 bytes but is unaware that Module B even uses the data. All goes well for months until the module A creates the first three byte value and passes it to module B. Depending upon the criticality of the application, the litigation could become interesting.

===Obscure Object Oriented Principle===
One does not hear much about Bertrand Meyer’s Principle of Explicit Interfaces. Modern texts such as Head First Design Patterns do not include it. The originator’s text, Object-Oriented Software Construction, presumably defines and explains the principle. At $102.05 on [http://www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/0136291554/ref=sr_1_3?ie=UTF8&s=books&qid=1258483189&sr=1-3 amazon.com], it will remain for others to research. While it appears that the principle has been absorbed into many other object oriented principles and commercial products such as Eiffel’s Contract by Design, the work does stand on its own merit as we will see in this wiki.

===Documentation===
To create an explicit interface for any language, assembler, FORTRAN, object and non-object oriented alike, one can use a technique as old as data processing itself, documentation. Create a document explicitly stating conditions that each module will accept and will produce. 
Assembler language Self Documentation
<pre>
MODULE A:
GLOB* $RES 2 . A two byte quantity passed from Module A to Module B
MODULE B:
GLOB* $RES 2 . A two byte quantity returned from Module B to Module A
</pre>

===Strong Typing===
For strongly typed object oriented languages, some changes to the contract between modules may be evident at compile time. Certain modifications can raise a red flag to the developer making an unwitting change.

===Require and Assure===
Eiffel goes so far to insure explicit interfaces that a language construct exists to facilitate the creation of a well defined and checked interface. 

<pre>
Eiffel example to go here!
</pre>

===Conclusion===
----
Bertrand Meyer’s principle of Explicit Interfaces is so simple that it has been incorporated in many other principles and patterns. So profound and yet obscure due to its simplicity and profound universal acceptance.

===Glossary===
----
Strongly typed – A technique used in many object oriented programming languages which results in compiler errors when a type mismatch occurs.

===References===
----
# Eric Freeman and Elisabeth Freeman. ''Head First Design Patterns''. O’Reilly Media, Inc., 2009. ISBN: 978-0-596-00712-6
# http://www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/0136291554/ref=sr_1_3?ie=UTF8&s=books&qid=1258483189&sr=1-3

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-07T19:29:13Z

RadioSignal: /* Perspective on Security */

''Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.''

===Perspective on Security===
----
This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer protecting his intellectual property. The second perspective is that of the data center manager keeping the hackers at bay. The third perspective is that of the programming manager or review team attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”

===Ruby===
From the programmer’s security perspective, Ruby is a nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by clients who will then attempt to get support for the modified product. Work is currently underway on having the ability of converting Ruby source code into Java bytecode through [http://xruby.com XRuby] or [http://jruby.org JRuby], which could then be better protected. Please see the Java discussion below for details of this protection. 
The data center manager’s view of Ruby is less clear. Ruby does have a robust [http://redmine.ruby-lang.org/ Issue Tracking System] which is comforting. The interpreted Ruby source language would also be safely protected from dissemination by layers of servers and firewalls. The potential vulnerability, which is increased by dynamic typing and extending classes, may be mitigated by utilization of the tainted and trusted object features. With the tainted feature, the concept is to not let uncontrolled external input modify a system. We can mark objects tainted that have been affected by external input. Methods, that can dangerously modify a system, can raise an exception if passed a tainted object. The variable $SAFE, determines how much protection Ruby will afford to the executing thread.[1] 
<pre>
#Example of Ruby Tainted Objects
puts "Programs start with $SAFE level = #{$SAFE}"
myTrustedObject = "Data to be protected"
myTrustedObject = "Data to be protected with valid update #1"
$SAFE = 2
myTrustedObject = "Data to be protected with valid update #2"
$SAFE = 3
myTaintedObject = "Tainted data can be destroyed"
puts "Thread at $SAFE level: #{$SAFE} produced myTaintedObject: #{myTaintedObject}"
myTaintedObject = "Tainted data destroyed"
puts "Thread at $SAFE level: #{$SAFE} destroyed myTaintedObject: #{myTaintedObject}"
$SAFE = 4
myTrustedObject = "Data destroyed"
puts myTrustedObject

Programs start with $SAFE level = 0
Thread at $SAFE level: 3 produced myTaintedObject: Tainted data can be destroyed
Thread at $SAFE level: 3 destroyed myTaintedObject: Tainted data destroyed
trust_test.rb:26:in `write': Insecure operation `write' at level 4 (SecurityError)
from trust_test.rb:26:in `puts'
from trust_test.rb:26</pre>

Ruby 1.9 also adds the concept of “Trust”. Here, code itself can be marked untrusted. All objects created by the code will be untrusted and all objects it can modify must also be untrusted. The effect is creating a wall between the untrusted objects and the trusted system.[1] 
<pre>
#It is anticipated that a Ruby Trusted Object example will be placed here; however,
#CSC/ECE 517 is currently using a level of Ruby that does not support this feature.</pre>
The programming manager and review teams also have a mixed-bag here. Ruby, the programmer’s best friend, is touted to provide programming efficiencies. That fact may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. However, extra time must be spent with peer and team reviews. All potentially dangerous code that could have a system impact must be manually analyzed to prevent the instantiation of an unforeseen type which could present a risk to the system. 

===Java===
From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through [http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html obfuscation]. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program. 
The data center manager’s view of Java is one of a tried and tested product. The Java source code is protected by complete separation from the application and database servers. [http://www.sun.com/support/ Security alerts] are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “trusted/untrusted” input feature, Java design conforms to the [http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc1.html “sandbox” model]. All remote code can be isolated and prevented from causing damage to local code and resources. Due to the static typing, there is a peace of mind that all input must conform to downstream types expected and understood by the design architect. 
While it may have taken the programming manager’s staff longer to create a product in a type safe environment, all bugs that could be found at compile time, were indeed found. The bugs and security vulnerabilities lurking due to an unchecked type, will not keep anyone up at night. 

===Conclusion===
----
Ruby gives the programmer dangerous tools which may allow latent vulnerabilities to exist in production code. The programmer and those reviewing his work must have heightened security awareness as to not put their organization at risk.

===Glossary===
----
Bytecode – An intermediate result from a programming language intended to be processed by a virtual machine and not directly by the underlying computer hardware 
Interpreted Code – The technique of directly processing programming language source text and delivering results without the intermediate steps of producing virtual machine bytecode or hardware dependent object code 
Obfuscation – The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer 
Tainted Object – Any Ruby object derived from some external source is automatically marked as being tainted. 
Trusted Object – A Ruby object, created by code running at $SAFE levels 0, 1 or 2, which cannot be modified by code running at $SAFE levels 3 or 4. 

===References===
----
# Dave Thomas, Chad Fowler and Andy Hunt. ''Programming Ruby 1.9'', chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5
# http://xruby.com
# http://jruby.org
# http://redmine.ruby-lang.org
# http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html
# http://www.sun.com/support
# http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc1.html

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-07T19:27:35Z

RadioSignal: /* Ruby */

''Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.''

===Perspective on Security===
----
This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer; protecting intellectual property. The second perspective is that of the data center manager; keeping the hackers at bay. The third perspective is that of the programming manager or review team attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”

===Ruby===
From the programmer’s security perspective, Ruby is a nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by clients who will then attempt to get support for the modified product. Work is currently underway on having the ability of converting Ruby source code into Java bytecode through [http://xruby.com XRuby] or [http://jruby.org JRuby], which could then be better protected. Please see the Java discussion below for details of this protection. 
The data center manager’s view of Ruby is less clear. Ruby does have a robust [http://redmine.ruby-lang.org/ Issue Tracking System] which is comforting. The interpreted Ruby source language would also be safely protected from dissemination by layers of servers and firewalls. The potential vulnerability, which is increased by dynamic typing and extending classes, may be mitigated by utilization of the tainted and trusted object features. With the tainted feature, the concept is to not let uncontrolled external input modify a system. We can mark objects tainted that have been affected by external input. Methods, that can dangerously modify a system, can raise an exception if passed a tainted object. The variable $SAFE, determines how much protection Ruby will afford to the executing thread.[1] 
<pre>
#Example of Ruby Tainted Objects
puts "Programs start with $SAFE level = #{$SAFE}"
myTrustedObject = "Data to be protected"
myTrustedObject = "Data to be protected with valid update #1"
$SAFE = 2
myTrustedObject = "Data to be protected with valid update #2"
$SAFE = 3
myTaintedObject = "Tainted data can be destroyed"
puts "Thread at $SAFE level: #{$SAFE} produced myTaintedObject: #{myTaintedObject}"
myTaintedObject = "Tainted data destroyed"
puts "Thread at $SAFE level: #{$SAFE} destroyed myTaintedObject: #{myTaintedObject}"
$SAFE = 4
myTrustedObject = "Data destroyed"
puts myTrustedObject

Programs start with $SAFE level = 0
Thread at $SAFE level: 3 produced myTaintedObject: Tainted data can be destroyed
Thread at $SAFE level: 3 destroyed myTaintedObject: Tainted data destroyed
trust_test.rb:26:in `write': Insecure operation `write' at level 4 (SecurityError)
from trust_test.rb:26:in `puts'
from trust_test.rb:26</pre>

Ruby 1.9 also adds the concept of “Trust”. Here, code itself can be marked untrusted. All objects created by the code will be untrusted and all objects it can modify must also be untrusted. The effect is creating a wall between the untrusted objects and the trusted system.[1] 
<pre>
#It is anticipated that a Ruby Trusted Object example will be placed here; however,
#CSC/ECE 517 is currently using a level of Ruby that does not support this feature.</pre>
The programming manager and review teams also have a mixed-bag here. Ruby, the programmer’s best friend, is touted to provide programming efficiencies. That fact may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. However, extra time must be spent with peer and team reviews. All potentially dangerous code that could have a system impact must be manually analyzed to prevent the instantiation of an unforeseen type which could present a risk to the system. 

===Java===
From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through [http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html obfuscation]. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program. 
The data center manager’s view of Java is one of a tried and tested product. The Java source code is protected by complete separation from the application and database servers. [http://www.sun.com/support/ Security alerts] are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “trusted/untrusted” input feature, Java design conforms to the [http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc1.html “sandbox” model]. All remote code can be isolated and prevented from causing damage to local code and resources. Due to the static typing, there is a peace of mind that all input must conform to downstream types expected and understood by the design architect. 
While it may have taken the programming manager’s staff longer to create a product in a type safe environment, all bugs that could be found at compile time, were indeed found. The bugs and security vulnerabilities lurking due to an unchecked type, will not keep anyone up at night. 

===Conclusion===
----
Ruby gives the programmer dangerous tools which may allow latent vulnerabilities to exist in production code. The programmer and those reviewing his work must have heightened security awareness as to not put their organization at risk.

===Glossary===
----
Bytecode – An intermediate result from a programming language intended to be processed by a virtual machine and not directly by the underlying computer hardware 
Interpreted Code – The technique of directly processing programming language source text and delivering results without the intermediate steps of producing virtual machine bytecode or hardware dependent object code 
Obfuscation – The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer 
Tainted Object – Any Ruby object derived from some external source is automatically marked as being tainted. 
Trusted Object – A Ruby object, created by code running at $SAFE levels 0, 1 or 2, which cannot be modified by code running at $SAFE levels 3 or 4. 

===References===
----
# Dave Thomas, Chad Fowler and Andy Hunt. ''Programming Ruby 1.9'', chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5
# http://xruby.com
# http://jruby.org
# http://redmine.ruby-lang.org
# http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html
# http://www.sun.com/support
# http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc1.html

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-07T01:22:57Z

RadioSignal: /* Ruby */

''Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.''

===Perspective on Security===
----
This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer; protecting intellectual property. The second perspective is that of the data center manager; keeping the hackers at bay. The third perspective is that of the programming manager or review team attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”

===Ruby===
From the programmer’s security perspective, Ruby is a nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by clients who will then attempt to get support for the modified product. Work is currently underway on the potential of converting the Ruby source code into Java bytecode through [http://xruby.com XRuby] or [http://jruby.org JRuby] which could then be better protected. Please see the Java discussion below for details of this protection. 
The data center manager’s view of Ruby is less clear. Ruby does have a robust [http://redmine.ruby-lang.org/ Issue Tracking System] which is comforting. The interpreted Ruby source language would also be safely protected from dissemination by layers of servers and firewalls. The potential vulnerability, which is increased by dynamic typing and extending classes, may be mitigated by utilization of the tainted and trusted object features. With the tainted feature, the concept is to not let uncontrolled external input modify a system. We can mark objects tainted that have been affected by external input. Methods, that can dangerously modify a system, can raise an exception if passed a tainted object. The variable $SAFE, determines how much protection Ruby will afford to the executing thread.[1] 
<pre>
puts "Programs start with $SAFE level = #{$SAFE}"
myTrustedObject = "Data to be protected"
myTrustedObject = "Data to be protected with valid update #1"
$SAFE = 2
myTrustedObject = "Data to be protected with valid update #2"
$SAFE = 3
myTaintedObject = "Tainted data can be destroyed"
puts "Thread at $SAFE level: #{$SAFE} produced myTaintedObject: #{myTaintedObject}"
myTaintedObject = "Tainted data destroyed"
puts "Thread at $SAFE level: #{$SAFE} destroyed myTaintedObject: #{myTaintedObject}"
$SAFE = 4
myTrustedObject = "Data destroyed"
puts myTrustedObject

Programs start with $SAFE level = 0
Thread at $SAFE level: 3 produced myTaintedObject: Tainted data can be destroyed
Thread at $SAFE level: 3 destroyed myTaintedObject: Tainted data destroyed
trust_test.rb:26:in `write': Insecure operation `write' at level 4 (SecurityError)
from trust_test.rb:26:in `puts'
from trust_test.rb:26</pre>

Ruby 1.9 also adds the concept of “Trust”. Here, code itself can be marked untrusted. All objects created by the code will be untrusted and all objects it can modify must also be untrusted. The effect is creating a wall between the untrusted objects and the trusted system.[1] 
The programming manager and review teams also have a mixed-bag here. Ruby, the programmer’s best friend, is touted to provide programming efficiencies. That fact may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. However, extra time must be spent with peer and team reviews. All potentially dangerous code that could have a system impact must be manually analyzed to prevent the instantiation of an unforeseen type which could present a risk to the system. 

===Java===
From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through [http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html obfuscation]. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program. 
The data center manager’s view of Java is one of a tried and tested product. The Java source code is protected by complete separation from the application and database servers. [http://www.sun.com/support/ Security alerts] are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “trusted/untrusted” input feature, Java design conforms to the [http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc1.html “sandbox” model]. All remote code can be isolated and prevented from causing damage to local code and resources. Due to the static typing, there is a peace of mind that all input must conform to downstream types expected and understood by the design architect. 
While it may have taken the programming manager’s staff longer to create a product in a type safe environment, all bugs that could be found at compile time, were indeed found. The bugs and security vulnerabilities lurking due to an unchecked type, will not keep anyone up at night. 

===Conclusion===
----
Ruby gives the programmer dangerous tools which may allow latent vulnerabilities to exist in production code. The programmer and those reviewing his work must have heightened security awareness as to not put their organization at risk.

===Glossary===
----
Bytecode – An intermediate result from a programming language intended to be processed by a virtual machine and not directly by the underlying computer hardware 
Interpreted Code – The technique of directly processing programming language source text and delivering results without the intermediate steps of producing virtual machine bytecode or hardware dependent object code 
Obfuscation – The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer 
Tainted Object – Any Ruby object derived from some external source is automatically marked as being tainted. 
Trusted Object – A Ruby object, created by code running at $SAFE levels 0, 1 or 2, which cannot be modified by code running at $SAFE levels 3 or 4. 

===References===
----
# Dave Thomas, Chad Fowler and Andy Hunt. ''Programming Ruby 1.9'', chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5
# http://xruby.com
# http://jruby.org
# http://redmine.ruby-lang.org
# http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html
# http://www.sun.com/support
# http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc1.html

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-06T16:07:36Z

RadioSignal: /* References */

''Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.''

===Perspective on Security===
----
This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer; protecting intellectual property. The second perspective is that of the data center manager; keeping the hackers at bay. The third perspective is that of the programming manager or review team attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”

===Ruby===
From the programmer’s security perspective, Ruby is a nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by clients who will then attempt to get support for the modified product. Work is currently underway on the potential of converting the Ruby source code into Java bytecode through [http://xruby.com XRuby] or [http://jruby.org JRuby] which could then be better protected. Please see the Java discussion below for details of this protection. 
The data center manager’s view of Ruby is less clear. Ruby does have a robust [http://redmine.ruby-lang.org/ Issue Tracking System] which is comforting. The interpreted Ruby source language would also be safely protected from dissemination by layers of servers and firewalls. The potential vulnerability, which is increased by dynamic typing and extending classes, may be mitigated by utilization of the tainted and trusted object features. With the tainted feature, the concept is to not let uncontrolled external input modify a system. We can mark objects tainted that have been affected by external input. Methods, that can dangerously modify a system, can raise an exception if passed a tainted object. The variable $SAFE, determines how much protection Ruby will afford to the executing thread. Ruby 1.9 also adds the concept of “Trust”. Here, code itself can be marked untrusted. All objects created by the code will be untrusted and all objects it can modify must also be untrusted. The effect is creating a wall between the untrusted objects and the trusted system.[1] 
The programming manager and review teams also have a mixed-bag here. Ruby, the programmer’s best friend, is touted to provide programming efficiencies. That fact may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. However, extra time must be spent with peer and team reviews. All potentially dangerous code that could have a system impact must be manually analyzed to prevent the instantiation of an unforeseen type which could present a risk to the system. 

===Java===
From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through [http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html obfuscation]. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program. 
The data center manager’s view of Java is one of a tried and tested product. The Java source code is protected by complete separation from the application and database servers. [http://www.sun.com/support/ Security alerts] are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “trusted/untrusted” input feature, Java design conforms to the [http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc1.html “sandbox” model]. All remote code can be isolated and prevented from causing damage to local code and resources. Due to the static typing, there is a peace of mind that all input must conform to downstream types expected and understood by the design architect. 
While it may have taken the programming manager’s staff longer to create a product in a type safe environment, all bugs that could be found at compile time, were indeed found. The bugs and security vulnerabilities lurking due to an unchecked type, will not keep anyone up at night. 

===Conclusion===
----
Ruby gives the programmer dangerous tools which may allow latent vulnerabilities to exist in production code. The programmer and those reviewing his work must have heightened security awareness as to not put their organization at risk.

===Glossary===
----
Bytecode – An intermediate result from a programming language intended to be processed by a virtual machine and not directly by the underlying computer hardware 
Interpreted Code – The technique of directly processing programming language source text and delivering results without the intermediate steps of producing virtual machine bytecode or hardware dependent object code 
Obfuscation – The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer 
Tainted Object – Any Ruby object derived from some external source is automatically marked as being tainted. 
Trusted Object – A Ruby object, created by code running at $SAFE levels 0, 1 or 2, which cannot be modified by code running at $SAFE levels 3 or 4. 

===References===
----
# Dave Thomas, Chad Fowler and Andy Hunt. ''Programming Ruby 1.9'', chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5
# http://xruby.com
# http://jruby.org
# http://redmine.ruby-lang.org
# http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html
# http://www.sun.com/support
# http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc1.html

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-06T16:05:56Z

RadioSignal: /* Java */

''Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.''

===Perspective on Security===
----
This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer; protecting intellectual property. The second perspective is that of the data center manager; keeping the hackers at bay. The third perspective is that of the programming manager or review team attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”

===Ruby===
From the programmer’s security perspective, Ruby is a nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by clients who will then attempt to get support for the modified product. Work is currently underway on the potential of converting the Ruby source code into Java bytecode through [http://xruby.com XRuby] or [http://jruby.org JRuby] which could then be better protected. Please see the Java discussion below for details of this protection. 
The data center manager’s view of Ruby is less clear. Ruby does have a robust [http://redmine.ruby-lang.org/ Issue Tracking System] which is comforting. The interpreted Ruby source language would also be safely protected from dissemination by layers of servers and firewalls. The potential vulnerability, which is increased by dynamic typing and extending classes, may be mitigated by utilization of the tainted and trusted object features. With the tainted feature, the concept is to not let uncontrolled external input modify a system. We can mark objects tainted that have been affected by external input. Methods, that can dangerously modify a system, can raise an exception if passed a tainted object. The variable $SAFE, determines how much protection Ruby will afford to the executing thread. Ruby 1.9 also adds the concept of “Trust”. Here, code itself can be marked untrusted. All objects created by the code will be untrusted and all objects it can modify must also be untrusted. The effect is creating a wall between the untrusted objects and the trusted system.[1] 
The programming manager and review teams also have a mixed-bag here. Ruby, the programmer’s best friend, is touted to provide programming efficiencies. That fact may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. However, extra time must be spent with peer and team reviews. All potentially dangerous code that could have a system impact must be manually analyzed to prevent the instantiation of an unforeseen type which could present a risk to the system. 

===Java===
From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through [http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html obfuscation]. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program. 
The data center manager’s view of Java is one of a tried and tested product. The Java source code is protected by complete separation from the application and database servers. [http://www.sun.com/support/ Security alerts] are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “trusted/untrusted” input feature, Java design conforms to the [http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc1.html “sandbox” model]. All remote code can be isolated and prevented from causing damage to local code and resources. Due to the static typing, there is a peace of mind that all input must conform to downstream types expected and understood by the design architect. 
While it may have taken the programming manager’s staff longer to create a product in a type safe environment, all bugs that could be found at compile time, were indeed found. The bugs and security vulnerabilities lurking due to an unchecked type, will not keep anyone up at night. 

===Conclusion===
----
Ruby gives the programmer dangerous tools which may allow latent vulnerabilities to exist in production code. The programmer and those reviewing his work must have heightened security awareness as to not put their organization at risk.

===Glossary===
----
Bytecode – An intermediate result from a programming language intended to be processed by a virtual machine and not directly by the underlying computer hardware 
Interpreted Code – The technique of directly processing programming language source text and delivering results without the intermediate steps of producing virtual machine bytecode or hardware dependent object code 
Obfuscation – The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer 
Tainted Object – Any Ruby object derived from some external source is automatically marked as being tainted. 
Trusted Object – A Ruby object, created by code running at $SAFE levels 0, 1 or 2, which cannot be modified by code running at $SAFE levels 3 or 4. 

===References===
----
# Dave Thomas, Chad Fowler and Andy Hunt. ''Programming Ruby 1.9'', chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-06T16:05:12Z

RadioSignal: /* Ruby */

''Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.''

===Perspective on Security===
----
This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer; protecting intellectual property. The second perspective is that of the data center manager; keeping the hackers at bay. The third perspective is that of the programming manager or review team attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”

===Ruby===
From the programmer’s security perspective, Ruby is a nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by clients who will then attempt to get support for the modified product. Work is currently underway on the potential of converting the Ruby source code into Java bytecode through [http://xruby.com XRuby] or [http://jruby.org JRuby] which could then be better protected. Please see the Java discussion below for details of this protection. 
The data center manager’s view of Ruby is less clear. Ruby does have a robust [http://redmine.ruby-lang.org/ Issue Tracking System] which is comforting. The interpreted Ruby source language would also be safely protected from dissemination by layers of servers and firewalls. The potential vulnerability, which is increased by dynamic typing and extending classes, may be mitigated by utilization of the tainted and trusted object features. With the tainted feature, the concept is to not let uncontrolled external input modify a system. We can mark objects tainted that have been affected by external input. Methods, that can dangerously modify a system, can raise an exception if passed a tainted object. The variable $SAFE, determines how much protection Ruby will afford to the executing thread. Ruby 1.9 also adds the concept of “Trust”. Here, code itself can be marked untrusted. All objects created by the code will be untrusted and all objects it can modify must also be untrusted. The effect is creating a wall between the untrusted objects and the trusted system.[1] 
The programming manager and review teams also have a mixed-bag here. Ruby, the programmer’s best friend, is touted to provide programming efficiencies. That fact may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. However, extra time must be spent with peer and team reviews. All potentially dangerous code that could have a system impact must be manually analyzed to prevent the instantiation of an unforeseen type which could present a risk to the system. 

===Java===
----
From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through [http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html obfuscation]. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program. 
The data center manager view of Java is one of a tried and tested product. The Java source code is protected by complete separation from the application and database servers. [http://www.sun.com/support/ Security alerts] are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “trusted/untrusted” input feature, Java design conforms to the [http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc1.html “sandbox” model]. All remote code can be isolated and prevented from causing damage to local code and resources. Due to the static typing, there is a peace of mind that all input must conform to downstream types expected and understood by the design architect. 
While it may have taken the programming manager’s staff longer to create a product in a type safe environment, all bugs that could be found at compile time, were indeed found. The bugs and security vulnerabilities lurking due to an unchecked type, will not keep anyone up at night. 

===Conclusion===
----
Ruby gives the programmer dangerous tools which may allow latent vulnerabilities to exist in production code. The programmer and those reviewing his work must have heightened security awareness as to not put their organization at risk.

===Glossary===
----
Bytecode – An intermediate result from a programming language intended to be processed by a virtual machine and not directly by the underlying computer hardware 
Interpreted Code – The technique of directly processing programming language source text and delivering results without the intermediate steps of producing virtual machine bytecode or hardware dependent object code 
Obfuscation – The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer 
Tainted Object – Any Ruby object derived from some external source is automatically marked as being tainted. 
Trusted Object – A Ruby object, created by code running at $SAFE levels 0, 1 or 2, which cannot be modified by code running at $SAFE levels 3 or 4. 

===References===
----
# Dave Thomas, Chad Fowler and Andy Hunt. ''Programming Ruby 1.9'', chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-06T15:43:14Z

RadioSignal: /* Java */

''Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.''

===Perspective on Security===
----
This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer; protecting intellectual property. The second perspective is that of the data center manager; keeping the hackers at bay. The third perspective is that of the programming manager or review team attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”

===Ruby===
----
From the programmer’s security perspective, Ruby is a nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by clients who will then attempt to get support for the modified product. Work is currently underway on the potential of converting the Ruby source code into Java bytecode through [http://xruby.com XRuby] or [http://jruby.org JRuby] which could then be better protected. Please see the Java discussion below for details of this protection. 
The data center manager’s view of Ruby is less clear. Ruby does have a robust [http://redmine.ruby-lang.org/ Issue Tracking System] which is comforting. The interpreted Ruby source language would also be safely protected from dissemination by layers of servers and firewalls. The potential vulnerability, which is increased by dynamic typing and extending classes, may be mitigated by utilization of the tainted and trusted object features. With the tainted feature, the concept is to not let uncontrolled external input modify a system. We can mark objects tainted that have been affected by external input. Methods, that can dangerously modify a system, can raise an exception if passed a tainted object. The variable $SAFE, determines how much protection Ruby will afford to the executing thread. Ruby 1.9 also adds the concept of “Trust”. Here, code itself can be marked untrusted. All objects created by the code will be untrusted and all objects it can modify must also be untrusted. The effect is creating a wall between the untrusted objects and the trusted system.[1] 
The programming manager and review teams also have a mixed-bag here. Ruby, the programmer’s best friend, is touted to provide programming efficiencies. That fact may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. However, extra time must be spent with peer and team reviews. All potentially dangerous code that could have a system impact must be manually analyzed to prevent the instantiation of an unforeseen type which could present a risk to the system. 

===Java===
----
From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through [http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html obfuscation]. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program. 
The data center manager view of Java is one of a tried and tested product. The Java source code is protected by complete separation from the application and database servers. [http://www.sun.com/support/ Security alerts] are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “trusted/untrusted” input feature, Java design conforms to the [http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc1.html “sandbox” model]. All remote code can be isolated and prevented from causing damage to local code and resources. Due to the static typing, there is a peace of mind that all input must conform to downstream types expected and understood by the design architect. 
While it may have taken the programming manager’s staff longer to create a product in a type safe environment, all bugs that could be found at compile time, were indeed found. The bugs and security vulnerabilities lurking due to an unchecked type, will not keep anyone up at night. 

===Conclusion===
----
Ruby gives the programmer dangerous tools which may allow latent vulnerabilities to exist in production code. The programmer and those reviewing his work must have heightened security awareness as to not put their organization at risk.

===Glossary===
----
Bytecode – An intermediate result from a programming language intended to be processed by a virtual machine and not directly by the underlying computer hardware 
Interpreted Code – The technique of directly processing programming language source text and delivering results without the intermediate steps of producing virtual machine bytecode or hardware dependent object code 
Obfuscation – The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer 
Tainted Object – Any Ruby object derived from some external source is automatically marked as being tainted. 
Trusted Object – A Ruby object, created by code running at $SAFE levels 0, 1 or 2, which cannot be modified by code running at $SAFE levels 3 or 4. 

===References===
----
# Dave Thomas, Chad Fowler and Andy Hunt. ''Programming Ruby 1.9'', chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-06T15:14:24Z

RadioSignal: /* Glossary */

''Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.''

===Perspective on Security===
----
This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer; protecting intellectual property. The second perspective is that of the data center manager; keeping the hackers at bay. The third perspective is that of the programming manager or review team attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”

===Ruby===
----
From the programmer’s security perspective, Ruby is a nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by clients who will then attempt to get support for the modified product. Work is currently underway on the potential of converting the Ruby source code into Java bytecode through [http://xruby.com XRuby] or [http://jruby.org JRuby] which could then be better protected. Please see the Java discussion below for details of this protection. 
The data center manager’s view of Ruby is less clear. Ruby does have a robust [http://redmine.ruby-lang.org/ Issue Tracking System] which is comforting. The interpreted Ruby source language would also be safely protected from dissemination by layers of servers and firewalls. The potential vulnerability, which is increased by dynamic typing and extending classes, may be mitigated by utilization of the tainted and trusted object features. With the tainted feature, the concept is to not let uncontrolled external input modify a system. We can mark objects tainted that have been affected by external input. Methods, that can dangerously modify a system, can raise an exception if passed a tainted object. The variable $SAFE, determines how much protection Ruby will afford to the executing thread. Ruby 1.9 also adds the concept of “Trust”. Here, code itself can be marked untrusted. All objects created by the code will be untrusted and all objects it can modify must also be untrusted. The effect is creating a wall between the untrusted objects and the trusted system.[1] 
The programming manager and review teams also have a mixed-bag here. Ruby, the programmer’s best friend, is touted to provide programming efficiencies. That fact may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. However, extra time must be spent with peer and team reviews. All potentially dangerous code that could have a system impact must be manually analyzed to prevent the instantiation of an unforeseen type which could present a risk to the system. 

===Java===
----
From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through [http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html obfuscation]. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program. 
The data center manager view of Java is one of a tried and tested product. The Java source code is protected by complete separation from the application and database servers. [http://www.sun.com/support/ Security alerts] are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “trusted/untrusted” input feature, there is peace of mind that all input must conform to all downstream types expected and understood by the design architect. 
While it may have taken the programming manager’s staff longer to create a product in a type safe environment, the peace of mind that every bug that could be found at compile time was indeed found is priceless. The bugs and security vulnerabilities lurking due to an unchecked type will keep one up at night. 

===Conclusion===
----
Ruby gives the programmer dangerous tools which may allow latent vulnerabilities to exist in production code. The programmer and those reviewing his work must have heightened security awareness as to not put their organization at risk.

===Glossary===
----
Bytecode – An intermediate result from a programming language intended to be processed by a virtual machine and not directly by the underlying computer hardware 
Interpreted Code – The technique of directly processing programming language source text and delivering results without the intermediate steps of producing virtual machine bytecode or hardware dependent object code 
Obfuscation – The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer 
Tainted Object – Any Ruby object derived from some external source is automatically marked as being tainted. 
Trusted Object – A Ruby object, created by code running at $SAFE levels 0, 1 or 2, which cannot be modified by code running at $SAFE levels 3 or 4. 

===References===
----
# Dave Thomas, Chad Fowler and Andy Hunt. ''Programming Ruby 1.9'', chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-06T14:52:48Z

RadioSignal: /* Glossary */

''Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.''

===Perspective on Security===
----
This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer; protecting intellectual property. The second perspective is that of the data center manager; keeping the hackers at bay. The third perspective is that of the programming manager or review team attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”

===Ruby===
----
From the programmer’s security perspective, Ruby is a nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by clients who will then attempt to get support for the modified product. Work is currently underway on the potential of converting the Ruby source code into Java bytecode through [http://xruby.com XRuby] or [http://jruby.org JRuby] which could then be better protected. Please see the Java discussion below for details of this protection. 
The data center manager’s view of Ruby is less clear. Ruby does have a robust [http://redmine.ruby-lang.org/ Issue Tracking System] which is comforting. The interpreted Ruby source language would also be safely protected from dissemination by layers of servers and firewalls. The potential vulnerability, which is increased by dynamic typing and extending classes, may be mitigated by utilization of the tainted and trusted object features. With the tainted feature, the concept is to not let uncontrolled external input modify a system. We can mark objects tainted that have been affected by external input. Methods, that can dangerously modify a system, can raise an exception if passed a tainted object. The variable $SAFE, determines how much protection Ruby will afford to the executing thread. Ruby 1.9 also adds the concept of “Trust”. Here, code itself can be marked untrusted. All objects created by the code will be untrusted and all objects it can modify must also be untrusted. The effect is creating a wall between the untrusted objects and the trusted system.[1] 
The programming manager and review teams also have a mixed-bag here. Ruby, the programmer’s best friend, is touted to provide programming efficiencies. That fact may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. However, extra time must be spent with peer and team reviews. All potentially dangerous code that could have a system impact must be manually analyzed to prevent the instantiation of an unforeseen type which could present a risk to the system. 

===Java===
----
From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through [http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html obfuscation]. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program. 
The data center manager view of Java is one of a tried and tested product. The Java source code is protected by complete separation from the application and database servers. [http://www.sun.com/support/ Security alerts] are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “trusted/untrusted” input feature, there is peace of mind that all input must conform to all downstream types expected and understood by the design architect. 
While it may have taken the programming manager’s staff longer to create a product in a type safe environment, the peace of mind that every bug that could be found at compile time was indeed found is priceless. The bugs and security vulnerabilities lurking due to an unchecked type will keep one up at night. 

===Conclusion===
----
Ruby gives the programmer dangerous tools which may allow latent vulnerabilities to exist in production code. The programmer and those reviewing his work must have heightened security awareness as to not put their organization at risk.

===Glossary===
----
Bytecode – An intermediate result from a programming language intended to be processed by a virtual machine and not the underlying computer hardware. 
Interpreted – In this context, interpreted code refers to the technique of directly processing a source text programming language and delivering results without the intermediate steps of producing virtual machine bytecode or hardware dependent object code. 
Obfuscation - The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer. 
Tainted – Any Ruby object derived from some external source is automatically marked as being tainted. 
Trusted – An object, not created by the running program that cannot be modified by the program. 

===References===
----
# Dave Thomas, Chad Fowler and Andy Hunt. ''Programming Ruby 1.9'', chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-06T14:47:39Z

RadioSignal: /* Conclusion */

''Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.''

===Perspective on Security===
----
This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer; protecting intellectual property. The second perspective is that of the data center manager; keeping the hackers at bay. The third perspective is that of the programming manager or review team attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”

===Ruby===
----
From the programmer’s security perspective, Ruby is a nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by clients who will then attempt to get support for the modified product. Work is currently underway on the potential of converting the Ruby source code into Java bytecode through [http://xruby.com XRuby] or [http://jruby.org JRuby] which could then be better protected. Please see the Java discussion below for details of this protection. 
The data center manager’s view of Ruby is less clear. Ruby does have a robust [http://redmine.ruby-lang.org/ Issue Tracking System] which is comforting. The interpreted Ruby source language would also be safely protected from dissemination by layers of servers and firewalls. The potential vulnerability, which is increased by dynamic typing and extending classes, may be mitigated by utilization of the tainted and trusted object features. With the tainted feature, the concept is to not let uncontrolled external input modify a system. We can mark objects tainted that have been affected by external input. Methods, that can dangerously modify a system, can raise an exception if passed a tainted object. The variable $SAFE, determines how much protection Ruby will afford to the executing thread. Ruby 1.9 also adds the concept of “Trust”. Here, code itself can be marked untrusted. All objects created by the code will be untrusted and all objects it can modify must also be untrusted. The effect is creating a wall between the untrusted objects and the trusted system.[1] 
The programming manager and review teams also have a mixed-bag here. Ruby, the programmer’s best friend, is touted to provide programming efficiencies. That fact may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. However, extra time must be spent with peer and team reviews. All potentially dangerous code that could have a system impact must be manually analyzed to prevent the instantiation of an unforeseen type which could present a risk to the system. 

===Java===
----
From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through [http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html obfuscation]. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program. 
The data center manager view of Java is one of a tried and tested product. The Java source code is protected by complete separation from the application and database servers. [http://www.sun.com/support/ Security alerts] are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “trusted/untrusted” input feature, there is peace of mind that all input must conform to all downstream types expected and understood by the design architect. 
While it may have taken the programming manager’s staff longer to create a product in a type safe environment, the peace of mind that every bug that could be found at compile time was indeed found is priceless. The bugs and security vulnerabilities lurking due to an unchecked type will keep one up at night. 

===Conclusion===
----
Ruby gives the programmer dangerous tools which may allow latent vulnerabilities to exist in production code. The programmer and those reviewing his work must have heightened security awareness as to not put their organization at risk.

===Glossary===
----
Bytecode – An intermediate result from a programming language intended to be processed by a virtual machine and not the underlying computer hardware. 
Interpreted – In this context, interpreted code refers to the technique of directly processing a source text programming language and delivering results without the intermediate steps of producing virtual machine bytecode or hardware dependent object code 
Obfuscation - The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer. 
Tainted – Any Ruby object derived from some external source is automatically marked as being tainted [1] 
Trusted – An object, not created by the running program that cannot be modified by the program. [1] 
Untrusted – Any object created by the executing program which is allowed to be modified by the program. [1] 

===References===
----
# Dave Thomas, Chad Fowler and Andy Hunt. ''Programming Ruby 1.9'', chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-06T14:45:48Z

RadioSignal: /* Ruby */

''Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.''

===Perspective on Security===
----
This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer; protecting intellectual property. The second perspective is that of the data center manager; keeping the hackers at bay. The third perspective is that of the programming manager or review team attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”

===Ruby===
----
From the programmer’s security perspective, Ruby is a nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by clients who will then attempt to get support for the modified product. Work is currently underway on the potential of converting the Ruby source code into Java bytecode through [http://xruby.com XRuby] or [http://jruby.org JRuby] which could then be better protected. Please see the Java discussion below for details of this protection. 
The data center manager’s view of Ruby is less clear. Ruby does have a robust [http://redmine.ruby-lang.org/ Issue Tracking System] which is comforting. The interpreted Ruby source language would also be safely protected from dissemination by layers of servers and firewalls. The potential vulnerability, which is increased by dynamic typing and extending classes, may be mitigated by utilization of the tainted and trusted object features. With the tainted feature, the concept is to not let uncontrolled external input modify a system. We can mark objects tainted that have been affected by external input. Methods, that can dangerously modify a system, can raise an exception if passed a tainted object. The variable $SAFE, determines how much protection Ruby will afford to the executing thread. Ruby 1.9 also adds the concept of “Trust”. Here, code itself can be marked untrusted. All objects created by the code will be untrusted and all objects it can modify must also be untrusted. The effect is creating a wall between the untrusted objects and the trusted system.[1] 
The programming manager and review teams also have a mixed-bag here. Ruby, the programmer’s best friend, is touted to provide programming efficiencies. That fact may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. However, extra time must be spent with peer and team reviews. All potentially dangerous code that could have a system impact must be manually analyzed to prevent the instantiation of an unforeseen type which could present a risk to the system. 

===Java===
----
From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through [http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html obfuscation]. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program. 
The data center manager view of Java is one of a tried and tested product. The Java source code is protected by complete separation from the application and database servers. [http://www.sun.com/support/ Security alerts] are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “trusted/untrusted” input feature, there is peace of mind that all input must conform to all downstream types expected and understood by the design architect. 
While it may have taken the programming manager’s staff longer to create a product in a type safe environment, the peace of mind that every bug that could be found at compile time was indeed found is priceless. The bugs and security vulnerabilities lurking due to an unchecked type will keep one up at night. 

===Conclusion===
----
Ruby gives the programmer more dangerous tools to leave latent vulnerabilities in production code. The programmer and those reviewing his work must have heightened security awareness as to not put their organization at risk.

===Glossary===
----
Bytecode – An intermediate result from a programming language intended to be processed by a virtual machine and not the underlying computer hardware. 
Interpreted – In this context, interpreted code refers to the technique of directly processing a source text programming language and delivering results without the intermediate steps of producing virtual machine bytecode or hardware dependent object code 
Obfuscation - The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer. 
Tainted – Any Ruby object derived from some external source is automatically marked as being tainted [1] 
Trusted – An object, not created by the running program that cannot be modified by the program. [1] 
Untrusted – Any object created by the executing program which is allowed to be modified by the program. [1] 

===References===
----
# Dave Thomas, Chad Fowler and Andy Hunt. ''Programming Ruby 1.9'', chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-05T18:15:05Z

RadioSignal: /* References */

''Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.''

===Perspective on Security===
----
This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer; protecting intellectual property. The second perspective is that of the data center manager; keeping the hackers at bay. The third perspective is that of the programming manager or review team attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”

===Ruby===
----
From the programmer’s security perspective, Ruby is a nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by clients who will then attempt to get support for the modified product. Work is currently underway on the potential of converting the Ruby source code into Java bytecode through [http://xruby.com XRuby] or [http://jruby.org JRuby] which could then be better protected. Please see the Java discussion below for details of this protection. 
The data center manager’s view of Ruby is less clear. Ruby does have a robust [http://redmine.ruby-lang.org/ Issue Tracking System] which is comforting. The interpreted Ruby source language would also be safely protected from dissemination by layers of servers and firewalls. The potential vulnerability, which is increased by dynamic typing and extending classes, may be mitigated by utilization of the tainted and trusted object features. Here, the concept is to not let uncontrolled external input modify a system. We can mark objects tainted that have been affected by external input. Methods, that can dangerously modify a system, can raise an exception if passed a tainted object. [1] 
The programming manager or supervisor also has a mixed-bag here. Ruby, the programmer’s best friend, is touted to provide programming efficiencies that may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. However, extra time must be spent with peer and team reviews on any potentially dangerous code could have a system impact from the instantiation of an unforeseen type. 

===Java===
----
From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through [http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html obfuscation]. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program. 
The data center manager view of Java is one of a tried and tested product. The Java source code is protected by complete separation from the application and database servers. [http://www.sun.com/support/ Security alerts] are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “trusted/untrusted” input feature, there is peace of mind that all input must conform to all downstream types expected and understood by the design architect. 
While it may have taken the programming manager’s staff longer to create a product in a type safe environment, the peace of mind that every bug that could be found at compile time was indeed found is priceless. The bugs and security vulnerabilities lurking due to an unchecked type will keep one up at night. 

===Conclusion===
----
Ruby gives the programmer more dangerous tools to leave latent vulnerabilities in production code. The programmer and those reviewing his work must have heightened security awareness as to not put their organization at risk.

===Glossary===
----
Bytecode – An intermediate result from a programming language intended to be processed by a virtual machine and not the underlying computer hardware. 
Interpreted – In this context, interpreted code refers to the technique of directly processing a source text programming language and delivering results without the intermediate steps of producing virtual machine bytecode or hardware dependent object code 
Obfuscation - The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer. 
Tainted – Any Ruby object derived from some external source is automatically marked as being tainted [1] 
Trusted – An object, not created by the running program that cannot be modified by the program. [1] 
Untrusted – Any object created by the executing program which is allowed to be modified by the program. [1] 

===References===
----
# Dave Thomas, Chad Fowler and Andy Hunt. ''Programming Ruby 1.9'', chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-05T18:12:08Z

RadioSignal: /* Ruby and Java from a security perspective. */

''Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.''

===Perspective on Security===
----
This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer; protecting intellectual property. The second perspective is that of the data center manager; keeping the hackers at bay. The third perspective is that of the programming manager or review team attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”

===Ruby===
----
From the programmer’s security perspective, Ruby is a nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by clients who will then attempt to get support for the modified product. Work is currently underway on the potential of converting the Ruby source code into Java bytecode through [http://xruby.com XRuby] or [http://jruby.org JRuby] which could then be better protected. Please see the Java discussion below for details of this protection. 
The data center manager’s view of Ruby is less clear. Ruby does have a robust [http://redmine.ruby-lang.org/ Issue Tracking System] which is comforting. The interpreted Ruby source language would also be safely protected from dissemination by layers of servers and firewalls. The potential vulnerability, which is increased by dynamic typing and extending classes, may be mitigated by utilization of the tainted and trusted object features. Here, the concept is to not let uncontrolled external input modify a system. We can mark objects tainted that have been affected by external input. Methods, that can dangerously modify a system, can raise an exception if passed a tainted object. [1] 
The programming manager or supervisor also has a mixed-bag here. Ruby, the programmer’s best friend, is touted to provide programming efficiencies that may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. However, extra time must be spent with peer and team reviews on any potentially dangerous code could have a system impact from the instantiation of an unforeseen type. 

===Java===
----
From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through [http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html obfuscation]. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program. 
The data center manager view of Java is one of a tried and tested product. The Java source code is protected by complete separation from the application and database servers. [http://www.sun.com/support/ Security alerts] are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “trusted/untrusted” input feature, there is peace of mind that all input must conform to all downstream types expected and understood by the design architect. 
While it may have taken the programming manager’s staff longer to create a product in a type safe environment, the peace of mind that every bug that could be found at compile time was indeed found is priceless. The bugs and security vulnerabilities lurking due to an unchecked type will keep one up at night. 

===Conclusion===
----
Ruby gives the programmer more dangerous tools to leave latent vulnerabilities in production code. The programmer and those reviewing his work must have heightened security awareness as to not put their organization at risk.

===Glossary===
----
Bytecode – An intermediate result from a programming language intended to be processed by a virtual machine and not the underlying computer hardware. 
Interpreted – In this context, interpreted code refers to the technique of directly processing a source text programming language and delivering results without the intermediate steps of producing virtual machine bytecode or hardware dependent object code 
Obfuscation - The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer. 
Tainted – Any Ruby object derived from some external source is automatically marked as being tainted [1] 
Trusted – An object, not created by the running program that cannot be modified by the program. [1] 
Untrusted – Any object created by the executing program which is allowed to be modified by the program. [1] 

===References===
# Dave Thomas, Chad Fowler and Andy Hunt. ''Programming Ruby 1.9'', chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-05T18:07:59Z

RadioSignal: /* CSC/ECE 517 Object Oriented Languages */

''Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.''

=== Ruby and Java from a security perspective. ===
Forward: This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer; protecting intellectual property. The second perspective is that of the data center manager; keeping the hackers at bay. The third perspective is that of the programming manager or supervisor attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”

===Ruby===
----
From the programmer’s security perspective, Ruby is a nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by clients who will then attempt to get support for the modified product. Work is currently underway on the potential of converting the Ruby source code into Java bytecode through [http://xruby.com XRuby] or [http://jruby.org JRuby] which could then be better protected. Please see the Java discussion below for details of this protection. 
The data center manager’s view of Ruby is less clear. Ruby does have a robust [http://redmine.ruby-lang.org/ Issue Tracking System] which is comforting. The interpreted Ruby source language would also be safely protected from dissemination by layers of servers and firewalls. The potential vulnerability, which is increased by dynamic typing and extending classes, may be mitigated by utilization of the tainted and trusted object features. Here, the concept is to not let uncontrolled external input modify a system. We can mark objects tainted that have been affected by external input. Methods, that can dangerously modify a system, can raise an exception if passed a tainted object. [1] 
The programming manager or supervisor also has a mixed-bag here. Ruby, the programmer’s best friend, is touted to provide programming efficiencies that may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. However, extra time must be spent with peer and team reviews on any potentially dangerous code could have a system impact from the instantiation of an unforeseen type. 

===Java===
----
From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through [http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html obfuscation]. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program. 
The data center manager view of Java is one of a tried and tested product. The Java source code is protected by complete separation from the application and database servers. [http://www.sun.com/support/ Security alerts] are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “trusted/untrusted” input feature, there is peace of mind that all input must conform to all downstream types expected and understood by the design architect. 
While it may have taken the programming manager’s staff longer to create a product in a type safe environment, the peace of mind that every bug that could be found at compile time was indeed found is priceless. The bugs and security vulnerabilities lurking due to an unchecked type will keep one up at night. 

===Conclusion===
----
Ruby gives the programmer more dangerous tools to leave latent vulnerabilities in production code. The programmer and those reviewing his work must have heightened security awareness as to not put their organization at risk.

===Glossary===
----
Bytecode – An intermediate result from a programming language intended to be processed by a virtual machine and not the underlying computer hardware. 
Interpreted – In this context, interpreted code refers to the technique of directly processing a source text programming language and delivering results without the intermediate steps of producing virtual machine bytecode or hardware dependent object code 
Obfuscation - The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer. 
Tainted – Any Ruby object derived from some external source is automatically marked as being tainted [1] 
Trusted – An object, not created by the running program that cannot be modified by the program. [1] 
Untrusted – Any object created by the executing program which is allowed to be modified by the program. [1] 

===References===
# Dave Thomas, Chad Fowler and Andy Hunt. ''Programming Ruby 1.9'', chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-05T17:54:43Z

RadioSignal: /* Conclusion */

== CSC/ECE 517 Object Oriented Languages ==
Proposition: Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.

=== Ruby and Java from a security perspective. ===
Forward: This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer; protecting intellectual property. The second perspective is that of the data center manager; keeping the hackers at bay. The third perspective is that of the programming manager or supervisor attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”

===Ruby===
----
From the programmer’s security perspective, Ruby is a nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by clients who will then attempt to get support for the modified product. Work is currently underway on the potential of converting the Ruby source code into Java bytecode through [http://xruby.com XRuby] or [http://jruby.org JRuby] which could then be better protected. Please see the Java discussion below for details of this protection. 
The data center manager’s view of Ruby is less clear. Ruby does have a robust [http://redmine.ruby-lang.org/ Issue Tracking System] which is comforting. The interpreted Ruby source language would also be safely protected from dissemination by layers of servers and firewalls. The potential vulnerability, which is increased by dynamic typing and extending classes, may be mitigated by utilization of the tainted and trusted object features. Here, the concept is to not let uncontrolled external input modify a system. We can mark objects tainted that have been affected by external input. Methods, that can dangerously modify a system, can raise an exception if passed a tainted object. [1] 
The programming manager or supervisor also has a mixed-bag here. Ruby, the programmer’s best friend, is touted to provide programming efficiencies that may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. However, extra time must be spent with peer and team reviews on any potentially dangerous code could have a system impact from the instantiation of an unforeseen type. 

===Java===
----
From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through [http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html obfuscation]. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program. 
The data center manager view of Java is one of a tried and tested product. The Java source code is protected by complete separation from the application and database servers. [http://www.sun.com/support/ Security alerts] are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “trusted/untrusted” input feature, there is peace of mind that all input must conform to all downstream types expected and understood by the design architect. 
While it may have taken the programming manager’s staff longer to create a product in a type safe environment, the peace of mind that every bug that could be found at compile time was indeed found is priceless. The bugs and security vulnerabilities lurking due to an unchecked type will keep one up at night. 

===Conclusion===
----
Ruby gives the programmer more dangerous tools to leave latent vulnerabilities in production code. The programmer and those reviewing his work must have heightened security awareness as to not put their organization at risk.

===Glossary===
----
Bytecode – An intermediate result from a programming language intended to be processed by a virtual machine and not the underlying computer hardware. 
Interpreted – In this context, interpreted code refers to the technique of directly processing a source text programming language and delivering results without the intermediate steps of producing virtual machine bytecode or hardware dependent object code 
Obfuscation - The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer. 
Tainted – Any Ruby object derived from some external source is automatically marked as being tainted [1] 
Trusted – An object, not created by the running program that cannot be modified by the program. [1] 
Untrusted – Any object created by the executing program which is allowed to be modified by the program. [1] 

===References===
# Dave Thomas, Chad Fowler and Andy Hunt. ''Programming Ruby 1.9'', chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-05T17:51:14Z

RadioSignal: /* Ruby */

== CSC/ECE 517 Object Oriented Languages ==
Proposition: Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.

=== Ruby and Java from a security perspective. ===
Forward: This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer; protecting intellectual property. The second perspective is that of the data center manager; keeping the hackers at bay. The third perspective is that of the programming manager or supervisor attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”

===Ruby===
----
From the programmer’s security perspective, Ruby is a nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by clients who will then attempt to get support for the modified product. Work is currently underway on the potential of converting the Ruby source code into Java bytecode through [http://xruby.com XRuby] or [http://jruby.org JRuby] which could then be better protected. Please see the Java discussion below for details of this protection. 
The data center manager’s view of Ruby is less clear. Ruby does have a robust [http://redmine.ruby-lang.org/ Issue Tracking System] which is comforting. The interpreted Ruby source language would also be safely protected from dissemination by layers of servers and firewalls. The potential vulnerability, which is increased by dynamic typing and extending classes, may be mitigated by utilization of the tainted and trusted object features. Here, the concept is to not let uncontrolled external input modify a system. We can mark objects tainted that have been affected by external input. Methods, that can dangerously modify a system, can raise an exception if passed a tainted object. [1] 
The programming manager or supervisor also has a mixed-bag here. Ruby, the programmer’s best friend, is touted to provide programming efficiencies that may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. However, extra time must be spent with peer and team reviews on any potentially dangerous code could have a system impact from the instantiation of an unforeseen type. 

===Java===
----
From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through [http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html obfuscation]. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program. 
The data center manager view of Java is one of a tried and tested product. The Java source code is protected by complete separation from the application and database servers. [http://www.sun.com/support/ Security alerts] are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “trusted/untrusted” input feature, there is peace of mind that all input must conform to all downstream types expected and understood by the design architect. 
While it may have taken the programming manager’s staff longer to create a product in a type safe environment, the peace of mind that every bug that could be found at compile time was indeed found is priceless. The bugs and security vulnerabilities lurking due to an unchecked type will keep one up at night. 

===Conclusion===
Ruby gives the programmer more tools to leave latent vulnerabilities in production code. The programmer and those reviewing his work must have a heightened security awareness as not to unduly put their enterprise at risk.

===Glossary===
----
Bytecode – An intermediate result from a programming language intended to be processed by a virtual machine and not the underlying computer hardware. 
Interpreted – In this context, interpreted code refers to the technique of directly processing a source text programming language and delivering results without the intermediate steps of producing virtual machine bytecode or hardware dependent object code 
Obfuscation - The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer. 
Tainted – Any Ruby object derived from some external source is automatically marked as being tainted [1] 
Trusted – An object, not created by the running program that cannot be modified by the program. [1] 
Untrusted – Any object created by the executing program which is allowed to be modified by the program. [1] 

===References===
# Dave Thomas, Chad Fowler and Andy Hunt. ''Programming Ruby 1.9'', chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-05T17:30:38Z

RadioSignal: /* Java */

== CSC/ECE 517 Object Oriented Languages ==
Proposition: Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.

=== Ruby and Java from a security perspective. ===
Forward: This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer; protecting intellectual property. The second perspective is that of the data center manager; keeping the hackers at bay. The third perspective is that of the programming manager or supervisor attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”

===Ruby===
From the programmer’s security perspective, Ruby is a nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by customers who will then attempt to get support for the modified product. There is a potential of converting the Ruby code into Java bytecode through [http://xruby.com XRuby] or [http://jruby.org JRuby] which could then be better protected. Also, please see the Java discussion below for details. 
The data center manager’s view of Ruby is less clear. The interpreted Ruby source language is safely protected from dissemination by layers of servers and firewalls. The potential vulnerability which is increased by dynamic typing may be mitigated by utilization of the tainted and trusted object features. The concept is to not let external input modify a system. We can mark objects tainted that have been affected by external input. Methods, that can dangerously modify a system, can raise an exception if passed a tainted object. [1] 
The programming manager or supervisor also has a mixed-bag here. Ruby, the programmer’s best friend is touted to provide programming efficiencies that may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. Extra time must be spent with peer and team reviews of potentially dangerous code that an unforeseen type may have on the system. 

===Java===
----
From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through [http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html obfuscation]. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program. 
The data center manager view of Java is one of a tried and tested product. The Java source code is protected by complete separation from the application and database servers. [http://www.sun.com/support/ Security alerts] are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “trusted/untrusted” input feature, there is peace of mind that all input must conform to all downstream types expected and understood by the design architect. 
While it may have taken the programming manager’s staff longer to create a product in a type safe environment, the peace of mind that every bug that could be found at compile time was indeed found is priceless. The bugs and security vulnerabilities lurking due to an unchecked type will keep one up at night. 

===Conclusion===
Ruby gives the programmer more tools to leave latent vulnerabilities in production code. The programmer and those reviewing his work must have a heightened security awareness as not to unduly put their enterprise at risk.

===Glossary===
----
Bytecode – An intermediate result from a programming language intended to be processed by a virtual machine and not the underlying computer hardware. 
Interpreted – In this context, interpreted code refers to the technique of directly processing a source text programming language and delivering results without the intermediate steps of producing virtual machine bytecode or hardware dependent object code 
Obfuscation - The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer. 
Tainted – Any Ruby object derived from some external source is automatically marked as being tainted [1] 
Trusted – An object, not created by the running program that cannot be modified by the program. [1] 
Untrusted – Any object created by the executing program which is allowed to be modified by the program. [1] 

===References===
# Dave Thomas, Chad Fowler and Andy Hunt. ''Programming Ruby 1.9'', chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-05T17:14:35Z

RadioSignal: /* Glossary */

== CSC/ECE 517 Object Oriented Languages ==
Proposition: Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.

=== Ruby and Java from a security perspective. ===
Forward: This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer; protecting intellectual property. The second perspective is that of the data center manager; keeping the hackers at bay. The third perspective is that of the programming manager or supervisor attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”

===Ruby===
From the programmer’s security perspective, Ruby is a nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by customers who will then attempt to get support for the modified product. There is a potential of converting the Ruby code into Java bytecode through [http://xruby.com XRuby] or [http://jruby.org JRuby] which could then be better protected. Also, please see the Java discussion below for details. 
The data center manager’s view of Ruby is less clear. The interpreted Ruby source language is safely protected from dissemination by layers of servers and firewalls. The potential vulnerability which is increased by dynamic typing may be mitigated by utilization of the tainted and trusted object features. The concept is to not let external input modify a system. We can mark objects tainted that have been affected by external input. Methods, that can dangerously modify a system, can raise an exception if passed a tainted object. [1] 
The programming manager or supervisor also has a mixed-bag here. Ruby, the programmer’s best friend is touted to provide programming efficiencies that may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. Extra time must be spent with peer and team reviews of potentially dangerous code that an unforeseen type may have on the system. 

===Java===
From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through [http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html obfuscation]. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program. 
The data center manager view of Java is one of a tried and tested product. The Java source code is completely protected by complete separation from the application and database servers. Security alerts are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “untrusted” input feature, there is peace of mind that all input must conform to all downstream types expected and understood by the design architect. 
While it may have taken the programming manager’s staff longer to create a product in a type safe environment, the peace of mind that every bug that could be found at compile time was indeed found is priceless. The bugs and security vulnerabilities lurking due to an unchecked type will keep one up at night. 

===Conclusion===
Ruby gives the programmer more tools to leave latent vulnerabilities in production code. The programmer and those reviewing his work must have a heightened security awareness as not to unduly put their enterprise at risk.

===Glossary===
----
Bytecode – An intermediate result from a programming language intended to be processed by a virtual machine and not the underlying computer hardware. 
Interpreted – In this context, interpreted code refers to the technique of directly processing a source text programming language and delivering results without the intermediate steps of producing virtual machine bytecode or hardware dependent object code 
Obfuscation - The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer. 
Tainted – Any Ruby object derived from some external source is automatically marked as being tainted [1] 
Trusted – An object, not created by the running program that cannot be modified by the program. [1] 
Untrusted – Any object created by the executing program which is allowed to be modified by the program. [1] 

===References===
# Dave Thomas, Chad Fowler and Andy Hunt. ''Programming Ruby 1.9'', chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-05T15:34:07Z

RadioSignal: /* Ruby */

== CSC/ECE 517 Object Oriented Languages ==
Proposition: Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.

=== Ruby and Java from a security perspective. ===
Forward: This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer; protecting intellectual property. The second perspective is that of the data center manager; keeping the hackers at bay. The third perspective is that of the programming manager or supervisor attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”

===Ruby===
From the programmer’s security perspective, Ruby is a nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by customers who will then attempt to get support for the modified product. There is a potential of converting the Ruby code into Java bytecode through [http://xruby.com XRuby] or [http://jruby.org JRuby] which could then be better protected. Also, please see the Java discussion below for details. 
The data center manager’s view of Ruby is less clear. The interpreted Ruby source language is safely protected from dissemination by layers of servers and firewalls. The potential vulnerability which is increased by dynamic typing may be mitigated by utilization of the tainted and trusted object features. The concept is to not let external input modify a system. We can mark objects tainted that have been affected by external input. Methods, that can dangerously modify a system, can raise an exception if passed a tainted object. [1] 
The programming manager or supervisor also has a mixed-bag here. Ruby, the programmer’s best friend is touted to provide programming efficiencies that may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. Extra time must be spent with peer and team reviews of potentially dangerous code that an unforeseen type may have on the system. 

===Java===
From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through [http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html obfuscation]. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program. 
The data center manager view of Java is one of a tried and tested product. The Java source code is completely protected by complete separation from the application and database servers. Security alerts are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “untrusted” input feature, there is peace of mind that all input must conform to all downstream types expected and understood by the design architect. 
While it may have taken the programming manager’s staff longer to create a product in a type safe environment, the peace of mind that every bug that could be found at compile time was indeed found is priceless. The bugs and security vulnerabilities lurking due to an unchecked type will keep one up at night. 

===Conclusion===
Ruby gives the programmer more tools to leave latent vulnerabilities in production code. The programmer and those reviewing his work must have a heightened security awareness as not to unduly put their enterprise at risk.

===Glossary===
Obfuscation - The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer.
===References===
# Dave Thomas, Chad Fowler and Andy Hunt. ''Programming Ruby 1.9'', chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-05T13:35:18Z

RadioSignal: /* Conclusion */

== CSC/ECE 517 Object Oriented Languages ==
Proposition: Ruby and Java from a security perspective. Ruby makes it easier to create code on the fly, which could be seen as a security risk. Moreover, it does not have static typing, which is used in the JVM to statically prevent many different kinds of attacks. On the other hand, Ruby has the concept of untrusted input, which Java does not have. Compare the security-related aspects of the languages evaluate the strengths and weaknesses of each language.

=== Ruby and Java from a security perspective. ===
Forward: This work is dependent upon one's view of security. We shall investigate Ruby and Java from several security perspectives. The first perspective is that of the programmer; protecting intellectual property. The second perspective is that of the data center manager; keeping the hackers at bay. The third perspective is that of the programming manager or supervisor attempting to limit the migration of vulnerability from compile-time to runtime. We will answer the question, “Does Ruby or Java give us the best protection viewed from each of these perspectives?”

=== Ruby ===
From the programmer’s security perspective, Ruby is a bad nightmare. Disseminating precious source language to his customers means certain plagiarism of his work. Modifications will be made by customers who will then attempt to get support for the modified product. 
The data center manager’s view of Ruby is less clear. The interpreted Ruby source language is safely protected from dissemination by layers of servers and firewalls. The potential vulnerability which is increased by dynamic typing may be mitigated by utilization of the “untrusted” input feature. 
The programming manager or supervisor also has a mixed-bag here. Ruby, the programmer’s best friend is touted to provide programming efficiencies that may offset the potential for easily detected compile-time bugs from perpetuating into runtime due to the lack of static typing. 

===Java===
From the programmer’s security perspective, while Java is no panacea, it’s certainly better than Ruby. Although Java’s compiled bytecode is vulnerable to reverse engineering, it can be somewhat protected through [http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obfuscation.html obfuscation]. The programmer may take some satisfaction in the fact that if his code is stolen, it was not without considerable effort on the part of the crook. His customers will also have to request modifications and support for any changes to the program. 
The data center manager view of Java is one of a tried and tested product. The Java source code is completely protected by complete separation from the application and database servers. Security alerts are published and contributed from a wide audience. Ironclad static typing prevents many potential threats. While there is no “untrusted” input feature, there is peace of mind that all input must conform to all downstream types expected and understood by the design architect. 
While it may have taken the programming manager’s staff longer to create a product in a type safe environment, the peace of mind that every bug that could be found at compile time was indeed found is priceless. The bugs and security vulnerabilities lurking due to an unchecked type will keep one up at night. 

===Conclusion===
Ruby gives the programmer more tools to leave latent vulnerabilities in production code. The programmer and those reviewing his work must have a heightened security awareness as not to unduly put their enterprise at risk.

===Glossary===
Obfuscation - The practice of removing meaningful aspects of compiled bytecode to render the result correct but difficult to re-engineer.
===References===
# Dave Thomas, Chad Fowler and Andy Hunt. ''Programming Ruby 1.9'', chapter Locking Ruby in the Safe, pp 425-429. The Pragmatic Bookshelf, 2009. ISBN 1-934356-08-5

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-05T13:26:32Z

RadioSignal: /* Glossary */

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-05T13:24:25Z

RadioSignal: /* References */

CSC/ECE 517 Fall 2009/wiki1a 10 RS56

2009-09-04T14:24:18Z

RadioSignal: