Hi David, See the RHEL bug [1] for the shellacking this now rescinded CVE received.
Removing pip from the python side should also be accompanied by removing maven from the Java side, if you are serious about addressing the actual security concern raised in this CVE. (That malicious content may exist somewhere on the internet, and people can download it via http). Also, remove every node from NiFi that allows the ingestion of data from any source, by the same token. That'll also help reduce developer maintenance workload on these nasty CVE filled nodes ;) ;) ;) [1] https://bugzilla.redhat.com/show_bug.cgi?id=1835736 On Thu, 25 July 2024, 06:16 David Handermann, <exceptionfact...@apache.org> wrote: > Team, > > Apache NiFi 2.0.0-M1 introduced support for native Python Processors, > bringing new capabilities and some new questions. Part of that initial > release included the installation of Python pip for dynamic dependency > installation in the unofficial Docker images. Although this feature is > useful in some development scenarios, pip has several known > vulnerabilities, including CVE-2018-20225, related to the potential > for passing an option to reference additional repositories. Although > NiFi does not use this option, the presence of pip is a notable > security concern at the level of runtime package retrieval. > > With that background, it seems that we should remove pip from the > unofficial Docker image builds. This would bring closer alignment with > the convenience binary downloads, which do not have Python support > enabled in the default configuration. Although this would require > users to build their own images to add pip, it follows the general > principle of providing secure defaults. There is a developer usability > tradeoff, but we have had similar considerations in the past, and have > leaned in the direction of security. > > Regards, > David Handermann >
