Release 10.17 #832
Merged
Release 10.17 #832
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Summary of this PR: 1. Creates a new file called "nr_php_packages.c" which adds new php package management functions 2. Adds new unit tests to ensure php package management functions are working correctly 3. Add new function called "nr_txn_add_php_package" which adds php package information to transaction 4. Create new unit test to ensure php package information is added to transaction 5. Add "nr_txn_add_php_package" in fw_laravel.c to show how once we find the version, we will call this function which will add the php package information to the transaction --------- Co-authored-by: Michal Nowacki <[email protected]> Co-authored-by: bduranleau-nr <[email protected]> Co-authored-by: Michael Fulbright <[email protected]>
This PR adds: - Flatbuffer communications of PHP package info from agent to daemon - Data type (PhpPackages) for storing PHP package info in the daemon - Support for the `update_modules_loaded` endpoint for sendubg PHP package info --------- Co-authored-by: Michal Nowacki <[email protected]>
This PR adds test cases for php package version testing. The basic idea is to take a simple existing test for a framework or library and add an EXPECT_PHP_PACKAGES section. This will trigger special behavior in the integration_runner that will look for existing packages and then compare this to the php packages harvest generated by the agent. The form of the EXPECT_PHP_PACKAGES is: ``` EXPECT_PHP_PACKAGES command=composer show -f json supported_packages=../../../include/supported_php_packages.json ``` The `command` is whatever needs to be run to generate a list of installed packages in JSON. The test needs to know what the expected packages are - there are two options: - The `supported_packages` option points at a JSON file which is just a list of all the packagist style names for packages we expect to detect. The integration_runner will run the `command` given above and filter the list of packages reported to those given in the supported JSON file. The file `includes/supported_json_packages.json` is included in the PR with a list of packages the agent could detect at the time of the PR. - The `expected_packages` options accepts a list of package names that the agent is expected to detect. Ideally the `supported_packages` approach would be best as it would let the tests auto-detect the expected packages. But in early testing we hit cases where the agent was not detecting all the expected packages (the test case wasn't using all the installed packages so some were not detected by the agent). So using `expected_packages` to limit the expected to just what the test uses was added. There are packages for which the agent cannot determine the package version - only that the package exists. The `options=package_name_only` option is used to tell the integration_runner there is no version info expected. This works for many cases - but there are cases where one of the detected packages has a version and another does not. The suggestion for future work is to change this option to something like `package_name_only=<package list>`, where `<package list>` is a list of packages which are expected to only return package names. This would require reworking the integration_runner to implement. --------- Co-authored-by: Hitesh Ahuja <[email protected]>
This PR extracts the version for the following PHP packages and adds the package name and version to the transaction. - Drupal 8, 9, 10 (`drupal/core`) - Guzzle 6 (`guzzlehttp/guzzle`) - Slim (`slim/slim`) - PHPUnit (`phpunit/phpunit`) - Predis (`predis/predis`) - Wordpress In addition, this PR also sends information about the following PHP packages. For the packages that are being added without a version, an empty string will be sent as the version: - Laminas without version information (`laminas/laminas-mvc`) - Laravel with version information (`laravel/framework`) - Lumen without version information (`laravel/lumen-framework`) - Symfony without version information (`symfony/http-kernel`) - Doctrine without version information (`doctrine/orm`) - MongoDB without version information (`mongodb/mongodb`) - Monolog without version information (`monolog/monolog`) --------- Co-authored-by: Michal Nowacki <[email protected]> Co-authored-by: ZNeumann <[email protected]>
…ld be enabled (#818) This PR does the following: - Adds a `newrelic.vulnerability_management.package_detection.enabled` INI option, which disables or enables package detection for vulnerability management. This is set to on by default. - Adds INI check before adding a package to a transaction to ensure the option is enabled. - Adds package information to transaction for Joomla, Mediawiki, and Magento. The version is sent as an empty string because the version is unknown.
This change determines if the string "null" (with leading and trailing whitespace) was given as the `EXPECT_PHP_PACKAGES` stanza body and if so sets it to "null" to simplify later processing. Changes needed to test PR #818.
This PR includes the following: - Removes the "options" option which was used to specify that detected packages would not have version info. This was applied to all packages detected and was too limiting as some test cases had some packages with versions and others without (laravel for example). This has been replaced with the "package_names_only" options which allows giving a comma separated list of packages which only have names detected. - Adds checks to verify only one of "supported_packages" or "expected_packages" is given. - Improves how "expected_packages" was implemented to overcome some internal issues that existed. --------- Co-authored-by: Hitesh Ahuja <[email protected]>
To retain ability to build on older golang compilers.
Account for locale differences when generating the DT w3c tracestate header. Mitigates a risk against unexpected locale settings using `,` rather than `.` for the decimal priority value breaking the PHP Agent's DT w3c handling. --------- Co-authored-by: Michal Nowacki <[email protected]>
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #832 +/- ##
==========================================
- Coverage 78.74% 78.69% -0.06%
==========================================
Files 189 191 +2
Lines 26370 26599 +229
==========================================
+ Hits 20766 20933 +167
- Misses 5604 5666 +62
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
mfulb
approved these changes
Feb 9, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.