David I had a feeling this was going to be a thing once that person posted about it in nifi slack yesterday...
To the extent we want the docker images to be a developer convenience mechanism then pip staying there is important. To the extent we want the docker images to be production ready then pip being there is not great for the reasons mentioned. Though the images need a lot of improvement. Matt - Maven and Pip do indeed both get used to source dependencies. Maven is used at build time whereas Pip is used at runtime. The necessary security posture is different. I don't think the point here is that the CVE is specifically applicable but rather sourcing dependencies at runtime is not an ideal production practice without some additional controls in place. Thanks Joe On Wed, Jul 24, 2024 at 4: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 > > >
