John Anderson wrote:
Profile directory doesn't seem like the best name for this directory to
me. I prefer repository directory. Also what is in randpool.dat and
cacert.pem and why shouldn't they be in the repository like the rest of
our data?
I believe you were in the meeting when we hashed this out, based on my
proposal. The bits are in
http://wiki.osafoundation.org/bin/view/Chandler/ProfileDirectory. Like
mentioned in the doc, we can implement things in stages, and this
profile directory is the first and easiest stage. The next steps could
be: support multiple accounts (=profiles) in the repository, fully
integrated ACL support, repository server. Once all these are done, we
could run the repository server as a privileged process (either locally
or remotely) and the only way regular users would be able to access data
in the repository is through the connection to the repository. At that
point there is no need for profiles, there would just be accounts in the
repository.
randpool.dat is a small file containing some random bits that is needed
for crypto operations. Read on startup, written on exit. Normally it is
not a big deal if it cannot be read or written.
cacert.pem is the CA certificate list that we trust (this is the same
list as Mozilla ships with). Any website, email address etc. that uses
an X.509 certificate issued by these CAs will work out of the box with
Chandler. Because this is just a flat file in PEM format, most people
who run their own SSL servers with self signed certificates can simply
append their CA certificates to this file.
Both of these could in theory live in the repository, but there is a
small catch - if we ever want to support a remote repository we will
need the CA and randpool before we connect to the remote repository.
This could be solved by having a local cache copy of the remote
repository, for example.
The reason why randpool.dat and cacert.pem are not in the repository now
is that it wasn't deemed necessary to spend cycles on that at this
point. The cacert.pem should really be broken into individual Items, one
per CA, but this presents some additional work because OpenSSL likes to
work with files rather than Chandler repository. We really need a
certificate store section/API in the repository that can talk directly
and efficiently with OpenSSL via M2Crypto.
These could be solved in the 0.6 time frame.
--
Heikki Toivonen
signature.asc
Description: OpenPGP digital signature
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
