Re: [GeneX-dev] Re: usersec table

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

I'd rather avoid an advocacy of whether Java or Perl or better
languages. 

I agree that the use of a browser in between the curation tool was a
hack. It was a hack that was supposed to enable us to have a working
prototype a year ago. Well that prototype was more than a year in the
making, it's here now, so good riddance to the browser.

I'm glad that we now have a module that enables the CT to speak SSL on
it's own. That's a big improvement.

The control bundle process being slow has nothing to do with the
browser, or the internet. The expat library which generates the
control bundle is written in optimized C code, even though it has perl
interface. Java won't make that faster. The real slowdown is *what* is
in the control bundle. It is fat and bloated and shouldn't be. One way
to fix that if for the curation tool to keep it's own local mini-genex
DB, and store what it needs, getting updates only when needed, instead
of downloading everything each time it logs on.

In general, we have way more things to do than time and money to do
them. To my mind re-writing what already works (even if it's
sub-optimal) is a spectacular waste of time, and money. We already
have an experiment set submission script, and although it's made of
bailing wire, it works. I'd be thrilled if anybody re-wrote it to be
better.

We don't need to re-write anything to communicate over SSL. All we
have to do is run an SSL-enable apache, and all our CGI scripts will
work fine. We were supposed to be doing that all along. 

The whole point of the meeting we had in Nov. was to identify what are
the most *important* things to do, prioritize things, and get to work,
either fixing what's broke, or adding new features.

I think have a Java API to the DB would wonderful. That would enable
you and everyone else to write client side applications that talk
directly to the DB. This is what we've wanted all along. It would be a
big boost to the project.

However, the server side doesn't really need it. Once the Java API is
written, sure, replace the Perl CGI scripts if you want, but that just
seems like a real low priority compared to enable client-side access
to the DB.

There's a lot of things I wish I had time to make more sexy, but if I
want to get GeneX working, and get more developers adding code, than
there is a lot of stuff that I need to get done. In case you hadn't
noticed, we are losing NCGR developers on this project a lot faster
than we are getting new ones. If we want to make any real progress we
will need to win over more talented people like Michael Pear as
quickly as possible. To do that we fist need a functional system,
which luckily we seem to finally have. Second we need to make it
available to the outside world, which I am busting my butt to do,
about 10-12 hours/day. And third, we need to document the hell out
things, which luckily, a lot has already been done.

So of course we could do a whole lot better than everything we've
already done, but wouldn't it be a good idea to be smart about we
spend our time on? Here's my tentative list:

1. Get a full GeneX release on sourceforge
2. Get all developer modules in CVS on sourceforge
3. Spread the word about the open source GeneX project
4. Improve the query interface to do real queries instead of
   pre-canned ones
5. Add more analysis tools
6. Improve how GeneXML communicates data
7. Improve the data model to support security
8. Improve the data model to support updates

That's a big list.

jas.

"Todd Peterson" <tf...@nc...> writes:

> We have a lot of trouble with browsers. The SSLServer takes care of the
> things that make life difficult on the curation tool side. The current issue
> is that logins, control-bundle downloads, experiment set downloads and
> experiment set submittals are not secure (just checked to confirm). They
> travel on an unencrypted socket in both directions. The control bundle
> download process is slow and full of ways to mess up (another separate
> issue...I think the database/web interface should be re-written using Java;
> servlets or SSL sockets), the user is relied upon to put the file in the
> correct location, the user is relied upon to select the correct control
> bundle in the correct location, the browser may mangle the filename, etc.,
> etc. The web server really doesn't have to be modified to implement this
> change. It's really just another module on the server side. The benefits are
> non-reliance on browser configuration, secure communications using sound
> certificate authentication technology, speed improvement (I'll bet $1) and a
> project-wide movement to standardization on a common language (Java). Right
> now, the tools for the GeneX suite are a hodge-podge of baling-wire, twine
> and duct-tape. We can do better than that.
> 
> Todd
> 
> ----- Original Message -----
> From: "Jason E. Stewart" <ja...@op...>
> To: "Todd Peterson" <tf...@nc...>
> Cc: <gen...@li...>
> Sent: Monday, January 22, 2001 3:32 PM
> Subject: [GeneX-dev] Re: usersec table
> 
> 
> > "Todd Peterson" <tf...@nc...> writes:
> >
> > > This is for curation tool. Password would come from user on curation
> > > tool to web server (connection encrypted by SSL, certificates signed
> > > and authenticated on both sides, public keys exchanged and
> authenticated,
> > > etc.).  Java SSLServer on Web server would query usersec
> > > table and attempt to match userid/password. If match SSLServer
> > > responds to curation tool with OK, otherwise responds with ERROR.
> >
> > I believe it's secure. So you're writing a Java module that's needed
> > by the server? I'm a bit Java stupid, so pardon any ignorance, but
> > what is Java SSLServer? Is there some way that we can reuse the
> > existing CGI scripts instead of making new ones?
> >
> >
> > > ----- Original Message -----
> > > From: "Jason E. Stewart" <ja...@op...>
> > > To: "Todd Peterson" <tf...@nc...>
> > > Cc: <gen...@li...>
> > > Sent: Monday, January 22, 2001 2:07 PM
> > > Subject: Re: usersec table
> > >
> > >
> > > hmm..taking my entry for example:
> > >    31   53  tfp          tf32BeZ2ZCE9o
> > > and using the crypt shell command I try:
> > > echo tf32BeZ2ZCE9o | crypt tf
> > > and get garbage
> > > what am i missing?
> > >
> > > even tried:
> > > echo print(crypt("tf32BeZ2ZCE9o", "tf")); > temp.pl
> > > perl < temp.pl
> > > tfUTCnrBskQVU
> >
> > crypt() encrypts the password, not decrypts it. So in perl you would
> > way to check:
> >    crypt($salt, $plain_text_pwd) eq $encrypted_pwd
> >
> >
> > so if you have a command-line crypt, then you would want:
> >    echo $plain_text_pwd |crypt $salt
> >
> > I tried it using the command line crypt() on solaris and got
> > crap. However, perl on solaris gives the proper answer. I have no idea
> > what the interface to the command line version is supposed to be,
> > sorry.
> >
> > jas.
> >
> > _______________________________________________
> > Genex-dev mailing list
> > Gen...@li...
> > http://lists.sourceforge.net/lists/listinfo/genex-dev
> >
> 
> 
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> http://lists.sourceforge.net/lists/listinfo/genex-dev