Transient framework dependencies / Security alerts

[Mathias Stocker]

Hi there

According to https://wiki.lyrasis.org/display/DSPACE/DSpace+Software+Support+Policy 

>  The DSpace Committers provide security updates/support for the most recent three (3) major releases of the platform.

As i can see, the version 7 branch of dspace-angular uses v15 for Angular, version 8 branch uses v17 and version 9 branch uses v18.

The only active supported Angular version of these three is v18, which is supported until this november (!).

This leads to transient dependency vulnerabilities.
In our project we have multiple moderate to critical security alerts which are related to the outdated Angular version used.

The same questions arise with regard to the backend. At least without paid enterprise support for the Spring framework.

IMHO updating to newer / maintained Framework versions should be part of the actively maintained DSpace versions.

Is there any ongoing discussion in this matter?
Would you accept PRs increasing the Framework version?

Best regards
Mathias

[DSpace Developers]

Hi Mathias,

While we do our best to upgrade dependencies in prior releases, Angular upgrades are often quite complex.  So, we've had to take the policy of (often) keeping each DSpace major version *pinned* to a major version of Angular.  This means that if you want to upgrade Angular, it's best to upgrade your entire DSpace release.

The reason for this decision is that Angular upgrades usually are not straightforward, and often require touching very large numbers of files.  For example:

* Here was our DSpace upgrade to Angular 16: https://github.com/DSpace/dspace-angular/pull/2871

* Here was our DSpace upgrade to Angular 17: https://github.com/DSpace/dspace-angular/pull/2934

* Here was our DSpace upgrade to Angular 18: https://github.com/DSpace/dspace-angular/pull/3717  (this also required an upgrade to Bootstrap 5: https://github.com/DSpace/dspace-angular/pull/3506)

Each of these PR is very large (2K-8K range), touching a very large number of files.  Additionally, some Angular upgrades require other upgrades (like Angular 18 requiring also upgrading to Bootstrap 5), which makes the effort even larger.

Because of the size of these Angular upgrades, when institutions perform these, they often will need to perform manual updates to their themes and similar.  This makes the process much more similar to a *major upgrade* of DSpace, instead of a minor upgrade. This is why we recommend the approach of upgrading your entire DSpace rather than attempting to "patch" a DSpace 7 or 8 site up to Angular 18 / Bootstrap 5.  In many cases it'd be *easier* for sites to upgrade to DSpace 9 than to backport these patches to an older version of DSpace.  

Additionally, as you noticed, because our DSpace major release schedule doesn't always match up well with Angular's major versions, there are sometimes gaps where an Angular release might go out of free support before our next DSpace major release.  But, in that scenario, it's worth noting it is possible to purchase Angular commercial support for sites that need it.  See https://endoflife.date/angular and https://www.herodevs.com/support/nes-angular. 

All of the above is not to imply we'd *never* backport an Angular major version upgrade.  If the Angular major version is mostly "backwards compatible" and provides a more seamless upgrade process, then we'd gladly include it in a minor DSpace release.  It's just been our experience that this is not often the case.

Everything above is much more specific to the frontend.  With regards to the backend, we do our best to upgrade Spring (and similar backend technologies) in minor releases where possible to do so.  In some cases, the upgrade is minor and can be done easily.  But, in other cases, it's not possible because the extent of the upgrade is too complex.  For instance, DSpace 7 still uses Spring 5 and cannot be easily upgraded to Spring 6. The reason is that Spring 6 *requires* using Jakarta EE, which was a massive change requiring upgrades also to Hibernate, Flyway, etc.  See https://github.com/DSpace/DSpace/pull/9321   

This again was such a large change that backporting it to DSpace 7 would prove highly complex. Instead, sites should upgrade to DSpace 8 or 9, which both use the latest versions of Spring 6 and Spring Boot 3.

Overall, our approach is to do our best to backport security fixes for transitive dependencies within reason.  If they are easy to backport, we'll do them immediately.  But, in the situation of Angular (and sometimes Spring), some are highly complex to backport, as they require updating other major dependencies as well.   So, in those scenarios, we unfortunately have to "pin" that DSpace major release to specific major releases of Angular (and sometimes Spring), and tell users to upgrade their DSpace if they want these dependencies updated.

I hope this helps clarify the situation, but further questions are welcome.

Tim

[Max Nuding]

Hi Mathias,

an upgrade is planned, at least for DSpace 10:

https://github.com/DSpace/dspace-angular/issues/4372

Ideally, every DSpace version that is currently under support should be
running on an angular version which is currently supported.
But with DSpace being run by volunteers and angular support windows
being quite a bit shorter than the DSpace support window, this will be
pretty hard.

Best
Max

On 30.09.25 16:19, 'Mathias Stocker' via DSpace Developers wrote:
> Hi there
>
> According to https://wiki.lyrasis.org/display/DSPACE/
> DSpace+Software+Support+Policy
>

> > The DSpace Committers provide security updates/support for the***most
> recent three (3) major releases <https://wiki.lyrasis.org/display/
> DSPACE/Releases#Releases-ReleaseNumberingScheme> *of the platform.

>
> As i can see, the version 7 branch of dspace-angular uses v15 for
> Angular, version 8 branch uses v17 and version 9 branch uses v18.
>
> The only active supported Angular version of these three is v18, which
> is supported until this november (!).
>
> This leads to transient dependency vulnerabilities.
> In our project we have multiple moderate to critical security alerts
> which are related to the outdated Angular version used.
>
> The same questions arise with regard to the backend. At least without
> paid enterprise support for the Spring framework.
>
>
> IMHO updating to newer / maintained Framework versions should be part of
> the actively maintained DSpace versions.
>
> Is there any ongoing discussion in this matter?
> Would you accept PRs increasing the Framework version?
>
> Best regards
> Mathias
>

> --
> All messages to this mailing list should adhere to the Code of Conduct:
> https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx <https://
> www.lyrasis.org/about/Pages/Code-of-Conduct.aspx>
> ---
> You received this message because you are subscribed to the Google
> Groups "DSpace Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to dspace-devel...@googlegroups.com <mailto:dspace-
> devel+un...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/dspace-
> devel/240d6465-c6c1-4d34-8914-1c905d4cbc0dn%40googlegroups.com <https://
> groups.google.com/d/msgid/dspace-devel/240d6465-
> c6c1-4d34-8914-1c905d4cbc0dn%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

--
Herr Max Nuding
Softwareentwickler / Abt. IT-Dienste für Forschung und Lehre
Kommunikations-, Informations-, Medienzentrum (KIM)
Universität Konstanz
78457 Konstanz
Tel.: +49.7531.88-4658
Raum: B 707

[Mathias Stocker]

Hello Tim

Thanks for your time to give me a detailed explanation which will help us with our update / migration decisions.

I understand that updating the frameworks for all three currently supported versions can be difficult and requires a lot of effort.

However, in my opinion, the statement in your wiki regarding security updates is a bit misleading, if it does not also apply to keeping main dependencies up-to-date, and this should at least be mentioned somewhere.

Best regards
Mathias

[DSpace Developers]

Hi Mathias,

The intention of the statement on our wiki was meant to reference support for fixing security issues within DSpace code itself.  However, I can understand how it could be misunderstood to imply that we will always be able to backport all dependency security patches/updates.  Unfortunately, that's often not possible in software development, as dependency updates are not always "backwards compatible" (and that is the scenario you are referencing... major versions of Angular are often *not* backwards compatible, which makes them very difficult to "backport").

To try to clarify, I've added a new bullet that says:

• Keep in mind, when vulnerabilities arise in dependencies (or dependencies go "end-of-life"), we may not always be able to apply the dependency update to all supported releases of DSpace. While we do our best to apply security-based dependency updates to all supported releases, any dependency updates that are not reasonably "backwards compatible" may only be possible to apply to the most recent release(s).

https://wiki.lyrasis.org/display/DSPACE/DSpace+Software+Support+Policy

While I know this isn't really the answer you are hoping for, this is a reality for DSpace. (Honestly, most other open source software products would have this same answer.)  DSpace is entirely built by volunteers. We have no central development team. Therefore it's usually not possible to backport changes which require a massive overhaul / refactor to old code. 

So, based on that, you may want to consider upgrading more frequently, or potentially purchasing longer-term support for Angular (as it is often the dependency with the biggest challenge regarding avoiding EOL).

Tim