Newer tin

Date: Wed, 28 Oct 1998 00:43:08 -0800
From: John Nemeth <jnemeth@cue.bc.ca>
To: csuite-tech@chebucto.ns.ca
Precedence: bulk
Return-Path: <csuite-tech-mml-owner@chebucto.ns.ca>

next message in archive
no next message in thread
previous message in archive
previous message in thread
Index of Subjects

Index of Subjects
On Oct 22,  1:20pm, Sean Garagan wrote:
} 
} Has anyone looked at using the latest tin version for CCN?  I have been
} following the rather uproarious comments from a few of the CCN users on the
} newsgroups, so I spent an hour going through the code last night.
} 
} It looks like the memory usage has gone down, altho that is a very
} preliminary look, further investigation is definately in order on that
} front.  They have prepared it for i18n, with only one case of English
} specific pluralization ("Added %d group%s").  I can't remember exactly what
} the /tmp race condition was, but they are using mktemp() for their temp file
} creation, which as I remember, does not check for a prexisting file.

     The /tmp race could be fixed by defining DONT_LOG_USER.  It was a
feature that logged who was using tin in a file in /tmp.  BTW,
mktemp() is insecure on many OS'es and should never be used.  It ranks
right up with gets() and sprintf().  The proper solution is to use
mkstemp().  To be completely portable, they may have to include a copy
of mkstemp() with the distribution.  If they're using mktemp() then
they haven't learned much about secure programming.

} It does have some nice features, not least of which is colour.  They have
} also improved threading and grouping, among other things.
} 
} So it looks like that i18n for it will be significantly easier than it was

     Sounds neat, but it also sounds like they need to learn something
about secure programming then audit the code.

}-- End of excerpt from Sean Garagan

next message in archive
no next message in thread
previous message in archive
previous message in thread
Index of Subjects