Hi Matthew, Thanks for highlighting the Red Hat response to CVE-2018-20225. Although the CVE was not withdrawn, the Red Hat response is worth noting.
The point of noting that CVE was not the issue itself, but the level of support for additional package installation in runtime deployments. Focusing on that particular point, Maven is not included in the Apache NiFi Docker image. As a composable processing system, NiFi supports custom solutions that could be considered potentially dangerous, so the purpose is not to simply check a box for security. The purpose of raising this particular question is to consider the default distribution approach, allowing users to make further decisions. Regards, David Handermann On Wed, Jul 24, 2024 at 6:51 PM Matthew Hawkins <hawko2...@gmail.com> wrote: > > 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 > >
