Am Montag, März 18, 2019 23:52 CET, Jeremy Evans <jer...@openbsd.org> schrieb:
> On 03/18 11:11, Sebastian Reitenbach wrote: > > Hi, > > > > Am Sonntag, M??rz 17, 2019 19:46 CET, "Sebastian Reitenbach" > > <sebas...@l00-bugdead-prods.de> schrieb: > > > > > Hi, > > > > > > attached a port of wpscan: > > > > > > WPScan is a black box WordPress vulnerability scanner. > > > > > > I deliberately didn't named the port ruby-wpscan, since it's just a tool, > > > and it's known as just wpscan. If ruby-wpscan would be preferred, I can > > > for sure rename it. > > > needs all of those just sent new gems. > > > > > > comments, concerns, or even test or OKs welcome. > > > > due to the fact I deliberately wanted the port as security/wpscan, jeremy@ > > recommended > > to use: > > MODRUBY_HANDLE_FLAVORS = No > > GEM_FLAGS = --no-format-executable > > > > this changes the package name from ruby25-wpscan to wpscan, as well as the > > binary > > name from wpscan25 to wpscan. Which is way much nicer. Thanks for that. > > > > However, he was concerned about the number of pure ruby gem dependencies > > added with tight constraints, which might lead to conflicts in the future > > if similar > > package arises. I'd say, if really something comes up in the future which > > may conflict or cause trouble, > > it can be reviewed again. > > I see the number of dependencies, but for me portroach bugs me to keep them > > up-to-date, which I find incredibly convenient. Also, the very tight > > dependency from > > wpscan to cms_scanner is because, both are from the wpscan team, like a few > > other dependencies of the cms_scanner. Since they're from the same team, > > they'll likely keep them in sync, so I don't see the problem as dark as > > jeremy@ does. > > One of the dependencies is already out of date. ruby-tzinfo uses > 1.2.5, when 2.0.0 has been out for a couple months. > > Updating that is going to be problematic, because this depends on > activesupport, which limits tzinfo to <2, and which is not able to > work with tzinfo 2 (see https://github.com/rails/rails/pull/35368). > > What I recommended to sebestia@ was to bundle the pure-ruby > dependencies, and only add port dependencies for compiled dependencies. > That makes the conflict issue much less likely, and reduces the number > of ports that require maintenance. It is probably more work for the > maintainer to do the bundling, which may be the reason sebastia@ is not > too fond of the idea. > > I'm not objecting to this and all dependencies being imported. However, > I'm not going to review/OK the new ports. gonzalo@ got around to test and OK. anyone else interested in wpscan as a port? To test, you'd all need these NEW ports, and those already updated ports. Two of the NEW ports are already in, since they were new dependencies to update existing ports, namely ruby-thread_safe and ruby-public_suffix . I'd be happy to hear of more tests, and or OK. Last wpscan port attached, that's the one based on jeremy@ suggestions. thanks, Sebastian NEW security/wpscan NEW security/ruby-cms_scanner NEW devel/ruby-activesupport NEW devel/ruby-progressbar NEW devel/ruby-opt_parse_validator NEW devel/ruby-concurrent-ruby NEW devel/ruby-thread_safe NEW net/ruby-public_suffix NEW sysutils/ruby-tzinfo NEW www/ruby-typhoeus NEW www/ruby-ethon NEW www/ruby-xmlrpc UPDATE devel/ruby-yajl UPDATE devel/ruby-minitest UPDATE www/ruby-addressable UPDATE devel/ruby-i18n UPDATE textproc/ruby-nokogiri > > Thanks, > Jeremy >
wpscan.tar.gz
Description: application/gzip
