Re: Feature removal proposal

One word on the "show your face" thing:

I have studied the code to evaluate how big the known
security issues are. The problem is: How much buffer 
space do you need to expand a gif compressed picture ?
I found this hard to do.

My personal bottom line was not to invest the toil of really
security audit this obsolete function.

Johannes

On Thu, Apr 15, 2004 at 08:46:26PM +1000, Soren H wrote:
> On Thu, Apr 15, 2004 at 10:26:54AM +0200, Attila Konietzka wrote:
> > Hello Soren,
> > Thanks for your request regarding these Features, so let me commend on what
> > i think.
> > >
> > > * "Show your face" graphics.  This comprises a complicated part of
> > > both the source code, and also the transmission protocol.  It is known
> > > to contain some problems, and I don't think any of the current
> > > developers know how it works.
> > 
> > Well I think it's not something that should remain in speak-freely because i
> > would rather implement some file transmission feature, and if someone asks
> > me what i look like, i can send him my jpeg-foto or do this image-exchange
> > totally via E-Mail.
> 
> It could be replaced by an option to locally associate a picture with
> a remote connection, as that would overcome the security issues of
> accepting untrusted image files.  That would need someone keener than
> I to get it done though.  My feeling is that unless someone steps up
> to learn the image transmission protocol and do an audit of the code,
> then the face feature will disappear from the next release.
> 
> > >
> > > * Simple 2x compression (4kHz sampling).  This is a special-case
> > > "compression mode" because it can be used in conjunction with other
> > > modes.  With the modern codecs and faster CPUs, I don't see this being
> > > useful anymore and it complicates the decoding process.
> > >
> > 
> > Well i had my bad experiences with this mode of compression, because lpc and
> > lpc10 as well as celp don't like this way of extra-compression, also the
> > speex codec integrated for testing purposes by john h. would crash the whole
> > program when used with simple compression, and afterall the speex codec
> > works also with 133 mhz pentium cpus as i was once running a teamspeak
> > server who would force the speex 9,1 Kbit/s codec upon anyone conecting to
> > my server, this only in case anyone here knows how teamspeak works.
> > 
> 
> Really, none of the modern codecs will work properly with it, because
> they are tuned to 8kHz sampling.  Even without the coding issues, it
> may be worth dropping for the sake of usability.  One codec at a time
> is enough for many users to worry about.
> 
> > > * VAT protocol.  This was made obsolete by RTP many years ago. Does
> > > anyone still use it?  Protocol detection is one of the more awkward
> > > areas, so reducing the options from 3 to 2 may help.
> > 
> > I agree, since vat is somehow outdated, and most programs use rather rtp for
> > this kind of communication i would agree on removing this protocol,
> > especially because it can't handle the whole crypto-stuff alltogether.
> > >
> > > * direct modem communications.  With the ubiquity of the internet, is
> > > this still likely to be of use?
> > >
> > 
> > PLEAAAASEEEEE don't remove it!!!! Because it is somehow necessary still in
> > some poorer countries in the world to exchange freely his communications so
> > that the opressors wouldn't hount you, for they had tapped your line and can
> > use anything what you said against you.
> > By the way, does this still work in 7.6a? i didn't find the modem connection
> > box, this was only something i found in the old 16bit versions of
> > speak-freely, in their options dialog so how does this work in 7.6a?
> > 
> 
> Ah, this is the type of response I was after.  The modem stuff is in
> the codebase, but it is all within #ifdef MODEM constructs.  It's
> possible that it simply wasn't enabled in 7.6a, or there could be a
> problem with it.  I've never looked at how it works myself, and just
> seen it in the code.  So far it hasn't got in my way, but I'm aware
> that it will be difficult to test and debug any modem handling issues
> after the code clean-up.  It would be good to hear from anyone who
> uses this feature so we can make sure it stays working if it is
> valuable. 
> 
> > > * Old version compatibility.  Is there anyone who would have problems
> > > if the next version released were not compatible with some versions of
> > > speakfreely prior to 7.6?   I think good backward compatibility will
> > > remain regardless, but it would be good to hear any constraints on
> > > this.
> > >
> > Well with the removal of some protocols and the removal of show-your-face
> > feature some of the compatibility will be lost to the versions which still
> > have this feature, but what do you mean besides this? Is there still for
> > example some connection-initialization bloat or more than one hand-shaking
> > routine that's coming with speak-freely, that needs to be run all through
> > sequencially in order for speak-freely to connect to all it's predecessors?
> > Any hint on what you specially mean would be appreciated.
> > Thanks, and keep up your good work all of you Developers.
> > 
> 
> The issue here is that if we weren't concerned about
> backward-compatibility, then we'd redesign the speakfreely protocol.
> It's valuable to retain interoperability though, but my question is
> how far back should this go?  Things like face removal won't stop
> compatibility for all the other features, but there are some more
> subtle issues.  In parts of the code there are hacks to workaround
> bugs in earlier versions, which are by now many years in the
> past. It's probably time to start removing some of those hacks, and
> force an upgrade on any person who is happening to still use the
> really old version and wants to talk to someone with a new version. 
> 
> It's mainly to ask is there anyone who knows they cannot upgrade to at
> least version 7.6a for some reason - and if so, what that reason is.
> It could be because it stopped working on some particular platform
> after version x.y.  It's not that we are likely to break compatibility
> with older versions, but more if there are any specific issues to have
> in mind.
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Speak-freely-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/speak-freely-users


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click