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

Andy myside at myside.mine.nu
Wed Jan 2 14:54:12 EST 2008



On Wed, 2 Jan 2008, Jon Daley wrote:

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

I would love to see new features in lifetype available to me as needed or 
provisioned, with seperation of the new features used as needed, options 
to disable these be default, yet all available with new releases.  This 
would give me the ability to add the desired new features as I see fit to 
my user base.

A personal Blog website would appreciate the automatic addition of 
functionality, however other systems would like these to be not available 
with an upgrade cycle.

I should mention, thank you for your time with these questions.

Sorry for sounding condacending, but could you send me a private e-mail 
in which I could send a URL describing my project.  Sorry to all others on 
the mailing list.

  > _______________________________________________
> pLog-svn mailing list
> pLog-svn at devel.lifetype.net
> http://limedaley.com/mailman/listinfo/plog-svn
>


More information about the pLog-svn mailing list