Description

The build_hooks module allows you to trigger a build hook on any service provider that supports build hooks.

The typical use case is for static sites built with Gatsby powered by the Gatsby Drupal source plugin.

This module mainly provides privileged users with a UI to:

- Trigger deployments of the connected static site(s) at will, or automatically via cron or when an entity is modified.
- View a log of the content that has been created, modified or deleted since the last deployment, by environment.

The 2.x version of the module is a major rewrite of the 1.0 version, with a new maintainer.

Project link

https://www.drupal.org/project/build_hooks

Git instructions

git clone --branch 8.x-2.x https://git.drupal.org/project/build_hooks.git

PAReview checklist

https://pareview.sh/pareview/https-git.drupal.org-project-build_hooks.git

Comments

vermario created an issue. See original summary.

avpaderno’s picture

Issue summary: View changes

Thank you for your contribution! I added the PAReview checklist. Reviewers will soon check the code and report here what they found out.

If you still haven't done it, please check what reported from the PAReview checklist. There could be some false positives; be careful of not changing code that should not be.

hasmimeraj’s picture

@vermario There are alot issue with your code. Please fix them specially naming convention to avoid name clashes in build_hooks.module file. Follow best drupal practice for code. First fix pareview error https://pareview.sh/pareview/https-git.drupal.org-project-build_hooks.git

avpaderno’s picture

Status: Needs review » Needs work
vermario’s picture

Status: Needs work » Needs review

Hi there!

I have fixed all the issues that were presented by the tool:

https://pareview.sh/pareview/https-git.drupal.org-project-build_hooks.gi...

It's still complaining about the line lengths (80 chars) in my readme.txt file. Is that a strict requirement? (it's just a text file, so I think probably not?)

vermario’s picture

klausi’s picture

Status: Needs review » Needs work
Issue tags: +PAreview: security

build_hooks.links.action.yml: the entity type name "frontend_environment" does not contain the module name, so that could be very confusing where this entity type is coming from.

function getLogItemsSinceTimestamp(): This is vulnerable to SQL injections. Never concatenate variables into SQL where() strings. Use the condition() method to pass variables as parameters to the database API. See https://www.drupal.org/docs/8/api/database-api/dynamic-queries/introduct... and https://www.drupal.org/docs/8/security/writing-secure-code-for-drupal-8

I think it is currently hard for an attacker to exploit the SQL injection since the timestamp is not directly read from user input but from the State API. Still, as a security precaution I would block this application until that is resolved. I also saw that the module already has a stable release, so probably best to create a security release once fixed and warn users about this attack vector.

And please don't remove the security tag, we keep that for statistics and to show examples of security problems.

getLogItemsSinceTimestamp(): the foreach() can be removed if you use fetchCol() from the database API.

vermario’s picture

Hello Klausi, thanks for your time looking into my module!

I understand your suggestion about the name of the entities: changing the machine name at this point would be problematic for the existing installs (in my projects for example) so I am thinking of leaving it. (naming things is famously hard :) )

As for the function, definitely an oversight on my part!

I have corrected the problem you have pointed out in this commit: https://cgit.drupalcode.org/build_hooks/commit/?id=9084560

And created a new point release with the fix: https://www.drupal.org/project/build_hooks/releases/8.x-2.1

Thanks again!

vermario’s picture

Status: Needs work » Needs review

Setting back to "needs review".

klausi’s picture

Status: Needs review » Reviewed & tested by the community

Thanks, otherwise looks good! Do not use \Drupal in classes like FrontendEnvironmentPluginCollection where you should use dependency injection instead.

Please also mark the recent release as security update once you get approved. If you can't do that from your end then please contact someone from the security team to help you with that.

avpaderno’s picture

Assigned: Unassigned » avpaderno
Status: Reviewed & tested by the community » Fixed

Thank you for your contribution! I am going to update your account.

These are some recommended readings to help with excellent maintainership:

You can find more contributors chatting on the IRC #drupal-contribute channel. So, come hang out and stay involved.
Thank you, also, for your patience with the review process.
Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.

I thank all the dedicated reviewers as well.

vermario’s picture

Thanks, this was interesting and learned some new stuff! :)

@kiamlaluno or @klausi : Apparently I cannot mark a release retroactively as a security update: as you suggested, could you do it for me?

https://www.drupal.org/project/build_hooks/releases/8.x-2.1 ?

avpaderno’s picture

Only the Security Team can mark a release as security update.

vermario’s picture

hi! i did report this, the people at the security team were satisfied with the current situation: since the data was not coming from the user it was enough that the problem was fixed in the current release.

Thank you again!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.