[pLog-svn] r6088 - plog/branches/lifetype-1.2/class/security

[Jon Daley]

On Wed, 2 Jan 2008, Andy wrote:
> I am mostly concerned with the major 2.x.x releases.  If a security hole
> were to be detected, and a major code change would have to be provisioned
> for the API - can you assure me that the references to object data
> requests would not be altered?
 	I am not sure what you mean when you say "references to object 
data requests".  I think most (all?) security fixes that have been added 
have been on the input validation side of things, prior to the data 
getting to the DAO layer.  But, if you are asking whether the object 
structure will change (as in if an object that is serialized with 2.0 can 
be unserialized with 2.0.1) I think that would be chancey, and it would be 
better to not save serialized copies of objects outside of LT between 
upgrades.
 	You shouldn't care about internal object data if you use the API 
methods, right?  I think I must be missing your point.

> My last concern is with new feature sets in which the current API I
> am using would not support, and additions would be made.  How would
> these new features be set at default, in a production system, with
> the new version, without disrupting the secure and effecient
> execution of the previous release, in addition to the above?
 	I am not quite sure what you are asking.  If there are new 
objects/functions that you don't call, they wouldn't affect anything, 
right?  The LT code generally provides default parameters where 
appropriate, and tries quite hard to never break anything during minor 
upgrades.
 	You shouldn't expect to be able to upgrade from 1.2.x to 2.0 
without any changes on your part.  I don't think anyone wants that to 
happen.  It is even worse in PHP that in say Microsoft world, since all of 
the functions have been parsed at run-time, and so as the code grows 
larger and larger, it not only gets confusing which function you want to 
use OpenFile, OpenFileEx, OpenFile2, etc. but also the whole application 
would run slower.  So, we need to prune out old functions some of the 
time.

> Could there be a separation of code features based on version releases,
> yet still be available in the new applications provided?
 	Can you explain more?