On Thu, Jan 28, 2010 at 3:39 AM, Michael Richardson
<..hidden..> wrote:
>>>>> "Chris" == Chris Travers <
..hidden..> writes:
Chris> user as the provided credentials. LDAP might be needed to
Chris> make that work cleanly though....
LDAP is not necessary or important.
Apache will provide a DN, etc. to the script.
see http://httpd.apache.org/docs/2.2/mod/mod_ssl.html, and the
SSL_CLIENT_* variables.
I was thinking more along the lines of authenticating that the certificate maps to a specific user, short of requiring the username in the cert. LDAP might make it easier to avoid problems.
>> What do you have in mind here?
>>
Chris> This: https://wiki.mozilla.org/Security/CSP/Spec
I see...very interesting. This is useful, particularly because it kills
eval() in the _javascript_.
Chris> I see SSL as a critical tool for solving certain kinds of
Chris> problems. It is hardly a panacea but it solves certain
Chris> specific problems quite well despite being somewhat clumsy
Chris> because it is a partial port of an OSI protocol to TCP/IP
Chris> (and OSI protocols ported to TCP/IP generally suck from a
Chris> TCP/IP standpoint).
The SSL certainly provides privacy, and combined with client side
certificates provides useful authentication. No question about that.
But, in the situation where the browser is on the corporate intranet,
one hop from the server, or in my personal company case, where the whole
thing is "localhost", it wasn't privacy that was the problem.
Ok, there is a specific issue with 1.3 that I think requires SSL on the corporate intranet in order to be effective.
The basic issue is that we use internal db accounts so we have to obtain credentials from the web browser we can use to authenticate against the db. Currently the only way supported to do this is via HTTP Basic Auth, though Kerberos could be supported for intranet environments with a little effort.
For an intranet environment really you need to either have Kerberos support (which doesn't exist yet but could be developed without too much effort) OR use SSL. For mixed intranet/VPN access, you might want to use both (to allow for someone logging into the db with a TGT created from credentials obtained via http basic auth).
The problem is inappropriate disclosure of data :-)
>> I'd rather we spent time on:
>> a) a good dump/restore/"fsck" program that can be used to
>> validate that data is still good.
>>
Chris> This will become less important as the data integrity
Chris> controls become more
Chris> robust as they do in each version.
hmm. I'm not sure I agree.
I think the proposals to rename the 1.2 tables, and then do INSERTs from
the into the 1.3 tables are good. What I want to do is to extend this
to support saving to a 2nd-normal-form representation such that a human
can more easily inspect what is going on....
What about a new schema with VIEWs that are in 2nf?
This is as much about producing good audit records as it is to permit
recovery from data corruption that may have occured in the past...
Has anyone considered having an ledgersmb mini-conference either
independently, or as a summit of another conference... e.g. PGcon,
OLS, onlinux, OScon, ???
Not yet. Maybe we will get there though :-) Efforts in helping with such things is appreciated.
Best Wishes,
Chris Travers