search

SamJoan / droopescan

A plugin-based scanner that aids security researchers in identifying issues with several CMSs, mainly Drupal & Silverstripe.
GNU Affero General Public License v3.0
1.22k stars 246 forks source link

update version in the code #36

Open blshkv opened 5 years ago

blshkv commented 5 years ago

I have installed the latest version, however the scanner displays v1.33.7 during runtime

https://github.com/droope/droopescan/blob/master/dscan/common/functions.py#L217

masterwebsk commented 5 years ago

The same issue, but, after check I see also outdated versions (at least for Drupal)

# droopescan stats

v1.33.7

Functionality available for 'drupal':

Versions should be 8.6.13, 7.65

Trying to update:

# pip install -U droopescan Requirement already up-to-date: droopescan in /usr/local/lib/python2.7/dist-packages Cleaning up...

Still the same version + outdated Drupals 7&8´s

SamJoan commented 5 years ago

Hi @blshkv ,

It always report 1.3.37 because it is hard-coded here. This is because I had an issue where the tool became completely broken because the code that attempted to read the version wasn't able to read the changelog.

I would consider a PR for this if you provide one, otherwise it is just an aesthetic issue so it would not be a high priority for me atm.

Thanks! Pedro

SamJoan commented 5 years ago

hi @masterwebsk

This occurs because a couple of new drupal versions have been released and I haven't been able to implement a new hash for them. I will do my best to get this updated asap however at the moment I am super swamped so a PR would be better if you're in a hurry.

droopescan has the ability to update itself, you'd need to clone the master branch of the repo and then run ./droopescan update --help for more information.

Keep in mind this is a development tool not meant for the end user. It clones drupal and other CMS' from github and performs a hash of the files required to perform identification, and then inserts them into the versions.xml file. I meant to document this process more thoroughly but I haven't had the time either.

Thanks! Pedro

blshkv commented 5 years ago

@droope thank you for your replies. How about go KISS, hardcode the correct version and update it every time if you can't find a better solution?

BTW, We (at Pentoo) install all tools as system-wide packages and expect users to run them under regular account (if possible), that means self-update feature will not work. In fact, we do not allow to update tools itself (such as binaries, configuration etc) because it is more like a malicious behaviour. All system-wide files must be installed and be under control of a package manager. Please keep it in mind while further implementing this feature.

SamJoan commented 5 years ago

hi @blshkv

Thanks for your feedback! I'll definitely keep in mind the idea of hard-coding the version. At the moment I use release scripts that don't take the version into account, but I will consider the option in the future.

Thanks! Pedro

SamJoan commented 4 years ago

I've given this more thought and after thinking about it hard-coding the version would cause more issues that it would solve, because even though I am as thorough as I can when releasing new versions I can be liable to forget to update the code as it is.

I think the proper solution is to either

a) update the release script so that it modifies the version, or b) update the function that displays the version to parse the CHANGELOG file. This is what I had tried earlier and caused errors at runtime, because it is not trivial to locate a text file within a python installation on all operating systems, as the location varies due to various python configurations and file system layouts.

I am open for a PR for this if anybody is willing to do it. I am busy with other projects at the moment and I am limiting myself to base maintenance for this project.

Thanks! Pedro