[dcc2] Multi file sends

Mon Apr 26 21:51:06 EDT 2004

Tom McAlee <tom at klient.com> said:

> Good points about the XML.
> 
> But, where you are seeing that info about the paths?  From section 4.3.1 in
> the current draft:
> 
> 4.3.1  File
>    Specify the file name being sent.  No directory information is included.
I think you're looking at the wrong draft (there are two). 

http://www.dcc2.org/specifications/draft-smith-irc-dcc2-files-00.txt

3.2.4
[...]
<name>/docs/othertext2.txt</name>

-- codemastr

> ----- Original Message ----- 
> From: <codemstr at ptdprolog.net>
> To: "DCC2 Working Group List" <dcc2 at dcc2.org>
> Sent: Monday, April 26, 2004 9:16 PM
> Subject: Re: [dcc2] Multi file sends
> 
> 
> > 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
> >
> 
> _______________________________________________
> dcc2 mailing list
> dcc2 at dcc2.org
> http://six.pairlist.net/mailman/listinfo/dcc2
> 

-- 