[dcc2] Multi file sends

Tue Apr 27 11:41:47 EDT 2004

i'll second this, im very anti-xml, and xml libraries are bloated, slow, and not easy to develop things for especially when the format only needs to be simple.

As for 'using compression programs that preserve path information' why cant we use zlib or something to gzip up the whole thing into some form of zip or tarball, and send that as a data stream, with a header appended?

Thanks,

Craig

>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
>> 
>
>
>
>-- 
>
>
>
>_______________________________________________
>dcc2 mailing list
>dcc2 at dcc2.org
>http://six.pairlist.net/mailman/listinfo/dcc2