Experience with updating the Spring Boot version independently from A12

Data Services
1

Hi all,

we are currently using Plattformserver from A12 21.3.9 which is as far as I know compatible with Spring Boot 1.5.4.RELEASE which is from mid 2017. Does anyone have experience with updating Spring Boot to the newest/newer minor version(s)?

I would be very happy if someone could could point me to documentation on compatible versions for our A12 version.

Thanks!

2

Hi,

the newest spring boot 1.5 release is 1.5.18 so an upgrade to that version is the minimum we need.
Especial for security bugfixes in used dependencies e.g. NVD - CVE-2017-7525 in the used 2.8.8 version of Jackson.

We (cosmo) lately migrated two applications from Spring Boot 1.5 to 2.0 with reasonable effort.
So i think it should be possible to migrate the Plattformserver 21.3.9 to Spring boot 2.0.

If you need help we can take a look together.

Thx Julian

3

@dmueller_inactive: My first impulse was to say in general that upgrading minor or patch updates from 3rd party libraries should work if they do proper semantic versioning - but it is also clear that not all vendors do this systematically, and if they do, then mistakes can happen… so I see your point.

We do upgrade 3rd party libraries eventually, but at the moment, we do not have an upgrade or patch policy, neither for the master nor for older release lines - this is obviously a gap.

We will look into this starting with security sensitive libraries.

4

@ansgar-solar-lake thanks for your reply.
This will mean that all project which are using A12 in production environments will have to take care about security updates for the transitive dependencies they get through A12 by themselves although they have no influence on them.

For all of those projects, this will result in a workflow like this:

  • find out about transitive dependencies they get through a12
  • establish a process for getting notified about important security updates
  • in case an update is necessary:
    • update the version
    • do regression testing
    • incase of potential incompatibilities with other transitive dependencies (also from a12) or with the a12 implementations
      • debug
      • find a solution
      • if not fixable in the project, create a12 bug ticket
      • wait until fixed

This leads to additional effort which has to be done in all projects instead of a12.

5

@dmueller_inactive: I can only repeat:
We will look into this starting with security sensitive libraries.

6

@ansgar-solar-lake Great to here that.

Please include in this effort also other libraries and dependencies.
Like angular 1.5.11 | Snyk

I think regular security tests should be performed by mgm SP on the A12 reference implementation.
So we find this problems before they come up in the projects.
see <INTERNAL_LINK> ( web security test for dpos)

7

@dmueller_inactive You are making a really good point! We are working hard together with TPI to setup a security infrastructure that will help all mgm projects to scan their third-party libraries. Once we have that, A12 will take care of patches & updates with respect to security.

8

@julian-typed-spruce Beside the topic of third-party libraries, we are also working on an internal platform to allow regular automated checks in addition to pentests that are important to be done for milestones.

Overall, I can only ask for a bit of patience, we have a long road to go, and we are just at the beginning, but there are many efforts going into the right direction.

Thx!

9

I’m glad to hear that there is something done in that direction.

10

Hi,

There is no documentation like this. We are updating 3rd party libraries regularly with major releases. Latest upgrade of the spring (spring 4.3.13.RELEASE → 5.0.5.RELEASE, spring-boot 1.5.4.RELEASE → 2.0.1.RELEASE) has been done in version 23.0.0. Please see: A12CORE-9368. The upgrade itself was a bit complicated because spring and spring-boot libraries should be upgraded together because if the versions would not be compatible it would create a mess in the versions of dependencies that those two libraries share. Furthermore there are changes in spring data API and there were some issues with the start-up sequence changes during upgrade.

In version 23.0.0 we also implemented an option to reliably enable the actuator interfaces. This has been done in ticket A12S-174 which is based on the spring boot version 2.0.1.RELEASE. We had issues with implementing actuator endpoints with older versions of spring boot because spring security needed for securing actuator endpoints was not fully compatible with services security. Upgrading to the newest version of spring-boot did not solve all of our issues but we were able to implement the solution that works.

To conclude:

  • Upgrading just spring-boot could create complicated dependency management because of same libraries in different versions
  • Upgrading of the spring (-boot) might lead to breaking changes in your code base and different behavior which was not tested on the services side (version 21.3.x was never run with different spring than it was delivered with)
  • We know that some features like actuator do not work properly in versions of spring-boot lower than 2 with the platform server