[dcc2] Multi file sends

Mark Cilia-Vincenti dcc2 at whybot.com
Wed Apr 28 12:21:01 EDT 2004 

I think it should be bigger than this in that it would be a section of
its own and you can put in a:

<module name>=<version number>


-----Original Message-----
From: dcc2-bounces at dcc2.org [mailto:dcc2-bounces at dcc2.org] On Behalf Of
Craig Edwards
Sent: 28 April 2004 09:46
To: DCC2 Working Group List
Subject: Re: RE: Re: [dcc2] Multi file sends

why not just have a 'filters=' section to your tags, so that you could
implement all compression and encryption as 'passthrough filters'. e.g.

filters=SSL,gzip,signed

etc...

>Jeremy Iverson <jeremy at algenta.com> said:
>
>> I think if we agree not to make clients require an extra library in
>> one area (XML), we shouldn't require a different library in another
>> area (zlib). That doesn't make much sense to me.
>I support adding zlib, but not as a standard. I mean, you have the
stuff to 
>implement SSL, so why not a token like Compression=mechanism
>
>So if you have the token, Compression=zlib
>then you know it's compressed using zlib. If you want to speed up file 
>transfers, compression is the way to do it.
>
>-- codemastr
>>  
>> 
>> -----Original Message-----
>> From: dcc2-bounces at dcc2.org [mailto:dcc2-bounces at dcc2.org] On Behalf
>> Of Craig Edwards
>> Sent: Tuesday, April 27, 2004 10:42 AM
>> To: DCC2 Working Group List
>> Subject: Re: Re: [dcc2] Multi file sends
>> 
>> 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
>> 
>> _______________________________________________
>> 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

More information about the dcc2 mailing list