[Newbies] Uploading Patches and Enabling Features in CommercialSystems

Wed Mar 7 15:28:43 UTC 2007

Hello all,

Nobody updated my list!  I guess this could mean two things either my list
is perfect, or nobody cares.  Please let me know if my comments are not
helpful so that I don't spend too much time on it.

Ok so one point at a time.

1) A system must be able to ensure that it is updating itself from a trusted
location.

Currently there is only one why that I know of to ensure that a site is
real.  The name, the ip address, the domain can all be lost, and some can be
spoofed.  The only way to ensure that the location is real is to provide a
certificate that can be verified by a Certificate Authority.  Of course this
option is only as good as you are at protecting your server.  If you loose
your private key then all bets are off.  Do your customers check this?  No,
it's my experience that people are mostly annoyed by security and are not
willing to give anything up to get it.  (They do yell loudly when systems
are compromised).

So you could go out and spend lots of money getting a SSL certificate.  Or
you could get the free one that I recommend.  www.cacert.org (now it appears
their web site is down, but they have been around a long time now and I'm
sure that is temporary, check out the wikipedia entry
http://en.wikipedia.org/wiki/CAcert.org )

Why would you want to use CACert?  Because it is free and because supporting
open source certificates is a really good idea, since anything that
encourages more security and decreases the barriers to security are good
things.

Why wouldn't you want to use CACert?  One good reason is that Internet
Explorer does not automatically support CACert as a trusted Certificate
Authority.  This is very easy to fix, you just double click on the root
certificate from CACert and it installs it on windows but it does give you a
lot of warning messages.  Many other browsers already include CACert in the
default list of trusted CA's.  Some users may see this as unprofessional so
it is a good idea to either go with a paid CA, or write up a very good and
professional rational for using CACert that you give to your users.  

So now that you have your certificate that verifies that your server is who
it says it is you are all set.  You can now have an SSL client connect to
your server and after verifying the certificate it can download your
patches.  This can be done with our SSL client in squeak, which was
developed by Rob Withers and me.  Rob has been working on verification and I
think that is working now.  You can find our code in the
www.squeaksource.com repository under cryptography.  You could also use the
libCurl plugin that is available for squeak and use openSSL.  We can talk
about how to do this as we put all of this together.  I encourage everyone
that is interested in cryptography to join the cryptography team!
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography 

Comments are encouraged; I really do not like talking to myself.

Happy Coding!

Ron Teitelbaum
President / Principal Software Engineer
US Medical Record Specialists
www.usmedrec.com 
Squeak Cryptography Team Leader 

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

> From: Ron Teitelbaum
> 
> 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
> 
> 
> _______________________________________________
> Beginners mailing list
> Beginners at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/beginners