[pmwiki-users] Uninstalling EProtect

Patrick R. Michaud pmichaud at pobox.com
Thu Apr 14 11:42:07 CDT 2005


On Thu, Apr 14, 2005 at 05:11:10PM +0200, Joachim Durchholz wrote:
> Overriding the PageStore class sounds tempting. I'd have to go through 
> $WikiDir and the $WikiLibDir elements and replace each page store with a 
> proxy that wraps the read() and write() functions with encode/decode 
> functions.

No, you really should only have to go through $WikiDir.  And besides,
this is one of those cases where I believe you have to honor the
admin's choices and not do too much on his/her behalf -- i.e., have
the admin do:

   $WikiDir = new EProtectedPageStore('wiki.d/$FullName');

as part of the install/config.

> I'd also need to protect the munged mail addresses from markup 
> substitution. I could do my own version of Keep(), but that sounds like 
> a pain (we just *might* accidentally generate something that looks like 
> PmWik markup).

Yup, that's a pain.

> Well, maybe writing a new PageStore subclass isn't such a good idea then.

Probably not -- I was just pointing out that the hooks are available. :)

> >Make the obfuscation key part of the encoded mail addresses. When 
> >decoding an address, always use the key that is part of the encoded 
> >address; when encoding an address, always use the wiki-administrator
> >supplied key.
> 
> Hmm... well, that would be quite a lot of data: 104 bytes per email 
> address. Multiply that with 10 addresses on a page (say, for a 
> participant list after a metting), and you get to sizes that begin to 
> make me reconsider.

Well, if not per-address, the perhaps encode the key once in the page
to be used for all obfuscated addresses on that page.  However,
things get ugly when dealing with links being included from other 
pages.


> This could be stripped down to a byte or two, but that would mean that 
> rot13 would have to go (even as a corner case of the algorithm).
> That would allow a very nifty feature (namely deriving the key from 
> $ScriptURL, so different sites would most likely have different keys, 
> with no configuration effort for the site admin), but would people mind 
> if eProtect will not be configurable for rot13 in the future?

I think deriving from $ScriptUrl might cause problems, as $ScriptUrl
often changes over the lifetime of a site.

Why not just use a 2-byte random "salt" for the key of each address?
That ought to provide plenty of obfuscation.

Pm



More information about the pmwiki-users mailing list