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

[Ingo Schwarze]

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
details.

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:

  <https://savannah.gnu.org/bugs/?55334>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/