On Dec 10, 2007 4:10 PM, johnf  wrote:
> On Monday 10 December 2007 02:50:04 pm Ricardo Aráoz wrote:
> > johnf wrote:
> > (snip...)
> >
> > > Right off the bat let me say the easiest way to setup a connection is to
> > > use the "CxnEditor.py" app.  It works and and is a great example of Dabo
> > > eating it's own dog food (CxnEditor was created using Dabo).  I use it
> > > for my projects and if there was a better way - I'd use it.  But it
> > > really does not do much (all the real work is done in the framework).
> > > CxnEditor creates a XML file that contains the parameters required by the
> > > python connection interface that applies to your database.  Like user
> > > name, password, host, database name or anything else that is needed to
> > > allow a database connection.
> >
> > Hi, so CxnEditor creates a XML file. Now you have in an ASCII file your
> > sensitive information (user, password - of course it will be a user with
> > append/update/delete rights) for anyone to see. My question is, how
> > would you manage the database security?
> >
> > TIA
>
> Currently, there is little real security.  Although the password has
> encryption.  However, it is very easy to subclass the login.py routines and
> add real security and still use the XML files.  But for the purposes of the
> tutorial what CxnEditor provides is enough.
>
> But here's a question.   What are you using for database security?  I have
> seen ODBC connections that use 'sa' and the same password for everyone that
> used the program.  I have seen RSA key fobs that cost a $100.00 for each
> seat.  What would you like to see in Dabo?
 
We have to be very careful with this.  I don't know where the lines
are with ITAR but we (devs in the US) cannot export encryption
technology above a certain standard.  If someone wants to tackle this
feel free, but please send an email to the dev list containing the
specs of the encryption standard before you commit so that we don't do
anything that would be a felony...
 
I wonder if we could hook GnuPG?
 
Cheers,
 
Nate L.