From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12398 invoked by alias); 11 Apr 2002 14:17:24 -0000 Mailing-List: contact docbook-tools-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: docbook-tools-discuss-owner@sources.redhat.com Received: (qmail 12364 invoked from network); 11 Apr 2002 14:17:22 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 11 Apr 2002 14:17:22 -0000 Received: from meme.surrey.redhat.com (meme.surrey.redhat.com [172.16.10.38]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id g3BEH7M10531; Thu, 11 Apr 2002 10:17:07 -0400 Received: from meme.surrey.redhat.com (localhost.localdomain [127.0.0.1]) by meme.surrey.redhat.com (8.12.2/8.12.2) with ESMTP id g3BDDxc4008952; Thu, 11 Apr 2002 14:13:59 +0100 Received: (from twaugh@localhost) by meme.surrey.redhat.com (8.12.2/8.12.2/Submit) id g3BDDwgE008950; Thu, 11 Apr 2002 14:13:58 +0100 Date: Fri, 20 Dec 2002 19:23:00 -0000 From: Tim Waugh To: Mark Whitis Cc: =?iso-8859-1?Q?=C9ric_Bischoff?= , docbook-tools-discuss@sources.redhat.com Subject: Re: multiple bugs and security hole (was: Re: BUG: docbook2html --nochunks) Message-ID: <20020411141357.J1633@redhat.com> References: <20020410080309.D13205@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="WHz+neNWvhIGAO8A" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from whitis@freelabs.com on Wed, Apr 10, 2002 at 10:40:59PM -0400 X-SW-Source: 2002/txt/msg00049.txt.bz2 --WHz+neNWvhIGAO8A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3346 Hi Mark, Thanks for your feedback. > Thanks for the quick response. I applied that patch directly to > /usr/bin/jw and it sorta-kinda fixed the problem. Still, it is a > kludge rather than a proper bugfix. docbook2html still can't be used > as a proper filter, for example: >=20 > | docbook2html ... | tidy ... | ... Well then all the other backends are 'broken', if you take that attitude. I think a more useful approach is to have consistent behaviour across all the backends: that of generating one or more output files in the current (or a specified) directory. That's what the man page says it does. > This is un*x. Filters should be able to take input on standard in > and send output to standard out with errors to standard error. If jw were to output to stdout, it would (in general) need to send a tar file! > The blow chunks mode is also probably also a serious security > hole in many situations (it creates files on the host system with > names based on text supplied by the untrustworthy remote user who > supplied the file). Don't believe me? Try this > Yes, this is an interesting attack. The docbook-dsssl package by default makes up its own names for output files when chunking; the Red Hat Linux docbook-utils package comes with a default custom stylesheet which turns on a feature to use IDs as filenames. We'll be correcting that shortly. > Denial of service attack: Lets suppose that on a system with > a 65536 inode limit, I process a mailicious file which has 65536 > 's. I can say the same thing about tar files (for example). > On a related note, Docbook2html files actually need to be tidy'ed so > badly that you might consider making a call to tidy (with > configurable options), a built option (or better yet, fix the > generator - but that is probably jade). The output is technically > legal HTML but the formatting violates the spirit of HTML. The output is determined by the stylesheets. They are the way they are because of technical details---significant whitespace is the reason for '>' being separate to the rest of the element, for example. I'm sure that Norm would welcome patches that make the HTML output nicer to read. How's your DSSSL? ;-) (On the other hand, who is it that is editing generating output rather than editing the source?) > Another question: does either 0.6.9 or the upcoming release fix > the "URL not supported" problem? docbook2html chokes on the DOCTYPE > in files generated by abiword: > "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd" For a long time the Red Hat Linux openjade package came with HTTP support disabled. It is enabled in the current package (in Skipjack). But you might want to consider using an XSL processor for DocBook XML. Take a look at the xmlto package for a way to start. > Now, this appears to be at least two bugs: > - URL in DOCTYPE is unimplemented feature (Actually a feature that defaults to 'disabled'.) > - failure to use a good catch-all document type where an exact > stylesheet match is not found. This is an unreasonable requirement and would just generate bogus bug reports. People should install the DTD for the document they are processing. Tim. */ --WHz+neNWvhIGAO8A Content-Type: application/pgp-signature Content-Disposition: inline Content-length: 232 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8tYwVyaXy9qA00+cRAug/AJ9bFohV92O4OKB44QqrrwLLvsxSRACfaDJ1 L20K4nWg+1wVqm05dzxbLDc= =51gp -----END PGP SIGNATURE----- --WHz+neNWvhIGAO8A-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12398 invoked by alias); 11 Apr 2002 14:17:24 -0000 Mailing-List: contact docbook-tools-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: docbook-tools-discuss-owner@sources.redhat.com Received: (qmail 12364 invoked from network); 11 Apr 2002 14:17:22 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 11 Apr 2002 14:17:22 -0000 Received: from meme.surrey.redhat.com (meme.surrey.redhat.com [172.16.10.38]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id g3BEH7M10531; Thu, 11 Apr 2002 10:17:07 -0400 Received: from meme.surrey.redhat.com (localhost.localdomain [127.0.0.1]) by meme.surrey.redhat.com (8.12.2/8.12.2) with ESMTP id g3BDDxc4008952; Thu, 11 Apr 2002 14:13:59 +0100 Received: (from twaugh@localhost) by meme.surrey.redhat.com (8.12.2/8.12.2/Submit) id g3BDDwgE008950; Thu, 11 Apr 2002 14:13:58 +0100 Date: Thu, 11 Apr 2002 07:17:00 -0000 From: Tim Waugh To: Mark Whitis Cc: =?iso-8859-1?Q?=C9ric_Bischoff?= , docbook-tools-discuss@sources.redhat.com Subject: Re: multiple bugs and security hole (was: Re: BUG: docbook2html --nochunks) Message-ID: <20020411141357.J1633@redhat.com> References: <20020410080309.D13205@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="WHz+neNWvhIGAO8A" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from whitis@freelabs.com on Wed, Apr 10, 2002 at 10:40:59PM -0400 X-SW-Source: 2002-q2/txt/msg00016.txt.bz2 Message-ID: <20020411071700.UqIAvdb-sDdespHprh0kFLf-g56oqeCOYozvmgSQCrQ@z> --WHz+neNWvhIGAO8A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3346 Hi Mark, Thanks for your feedback. > Thanks for the quick response. I applied that patch directly to > /usr/bin/jw and it sorta-kinda fixed the problem. Still, it is a > kludge rather than a proper bugfix. docbook2html still can't be used > as a proper filter, for example: >=20 > | docbook2html ... | tidy ... | ... Well then all the other backends are 'broken', if you take that attitude. I think a more useful approach is to have consistent behaviour across all the backends: that of generating one or more output files in the current (or a specified) directory. That's what the man page says it does. > This is un*x. Filters should be able to take input on standard in > and send output to standard out with errors to standard error. If jw were to output to stdout, it would (in general) need to send a tar file! > The blow chunks mode is also probably also a serious security > hole in many situations (it creates files on the host system with > names based on text supplied by the untrustworthy remote user who > supplied the file). Don't believe me? Try this > Yes, this is an interesting attack. The docbook-dsssl package by default makes up its own names for output files when chunking; the Red Hat Linux docbook-utils package comes with a default custom stylesheet which turns on a feature to use IDs as filenames. We'll be correcting that shortly. > Denial of service attack: Lets suppose that on a system with > a 65536 inode limit, I process a mailicious file which has 65536 > 's. I can say the same thing about tar files (for example). > On a related note, Docbook2html files actually need to be tidy'ed so > badly that you might consider making a call to tidy (with > configurable options), a built option (or better yet, fix the > generator - but that is probably jade). The output is technically > legal HTML but the formatting violates the spirit of HTML. The output is determined by the stylesheets. They are the way they are because of technical details---significant whitespace is the reason for '>' being separate to the rest of the element, for example. I'm sure that Norm would welcome patches that make the HTML output nicer to read. How's your DSSSL? ;-) (On the other hand, who is it that is editing generating output rather than editing the source?) > Another question: does either 0.6.9 or the upcoming release fix > the "URL not supported" problem? docbook2html chokes on the DOCTYPE > in files generated by abiword: > "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd" For a long time the Red Hat Linux openjade package came with HTTP support disabled. It is enabled in the current package (in Skipjack). But you might want to consider using an XSL processor for DocBook XML. Take a look at the xmlto package for a way to start. > Now, this appears to be at least two bugs: > - URL in DOCTYPE is unimplemented feature (Actually a feature that defaults to 'disabled'.) > - failure to use a good catch-all document type where an exact > stylesheet match is not found. This is an unreasonable requirement and would just generate bogus bug reports. People should install the DTD for the document they are processing. Tim. */ --WHz+neNWvhIGAO8A Content-Type: application/pgp-signature Content-Disposition: inline Content-length: 232 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8tYwVyaXy9qA00+cRAug/AJ9bFohV92O4OKB44QqrrwLLvsxSRACfaDJ1 L20K4nWg+1wVqm05dzxbLDc= =51gp -----END PGP SIGNATURE----- --WHz+neNWvhIGAO8A--