We had our first Open Source Support Briefing for uPortal this year on April 27th. We covered Q4 of 2021 and Q1 of 2022.
The uPortal OSS Periodic Briefing is an opportunity to share the contributions performed by Unicon on behalf of the OSS program, highlight Unicon's perspective on contributions, share happenings in the community, and describe opportunities to engage further with Unicon.
Topics for this briefing included the uPortal OSS Program review, the state of the uPortal ecosystem, an update about the uPortal Steering Committee, community events, and an overview of the Log4J and Spring security CVEs that recently hit the tech sector.
Watch the uPortal Briefing Webinar here, and/or read a recap of the session below.
uPortal OSS Program Review
Two new subscribers joined the uPortal program which increases the resources we have to invest into uPortal and related open source projects. This brings us up to 18 subscribers that help to keep uPortal healthy.
In Q4 2021 and Q1 2022, 100% of commits to uPortal-related repos were done through this OSS program and related projects. This includes all the new releases as well.
We had 42 tickets opened during this period. This was a mix of Support Assistance and Consulting Assistance hours. There were even a few Sustaining Engineering requests. As a reminder, the unlimited Support Assistance is used to answer questions and provide recommendations. Consulting Assistance hours, usually 20 hours per year, are for digging into logs, researching solutions, and other efforts that take more than an hour or two.
Finally, we shared that Unicon provides services and support outside of the OSS program. Recently, a subscriber asked if we could help more than is covered by the program. Certainly! We provide installation and upgrade services, training, and custom work.
State of the uPortal Ecosystem
We started with a reminder that we moved from https://github.com/jasig/ to https://github.com/uPortal-Project/ as our main organization for uPortal repositories. This is the github organization for active, adopted projects. uPortal-Contrib is the organization that houses projects that have not been officially adopted, but have provided value to someone in our community. These projects may eventually become sponsored, or officially adopted. Lastly, uPortal-Attic is where retired repos go. These are no longer maintained but kept available in case someone needs access to the source.
We have started migrating documentation from uPortal repositories and the uPortal 4.x manuals to https://github.com/uPortal-project/uportal-project.github.io/ as a new centralized repository for core uPortal documentation. Portlets will retain their own documentation in their respective repositories.
We went over the release notes for uPortal v5.11.1, FeedbackPortlet v1.2.3, and BookmarksPortlet v1.2.5. In the uPortal release, the two fixes of note include an NPE in the cookiecheck code and making JGroups optional to avoid network delays. The portlets’ fixes center around migrating logging to SLF4J.
uPortal Steering Committee Update
While the steering committee is not part of the Unicon OSS program, it is an important community-based vehicle for uPortal. Both Chris Beach and I sit on the committee. You can stay updated on the meeting minutes in the uPortal-project.github.io project.
We highlighted three main areas we have been discussing over the last several months:
- Community involvement - This provides guidance to the roadmap and really drives the work. We use informal surveys via mailing lists to assess use and interest.
- Coding efforts - This has been focused on automated testing. We also have been talking about rich content editing and management in uPortal.
- Documentation and clean-up - We’ve aligned on a strategy in this area for clarity, and documented it here. We’ve also cleaned up older/unused repos and migrated them into the uPortal-Attic.
It is important to note that these efforts are often done through Sustaining Engineering hours in this program.
Digging deeper into automated testing, there is an effort to build out automated UX and API testing. We are targeting Playwright as the tool that will run against uPortal-start. We would like to use GitHub Actions to run these on PRs and code merges into the main branches.
The steering committee was hoping to have a uPortal public demo site available by now; however, that has been placed on hold for the time being.
The steering committee documents the roadmap based on community input. Our current roadmap includes converting portlets to web components, security patches, Java 11/17, upgrading to Spring 5, and modernizing QuickStart (uPortal demo). There is no definitive timeline for uPortal 6, but some of these enhancements are significant enough that they will be held until uPortal v6.
Subscribers can (and should) influence the roadmap. We urge you to provide feedback to inform us on next steps and the direction to take with the roadmap.
Community Events
Open Apereo 2022 will be virtual with regional gatherings on June 14 & 15. For more details visit https://www.apereo.org/content/open-apereo-2022-value-open-source. The conference runs from 9:00 a.m. to 1:00 p.m. US Eastern for both days. The focus this year will be on gaining new adopters and providing introductions to Apereo projects rather than technical deep dives. If we have enough uPortal folks attending, we often have a roadmap discussion at the end or right after the conference.
We are also hoping to have uPortal Dev Days if there is enough interest in the community. While the Unicon uPortal team can present most of the time if needed, there is a high value-add to having others share their experiences with the rest of the uPortal community. In the call, there was a lot of interest, so we continue to plan this event.
Since the Open Apereo conference is focused on introducing folks to uPortal, what is your interest in a more technical event? Please let us know if you’d like to attend the next uPortal Dev Days event.
Tech Talk: Log4J and Spring CVEs
We started with the background of Log4J and how it evolved. Originally it provided support for only logging a string. Loggers that followed provided token replacement to avoid string concatenation. Most are simple token replacements mapped to the following call parameters. Not to be outdone, Log4J v2 added this along with more advanced processing of tokens with additional features. This opened up Log4J v2 to vulnerabilities. There was a path where Log4J would process parameters that opened up a vulnerability. There have been some patches, but many are suspicious of additional security issues.
The uPortal community had decided several years ago to move away from Log4J and adopt SLF4J/Logback for logging. A couple of portlets are still using Log4J, but they have not been updated in a long time, so they are using version 1 which does not have these types of vulnerabilities. There was one portlet that had the Log4J v2 API, but was mapping those API calls through SLF4J. In summary, the uPortal ecosystem is safe from that specific Log4j2 issue. Now, Log4J v1 might have some vulnerabilities, so we do want to migrate all active projects to SLF4J. That’s why the releases mentioned earlier center on SLF4J migration.
Q2 will see more releases with SLF4J migration. There are some dependency challenges to upgrading some dependencies irrelevant to the log migration, but the goal is to update all portlets. This was the big thing that hit our industry from early December through the start of this year. While we did not have the security issue, we spent a good deal of time understanding the issue and researching the code for uPortal and related projects.
The latest security risk in our industry is that Spring (versions 3 to 5) has a similar vulnerability as noted for Log4j2, but it only affects code running on JDK9+. Again, we dodged a bullet by not being current. You might be able to run uPortal on JDK 9, but officially uPortal 5 only runs on Java 8. We are working on support for newer versions of Java.
Similar to Log4J, Spring was written to use some Java libraries with certain expectations based on the current JDK. Then JDK9+ had expanded how it handles and processes some existing low-level calls that opened up Spring to these vulnerabilities.
We are holding back on a uPortal 6 release for two reasons. One, we want to make sure we are current on all dependencies. We want to be able to quickly respond with patches to minimize windows of vulnerabilities as we move forward. Out-of-date dependencies often have a negative impact on the amount of time to perform a release. And two, we want to roll up the Spring upgrade effort into the next major release. This has the potential of requiring significant refactoring.
We keep with our general recommendation to stay current on uPortal and portlet versions. Prepare your institution to cut releases quickly. If they are prepped and ready to adopt community releases with a short turn-around, you greatly reduce your window of exposure to security risks.
Looking ahead, with an upgrade to JDK11+, we will be able to upgrade Tomcat beyond 8.x. This will require some configuration changes, which will require a major uPortal release. While the current long-term Java version is JDK17, we are targeting 11 to get off of Java 8 as soon as possible, and then work on the move to JDK17.
Wrapping Up
We had a lot of interest in uPortal Dev Days in chat. Jim Helwig also mentioned that if anyone is interested in joining the uPortal Steering Committee, please feel free to reach out to us or the mailing list to express your interest. Last, there was a great question about whether to wait for releases or to get current right away. We recommend updating to the latest uPortal and portlet versions today. It often makes the next patch release adoption easier.
Community Engagement Resources
Interested in uPortal? We invite you to join the community and make an impact.
