- Issue created by @nicxvan
- 🇮🇹Italy apaderno Brescia, 🇮🇹
It's not clear to me why extending @internal would present a consideration for security coverage.
Applications to get the permission to opt projects into security advisory coverage verify what the person who applies understands about writing secure code that follows the Drupal coding standards and correctly uses the Drupal APIs, following the Drupal best practices. ( Apply for the permission to opt into security advisory coverage / Purpose → )
Verifying a class/method/function that is not backward compatible is not used is part of the correctly uses the Drupal APIs; that includes the internal classes/methods/functions and classes/methods/functions that are new in Drupal N that are used in modules compatible with previous Drupal releases. - 🇺🇸United States nicxvan
Thank you, I think the point to discuss is that it is acceptable to extend internal code, the only thing is the module author is responibke to test with new releases because core will not provide bc and deprecations.
- 🇮🇹Italy apaderno Brescia, 🇮🇹
it is acceptable to extend internal code
It depends on the code: If a class would extend an internal class just to add its own methods, when there is a base class, that would not be acceptable.
The purpose of the applications is pointing out those cases; not pointing out them would be not reporting that a module that is compatible with Drupal 10 and Drupal 11 is using a class that exist only in Drupal 11.