[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #55334] preconv fails when build with libuchardet on MS-Windows

From: Ingo Schwarze
Subject: [bug #55334] preconv fails when build with libuchardet on MS-Windows
Date: Mon, 31 Dec 2018 08:05:19 -0500 (EST)
User-agent: Mozilla/5.0 (X11; OpenBSD amd64; rv:63.0) Gecko/20100101 Firefox/63.0

Update of bug #55334 (project groff):

                Severity:              3 - Normal => 5 - Blocker            
                  Status:                    None => Confirmed              
             Assigned to:                    None => bgarrigues             
         Planned Release:                    None => 1.22.5                 


Follow-up Comment #1:

I confirm that this is a bug.  Of course we cannot use fseek(3) on the input
stream, and using fstat(2) is also dubious at best.  Since groff utilities are
typically used in pipes, this breaks typical use cases, so i'm changing the
severity to "blocker"
and the planned release to 1.22.5.

Assigning to bgarrigues@ because he intregrated uchardet.
Of course, anyone is welcome to fix it.

However, i strongly object to the attached patch.  Please do not commit it. 
It introduces obvious security vulnerabilities.  In particular, it uses
tmpnam(3), which is almost never acceptable and almost always vulnerable, even
when used carefully; on top of that, the present patch is using it in a
totally naive and careless way.  See https://man.openbsd.org/tmpnam.3#BUGS for

Even using mkstemp(3) instead would be very ugly, and i would not particularly
like that.  We really shouldn't have to create a temporary file merely for
charset recognition.

One possibility for a proper solution might be to read a sufficient amount of
text from the input stream into memory, then work purely in memory (for
example, mandoc does it that way), but i did not check whether that easily
works with the architecture of preconv(1) and uchardet.

If it turns out there is no viable solution, then i would strongly prefer
completely removing the broken uchardet support rather than making matters
even worse with buggy interfaces like tmpnam(3).


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]