Final Word on the Password Problem

[Jay R. Ashworth]

On Tue, Jul 13, 2004 at 04:11:10PM -0400, Kenneth Brody wrote:
> "Jay R. Ashworth" wrote:
> > 
> > On Tue, Jul 13, 2004 at 01:07:18PM -0400, Kenneth Brody wrote:
> > > "Jay R. Ashworth" wrote:
> > > > On Tue, Jul 13, 2004 at 12:28:20PM -0400, Kenneth Brody wrote:
> > > [...]
> > > > > The site password is only placed in processing tables that you
> > > > > create/edit that do not already have a processing password.
> > > > > Changing the site password has no direct effect on existing
> > > > > passworded tables. However, it you change the password such
> > > > > that the processing table's password no longer matches the
> > > > > site password, then filePro will start asking for the password
> > > > > before you can see/edit the processing. (The same is true if
> > > > > you take the file to a different machine, such as a client's,
> > > > > where the site password is not the same.)
> > > >
> > > > Ah... but *which* password, Ken? The one you know, cause you set
> > > >it?
> > > >
> > > > Or the old one, which you either forgot or didn't set in the
> > > > first place?
> > >
> > > Wasn't that Nancy's argument for "assign a site password" rather
> > > than "leave it unset and scramble for a fix when someone changes
> > > it to something you don't know"?
> >
> > I'll infer that your non-responsive answer means "the old one".
> >
> > :-)
> >
> > That may have been Nancy's argument, but I think hers was as obscure
> > as yours.
>
> Then perhaps I missed the point of your question. (I thought that you
> were emphasizing Nancy's "know thy password" position.)
>
> _Which_ "*which* password" are you referring? There's the password in
> the processing table, the site password in the original machine, and
> the site password on the new machine. I also mentioned changing the
> site password, as well as passwords matching or not.

I'm referring to "the password which filePro will start asking for".

> A processing table that is created, or a non-passworded table that is
> edited, will have the current site password stored in it.
>
> If the password stored in the table does not match the current site
> password, then you need to know the password in the processing table
> in order to view it. (No password is needed to run it.)

"...using dcabe."  Obviously if it's in ASCII, you don't need to know
that password to edit it in vi.

So, Nancy's advice, which *sounds like* "run right out and set site
passwords on all your machines right now" to *me* is indeed bad,
because it won't protect most of those files until they're touched by
dcabe, which could take forever.

It's really only useful advice for developers on development machines
freshly installed, with no work done on them yet, as far as I can see.
Am I missing something?

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	"You know: I'm a fan of photosynthesis as much as the next guy,
	but if God merely wanted us to smell the flowers, he wouldn't 
	have invented a 3GHz microprocessor and a 3D graphics board."
					-- Luke Girardi