Menu
▾
▴
phpwiki-talk
|
From: Jeff D. <da...@da...> - 2001-02-07 19:19:09
|
Hi.
Yes I'm still alive!
Great work everyone on the current 1.2.0 release.
Sorry I disappeared so suddenly.
I'm back, at least for a bit.
You didn't ask (well actually you just did, at least on one of these),
but here's my snooty opinions on a bunch of things:
The move to PHP4:
My (cheap) virtual host provider is still running
only PHP3. I've put in a request to fix that, but who know when that
might happen. I'm sure others are in the same boat. Is there really
a pressing reason to drop support for PHP3?
Tables:
I personally like the idea of tables --- I've wanted to use them
on several occasion.
As for what markup to use, I have no strong feeling other than that
I think one should avoid raw HTML. (Remind me what's wrong with
the bar ('|') based mark-ups?) I think the markup should provide
for left-adjust, right-adjusted, and centered columns.
So count one vote for tables.
Footnotes:
If there's a push for keeping the mark-up simple, why footnotes?
Carrying the references around as page meta-data has been a
pain-in-the-database-code. Why not just get rid of it all?
So count one vote against footnotes.
We also need to think about how to deal with the references on
the existing pages. My vote is to make the restore-from-zip-archive
tag some text with the references onto the bottom of the page.
When to Archive:
If I edit a page that was last edited by myself six months ago,
I would like the old contents of the page to be archived.
I propose that the edit form should have a checkbox labeled
"This is a minor edit, do not archive". The default state of
the checkbox should depend on the whether the current author matches
the previous author, and also on the time since last edit.
What do y'all think? I'll add it if you give the go-ahead.
Archiving Multiple Versions:
This has been talked about forever. Back before I disappeared,
I suggested a database API which handled this. You guys apparently
didn't like it (that's okay).
I think this needs to be made a high priority, or it will never get done.
User ID's / Logins:
I think they're a good idea. (Useful for some sites, at least.)
Security:
On machines where httpd runs as 'nobody' (or similar), admin.php must
be world readable. This allows anyone with an account on the machine
access to the username and password in admin.php (same problem for
the sql password in config.inc).
Is there a solution?
PATH_INFO:
Whatever happened to page names in PATH_INFO? Did that get nixed for
a good reason? Or just because I never did it.
If it's okay, I'll try to add it again. Should it be switchable in
the config file?
On a related note, there's a bug:
Currently 'index.php?zip=all' will get you to the wiki page named 'zip=all'.
This is probably a bad idea ('zip=all' is an allowable page name,
but it should have to be url-encoded.)
I'll fix this unless you object.
I think that's it for now.
Jeff
|
|
From: Steve W. <sw...@wc...> - 2001-02-07 19:53:06
|
On Wed, 7 Feb 2001, Jeff Dairiki wrote:
> The move to PHP4:
>
> Is there really
> a pressing reason to drop support for PHP3?
For a new development tree, which won't mature for at least six months, I
don't see the reason to slow down development by supporting the old 3.0.x.
There are a lot of new features in 4.0 we deny ourselves. Sooner or later
the rest of the world will catch up. There's always the possibility others
will send patches for us; but I want to start using array_walk() and other
4.0 features already. It just makes sense in the long run.
> Tables:
> As for what markup to use, I have no strong feeling other than that
> I think one should avoid raw HTML. (Remind me what's wrong with
> the bar ('|') based mark-ups?)
HTML == security hole, basically... we'd have to restrict the markup
allowed. The bar syntax allows any HTML.
> I think the markup should provide
> for left-adjust, right-adjusted, and centered columns.
Inevitiably people will want to use markup inside tables.. I will say it
again and keep saying it until I drive all of you off the project: We are
not going to reinvent HTML. It's not fun.
> Footnotes:
>
> If there's a push for keeping the mark-up simple, why footnotes?
> Carrying the references around as page meta-data has been a
> pain-in-the-database-code. Why not just get rid of it all?
It's a small addition, already done, so it's a moot point...
> We also need to think about how to deal with the references on
> the existing pages. My vote is to make the restore-from-zip-archive
> tag some text with the references onto the bottom of the page.
This is more of a problem. Your solution sounds fine though. Can existing
references be converted to footnotes?
> When to Archive:
>
> If I edit a page that was last edited by myself six months ago,
> I would like the old contents of the page to be archived.
>
> I propose that the edit form should have a checkbox labeled
> "This is a minor edit, do not archive". The default state of
> the checkbox should depend on the whether the current author matches
> the previous author, and also on the time since last edit.
>
> What do y'all think? I'll add it if you give the go-ahead.
This is great! Basically I want to copy UseModWiki's model.
http://www.usemod.com/cgi-bin/wiki.pl?UseModWiki
Your idea of a checkbox is almost identical to UseMod's approach.
> Archiving Multiple Versions:
>
> This has been talked about forever. Back before I disappeared,
> I suggested a database API which handled this. You guys apparently
> didn't like it (that's okay).
Oh no, I do like that idea. The wiki_pages table and the wiki_archive
table should have separate APIs. There's no reason to assume we will
always store pages in the archive the same way we store them in the
wiki_pages table.
> I think this needs to be made a high priority, or it will never get done.
It's on the Task List on Sourceforge as of yesterday (feel free to add
tasks):
<URL:http://sourceforge.net/pm/task.php?group_project_id=7691&group_id=6121&func=browse>
> Security:
>
> On machines where httpd runs as 'nobody' (or similar), admin.php must
> be world readable. This allows anyone with an account on the machine
> access to the username and password in admin.php (same problem for
> the sql password in config.inc).
>
> Is there a solution?
Ack. That is bad. .htaccess? Or add 'nobody' to your group?
> PATH_INFO:
>
> Whatever happened to page names in PATH_INFO? Did that get nixed for
> a good reason? Or just because I never did it.
It fell off the radar. Ari has code for it, but we never integrated it.
You probably recall the NBTSC Wiki code is on Sourceforge in the ftp
directory.
> If it's okay, I'll try to add it again. Should it be switchable in
> the config file?
If there are no platform issues, I would rather see it a permanent
feature.
> On a related note, there's a bug:
>
> Currently 'index.php?zip=all' will get you to the wiki page named 'zip=all'.
> This is probably a bad idea ('zip=all' is an allowable page name,
> but it should have to be url-encoded.)
> I'll fix this unless you object.
nope, hack away! :-)
> I think that's it for now.
Welcome back! :-)
~swain
...............................ooo0000ooo.................................
Hear FM quality freeform radio through the Internet: http://wcsb.org/
home page: www.wcsb.org/~swain
|
|
From: Steve W. <sw...@wc...> - 2001-02-07 20:03:13
|
These tasks are in the task list now, except for the zip= thing, which I suspect you'll take care of shortly. ~swain ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
|
From: <ph...@de...> - 2001-02-07 20:15:22
|
On Wed, 07 Feb 2001 11:19:29 -0800, you wrote: <snip lots of good stuff> => Security: => On machines where httpd runs as 'nobody' (or similar), admin.php must => be world readable. This allows anyone with an account on the machine => access to the username and password in admin.php (same problem for => the sql password in config.inc). => Is there a solution? One shared hosting provider (www.pair.com) allows users to run PHP "wrapped" through a CGI-WRAP so that the process runs as the user, rather than as nobody (which allows you to set all your code and INC files etc etc to 600 or whatever). One needs to be sure the code is tight because it's going to run as if it were the account owner logged in thru telenet (rather than as the webserver), but it works very well. Pair also allows the user (webmaster level account or above) to configure and compile their own version(s) of PHP under their own account. Also works quite well. Cheers, - Don (a pair customer/VAR but don't ask me for an account) |
|
From: Malcolm R. <mal...@cs...> - 2001-02-08 06:11:07
|
>
> Security:
>
> On machines where httpd runs as 'nobody' (or similar), admin.php must
> be world readable. This allows anyone with an account on the machine
> access to the username and password in admin.php (same problem for
> the sql password in config.inc).
>
> Is there a solution?
Well, we could do what the UNIX passwd system does, and compute and store
a hash of the password (one-way encrypted) instead of the plain-text.
This could be done via the following (untested) change to admin.php:
// set these to your preferences. For heaven's sake
// pick a good password!
$wikiadmin = "malcolmr";
$adminkey = "BHZ";
$adminpasswd = "750c783e6ab0b503eaa86e310a5db73"; // Not the real value
// Do not tolerate sloppy systems administration
if (empty($wikiadmin) || empty($adminpasswd)) {
echo "Set the administrator account and password first.\n";
exit;
}
// from the manual, Chapter 16
if (($PHP_AUTH_USER != $wikiadmin ) ||
(bin2hex(mhash(MHASH_MD5, $PHP_AUTH_PW, $adminkey)) != $adminpasswd)) {
Header("WWW-Authenticate: Basic realm=\"PhpWiki\"");
Header("HTTP/1.0 401 Unauthorized");
echo gettext ("You entered an invalid login or password.");
exit;
}
Unfortunately, I can't test this, because none of the PHP installations
available to me have mhash installed.
Generating an encrypted password would require a separate program, but
is easily done.
This is still vulnerable to dictionary attacks, but if the password is
well chosen, it should be fairly secure.
Malcolm
--
Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/
AI Dept, CSE, UNSW, Australia, Phone: +61 2 9385-6906 Fax: +61 2 9385-1814
"He causes his sun to rise on the evil and the good,
and sends rain on the righteous and the unrighteous." - Matt 5:45
|
|
From: Steve W. <sw...@wc...> - 2001-02-08 15:40:46
|
On Thu, 8 Feb 2001, Malcolm Ryan wrote: > This could be done via the following (untested) change to admin.php: > > // set these to your preferences. For heaven's sake > // pick a good password! > $wikiadmin = "malcolmr"; > $adminkey = "BHZ"; > $adminpasswd = "750c783e6ab0b503eaa86e310a5db73"; // Not the real value Would this require the server to write to the file? That in itself is a problem. We should probably move the login/passwd to a separate file, not store it in config.php. If we create our own passwd file via the server, it could be -rw------- nobody nobody and that might be a minor gain in itself. Good security is so hard. ~swain ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
|
From: Arno H. <aho...@xm...> - 2001-02-08 08:31:18
|
> On machines where httpd runs as 'nobody' (or similar), admin.php must > be world readable. This allows anyone with an account on the machine > access to the username and password in admin.php (same problem for > the sql password in config.inc). Solution for admin.php: stored an md5() hash and not the user and/or=20 password itself. I can't think of a solution for config.php. This is actually much more serious then the admin password. Don't fix admin.php until you found a fix for config.php -- gives a false= =20 sense of security. /Arno |
|
From: Arno H. <aho...@xm...> - 2001-02-08 09:03:06
|
> Don't fix admin.php until you found a fix for config.php -- gives a fal= se > sense of security. Following up on my own email: I remembered that phorum has quite a good=20 description of how to securely install their app. Taken from their security.txt: If you want to run Phorum on a shared server, you absolutely need to wrap the scripts... unless, of course, your provider makes all of your scripts run as your userid. [...] What "wrapping" means is to have the .php scripts executed under your userid instead of the web server's default "nobody". This is because, no matter how well you hide the script (e.g. in a directory that's chmod 711), any user on your server could create a script that is run as "nobody" by the web server which could [read] your config files. This is especially bad on a shared server because the config file could also give the user access to your database passwords which, in many cases= , will let them mess with more than just your Phorum tables. On a shared server, your provider should be "providing" you with a secure and PHP-friendly script wrapper. If they are not, you should either not run scripts like Phorum that read/write files that include passwords or you should move to another provider. Bottom line: there's no way to secure config.php on a shared server if th= e=20 web server runs as nobody. /Arno |
|
From: <ph...@de...> - 2001-02-08 16:49:12
|
On Thu, 8 Feb 2001 10:02:42 +0100, you wrote: => Bottom line: there's no way to secure config.php on a shared server if the => web server runs as nobody. <snip, move, cut, paste, etc> => Taken from their security.txt: => If you want to run Phorum on a shared server, you absolutely need to wrap => the scripts... unless, of course, your provider makes all of your scripts => run as your userid. [...] It is a *GoodIdea* if the confidential user, password and servername info etc are kept in a separate "include/require" file, so that folks (such as me) who run Wiki under their user permissions can then move the PASSWORD.INC or whatever totally out from under the document root. Also, if left under the document root, one can use .htaccess to block pedestrian access through the web server to specific files/types. Cheers, - Don |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X