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

Bug#2100: Efax: errors in /usr/bin/fax



  b c writes:
  Brian> Package: efax
  Brian> Version: 07a
  Brian> Revision: 4
  Brian>
  Brian> 1) The security hole still exists because the "&C0" command is still
  Brian> present when going into "answer" mode on systems that will accept
  Brian> incoming data connections.  The string "&C1" should be added to the
  Brian> DATAINIT variable on such systems.  I have heard that some modems
  Brian> will not receive faxes under this setup, however.

Yes, you reported that once before as bug#1949. The author of efax is aware
of this, but has no answer (yet). A new version of efax is due RSN anyway.
All I can do at this stage is to but a warning into /etc/efax.rc just before
the DATAINIT declaration. I doubt that many people use efax for fax and data
calls.

  Brian> 2) The 'sed' line that processes the device name into a log-file
  Brian> name needs a small fix in case (for some oddball reason) the device
  Brian> name has more than one slash in it. (line 394)
  Brian>
  Brian>     From: eval DEVN=`echo $DEV|sed -e s./._.`
  Brian>     To:   eval DEVN=`echo$ DEV|sed -e s./._.g`

Wait a sec. A common definition of DEV is cua1 or cua3. There is not even
_one_ slash, let alone two. I don't see the the merit of this patch.

  Brian> 3) An incorrect directory is specified for "answer" mode. (line 427)
  Brian>
  Brian>     From: if cd $FAXDIR ; then :
  Brian>     To:   if cd $FAXINDIR ; then :

That is indeed a bug, caused by the qfax patch that I integrated on
demand. I'll fix this one and report it upstream to the qfax author.

I close this bug report, given that 1) is still open as bug#1949.

--
Dirk Eddelb"uttel                              http://qed.econ.queensu.ca/~edd


Reply to: