On 03/18 11:11, Sebastian Reitenbach wrote: > Hi, > > Am Sonntag, M??rz 17, 2019 19:46 CET, "Sebastian Reitenbach" > <[email protected]> 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. Thanks, Jeremy
