[dcc2] Multi file sends

Mon Apr 26 21:16:40 EDT 2004

Tom McAlee <tom at klient.com> said:

> I'm not a fan of XMLifying everything, although this does seem to be an
> appropriate use of it.  Like others have said, even without XML libraries it
> wouldn't be much more effort than parsing a tokenized string.  For those who
> have and/or already use XML libraries, it will fit right in.

Would parsing XML be trivial? Sure. Well, at least parsing valid XML. But 
lets face it, not everyone is nice and plays by the rules. You are going to 
have people who will develop specifically crafted XML headers to try and 
cause crashes and exploits. Anytime you build a parser, you run the risk of 
these kinds of things. What happens if someone specifies an invalid tag? What 
happens if they leave out an ending tag? For get a quote? Specify multiple 
angle brackets? There could be hundreds of potential areas of issue with XML 
because it is rather complex. However, with a simple text format, you don't 
need much more than a modified strtok() [to support quoted strings] in order 
to do your parsing. We've all seen the havoc that DCC bugs can cause (mIRC), 
and those bugs occurred while parsing the incredibly simplistic format DCC 
uses today. Using XML makes the format more complex and therefore more 
bugprone. For example, one thing I'm thinking of right off the top of my 
head. HTML-style encoding. What if I want my meta data to include 
<test>hey</test>? Or even in the file description. To do that, I'm going to 
need to &lt; and &gt; That means the parser is going to need to decode HTML-
style character codes. That is already making it a great deal more complex. 
With a simple text format, the only kind of escaping you need is one for " 
(\"). That's much easier than adding support for HTML character codes. 

If you use libxml/expat, you likely will not have problems (they are fairly 
well tested), but for those suggesting you can simply write your own basic 
parser, you're opening up a can of worms. If you do some Googling for "libxml 
exploit," you'll see that XML is no stranger to exploits and parsing bugs. 
Why introduce these problems into IRC? 

Also another security and general issue associated with multi-sends. I don't 
see anywhere the draft mentioning how paths should be handled. In the 
samples, they all use "/path" notation. Well that's fine for the *nix world, 
but on Windows that's no good. But lets look at the opposite. If I do 
<name>C:\dir\file.txt</name> How should a linux client deal with that? But, 
lets consider the dangers of allowing paths. <name>C:\windows\system32
\my.dll</name>. Something like that would apparently be allowed using the 
multi file send system. That seems horribly dangerous to me. Personally, I 
again don't see the need to specify path information. As someone else said, 
if that's what you want, there are tons of compression programs out there 
that can maintain path information.

> Somebody else brought up the possibility of writing binary data at the
> beginning of the file.  I'm not so sure about that idea.  Given the
> skepticism thats already out there concerning DCC2's security, an open XML
> format that is easily readable by anyone is probably preferable.  People are
> more comfortable with something when it is not obscured.

I still say a basic text format is best. Someone said my suggestion was no 
good because it doesn't allow meta data, so? Expand it so it can!
FILE <ID> "<FILE.EXT>" "<DESC>" <SIZE> <CRC> "<META DATA>"
FILE 1 "file.txt" "My fun file" 123 12341234 "Permissions=700 
Createtime=1234567890 Owner=joe"

That to me is much easier to parse than an XML file.

-- codemastr

> ----- Original Message ----- 
> From: "Phoenix Fyrestar" <miyako_houou at comcast.net>
> To: "DCC2 Working Group List" <dcc2 at dcc2.org>
> Sent: Monday, April 26, 2004 7:23 PM
> Subject: Re: [dcc2] Multi file sends
> 
> 
> > Yeah, that was the point I was trying to make, though I think you made it
> > better than I did.
> > At the end of the day, XML is not signifigantly more difficult to parse
> than
> > any other effective scheme, and we get the benefit of having an open and
> > human-readable standard that is well understdood by many applications with
> > much library support.
> > While it is always a good idea to consider alternate possiblities, I think
> > that spending too much time on comming up with another way may lead to
> > re-inventing the wheel so to speak.
> >
> > On Monday 26 April 2004 05:55 pm, Riley White wrote:
> > > On Apr 26, 2004, at 3:44 PM, Phoenix Fyrestar wrote:
> > > > I personally think that using XML is one of the better possible
> > > > solutions.
> > > > While I understand the reluctance to do this because it would require
> > > > an XML
> > > > parser, I think that any good solution would end up comming back to
> > > > something
> > > > XML-like anyway.
> > >
> > > I honestly don't understand why XML could be considered a bad thing
> > > here. Some sort of format is going to have to be defined, and why not
> > > XML? For those of us that don't want to link to XML libraries, we're
> > > really only dealing with one specific format of data so it can be
> > > manually parsed just like any other solution will have to be. For those
> > > of us that don't mind using XML libraries, we have that choice. Manual
> > > parsing of XML conforming to a known schema may be a little more
> > > difficult than whitespace delimited strings, but, speaking as somebody
> > > whose had to do it on a couple of occasions, it's not too bad.
> > >
> > > --Riley
> > >
> > > _______________________________________________
> > > dcc2 mailing list
> > > dcc2 at dcc2.org
> > > http://six.pairlist.net/mailman/listinfo/dcc2
> >
> > _______________________________________________
> > dcc2 mailing list
> > dcc2 at dcc2.org
> > http://six.pairlist.net/mailman/listinfo/dcc2
> >
> 
> _______________________________________________
> dcc2 mailing list
> dcc2 at dcc2.org
> http://six.pairlist.net/mailman/listinfo/dcc2
> 

-- 