Creating a WPScan Gem

[ethicalhack3r]

@thesp0nge asked: "Another question guys... is there some background decision on about not creating wpscan as a rubygem? I think packing the scanner in a standard rubish CLI way can be a great deal don't you?"

[ethicalhack3r]

This was suggested to me right at the beginning of development of WPScan but the codebase then was pretty messy and it would have taken a lot of work to get it gem compatible. There has been great improvements to the code and organisation of it since then though and WPScan is more the 'ruby way' now so I think it should be much easier to accomplish.

[thesp0nge]

I can work on it on my fork and then submitting a new pull request

[ethicalhack3r]

Sounds great!

Just reading through the 'Package your programs as gems' chapter of Eloquent Ruby book to get myself acquainted with the process. :)

[gbrindisi]

Wouldn't packaging wpscan in a gem interfere with our git based updating mechanism? Genuine question, I have no experience in this.

Because In the case we'll have to wait to implement the web api to handle db updates.

[ethicalhack3r]

The gem won't include the very latest github code, so users will still update the normal way.

We'll just build gems from time to time which makes it easier for users to install and for us to distribute the code.

[ethicalhack3r]

Actually, user wouldn't be able to update in the usual way because they wouldn't have installed it with git.

[ethicalhack3r]

Maybe we can put gems out there for people who want the ease of installation, don't really care if it the very latest version. We'll release them every now and then.

But also keep what we do now for users who don't mind installing dependencies and want the very latest code.

[thesp0nge]

IMHO having a vulnerability DB API that the tool will prompt for KB updates it's a feasible approach

[gbrindisi]

Yes the development version will always be available from our public repository but we should try to stick with just one updating system.

Packaging everything in a gem is great but we should wait for the api to deliver db updates which are more critical than code changes.

[thesp0nge]

@gbrindisi it makes sense, however I think that porting the code base to gem it will require some coding time so I think that you'll have public API for KB updating.

An aside node... ruby is more familiar with JSON rather than XML (that has also minor overhead in terms of bytes), we can think about refactoring data format that wpscan will fetch from DB... is there any doc about DB API implementation?

[gbrindisi]

IMHO having a vulnerability DB API that the tool will prompt for KB updates it's a feasible approach

@thesp0nge yes this is our opinion as well and we are building a prototype right now. The problem is that we are actually delivering db updates trough git and we (IMO) can't afford to ditch it suddenly... while is perfectly acceptable to use outdated versions of the code without fresh db updates half of the functionalities of wpscan becomes useless.

I suggest this: let's plan a development roadmap that leads to the 3.0 milestone which comprises of the new gem architecture and the new api based update system. We stick to it, make tests, implement everything we need and once ready we release 3.0 in a nice gem wrap.

[ethicalhack3r]

@gbrindisi You're right, a gem will add complexity and maintainability issues for little benefit. We'll hang fire on this until the api is ready and then take another look at it then.

@thesp0nge We've just started working on public which is currently closed source. This is mainly headed by @gbrindisi.

[gbrindisi]

An aside node... ruby is more familiar with JSON rather than XML (that has also minor overhead in terms of bytes), we can think about refactoring data format that wpscan will fetch from DB... is there any doc about DB API implementation?

@thesp0nge We are still designing it. Anyway the prototype implements json as the api data format.
If you have suggestions I'd love to hear them (feel free to mail me or dm on twitter if you like).

[thesp0nge]

I suggest this: let's plan a development roadmap that leads to the 3.0 milestone which comprises of the new gem
architecture and the new api based update system. We stick to it, make tests, implement everything we need and
once ready we release 3.0 in a nice gem wrap.

@gbrindisi Super, keep me posted, I'd like to contribute if it's ok for you

[ethicalhack3r]

Closing this for now. We can re-open in future to take another look at it.

[thesp0nge]

Definitely it makes sense now. Let's freeze this one.

On 26 October 2012 11:59, ethicalhack3r notifications@github.com wrote:

Closing this for now. We can re-open in future to take another look at it.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/46#issuecomment-9808195.

$ cd /pub
$ more beer

The blog that fills the gap between appsec and developers:
http://armoredcode.com