The proposal sounds great to me. I know people often say NiFi Registry is confusing additional software to configure, and we often just us it to for its ability to sync to git.
One issue we've had with the new built in gitlab integration, is that we can't specify a custom CA trust for SSL. We are using the nifikop operator and it doesn't support adding multiple custom CA's. Since our gitlab is under a different CA we can't connect to it. It would be nice if this had a feature to define custom CAs/certs when adding the git registries. On 2026/01/12 17:49:25 Pierre Villard wrote: > Hello NiFi community, > > I'd like to start a discussion about the future of NiFi Registry and > propose that we deprecate this component. > > **Current State** > NiFi Registry has accumulated a significant number of security > vulnerabilities (CVEs) related to its Angular-based frontend, with the > count now reaching double digits. Unfortunately, these CVEs cannot be > resolved through simple dependency updates. The only viable path to > address the security issues requires completing a full rewrite of the > Registry UI to use modern Angular, an effort that was started but > remains incomplete as of today. > > **Maintenance Challenges** > Over the past several years, NiFi Registry has received minimal > maintenance attention. The UI modernization effort has stalled, and > there is currently no clear path to completion without significant > volunteer contributions. While an initial PR was submitted and merged, > the remaining work—including user/group management pages, > comprehensive testing, etc—still needs to be addressed. As a PMC, we > have an obligation to respond to CVEs in software we release. > Continuing to ship NiFi Registry with known, unresolved security > vulnerabilities is not sustainable. > > **Alternatives Available** > NiFi 2.x introduced direct integration options with Git-based registry > clients that provide an alternative path for flow versioning: > - Git-based registry clients offer native integration with existing > version control infrastructure > - These clients are actively maintained and do not carry the same security > debt > > The main feature gap is the permission model in NiFi Registry that > allows users to access specific flows based on permissions (useful for > multi-tenant deployments). With Git-based clients, access control is > typically all-or-nothing at the repository level. However, the > advantages of Git-based registry clients largely compensate for this > limitation for most use cases. > > **Maintenance Requirements** > If you or your organization depends on NiFi Registry and would like to > see it continue as part of the project, now is the time to step > forward and contribute to its maintenance. The work required includes: > - Completing the Angular UI rewrite > - Complete testing following the full rewrite > - Backend changes to have feature parity in terms of OIDC/SAML support > for authentication, remove support for Kerberos, etc > > **Proposal** > I propose that we: > - Immediately deprecate NiFi Registry - Mark it as deprecated in the > documentation and codebase, clearly communicating to users that they > should migrate to alternative solutions. > - Set a removal timeline - Plan to remove NiFi Registry from the > codebase as part of NiFi 3.0, giving users adequate time to migrate. > - Welcome community contributions - If any community members or > organizations rely on NiFi Registry and wish to maintain it, we > welcome contributions to complete the UI rewrite and address the > outstanding CVEs. The deprecation decision could be revisited if > substantial progress is made. > > Without active maintainers willing to do this work right away, > deprecation and eventual removal is the responsible path forward. > I look forward to hearing the community's thoughts on this proposal. > > Thanks, > Pierre >
