Package validation and quality checking are failed because of sensitive data (test/certs/server.key)

[sergei-aivazian]

Is it possible to exclude tests data from final package?
To decrease amount of loaded data and don't load test code with test data in production?

[jsumners]

Thank you for your interest in this topic. Please see the discussion in fastify/skeleton#42 (comment) for my reasoning against such a change.

[lancerdima]

The issue highlighted in the issue header has nothing to do with package size.

The precence of server.key is flagged by security scanning software (e.g. AquaScan) as sensitive data. As our project is to be deployed within the regulated corporate environment, our team is forced to migrate away from pino/pino-socket because of this issue.

Would be great, if team behind pino-socket reconsiders the presence of test components not just to reduce the size of the package, but to make sure community can use pino without hidden obstacles.

[jsumners]

The issue highlighted in the issue header has nothing to do with package size.

Read the part about maintaining exclusion and inclusion lists.

The precence of server.key is flagged by security scanning software (e.g. AquaScan) as sensitive data.

In my experience, such tools have ways to mark false positives. We are not responsible for your tooling.

As our project is to be deployed within the regulated corporate environment

Pino is used by many large, very well known corporations.

our team is forced to migrate away from pino/pino-socket because of this issue.

Would be great, if team behind pino-socket reconsiders the presence of test components not just to reduce the size of the package, but to make sure community can use pino without hidden obstacles.

We do not condone this sort of entitlement to our time. These modules are provided as-is; the license is very clear. As such, I am closing this issue as not planned. However, if you would like to resolve the issue, you are quite welcome to submit a pull request that resembles fastify/fast-proxy#72.