🇮🇹Italy @apaderno

No post/comment needed to be published.

That page is a view which uses view-drupalorg-docs-management and view-id-drupalorg_docs_management as CSS classes. I take it is a view defined in a drupal.org customization module/feature.

avpaderno → changed the visibility of the branch 8.x-1.x to hidden.

I added the feed to Planet Drupal ( https://www.drupal.org/aggregator/sources/2095 → ).

I changed ownership as requested. I also confirmed the progressivedigital account, since only confirmed accounts can edit organization nodes.

The publication date for the articles is October first, 2024. That does not make the articles appear on Planet Drupal. I would suggest to either change the publication date for those articles or add a new article.

Also, this module does not contain PHP code, which means it cannot install any module. It can eventually add a new module to the Composer requirements.

A task issue needs to describe what needs to be done and why. A title is not sufficient for an issue.

A module does not usually install another module, except in the case both the modules are part of the same project.
In the case the projects are different, a module should add the other module as dependency, if that module is really required for the first module to run. Otherwise, the first module can implement hook_requirements() to show a suggestion to install the other module.

I am closing this issue because there has not been any follow-up action as described in How to become project owner, maintainer, or co-maintainer → from the person who opened this offer.

I am closing this issue because there has not been any follow-up action as described in How to become project owner, maintainer, or co-maintainer → from the person who opened this offer.

Since multiple offers have been open, without giving any detail on what the plan is, and no follow-up action has been done, I am going to close this issue.
This project is also covered by the security advisory policy; it means we should be careful in adding co-maintainers who cannot opt projects into security advisory coverage.

(I am changing title to better track these issues. I apologize for bumping this issue.)

Thank you for applying!

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.

The important notes are the following.

• If you have not done it yet, enable GitLab CI for the project, and fix what reported from the phpcs job. This help to fix most of what reviewers would report.
• For the time this application is open, only your commits are allowed. No other people, including other maintainers/co-maintainers can make commits.
• The purpose of this application is giving you a new drupal.org role that allows you to opt projects into security advisory coverage, either projects you already created, or projects you will create. The project status won't be changed by this application.
• Nobody else will get the permission to opt projects into security advisory policy. If there are other maintainers/co-maintainers who will to get that permission, they need to apply with a different module.
• We only accept an application per user. If you change your mind about the project to use for this application, or it is necessary to use a different project for the application, please update the issue summary with the link to the correct project and the issue title with the project name and the branch to review.

To the reviewers

Please read How to review security advisory coverage applications → , Application workflow → , What to cover in an application review → , and Tools to use for reviews → .

The important notes are the following.

• It is preferable to wait for a Code Review Administrator before commenting on newly created applications. Code Review Administrators will do some preliminary checks that are necessary before any change on the project files is suggested.
• Reviewers should show the output of a CLI tool → only once per application. The configuration used for these tools needs to be the same configuration used by GitLab CI, stored in the GitLab Templates repository.
• It may be best to have the applicant fix things before further review.

For new reviewers, I would also suggest to first read In which way the issue queue for coverage applications is different from other project queues → .

The feed needs to have at least two articles posted in the past three months and three weeks. Only an article has been published this year; the other ones have been published in 2024, or later.

The feed passes validation.

Since patches are no longer tested, the issue needs to provide a merge request. The description of the issue needs to go in the issue summary, which must be updated.

I am not sure that removing the rules for the .form-item--error-message::before selector is the right way to fix the issue: Inline errors need to be styled; if a selector is still used in absence of errors, that could be a problem with the code that adds that selector.

📌 TestDiscovery expects @group annotations, fails with #[Group()] attributes Active has been marked as duplicate of 📌 Deprecate TestDiscovery test file scanning, use PHPUnit API instead Active , which has been fixed. I guess this issue should be no longer postponed.

Expanded the text to at least say which tools should be used for automatic reviews; made clear why using the same configuration files for PHP_CodeSniffer and PHPStan GitLAb CI use is better.

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Config%21... redirects to https://api.drupal.org/api/drupal/11.x/search, with a Sorry, the path api/drupal/core%21lib%21Drupal%21Core%21Config%21Entity%21ConfigDependencyManager.php/class/ConfigDependencyManager/11.x cannot be matched against any page in this branch. Try searching by one of the components of the path. message.

I added smustgrave as co-maintainer.

I published 🐛 SchemaIncompleteException when saving Views with Facets filters - Missing processor schema definitions Active .

I am crediting boobaa, who confirmed the account.

These offers need to be created in the project issue queue, even when the person asking for more permissions is already co-maintainer or maintainer. As per Offering to become a project owner, maintainer, or co-maintainer → , they can be moved in the Drupal.org project ownership queue → , 14 days after the offer was posted/moved in the project queue, if the offer has not been declined by maintainers (including the project owner).
Remember to give the project link, when the issue is moved.

The time for adding a co-maintainer is the same for unsupported project and supported projects.
Projects are marked unsupported to let people know they should consider another project, not to make the time to add a new maintainer shorter.

This is the message I sent.

Hello Dave,

I am contacting you because Andrey ( https://www.drupal.org/u/andypost → ) offered to become maintainer for #project (#link), a project you created for which you are project owner and sole maintainer, to host the Drupal core module with the same name. (The Drupal core module will be deprecated and removed from Drupal core.)

May you post a comment on https://www.drupal.org/project/projectownership/issues/3521198 📌 Create 3.x branch to import core module Active about accepting or declining the offer? Please do not reply via email; we need a reply on the offer issue.
Without a comment posted on that issue in the next 14 days, Andrey will be probably made maintainer.

Project moderators will not remove the existing maintainers/co-maintainers; the project owner will not be replaced either. Maintainers cannot change the project owner; co-maintainers/maintainers can only be removed/added by people who have the permission to administer co-maintainers/maintainers.

As last note: This offer is about being maintainer, which is different from being co-maintainer. A maintainer is a person who has all the drupal.org permissions on a project: Write to VCS, Edit project, Administer maintainers, Maintain issues, Administer releases. A person who does not have all those permissions is a co-maintainer.
If there is any reason for not giving all those permissions, please explain that on https://www.drupal.org/project/projectownership/issues/3521198 📌 Create 3.x branch to import core module Active . We need this to know it was intentional and not a misunderstanding on what the offer required.

Best regards,
Alberto Paderno
-- Drupal.org project moderator
-- Drupal.org site moderator

The status is Postponed because we are waiting for a reply.

Please post a comment after 14 days, if your offer has not been declined. It will show you are still interested in maintaining this project and it will serve as reminder an action is required for this offer.

I apologize: I will handle this after my lunch.

Also ddev composer create drupal/recommended-project:^10 needs to be changed.

I am not sure the shown commands need to be updated; Drupal 10 is still supported.
I would rather make explicit the shown commands are for Drupal 10; in this way, a beginner person would not use them to install Drupal 11.

The issue summary does not contain the project link. Which one is it?

An issue asking whether a project is still maintained cannot be changed to an offer to become co-maintainer once it is moved to the Drupal.org project ownership queue.

If nagy.balint wants to be co-maintainer, he needs to create a new issue in the project queue. I am not going to mark the project abandoned, if nagy.balint's intention is offering to be co-maintainer.

This issue has been closed as duplicate but no link to the duplicated issue has been provided. Is the correct status, or should the issue be closed as Closed (won't fix), which should be done by maintainers?

Since patches are no longer tested, a merge request needs to be provided.

composer create-project drupal/cms is the correct command. Why do you propose to change it?

Let's see if other reviewers report other changes.

IMHO a hash calculated from user input should be treated as user input here but I could be wrong.

The example given in the PHP documentation is clear about what they call "user input": It is a value completely provided by the user. They also make clear that a value given in the HTTP request is considered "user input." $computed_hash is not provided in the HTTP request, so it is not "user input."
$known_string is not a value stored in a database, though; it is the value I get from the function to calculate the "hash." To make a different example, if I store in a database the largest integer supported by PHP, what I should I consider the known value when checking the value stored in the database? PHP_INT_MAX, not the value stored in the database.

I'm not fluent in C but my understanding is that it matters in algorithms that can handle hashes with a different length (which hash_equals() does not support currently but could add in the future) because it could stop the comparison early if the user string and known string are inverted.

Two strings are equal if they have the same length and all their bytes are equal. With a four-byte string and a five-byte string, only four bytes can be compared, but the strings are still different because they have different lengths.

Since the code cannot be optimized, C code is not much different from PHP code. In both the cases, two bytes can be compared in constant-time by XORing their value. (A XOR B is 0 when A and B have the same value, and it is different from 0 when A and B have different values.) Eventually, since constant-time code avoids if statements, the code could use $result = $known_string_length - $user_string_length; instead of if ($known_string_length !== $user_string_length) { return; }, but the code woud still be XORing the bytes.
Eventually, the C code could be different if it is rewritten to in Assembly and all the CPUs would have instructions to compare two strings in constant-time. The alghoritm would not change, though.

I do not have time for a complete review, but the following code needs to be changed.

  /**
   * DynamicReferenceSelectionUtil constructor.
   *
   * @param \Symfony\Component\DependencyInjection\ContainerInterface $container
   *   The container service.
   */
  public function __construct(ContainerInterface $container) {

    $this->container              = $container;
    $this->entityFieldManager     = $container->get('entity_field.manager');
    $this->fieldTypePluginManager = $container->get('plugin.manager.field.field_type');
    $this->request                = $container->get('request_stack')
      ->getCurrentRequest();
  }

Services define their dependencies in the .services.yml file, and those are directly passed to the class constructor.

Thank you for applying!

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.

The important notes are the following.

• If you have not done it yet, enable GitLab CI for the project, and fix what reported from the phpcs job. This help to fix most of what reviewers would report.
• For the time this application is open, only your commits are allowed. No other people, including other maintainers/co-maintainers can make commits.
• The purpose of this application is giving you a new drupal.org role that allows you to opt projects into security advisory coverage, either projects you already created, or projects you will create. The project status won't be changed by this application.
• Nobody else will get the permission to opt projects into security advisory policy. If there are other maintainers/co-maintainers who will to get that permission, they need to apply with a different module.
• We only accept an application per user. If you change your mind about the project to use for this application, or it is necessary to use a different project for the application, please update the issue summary with the link to the correct project and the issue title with the project name and the branch to review.

To the reviewers

Please read How to review security advisory coverage applications → , Application workflow → , What to cover in an application review → , and Tools to use for reviews → .

The important notes are the following.

• It is preferable to wait for a Code Review Administrator before commenting on newly created applications. Code Review Administrators will do some preliminary checks that are necessary before any change on the project files is suggested.
• Reviewers should show the output of a CLI tool → only once per application. The configuration used for these tools needs to be the same configuration used by GitLab CI, stored in the GitLab Templates repository.
• It may be best to have the applicant fix things before further review.

For new reviewers, I would also suggest to first read In which way the issue queue for coverage applications is different from other project queues → .

• The following points are just a start and don't necessarily encompass all of the changes that may be necessary
• A specific point may just be an example and may apply in other places
• A review is about code that does not follow the coding standards, contains possible security issue, or does not correctly use the Drupal API
• The single review points are not ordered, not even by importance

src/Form/NodeSwapperConfirmForm.php

  /**
   * The config factory.
   *
   * @var \Drupal\Core\Config\ConfigFactoryInterface
   */
  protected $configFactory;

A parent class already defines that property, which does not need to be re-declared.

  public function __construct(
    ConfigFactoryInterface $config_factory,
    RequestStack $request_stack,
    Connection $connection,
    AliasManagerInterface $alias_manager,
    TimeInterface $time,
    EntityTypeManagerInterface $entity_type_manager,
    NodeSwapperService $node_swapper_service,
    NodeInterface $src,
    NodeInterface $dest,
  ) {
    $this->configFactory = $config_factory;
    $this->requestStack = $request_stack;
    $this->database = $connection;
    $this->aliasManager = $alias_manager;
    $this->time = $time;
    $this->entityTypeManager = $entity_type_manager;
    $this->nodeSwapperService = $node_swapper_service;
    $this->src = $src;
    $this->dest = $dest;
  }

  /**
   * {@inheritdoc}
   */
  public static function create(ContainerInterface $container) {
    return new static(
      $container->get('config.factory'),
      $container->get('request_stack'),
      $container->get('database'),
      $container->get('path_alias.manager'),
      $container->get('datetime.time'),
      $container->get('entity_type.manager'),
      $container->get('node_swapper.service'),
      $container->get('current_route_match')->getParameter('src'),s
      $container->get('current_route_match')->getParameter('dest'),
    );
  }

create() should also call $this->setMessenger() with the messenger service retrieved from the container.

    $message = '';
    $message .= "<p>This will point all alises and redirects of \"{$src_node->label()}\" to \"{$dest_node->label()}\".</p>";
    $message .= "<p>In addition, <b>ALL</b> aliases of \"New Node\" will be deleted. Redirects will not be deleted.</p>";

$message needs to be a translatable string.

There are no unpublished posts/comments.

I did not find any post/comment to publish.

The issue summary should explain what needs to be improved and why.

I published ✨ Webform Booking/Scheduling (Date Range Selection) Active and confirmed the account.

Truly, this application should get reviewed by other reviewers too. A partial review is not sufficient to change the status to Reviewed & tested by the community.

Truly, this application should wait for other reviewers.

The code has not been changes as for my previous #38 📌 dbc:2.1.x Needs review comment.

Truly, the arguments order does not matter with the previous implementation either.

mod_len = MAX(known_len, 1);

/* This is security sensitive code. Do not optimize this for speed. */
result = known_len - user_len;
for (j = 0; j < user_len; j++) {
    result |= known_str[j % mod_len] ^ user_str[j];
}

RETURN_BOOL(0 == result);

C code to compare in constant time two strings cannot be much different from the previous implementation and the actual implementation. I cannot see in which way they could rewrite the code to be dependent from the arguments order and still be constant-time code.

The issue summary says Drupal core uses hash_equals() in multiple places. The merge request just fixes the given example, but it should fix all the hash_equals() calls, when the user input is passed as first argument.

It is not a matter of pre-calculated values, which would eventually be values I calculate before I need them (and store in some places), not right before calling hash_equals().

In PhpassHashedPasswordBase::check(), the attacker is trying to guess the password so the hash computed from the sent password has to be second.

$computed_hash is not user-input. The user can just change the entered password, but finding a password that gives a specific hash is only possible by brute force, by definition of cryptographic hash, which is invertible and collision resistant.
With passwords, the operation is more complex, and it is more difficult to find a password that gives an exact $computed_hash.

When the PHP doc says the known string "must be kept secret" it does not mean it can't be stored, it means it is the sensitive string that an attacker would be trying to get with a timing attack.

You missed the point. Neither $computed_hash nor $stored_hash is user-input (provided in the HTTP request), so there is no difference in choosing which value to pass as second argument; my preference is for $stored_hash, which could not be the preference somebody else has. It is no longer a matter of user input. (This does not mean the arguments order should not be changed.)

Timing attacks work by sending a lot of different values and checking if the time it takes the server to respond vary.

The only way to avoid timing attacks is using constant-time code, which does not mean just using hash_equals().

In the example used by the PHP documentation, the hash calculated from a value provided by the user is passed as first parameter, not second.

// Value and signature are provided by the user, e.g. within the URL
// and retrieved using $_GET.
$value = 'username=rasmuslerdorf';
$signature = '8c35009d3b50caf7f5d2c1e031842e6b7823a1bb781d33c5237cd27b57b5f327';

if (hash_equals(hash_hmac('sha256', $value, $secretKey), $signature)) {
    echo "The value is correctly signed.", PHP_EOL;
} else {
    echo "The value was tampered with.", PHP_EOL;
}

$known_string is the calculated hash, which must be kept secret. It cannot be a value stored in the database.

I added matthijs as maintainer.

Thank you for applying!

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.

The important notes are the following.

• If you have not done it yet, enable GitLab CI for the project, and fix what reported from the phpcs job. This help to fix most of what reviewers would report.
• For the time this application is open, only your commits are allowed. No other people, including other maintainers/co-maintainers can make commits.
• The purpose of this application is giving you a new drupal.org role that allows you to opt projects into security advisory coverage, either projects you already created, or projects you will create. The project status won't be changed by this application.
• Nobody else will get the permission to opt projects into security advisory policy. If there are other maintainers/co-maintainers who will to get that permission, they need to apply with a different module.
• We only accept an application per user. If you change your mind about the project to use for this application, or it is necessary to use a different project for the application, please update the issue summary with the link to the correct project and the issue title with the project name and the branch to review.

To the reviewers

Please read How to review security advisory coverage applications → , Application workflow → , What to cover in an application review → , and Tools to use for reviews → .

The important notes are the following.

• It is preferable to wait for a Code Review Administrator before commenting on newly created applications. Code Review Administrators will do some preliminary checks that are necessary before any change on the project files is suggested.
• Reviewers should show the output of a CLI tool → only once per application. The configuration used for these tools needs to be the same configuration used by GitLab CI, stored in the GitLab Templates repository.
• It may be best to have the applicant fix things before further review.

For new reviewers, I would also suggest to first read In which way the issue queue for coverage applications is different from other project queues → .

This issue queue is for reporting changes to the documentation. It is not an issue queue for reporting bugs in contributed projects, nor for asking support for those projects.

I removed the articles from that feed and suspended it.

May you give a title of an article from that feed shown on Planet Drupal?

It is not possible to search for feed URLs; searching for drupal.com.ua in this issue queue does not give any issue link, not even the link for this very issue.

Lines like the following ones needs to be changed, then.

return $computed_hash && hash_equals($stored_hash, $computed_hash);

$computed_hash is the expected hash, not the user-provided value.
In that case, there is no user-provided value, but a value stored in the database, which could be altered. If I follow that warning, it is $stored_hash that needs to be passed as second argument.

I did not check all the hash_equals() calls, but there are more lines that should be changed, if we follow to the letter the warning given in the PHP documentation.

Thank you for applying!

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.

The important notes are the following.

• If you have not done it yet, enable GitLab CI for the project, and fix what reported from the phpcs job. This help to fix most of what reviewers would report.
• For the time this application is open, only your commits are allowed. No other people, including other maintainers/co-maintainers can make commits.
• The purpose of this application is giving you a new drupal.org role that allows you to opt projects into security advisory coverage, either projects you already created, or projects you will create. The project status won't be changed by this application.
• Nobody else will get the permission to opt projects into security advisory policy. If there are other maintainers/co-maintainers who will to get that permission, they need to apply with a different module.
• We only accept an application per user. If you change your mind about the project to use for this application, or it is necessary to use a different project for the application, please update the issue summary with the link to the correct project and the issue title with the project name and the branch to review.

To the reviewers

Please read How to review security advisory coverage applications → , Application workflow → , What to cover in an application review → , and Tools to use for reviews → .

The important notes are the following.

• It is preferable to wait for a Code Review Administrator before commenting on newly created applications. Code Review Administrators will do some preliminary checks that are necessary before any change on the project files is suggested.
• Reviewers should show the output of a CLI tool → only once per application. The configuration used for these tools needs to be the same configuration used by GitLab CI, stored in the GitLab Templates repository.
• It may be best to have the applicant fix things before further review.

For new reviewers, I would also suggest to first read In which way the issue queue for coverage applications is different from other project queues → .

It that's really the case, should we try to get the PHP doc fixed?

The PHP documentation should not show the It is important to provide the user-supplied string as the second parameter, rather than the first. warning, which seems to be a left-over from the previous implementation.
IMO, it does not generally make sense. For example, in Drupal, hashes are not always values users provide.

Looking at the C code used by php_safe_bcmp(), I would say that inverting the arguments does not increase the possibilities of timing attacks.

	const volatile unsigned char *ua = (const volatile unsigned char *)ZSTR_VAL(a);
	const volatile unsigned char *ub = (const volatile unsigned char *)ZSTR_VAL(b);
	size_t i = 0;
	int r = 0;

	if (ZSTR_LEN(a) != ZSTR_LEN(b)) {
		return -1;
	}

	/* This is security sensitive code. Do not optimize this for speed. */
	while (i < ZSTR_LEN(a)) {
		r |= ua[i] ^ ub[i];
		++i;
	}

	return r;

r |= ua[i] ^ ub[i]; and r |= ub[i] ^ ua[i]; would take the same amount of time to run.

I take that in the following code the $known_hash parameter should be $computed_hash, and the $user_string parameter should be $stored_hash.

return $computed_hash && hash_equals($stored_hash, $computed_hash);

(In other words, the correct code should be the following one.

return $computed_hash && hash_equals($computed_hash, $stored_hash);

I did not check all the calls to hash_equals(). There could be other cases where the arguments must be inverted.

I am not sure the code should be changed as for the first point. Checking the string lengths in PHP could make the code more susceptible of timing attacks. If that is not a reason for changing code, the first point should be removed from the issue summary.

Is there any evidence that passing the arguments in the wrong order would increase the possibilities of timing attacks?
Given that base64_encode() and base64_decode() are not constant-time, and both the functions are used by Drupal core, would just fixing the arguments-order for hash_equals() make Drupal core code less prone of timing attacks?

The typical path to confirming users usually involves reviewing the content created on this site. In this case, you have not created any content except this post, so there is no content to review.

I am postponing this issue, for now. After you have posted some content on this site, you may want to add a comment to this issue to request a new review.

Please see Become a confirmed user for information on the role and how it is granted.

Thank you and welcome!

I can do it, but not before July 10. (I am a little busy these days.)

Anything that GitLab replaces should be reverted, including <one line to give the program's name and a brief idea of what it does.>.

The license file does not contain any header. It starts with GNU GENERAL PUBLIC LICENSE.

See the merge request I created in the project issue queue. It contains the correct license file.

I usually create the license file from the GitLab interface, knowing that <year> and <name of author> are replaced by the current year and the name of the person adding the file, when they should not be.

avpaderno → created an issue.

I do not have time to make a more complete review, but the following point needs to be fixed.

Projects hosted on drupal.org are licensed under GPLv2+, the same license used from Drupal core. If you are licensing a project under a different license, it cannot he hosted on drupal.org. More details are given in Drupal Git Contributor Agreement & Repository Usage Policy → .

All code that is a derivative work of Drupal (typically PHP code, including but not limited to: core patches, modules, themes, etc) committed to Drupal.org's git repository is licensed as GPL version 2.0 and later (official short identifier: “GPL-2.0-or-later”). This means that the code is licensed under GPLv2, and there exists an option that allows downstream recipients to re-license the code to be under a later version of GPL.

For code licensed under GPLv3, see See I want to release my work under GPL version 3 or under GPL version 2-only. Can I do so and host it on Drupal.org? →

No. You can release your work under any GPL version 2 or later compatible license. However, you may only check it into Drupal's Git repositories if you are releasing it under the same license as Drupal itself, that is GPL version 2 or later, allowing users to choose between the terms of the GPL version 2 or the terms in any new versions as updated by the FSF. If you are unable or unwilling to do so, do not check it into a Drupal Git repository.

Thank you for applying!

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.

The important notes are the following.

• If you have not done it yet, enable GitLab CI for the project, and fix what reported from the phpcs job. This help to fix most of what reviewers would report.
• For the time this application is open, only your commits are allowed. No other people, including other maintainers/co-maintainers can make commits.
• The purpose of this application is giving you a new drupal.org role that allows you to opt projects into security advisory coverage, either projects you already created, or projects you will create. The project status won't be changed by this application.
• Nobody else will get the permission to opt projects into security advisory policy. If there are other maintainers/co-maintainers who will to get that permission, they need to apply with a different module.
• We only accept an application per user. If you change your mind about the project to use for this application, or it is necessary to use a different project for the application, please update the issue summary with the link to the correct project and the issue title with the project name and the branch to review.

To the reviewers

Please read How to review security advisory coverage applications → , Application workflow → , What to cover in an application review → , and Tools to use for reviews → .

The important notes are the following.

• It is preferable to wait for a Code Review Administrator before commenting on newly created applications. Code Review Administrators will do some preliminary checks that are necessary before any change on the project files is suggested.
• Reviewers should show the output of a CLI tool → only once per application. The configuration used for these tools needs to be the same configuration used by GitLab CI, stored in the GitLab Templates repository.
• It may be best to have the applicant fix things before further review.

For new reviewers, I would also suggest to first read In which way the issue queue for coverage applications is different from other project queues → .

Remember to change status, when the project is ready for review, as in this queue Active means Don't review yet the project I am using for this application.

Thank you for applying!

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.

The important notes are the following.

• If you have not done it yet, enable GitLab CI for the project, and fix what reported from the phpcs job. This help to fix most of what reviewers would report.
• For the time this application is open, only your commits are allowed. No other people, including other maintainers/co-maintainers can make commits.
• The purpose of this application is giving you a new drupal.org role that allows you to opt projects into security advisory coverage, either projects you already created, or projects you will create. The project status won't be changed by this application.
• Nobody else will get the permission to opt projects into security advisory policy. If there are other maintainers/co-maintainers who will to get that permission, they need to apply with a different module.
• We only accept an application per user. If you change your mind about the project to use for this application, or it is necessary to use a different project for the application, please update the issue summary with the link to the correct project and the issue title with the project name and the branch to review.

To the reviewers

Please read How to review security advisory coverage applications → , Application workflow → , What to cover in an application review → , and Tools to use for reviews → .

The important notes are the following.

• It is preferable to wait for a Code Review Administrator before commenting on newly created applications. Code Review Administrators will do some preliminary checks that are necessary before any change on the project files is suggested.
• Reviewers should show the output of a CLI tool → only once per application. The configuration used for these tools needs to be the same configuration used by GitLab CI, stored in the GitLab Templates repository.
• It may be best to have the applicant fix things before further review.

For new reviewers, I would also suggest to first read In which way the issue queue for coverage applications is different from other project queues → .

I published ✨ Add filter option for bynder compact view Active and confirmed the account.