| | | | |
|---|
| Java release strategy | https://en.wikipedia.org/wiki/Java_version_history |
| Use only Long Term Support versions: v11 (and v17 in the future) |
| Java and Alpine upgrade for Frankfurt | -SECCOM requires that Java projects upgrade to Java 11 (Java SE 11.0.5) and Alpine 3.10.3 in Frankfurt -PTL latest feedback No prebuilt Docker images for Java 11Prebuilt Docker images for Java 12 and 13(call on 18th of November) - Martial shared his container with Java 11.0.5 and Alpine 3.10.3
- Pam proposed to synch with Integration Team - we will join their weekly call on Wednesday 2PM UTC and address:
- Container management
- OJSIs context (but Krzysztof will be not available), including scripts for http vs. https
- Moving to later version than Java 11 may cause problem for oparent, which specifies Java 11
- Frankfurt version of oparent is 3.x (is it available on Nexus already?) and specifies Java 11
- All projects in El Alto use oparent 2.x
- Distinction between the Java runtime and the Java source code versions
- Java runtime is backward compatible
- Source code can be Java 8 or higher
- Runtime can be Java 11 or 13
- Java 11: Java SE 11.0.5Java 13: Java SE 13.0.1
|
| -SECCOM recommendation No change needed for the requirement because it requires Java 11 but allows Java 13Prebuilt imagesProjects choosing Java 13 can use prebuilt (modified) - Prebuilt images
- CLAMP has a created a Java 11 Docker image that can be used by other projects -
https://gerrit.onap.org/r/c/clamp/+/91241/4/src/main/docker/backend/Dockerfile - Java 12 or 13
- AAF migrated to 12 with no problems; CLAMP has migrated to 13; changes can be made to override oparent
- AAF migration to 13: will not require project to migrate to 13 because AAF-CADI can run on Java 8 - 13
- Other dependencies – Portal SDK, ODL (CCSDK, APPC)
- Oparent dependency
SECCOM will update REQ-192 ( both not recommended due to its short LCM) - SECCOM updated REQ-219 with the following
- Required version of Java 11 JDK: Java SE 11.0.5Required version of Java 13 JDK: Java SE 13.0.1
- Requirement that shared libraries must run in JDK 11for JDK 13, override JDK 11 as specified by oparent
- Due to end of support for Java 8, SECCOM recommends all ONAP projects to analyze for their specific case the impact of migration from Java 8 to Java 11, the next long term support (LTS) version. In order to provide feasible requirements to the teams, we propose:
- All projects SHOULD be migrated to Java 11 (Java SE 11.0.5) for the Frankfurt release
Python – Vijay poposed image with 3.7 version and Alpine: https://hub.docker.com/_/python - to be further analyzed (Amy) |
| Password encryption | Passwords encrypted before putting passwords in OOM - efforts to make more secrets – not to put private key in the same place - Certificate, private key are on a shared volume
- There should be no passwords in OOM, should use init config
- Password and encryption key are both on the shared volume
|
| Krzysztof, Jonathan, Samuli will discuss solutions and provide a recommendation |
| ONAP SECCOM and MSB synch call (15/11/19) | -OJSI review and explaination (Krzysztof) - #tags to be provided by Huabing
-CII Badging review (Tony) – feedback was already provided |
|
|
| SECCOM and CLI synch call proposed to Kanagaraj | but no answer so far… |
| Update 22/11/2019: Meeting to be scheduled on Monday 25th of November. |
| Nexus-IQ vs. Whitesource | -Renan was reasked for the status update – feedback received that some effort is planned in current week (W47), Jess confirmed her availability -Dan completed his analysis for known vulns in CCSDK |
| Update 22/11/2019: Meeting scheduled between Jess and Renan on Friday 22nd of November at noon. |
| initial PoC for OOM call for OOM common secrets (Krzysztof) |
|
|
|
| ONAP F2F in Prague – topics proposals (https://wiki.lfnetworking.org/display/LN/Call+for+ONAP+DDF+Topics+-+Prague+2020 ): | - SECCOM F2F
- Working session – testable VNF security requirements
- Joint discussion with CNTT on security like security requirements,
- Status update OOM password removal
- Status update ingress controller introduction
- ISTIO common discussion
- Communication matrix update – diagram and interactions from it
|
|
|
| Remediating direct and transitive third party dependencies (topic for 19/11/19) | -PTL feedback - Determining effective and ineffective status of vulnerabilities is extremely time consuming
- Analysis direct and transitive is time consuming
- Determining remediation action difficult
- NexusIQ does not provide this analysis directly
-Proposal for dependency remediation in Frankfurt - Require projects to upgrade their direct dependencies to latest version of package at M1
- Considered industry best practice
- Will not eliminate all vulnerabilities, but will reduce the number
- KPI – number of packages upgraded
- Edge cases
- Projects with ODL dependencies
|
|
|