Closed (fixed)
Project:
Drupal.org security advisory coverage applications
Component:
module
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
9 May 2023 at 22:42 UTC
Updated:
18 Jul 2023 at 16:54 UTC
Jump to comment: Most recent
Comments
Comment #2
shashank5563 commentedThank you for applying! Reviewers will review the project files, describing what needs to be changed.
Please read Review process for security advisory coverage: What to expect for more details and Security advisory coverage application checklist to understand what reviewers look for. Tips for ensuring a smooth review gives some hints for a smoother review.
To reviewers: Please read How to review security advisory coverage applications, What to cover in an application review, and Drupal.org security advisory coverage application workflow.
While this application is open, only the user who opened the application can make commits to the project used for the application.
Reviewers only describe what needs to be changed; they don't provide patches to fix what reported in a review.
Comment #3
shashank5563 commentedFix phpcs issues.
Comment #4
vishal.kadamComment #5
almunningsThanks for the responses thus far.
I've fixed the case for GraphqlComposeSchema
But am unable to replicate your results for CRLF.
Searching 248 files for "\r\n" (regex)
0 matches
Is this possibly something on your end? Do you have any suggestions on how to remediate, as I cannot see the CRLFs
Comment #6
almunningsComment #7
shashank5563 commentedIts looks fine to me.
Let’s wait for other reviewers to take a look and if everything goes fine, you will get the role.
Comment #8
vishal.kadam1. Remove the LICENSE.txt file. The LICENSE file isn't necessary. It will be added automatically by the packaging script.
2. As per Drupal coding standards (Function Declarations) function/method declarations must be in a single line. That code is formatted following the PSR12 coding standards, which are not the coding standards Drupal uses.
FILE: src/LanguageInflector.php
FILE: graphql_compose.api.php
FILE: src/Form/SettingsForm.php
FILE: src/Wrapper/EntityTypeWrapper.php
FILE: src/Plugin/GraphQLComposeEntityTypeManager.php
FILE: src/Plugin/GraphQLComposeFieldTypeManager.php
FILE: src/Plugin/GraphQLComposeSchemaTypeManager.php
FILE: src/Plugin/GraphQLCompose/GraphQLComposeEntityTypeBase.php
FILE: src/Plugin/GraphQLCompose/GraphQLComposeFieldTypeBase.php
FILE: src/Plugin/GraphQLCompose/GraphQLComposeSchemaTypeBase.php
3. FILE: src/Plugin/GraphQL/Schema/GraphQLComposeSchema.php
You should remove the methods if they are not used.
4. FILE: src/Plugin/GraphQLCompose/FieldUnionTrait.php
{@inheritdoc} is used if you are overriding or implementing a method from a base class or interface.
Comment #9
vishal.kadamComment #10
almunningsThank you again for looking into this.
#1 Done, thank you.
#2 I will not be changing.
#3 This is a requirement from the interface imported to create the form. Comment adjusted accordingly.
#4 Done, thank you.
In regards to #2 - I don't believe PSR12 is a blocking issue for security assessment, and the code adheres to the Drupal and DrupalPractice, and I will not be adjusting that.
Comment #11
avpadernoActually, these applications are for checking the following points, also described in Apply for permission to opt into security advisory coverage / Purpose.
It is a misconception that we just check for security issues.
Comment #12
almunningsAll good,
I just don't see any particular reference to PSR12 in the standards or in the linked documentation, and it adheres to the PHPCS rulesets.
Appreciate the guidance.
Comment #13
avpadernoThat is because Drupal coding standards are different from the PSR12 coding standards. There are no references to the WordPress coding standards, but that does not mean projects used for these applications can use WordPress coding standards.
Comment #14
almunningsWhich is fine. If you could just point to the standard?
Comment #15
avpadernoThe Drupal coding standards are described in Coding standards and its sub-guides.
Comment #16
avpadernoComment #17
almunningsThere is no mention about any of these requirements you are requesting.
If we could move on.
https://www.drupal.org/project/coding_standards/issues/3295249
Comment #18
avpaderno#3295249: Allow multi-line function declarations has been created exactly because the Drupal coding standards do not allow multi-line function declarations; if they were already allowed, that issue would not have been created.
That issue has not been marked Fixed; that means the Drupal coding standards do not allow multi-line function declarations.
Comment #19
almunningsI understand. But there is no standard here. There is a suggested standard. But I am not at present breaking any standard.
The documented standards do not state what you are asking me to do. The phpcs rules do not state what you are asking.
Unless you can show me otherwise.
Comment #20
simeI read this section of the the coding standards and they are ambiguous on the issue of multi-line. they don't mention single lines:
Functions should be called with no spaces between the function name, the opening parenthesis, and the first parameter; spaces between commas and each parameter, and no space between the last parameter, the closing parenthesis, and the semicolon. Here's an example:Additionally, given that there the open PR for allowing multi-line, that is aligned with PHP practice, and has core committer support, I think we shouldn't block this on this point.
I don't see any other issues in my reading of the ticket.
Comment #21
simeIt seems odd that phpcs doesn't pick this up.
Comment #22
simeFor examples see
core/modules/views/src/ViewsConfigUpdater.php, and contrib modules: key, config_split, jwt, admin_toolbar, metatag. (From a d9 project locally)Comment #23
almunningsAlso see:
- auditfiles
- commerce
- commerce_license
- devel
- eck
- monolog
- purge
- rabbit_hole
- scheduler
- simple_sitemap
- views_bulk_operations
The list could go on.
Comment #24
pameeela commentedSo I read the existence of #3295249: Allow multi-line function declarations as an indication that there is currently no standard for this. The purpose of that issue was to decide whether to allow them or not. Option A is to adopt the PSR-12 standard, and option B is to adopt a standard not to allow multi-line function declarations.
If #3295249: Allow multi-line function declarations were leaning toward option B, then this probably should be changed. But option A has been agreed and the issue is RTBC so it certainly seems safe to assume it will be adopted.
In the interest of moving things forward, @apaderno, would you remove your objection only if the issue to adopt the standard is marked fixed?
Comment #25
avpadernoIf we are going to use Drupal core as example, there are more methods/function declarations that are written in a single line.
As for contributed modules, they cannot be used as evidence; it is not that because another module wrongly uses the Drupal API, then these applications cannot report that a project used for an application is not correctly using the same Drupal API.
Also my comments have been for the following comment.
It is not true that in these applications only security issues are applications stoppers.
I don't believe […] is not a reason for not changing a file as per reviews. Otherwise, I don't believe I am passing the wrong arguments to
t(). would be a reason sufficient to not change code that passes user input as first argument tot().Comment #26
avpaderno@pameeela My objection is not to the code, but to the reply given to the reviewer, a reply that also shows a misunderstanding on what the reviews for these applications check.
Comment #27
pameeela commented@apaderno thanks for coming back to us but just wondering what it will take to resolve this?
If the other issue is marked fixed would that be sufficient to progress as is? Or are there any other blockers?
Comment #28
almunningsI have said I understand your position, and appreciate your guidance on the subject. I don't believe there is any misunderstanding here.
Comment #29
pameeela commentedSorry, I posted my reply before I saw yours! Understood and I think we both recognise that the review is not strictly about security-related blockers.
It seems there is a genuine debate about the current coding standard, so I was just weighing in on that.
Comment #30
avpadernoThe misunderstanding is that these applications just report security issues, or that only security issues are application blockers. I am not referring to other misunderstandings.
@pameeela This application will follow the same path followed by other applications. We cannot wait the issue on the Coding Standards queue is marked fixed, given that #2464123: Remove the requirement that no blank line follow an inline comment status has been Reviewed & tested by the community since 2019.
Comment #31
almunningsNo, your point is clearly understood. At post 30 I am well aware this is not just about security reviews.
Comment #32
pameeela commentedTo clarify, I wasn't suggesting that we *should* wait for it to be marked fixed, I was just trying to understand what the possible paths forward are.
Comment #33
quietone commented@AlMunnings, reached out to me on Slack about the multi-line function declaration coding standard issue here. I propose a way forward is to allow the project to use
phpcs:disableandphpcs:enablearound the function/method declarations. I suggest this because the associated issue in the coding standards project is RTBC, with core committer support, and is not controversial. It is help up on governance issues, not technical or lack of consensus. As for the governance, the committers are meeting next week and this is one of the topics for discussion.Cheers
Comment #34
almunningsSquiz.Functions.MultiLineFunctionDeclaration.OneParamPerLine appears to be the closest thing to a "kind of maybe what" we're discussing - But OneParamPerLine actually supports multi-line params. Its in the name.
I cant see any rule in https://github.com/drupal/drupal/blob/10.1.x/core/phpcs.xml.dist
And there isn't any supporting documentation against using multi-line.
The multi-line functions are not triggering any requirement for a phpcs:disable.
There is no phpcs errors returned from the code atm.
The ~closest~ thing to a standard I can suss is the RTBC policy.
As a first time contributor I'm just trying to do the right thing. The point I'm contending is that the PHPCS is now passing. I would love to continue the process beyond this.
Comment #35
quietone commentedOn the other hand, there is ViewsConfigUpdater in core which does use a multi-line constructor. Thanks to @AlMunnings for finding that. I did have a memory of such a file but I neglected to search for it. That was a mistake.
So #8 is incorrect in the interpretation of the relevant coding standard (as was I earlier). It is widely practiced that function parameters are on one line but not stated as a requirement in the standard. Sorry for any confusion, I am rather distracted with preparation for an overseas trip.
I hope that helps.
Comment #36
cmlaraAddtionaly per https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or...
It is important that this queue focuses on the more significant issues. We have had at least 2 applications be approved with XSS vulnerabilities present and at least 1 application with an Access Bypass vulnerability present in the past 12 months, security vulnerabilities are the most important portion of the review process and are often given the least amount of time. Yes security is not the only item reviewed as part of the process, but it is the portion that is intended to receive the most time along with legal compliance.
A single disputed coding standards being used to object to an application continuing is not in the spirit of this queues responsibility and qualifies as 'gatekeeping'.
Regarding #8 suggestion to remove the LICENSE.txt file:
Removing this file may be a breach of the GPLv2 license. Reviewers should never suggest removing the license file, especially when it was not created by the applicant and the applicant is not the sole copyright holder to the project.
Quoting the GPL (emphasis mine):
The fact that the Drupal.org packaging service adds the license.txt as part of packaging is irrelevant, it is suppose to be included with the source code available via GIT.
This is a know issue see: https://www.drupal.org/project/drupal_lwg/issues/1663716#comment-10214457
Comment #37
andypostWe should not postpone contribution waiting for standard accepted #1539712: [policy, no patch] Coding standards for breaking function calls and language constructs across lines
Comment #38
nigelcunningham commentedHi all.
I'm a coworker of Al, and have reviewed the project after he mentioned this thread, without being asked (ie I'm not being biased!). I'm not a member of the security team so can't approve the project or otherwise. Just doing community contrib.
I have read through the code, explicitly looking only for issues with security and such like. I've noted good commenting, good access control in the main module, careful control of the rendering of data and access control in the views integration.
The only class I noticed that allows data to be edited is modules/graphql_compose_comments/src/Plugin/GraphQL/DataProducer/CreateComment.php. This can create comments and looks fine to me.
I have a small number of notes:
1) I did note the entity_access hook in the menu submodule and wondered whether other submodules (eg users) should also implement that or similar hooks (or is the main module access control enough?).
2) In modules/graphql_compose_edges/src/EntityConnection.php, I noticed a mySQL specific comment (line 228). I'm not seeing anything mySQL specific in the database use but wondered whether the code had been checked against a Postgresql server.
3) There are a couple of @todos in the project. One in particular at modules/graphql_compose_comments/src/CommentableTrait.php, line 79 might need followup as a potential access control issue if I'm reading it correctly.
4) I'm not confident that I'm familiar enough with modules/graphql_compose_routes/src/GraphQL/Buffers/SubrequestBuffer.php and would request that someone else review it.
One other queries I have aren't security issues:
5) In graphql_compose_modules_installed in graphql_compose.module, is a module name starting with graphql_compose_ the best way of deciding whether to trigger _graphql_compose_cache_flush? (What if a module whose name doesn't start with _graphql_compose should also trigger a flush)?
6) The use of ??= in the return in the add method in src/Plugin/GraphQLComposeSchemaTypeManager.php - is that intended? (It looks potentially buggy or at least confusing to a reader of the code to assign it to the array only if the value doesn't already exist and return the array) from the method.
Regards,
Nigel
Comment #39
almunningsThanks Nij
1) I'll take this under advisement, the hook there is required to load the menu, whereas user data is just a fielded entity and it's permissions are done via the parent GraphQL module's resolver. I'm unsure that it's required elsewhere, but am interested if this is an acceptable method in general. I'll also note https://security.drupal.org/node/177775 could be relevant, but I was not involved with that discussion.
2)
I've not done any pgsql testing. This is working with pgsql, tested with 13. This functionality is seemingly copied from the OpenSocial module, any guidance appreciated.3) This is referring to the schema name that maps the input fields. EG: comment(data: { body: "hello" })
My concern with the todo is mostly UX based. If a field is named "bananas" by a user, the input would use the original fieldname of "body" - If this is considered a security issue I'm more than happy to modify this.
4) Any insight appreciated here, this is an upstream patch from GraphQL, implemented to avoid DX patching to get the module working with breadcrumbs. Any review could help contrib up the line to GraphQL. In our usage, the subrequest is required to ensure breadcrumbs build correctly.
5) Thanks for that, I agree, and have altered the method accordingly. https://git.drupalcode.org/project/graphql_compose/-/commit/84e26283bece...
6) I guess, it's fairly concise, it's just new.
---
Possibly to help aid further review, points of interest within the app are going to be any custom DataProducer plugins for GraphQL and yeah, hook access modifications. I hope I haven't been too sloppy.
Comment #40
almunningsTaking the consensus on #8 into account, I've updated the docblocks throughout the module(s) to be consistent with standards (I think?).
- 894c05a4
- 7309522d
- 4e58e2ae
- 160c4f03
- 4e944f81
- 3aab732f
Hopefully this reduces any further styling issue. As stated, this is my first adventure into module development on drupal.org, and all guidance is appreciated.
Do you have any further requirements @apaderno ?
I'm now not sure what you would like to happen from here.
Comment #41
cmlaraUpgrading priority per Application Review Timelines
Comment #42
vinaymahale commentedRechecked and found below PHPCS issues. Please fix.
Comment #43
almunningsDone
https://git.drupalcode.org/project/graphql_compose/-/pipelines/13020
Comment #44
vinaymahale commentedRan PHPCS tests. No issues were found. Let's wait for other reviewers
Comment #45
avpadernoThank 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 Slack #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 reviewers.
Comment #46
avpaderno