[Newbies] Uploading Patches and Enabling Features in Commercial Systems

Tue Mar 6 21:22:03 UTC 2007

Hi JP,

OK before answering let me say that these are only suggestions and you are
responsible for taking suggestions as suggestions.  In other words I can not
be responsible for anything that goes wrong on your system, use my
suggestions at your own risk.

THE OPINION IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE OPINION OR THE USE OR OTHER DEALINGS IN SOFTWARE.

I'm sure all that goes without saying but now it is said.

The first question you asked was: how does a system update itself?    

Here are the issues as I see them.

1) A system must be able to ensure that it is updating itself from a trusted
location.
2) A system must be able to ensure that only the trusted system can ask it
to update itself.
3) A system must be able to ensure that it can securely store an update
location.
4) A system must be able to securely change the update location.
5) All communications must be encrypted.
6) A System must be able to verify patches before applying them.
7) A System must be able to automatically load the patch.
8) A System should be able to update without restarting the application.
9) A System must be able to report back success or failure of patch
installation.
10) A System must be able to recover from a failed patch. 

Ok so basic caveat, I just made these up and I'm sure I left something out.

The second question is how you can limit functionally in your system unless
and until payment is received.

1) A system must be able to enable features for a single instance and
prevent those features from being shared to other systems.
2) A system could be able to detect features being used inappropriately
3) A system could be able to periodically check for permission (trial
software)

Ok so since I ran out of time I'll try to take each point one at a time
starting tomorrow.

Does this list help the conversation?  Can you add to the list things that
you think the system needs to do?

Ron Teitelbaum
President / Principal Software Engineer
US Medical Record Specialists
Squeak Cryptography Team Leader

> From: Jens Pall
> Sent: Tuesday, March 06, 2007 3:10 PM
> 
> Ron Teitelbaum wrote:
> > Hi JP,
> >
> > This is not an easy question.  There are a number of things that you
> need to
> > consider.  First you need to decide how secure the update needs to be.
> If
> > you are not worried about security then you have a much easier job and
> many
> > more options.  In general Squeak is not secure, but it is also not less
> > secure then many other tools that are sent to end users.
> >
> > So first answer some questions.
> >
> > Is your system likely to be used by people that are interested in
> cracking
> > the system?
> 
> Some of the end-users might try this but most of them will not. They
> just want a system that works and does its job. We are working with
> partners who are distributing our software and I know that some of them
> will try to open up the software, modify it and, in some cases, try to
> sell it as their own if it is easy to get at the source. If the source
> is not available and it is a bit hard to get access to the developing
> interface then I believe this risk is greatly reduced.
> 
> > Does your system have access to network facilities that attach to other
> > installations of your system?
> 
> Yes. This is a distributed networked application. It lives and breathes
> on the network.
> 
> > Are you concerned that someone might try to build a patch and upload
> that
> > code to your system installations?  (i.e. spyware, worms, viruses)
> 
> Well, not really. Our installations mainly run on private WAN networks
> owned by the customer but you never know what malicious internal users
> might do. We plan on being able to run this over the Internet where this
> is a major concern but will try to limit it by using secure network
> connections.
> 
> > Are you trying to prevent users from using features of your system
> without
> > authorization?  (i.e. Try before you buy?)
> 
> Yes. We must be able to issue licenses for using features of the system.
> 
> > There are no easy answers but I do believe it is a very interesting
> > discussion.
> 
> It indeed is and one that needs to be addressed if Squeak is to be
> seriously considered as a commercial vehicle. It has huge potential in
> that area if the proper hooks are in place.
> 
> As a side note I might mention that our current system is implemented in
> C++ and, if it turns out to be possible with respect to the topic of
> this thread, we are seriously considering porting it to Squeak. Croquet
> will also play a major role as the monitoring / management tool.
> 
> > Ron Teitelbaum
> > President / Principal Software Engineer
> > US Medical Record Specialists
> > www.usmedrec.com
> > Squeak Cryptography Team Leader
> >
> >
> >> -----Original Message-----
> >> From: beginners-bounces at lists.squeakfoundation.org [mailto:beginners-
> >> bounces at lists.squeakfoundation.org] On Behalf Of Jens Pall
> >> Sent: Tuesday, March 06, 2007 2:09 AM
> >> To: Squeak Beginners
> >> Subject: [Newbies] Squeak in commercial projects
> >>
> >> Hi
> >>
> >> How can I use Squeak in a commercial closed source project (whole
> image)?
> >>
> >> How about upgrades? I want to be able to send an upgrade to the
> customer
> >> which only contains the changed code.
> >>
> >> Thanks,
> >> JP
> 
> 
> _______________________________________________
> Beginners mailing list
> Beginners at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/beginners