>>>>> "OX" == Oliver Xymoron <oxymoron@waste.org> writes:
OX> Security - I just see no reason to expose this information. Why for
OX> instance is it necessary for anyone to know the actual address of
OX> owner-*?
The problem is that if you're running client/server the core can't assume
that it knows what's on the other end of the connection. Sure,
client/server doesn't work now but things were designed with that in mind.
And there is certain information that the core must expose to the
interface; making, say, the shell interface hide it is just security
through obscurity. (Not that hiding it from certain commands wouldn't
necessarily be a bad thing to do, but you can't fool yourself that it's
really secure.)
Now the specific example of the owners is a mistake; the original code had
the interface forwarding the message (and so it needed the addresses) but
now the interface passes the message to the core which forwards it
internally. The list of variables that is exposed is definitely something
that needs to be re-evaluated; the interfaces have changed a bit since some
of those variables were created. That should be easy enough for me to do
later today.
OX> Couple more notes: master_passwd on newly created lists defaults to a
OX> nice guessable value. It would probably be better to force the admin to
OX> supply a passwd or generate a random one.
The grand idea is to randomly generate a password and mail the equivalent
of the list-owner-info document with the information already filled in to
the supplied owner when the createlist is done. Right now there's no way
to communicate the password to anyone who needs to know it, so I've stuck
with the 1.94 method.
OX> Also, I think the comment for whoami is wrong in the context of lists -
OX> requests should be sent to list-request.
A large number of the config variable comments are going to be really
wrong, as they're unchanged from 1.94.4. (The original file was
autogenerated. A good number of those variables aren't even used and will
have to be removed, but they exist as placeholders to remind me of things
not implemented.)
OX> A function to re-justify text for files with interpolated variables
OX> would pretty up a number of things too.
I agree; is there one in a module somewhere? Maybe there's one in
Text::Format. The problem is keeping it from reformatting things that you
don't want it to reformat (like a big URL).
OX> There's a fair amount of documentation and proofreading that needs to
OX> be done and perhaps the help texts could be a little less involved.
The documentation is the bad point, because I'm bad at writing
documentation. The help texts are actually shortened versions of what's in
1.94.4, although with the new help system they could be even smaller. Some
of the config variable descriptions can definitely be shortened and moved
out into separate pages; they're kept together now because some of them are
just blueprints for how things are supposed to work/may end up working.
The command descriptions could probably use a bit of work. If you see
anything that needs adjustment, feel free to mail a patch.
OX> Biggest barrier for general usability is lack of digests (something I'd
OX> be interested in doing some coding for).
Yes, not having digests is a big hole. If you want to shoot around ideas;
feel free. The digest_rules description and what's in the TODO list form a
blueprint for what I think would be nice to happen, but that may not turn
out to be feasible.
OX> But I'm just about ready to start using it for several existings lists.
Do beware that I'm going to break compatibility when I move things to the
global address stuff.
OX> ps: what's the procedure for adding new domain directories?
You can redo the Makefile.PL conversation and add them there then run
postinstall as root. You can also follow what postinstall does:
mkdir $domain
mkdir $d/GLOBAL
mkdir $d/GLOBAL/files
mkdir $d/GLOBAL/sessions
Then it populates a few pieces of the global configuration
(master_password, tmpdir, site_name, install_dir, lists_dir, mta,
whereami).
The aliases are generated with:
mj_shell -d $dom -p $passwd createlist-nocreate-quiet GLOBAL
And you need the crontab entries corresponding to the domain.
- J<
References:
|
|
