Re: implement .so

[Joerg Sonnenberger <joerg@britannica.bec.de>]

On Sun, Oct 24, 2010 at 09:41:30PM +0200, Ingo Schwarze wrote:
> Besides, Marc made the point that if we want to convince people
> to accept mandoc as a standard implementation for formatting
> manuals, we will almost certainly need .so support anyway:
> Not everyone will agree that is useless, if even among ourselves
> we are not 100% sure, so we risk fruitless and distracting
> discussions whether mandoc is complete or defective.

As we have seen in Rostock, full .so implementation has some funny side
effects, so I consider it a broken feature. I won't oppose a clean
patch, we have already seen that it is straight forward to implement.

> > Actually, there are a number of useful cases where you have to fix it
> > up already.  Consider using compressed man pages by default.
> > That breaks badly with .so.
> 
> Indeed, i don't expect we want to link against zlib.
> So, such special needs would still need to be handled outside
> mandoc - but only by those systems wanting them.

My point is that it essentially falls apart if you want to use
compressed man pages. So it really, really shouldn't be used.

> >>  * All people i'm asking tend to say i should not worry that
> >>    much about the my security concerns, maybe i'm indeed
> >>    excessively paranoid in that respect.
> 
> > Allow path names relative to the current directory and with /../
> > in them.
> 
> Hm?  Sorry?
> I definitely need to allow path names relative to the current dir.
> That's used all over the place.
> 
> You mean, i should *not* allow absolute path names,
> and i should not allow pathnames with ../ in them?

Sorry, yes. Only allow relative path names without /../ components.

Joerg
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv