[dcc2] Multi file sends

Mon Apr 26 21:51:33 EDT 2004

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.

----- 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
>