Re: [NSE] Microsoft SQL Server (MSSQL) library and scripts

[Kris Katterjohn <katterjohn () gmail com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/28/2010 08:58 PM, Fyodor wrote:
> On Sun, Mar 28, 2010 at 07:54:59PM -0500, Kris Katterjohn wrote:
> > OK, I guess I'll be the first to actually argue :)
>
> Well I think I agree with your "argument" :).  I'm not suggesting we
> go wholesale combining scripts with different purposes just because
> they talk to the same service.  My suggestion relates to scripts which:
>  o Talk to the same service
>  o Their whole function is to query that service for information and
>    report it.
>  o Belong to (or can be made to properly belong to) the same
>    categories

I think I came off a tad the wrong way in my last email :)  I was speaking
moreso on script combination in general than based on any presumption of what
you had in mind.

I think combining scripts can be a good thing, as long as it's done the "right
way" wrt overall code maintainability, functionality, and with thought for
future script additions.  I believe I covered all of these, but I think my
"argument" comment may been inadvertently misconstrued... I meant "argue" more
as poking for more information and pointing out where there be dragons :)

> > I have
> > manually removed scripts which shared categories with previous ones in the
> > list (do correct my list if I made a mistake!).
>
> In so doing, you have removed all of the scripts I would want to
> combine :).

Well that's good news then :)

> I see the benefits of the combination as:
<snip>
> But I also see advantages to individual scripts, particularly in cases
> where:
<snip>
> I hope that makes sense.

This does make sense, and I think these are good things to think about.

> > Only combine them if the categories are similar?  I don't know how
> > you can have a file with mixed categories or how you could possibly call it
> > from --script.
>
> Right.  Scripts which are different enough to require different
> categories are probably different enough to remain separate.

Indeed.

> > Please note that I'm not saying don't combine any scripts!
>
> And I'm not saying we should combine all the scripts :).

As I mentioned, my use of script length was not related to the actual
combination of every script in those groups, but rather I was hoping to show
that since there will be more scripts in the future using these protocols then
we can get some big combo scripts, especially _if done poorly_.

I suppose I was trying to get to this question: What will you do if more
scripts are written in the future which are similar--and if they existed now
you would combine them--but a future script it's similar to has grown largely?
 Add it anyway under observation?  Keep it separate even though it's related?
 Split the large one into two combos?  I don't know.  I was saying "be
careful" because someone 3 or 5 years from now may suggest splitting scripts up :)

If dragons are avoided and the ideas you listed are pondered on, I don't think
combos are a bad idea :)

> Cheers,
> Fyodor

Cheers,
Kris Katterjohn

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJLsB3UAAoJEEQxgFs5kUfu1X4P+QG1urIYx5/vRZ+AfyZz+93K
Izl7bhCRAyeXpEOKtwqOVbYgaejMe5nwoirsti1UTeOVudn9N2w3WMaUuOglnxqs
stMUZzyCzjg1bp83sfpmlq5kgfm+pGA3M31MqCZWXUYFj9ic06as+a5IQ4NGUC/T
ecq2++Iqr6pdZS1WYw9gYX9RPEo0+2l1I/EDqXwnJ4gkdZ9iXbTG52e3PgsjQ1fA
PIiYzQRzk5KDNnMrkzqN3q8aSgJmoHYBAIa8kerT4SwSoY2PTawY/7m0TUAbWK39
2BufypWP8xNhzjlBz9e0LPAoslOvjiDi+Aoo5Pbv2wqLvPNZY+oSWRZCwpIEqNW1
TcKn/V+j1odZcAyACcvKmWCjPFeJvNvCkPOrjhojV2/bPi/gkADCZJZCf8SKmP28
3d56RAINAc+7XGaASNEiey1k9g3iS6lkSfev8gyoRdCAOtvX6JbzQj0CUSzEIZVx
cwtQG9+ygEU8yRqgAH3LNHm/JKyZ6DmhptmkTFeOz0QGQtiH//LLtRqJ9MzB03MH
L9GsU4nmBvdWvc1RKdDyzqrm6HUoLvshoDvJaI2YyhvzgBy2TBLqsScm726q5vFd
jnWbMR84bz04ffENEMY61hoKx6QI6aTlu3H3TN5fmatdAxvo4d3nskmU4JsvL4XH
dBitfpLdk0K19fYq1BX9
=KQ4w
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/