finos / legend-sdlc Goto Github PK

Feature Request

Add project pipeline. Pipeline should build project and run any tests and plugins defined in project.
Each project will run

• build process
• validation tests on entities
• mapping and service tests defined in project
• model generation plugin
• file generation plugin
• service execution plugin
• version plugin

Implementation

• Add test utils
• Add relevant plugins (file, model, service, version)
• Add extension collection modules in sdlc/engine
• Introduce project structure 11
• Add simple ci files for Finos
• Clean up tests

Related PRS

• Add definition and dataspace implementation - finos/legend-engine#833
• Update definition based on 8/31 discussion - finos/legend-engine#900
• Add handling to sdlc pipeline - #481
• Add reading and storing artifacts to depot finos/legend-depot#98
• legend-studio use depot api to fetch dataspace analytics

Description of Problem

We want to generate useful artifacts for specific Packageable Elements. This is useful for caching the contents of these artifacts through legend-depot to improve performance when fetching these artifacts.

This comes in handy when doing complicated analytics on Packageable elements which takes time and resources to recalculate. An example is generating an ExecutionPlan for a service element. With this feature, the generation of the execution plan will occur once during the build step of the project and can therefore be used whenever the generation plan for the service is needed (i.e executing query etc.).

Solution Overview

We already have a maven plugin to generate files for an sdlc project. Right now it reads FileGeneration elements defined in the GenerationSpecification. The limitation here is that the user must specify the generation and also it is tied to having a generator driven by a schema/code generation.
We will define the ArtifactGenerationExtension more loosely. The main driver will be a packageable element, which will now be referred as the generator, in the graph that can define its own generation.

Current Approach: Use element path as driver for file paths

ArtifactGenerationExtension Diagram

File Structure

The generate method of the ArtifactGenerationExtension will return a list of artifacts with filePaths on them. When seralizing them to files we will place these files under the sub folder with the name tied to the generator that generated these files + the extension root folder.

Example

Generators with files generated

• model::CodeGeneration : (extension with root path code-generation)
  • generated/MyJava.java
  • MyPython.py
• model::CodeGeneration2 : (extension with root path code-generation)
  • MyPthon.py
• model::SchemaGeneration
  • schemaGen/MyJson.json : (extension with root path schmea-generation)
  • MyProto.proto
• model::MyClass : (extension with root path other-generation)
  • someGeneration/stuff.txt
  • MyStuff.txt

File Structure on file generation jar output

• model
  • CodeGeneration
    • code-generation
      • generated
        • MyJava.java
      • MyPyton.py
  • CodeGeneration2
    • code-generation
      • MyPyton.py
  • SchemaGeneration
    • schema-generation
      • schemaGen
        • MyJson.json
      • MyProto.proto
  • ClassGeneration
    • other-generation
      • someGeneration
        • stuff.txt
      • MyStuff.txt

Impact on Depot

• Currently depot uses classifier path to index files generated through the file generation maven plugin by:
  • fetching GenerationSpecification entity through classifier path.
  • fetching fileGenerations defined in GenerationSpecification
  • for each fileGeneration we use either the generationOutputPath if defined in the fileGeneration path or we use the file generation path to determine the path to index
  • this path will be indexed as the location of where the expected files generated by this fileGeneration will be located.
• Enhancement We should update apis to unpack all files generated as part of file generation maven plugin. We con potentially query files generated by generator.

Abandoned Approach: Use of RootPaths per extensions

• abandoned on 08/31 due to
  • its effect on depot causing chaos on file distribution and lineage between the generator (packageable elements) and the path location of the files.
  • Extension changes cause non backward compatible changes for depot and clients using depot

Approach (Abandoned )

We will define the ArtifactGenerationExtension more loosely. It is driven by a packageable element in the graph that can define its own generation.

The generate method on the extension will be the main driver of the extension and will expect the element with its compiled model PureModel to produce artifacts.

Impact on Depot (Abandoned )

Current depot apis rely on the paths of the files generated. This will not change for the current FileGeneration element as the location of the files generated by those elements will stay the same and will continue to be defined (for now in GenerationSpecification)

Folder Structure (Abandoned )

All files generated by ArtifactGenerationExtension will be generated under the root folder artifacts-generation-root. Furthermore, each extension will define its artifactsRootPath that will create a folder under the root folder for the files generated by the extension

• (root) artifacts-generation-root
  • (extension1) extenstion1-root-path
    • generatedFile.json (generated by extension1)
  • (extension2) extenstion2-root-path
    • generatedFile.json (generated by extension2)

CVE-2020-5245 - High Severity Vulnerability

Vulnerable Library - dropwizard-validation-1.3.5.jar

Dropwizard is a Java framework for developing ops-friendly, high-performance, RESTful web applications.

Library home page: http://www.dropwizard.io/1.3.5

Path to dependency file: legend-sdlc/legend-sdlc-server/pom.xml

Path to vulnerable library: /home/wss-scanner/.m2/repository/io/dropwizard/dropwizard-validation/1.3.5/dropwizard-validation-1.3.5.jar,/home/wss-scanner/.m2/repository/io/dropwizard/dropwizard-validation/1.3.5/dropwizard-validation-1.3.5.jar

Dependency Hierarchy:

• dropwizard-core-1.3.5.jar (Root Library)
  • ❌ dropwizard-validation-1.3.5.jar (Vulnerable Library)

Found in HEAD commit: b2f937f6a53111607cfaaa3be4705b6c290b4a73

Found in base branch: master

Vulnerability Details

Dropwizard-Validation before 1.3.19, and 2.0.2 may allow arbitrary code execution on the host system, with the privileges of the Dropwizard service account, by injecting arbitrary Java Expression Language expressions when using the self-validating feature. The issue has been fixed in dropwizard-validation 1.3.19 and 2.0.2.

Publish Date: 2020-02-24

URL: CVE-2020-5245

CVSS 3 Score Details (8.8)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: Low
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: High
  • Integrity Impact: High
  • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5245

Release Date: 2020-02-24

Fix Resolution: 1.3.19,2.0.2

CVE-2019-10247 - Medium Severity Vulnerability

Vulnerable Library - jetty-server-9.4.11.v20180605.jar

The core jetty server artifact.

Library home page: http://www.eclipse.org/jetty

Path to dependency file: legend-sdlc/legend-sdlc-server-shared/pom.xml

Path to vulnerable library: canner/.m2/repository/org/eclipse/jetty/jetty-server/9.4.11.v20180605/jetty-server-9.4.11.v20180605.jar,/home/wss-scanner/.m2/repository/org/eclipse/jetty/jetty-server/9.4.11.v20180605/jetty-server-9.4.11.v20180605.jar

Dependency Hierarchy:

• ❌ jetty-server-9.4.11.v20180605.jar (Vulnerable Library)

Found in HEAD commit: b2f937f6a53111607cfaaa3be4705b6c290b4a73

Found in base branch: master

Vulnerability Details

In Eclipse Jetty version 7.x, 8.x, 9.2.27 and older, 9.3.26 and older, and 9.4.16 and older, the server running on any OS and Jetty version combination will reveal the configured fully qualified directory base resource location on the output of the 404 error for not finding a Context that matches the requested path. The default server behavior on jetty-distribution and jetty-home will include at the end of the Handler tree a DefaultHandler, which is responsible for reporting this 404 error, it presents the various configured contexts as HTML for users to click through to. This produced HTML includes output that contains the configured fully qualified directory base resource location for each context.

Publish Date: 2019-04-22

URL: CVE-2019-10247

CVSS 3 Score Details (5.3)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: Low
  • Integrity Impact: None
  • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://bugs.eclipse.org/bugs/show_bug.cgi?id=546577

Release Date: 2019-04-22

Fix Resolution: 9.2.28.v20190418

• Check this box to open an automated fix PR

Feature Request

Description of Problem:

When supporting function overloading, the changes made in Engine Parser cause an issue of pulling entities from Gitlab.
This inspires supporting a comprehensive error handling strategy for all breaking grammar changes or any reason, which avoids providing workarounds for each different case.

Potential Solutions:

• Provide an API for getting an entities with an option of turning off error exceptions.
  Similar to GET [​/projects​/{projectId}​/groupWorkspaces​/{workspaceId}​/entities(http://localhost:7070/api/swagger#/Entities/getAllEntities_12) Get entities of the group workspace, getAllEntities API will have a parameter that is used for passing through all validations even if there are corrupted entities due to non-backward-compatible grammar changes.

• Provide an API for getting all corrupted entities

• Generate useful/concrete failure analysis and throw corresponding exceptions

• Create a mechanism(APIs) to fix all corrupted entities

Feature Request

Description of Problem:

...what problem are you trying to solve that the project doesn't currently solve?

...please resist the temptation to describe your request in terms of a solution. Job Story form ("When [triggering condition], I want to [motivation/goal], so I can [outcome].") can help ensure you're expressing a problem statement.

Potential Solutions:

...clearly and concisely describe what you want to happen. Add any considered drawbacks.

... if you've considered alternatives, clearly and concisely describe those too.

WS-2019-0379 - Medium Severity Vulnerability

Vulnerable Library - commons-codec-1.12.jar

The Apache Commons Codec package contains simple encoder and decoders for various formats such as Base64 and Hexadecimal. In addition to these widely used encoders and decoders, the codec package also maintains a collection of phonetic encoding utilities.

Library home page: http://commons.apache.org/proper/commons-codec/

Path to dependency file: legend-sdlc/legend-sdlc-server/pom.xml

Path to vulnerable library: canner/.m2/repository/commons-codec/commons-codec/1.12/commons-codec-1.12.jar,canner/.m2/repository/commons-codec/commons-codec/1.12/commons-codec-1.12.jar

Dependency Hierarchy:

• ❌ commons-codec-1.12.jar (Vulnerable Library)

Found in HEAD commit: b2f937f6a53111607cfaaa3be4705b6c290b4a73

Found in base branch: master

Vulnerability Details

Apache commons-codec before version “commons-codec-1.13-RC1” is vulnerable to information disclosure due to Improper Input validation.

Publish Date: 2019-05-20

URL: WS-2019-0379

CVSS 3 Score Details (6.5)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: Low
  • Integrity Impact: Low
  • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: apache/commons-codec@48b6157

Release Date: 2019-05-12

Fix Resolution: 1.13-RC1

• Check this box to open an automated fix PR

CVE-2018-1000873 - Medium Severity Vulnerability

Vulnerable Library - jackson-datatype-jsr310-2.9.6.jar

Add-on module to support JSR-310 (Java 8 Date & Time API) data types.

Library home page: https://github.com/FasterXML/jackson-modules-java8/

Path to dependency file: legend-sdlc/legend-sdlc-server-shared/pom.xml

Path to vulnerable library: /home/wss-scanner/.m2/repository/com/fasterxml/jackson/datatype/jackson-datatype-jsr310/2.9.6/jackson-datatype-jsr310-2.9.6.jar,/home/wss-scanner/.m2/repository/com/fasterxml/jackson/datatype/jackson-datatype-jsr310/2.9.6/jackson-datatype-jsr310-2.9.6.jar

Dependency Hierarchy:

• dropwizard-configuration-1.3.5.jar (Root Library)
  • dropwizard-jackson-1.3.5.jar
    • ❌ jackson-datatype-jsr310-2.9.6.jar (Vulnerable Library)

Found in HEAD commit: b2f937f6a53111607cfaaa3be4705b6c290b4a73

Found in base branch: master

Vulnerability Details

Fasterxml Jackson version Before 2.9.8 contains a CWE-20: Improper Input Validation vulnerability in Jackson-Modules-Java8 that can result in Causes a denial-of-service (DoS). This attack appear to be exploitable via The victim deserializes malicious input, specifically very large values in the nanoseconds field of a time value. This vulnerability appears to have been fixed in 2.9.8.

Publish Date: 2018-12-20

URL: CVE-2018-1000873

CVSS 3 Score Details (6.5)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: Required
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: None
  • Integrity Impact: None
  • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://nvd.nist.gov/vuln/detail/CVE-2018-1000873

Release Date: 2018-12-20

Fix Resolution: 2.9.8

CVE-2018-10237 - Medium Severity Vulnerability

Vulnerable Library - guava-24.0-jre.jar

Guava is a suite of core and expanded libraries that include utility classes, google's collections, io classes, and much much more.

Library home page: https://github.com/google/guava

Path to dependency file: legend-sdlc/legend-sdlc-server/pom.xml

Path to vulnerable library: /home/wss-scanner/.m2/repository/com/google/guava/guava/24.0-jre/guava-24.0-jre.jar,/home/wss-scanner/.m2/repository/com/google/guava/guava/24.0-jre/guava-24.0-jre.jar

Dependency Hierarchy:

• guice-4.2.1.jar (Root Library)
  • ❌ guava-24.0-jre.jar (Vulnerable Library)

Found in HEAD commit: b2f937f6a53111607cfaaa3be4705b6c290b4a73

Found in base branch: master

Vulnerability Details

Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable.

Publish Date: 2018-04-26

URL: CVE-2018-10237

CVSS 3 Score Details (5.9)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: High
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: None
  • Integrity Impact: None
  • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://nvd.nist.gov/vuln/detail/CVE-2018-10237

Release Date: 2018-04-26

Fix Resolution: 24.1.1-jre, 24.1.1-android

CVE-2020-11002 - High Severity Vulnerability

Vulnerable Library - dropwizard-validation-1.3.5.jar

Dropwizard is a Java framework for developing ops-friendly, high-performance, RESTful web applications.

Library home page: http://www.dropwizard.io/1.3.5

Path to dependency file: legend-sdlc/legend-sdlc-server/pom.xml

Path to vulnerable library: /home/wss-scanner/.m2/repository/io/dropwizard/dropwizard-validation/1.3.5/dropwizard-validation-1.3.5.jar,/home/wss-scanner/.m2/repository/io/dropwizard/dropwizard-validation/1.3.5/dropwizard-validation-1.3.5.jar

Dependency Hierarchy:

• dropwizard-core-1.3.5.jar (Root Library)
  • ❌ dropwizard-validation-1.3.5.jar (Vulnerable Library)

Found in HEAD commit: b2f937f6a53111607cfaaa3be4705b6c290b4a73

Found in base branch: master

Vulnerability Details

dropwizard-validation before versions 2.0.3 and 1.3.21 has a remote code execution vulnerability. A server-side template injection was identified in the self-validating feature enabling attackers to inject arbitrary Java EL expressions, leading to Remote Code Execution (RCE) vulnerability. If you are using a self-validating bean an upgrade to Dropwizard 1.3.21/2.0.3 or later is strongly recommended. The changes introduced in Dropwizard 1.3.19 and 2.0.2 for CVE-2020-5245 unfortunately did not fix the underlying issue completely. The issue has been fixed in dropwizard-validation 1.3.21 and 2.0.3 or later. We strongly recommend upgrading to one of these versions.

Publish Date: 2020-04-10

URL: CVE-2020-11002

CVSS 3 Score Details (8.8)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: Low
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: High
  • Integrity Impact: High
  • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-8jpx-m2wh-2v34

Release Date: 2020-04-10

Fix Resolution: io.dropwizard:dropwizard-validation:2.0.3,1.3.21

• 1st phase: the refactoring we have to do in SDLC codebase
  • Moving Gitlab and In-Memory out to its own module
  • Create a bundle:
    • Web-filter
    • Dropwizard (module mapping, dependency injection)
  • Configuration:
    • Backend configuration
  • [ ]Think about the shaded JAR module + Docker setup
• 2nd phase: the refactoring that we need to do in tandem with Studio
  • Create set of enum of features, backend returns a set of enum values to tell what it can and cannot support
  • We have 3 levels of feature supports (the top is the most important and will override all the one below it):
    • Server: what feature the server itself allows
    • Backend: what the backend can support
    • Project (its own thing): we allow each project to configure what it can support,or this can be derived from user's permission
  • Studio askes the server: combine the configuration + backend (do the overlay), we have 2 APIs:
    • Server level
    • Project level

SDLC (as of project structure version 8) starts to store entities in grammar text. This has many upsides but somewhat punish performance heavily.

• In terms of write, it does multi-parsing and composing: for example, it, first, tries to ask if an entity is parsable, it composes then parses the entity and do a roundtrip comparison to make sure parsing is properly done. If yes, it proceeds with parsing, otherwise, it stores the entity in JSON, and this means when we read the entity, we have to look up where the entity could have been stored based on its format (please fact-check this).
• In terms of read, it parses the entity from text to JSON, which doubles up the size due to source information being returned as well. Also because of this, entities being published to metadata server (a.k.a depot) also contains source information which really blows up the size of models to 100% if not 200%!

Therefore, we could consider:

• Introducing a mechanism for SDLC server to prune source information while parsing grammar text
• Introduce a mechanism for SDLC to store entities in JSON only, maybe a config at project structure level.

Feature Request

Description of Problem:

When packaging legend model to gitlab, we generate a multi module maven project. The project is built using specific legend SDLC and legend engine dependencies where version is hardcoded in the legend SDLC code.

@see: https://github.com/finos/legend-sdlc/blob/master/legend-sdlc-server/src/main/java/org/finos/legend/sdlc/server/project/ProjectStructureV11Factory.java#L81

@see: https://github.com/finos/legend-sdlc/blob/master/legend-sdlc-server/src/main/java/org/finos/legend/sdlc/server/project/ProjectStructureV11Factory.java#L87

        private static final String LEGEND_ENGINE_VERSION = "2.37.0";

As a consequence, model built on a specific version of the runtime would not benefit from the latest runtime features at compile time.

Potential Solutions:

Capture the version of dependencies used for SDLC server and inject those exact version to pom.xml generation. This could be done by creating an application.properties file where versions are injected at compile time

legend-sdlc-server/src/main/resources/legend.properties

org.finos.legend.sdlc       ${legend.sdlc.version}
org.finos.legend.engine     ${legend.engine.version}

legend-sdlc-server/pom.xml

        <resources>
            <resource>
                <directory>/</directory>
                <includes>
                    <include>legend.properties</include>
                </includes>
                <filtering>true</filtering>
            </resource>
        </resources>

legend-sdlc-server/src/main/java/org/finos/legend/sdlc/server/project/ProjectStructureV11Factory.java

protected static String getEngineVersion() throws IOException
    {
        Properties properties = new Properties();
        properties.load(MavenProjectStructure.class.getResourceAsStream("/legend.properties"));
        return properties.getProperty("org.finos.legend.engine");
    }

Feature Request

Integrate Elastic Search into the existing GitlabProjectAPI implementation.

Description of Problem:

The current implementation of the ProjectAPI iterates through all Gitlab projects and filters the projects with the Legend tag.
This is "slow" as it makes multiple network calls to the Gitlab API.

Potential Solutions:

The Gitlab Enterprise Edition offers Elastic Search indexing. Instead of iterating over all projects we can search for Legend projects.

Note : Elastic Search Indexing is not available on the community edition. We have to support both the Enterprise and Community Editions.

Feature Request

Description of Problem:

...what problem are you trying to solve that the project doesn't currently solve?

...please resist the temptation to describe your request in terms of a solution. Job Story form ("When [triggering condition], I want to [motivation/goal], so I can [outcome].") can help ensure you're expressing a problem statement.

Potential Solutions:

...clearly and concisely describe what you want to happen. Add any considered drawbacks.

... if you've considered alternatives, clearly and concisely describe those too.

Support Question

I am trying to setup Legend locally following Maven Installation Guide, I have the Engine, Studio, and SDLC running but when I open the Studio I get the following error.

What am I doing wrong?
Thanks

CVE-2019-12402 - High Severity Vulnerability

Vulnerable Library - commons-compress-1.18.jar

Apache Commons Compress software defines an API for working with compression and archive formats. These include: bzip2, gzip, pack200, lzma, xz, Snappy, traditional Unix Compress, DEFLATE, DEFLATE64, LZ4, Brotli, Zstandard and ar, cpio, jar, tar, zip, dump, 7z, arj.

Path to dependency file: legend-sdlc/legend-sdlc-server/pom.xml

Path to vulnerable library: canner/.m2/repository/org/apache/commons/commons-compress/1.18/commons-compress-1.18.jar

Dependency Hierarchy:

• ❌ commons-compress-1.18.jar (Vulnerable Library)

Found in HEAD commit: b2f937f6a53111607cfaaa3be4705b6c290b4a73

Found in base branch: master

Vulnerability Details

The file name encoding algorithm used internally in Apache Commons Compress 1.15 to 1.18 can get into an infinite loop when faced with specially crafted inputs. This can lead to a denial of service attack if an attacker can choose the file names inside of an archive created by Compress.

Publish Date: 2019-08-30

URL: CVE-2019-12402

CVSS 3 Score Details (7.5)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: None
  • Integrity Impact: None
  • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12402

Release Date: 2019-08-30

Fix Resolution: 1.19

• Check this box to open an automated fix PR

Feature Request

Implement a lightweight in-memory Gitlab backend for quick proofs of concept/testing

Description of Problem:

The SDLC server integrates with Gitlab. While we do run an instance of Gitlab for integration tests, it is not very lightweight.
It requires Docker and is also very specific to how Docker is being run.

Also, a light weight implementation can be useful for quick proofs of concept.

Potential Solutions:

Solutions include an implementation of the various APIs (like ProjectAPI etc) backed by an in-memory store.

Another option is to use a Git java library to implement a new backend for SDLC.

CVE-2019-10241 - Medium Severity Vulnerability

Vulnerable Libraries - jetty-util-9.4.11.v20180605.jar, jetty-servlet-9.4.11.v20180605.jar, jetty-server-9.4.11.v20180605.jar

jetty-util-9.4.11.v20180605.jar

Utility classes for Jetty

Library home page: http://www.eclipse.org/jetty

Path to dependency file: legend-sdlc/legend-sdlc-server-shared/pom.xml

Path to vulnerable library: /home/wss-scanner/.m2/repository/org/eclipse/jetty/jetty-util/9.4.11.v20180605/jetty-util-9.4.11.v20180605.jar,/home/wss-scanner/.m2/repository/org/eclipse/jetty/jetty-util/9.4.11.v20180605/jetty-util-9.4.11.v20180605.jar

Dependency Hierarchy:

• jetty-servlets-9.4.11.v20180605.jar (Root Library)
  • ❌ jetty-util-9.4.11.v20180605.jar (Vulnerable Library)

jetty-servlet-9.4.11.v20180605.jar

Jetty Servlet Container

Library home page: http://www.eclipse.org/jetty

Path to dependency file: legend-sdlc/legend-sdlc-server-shared/pom.xml

Path to vulnerable library: /home/wss-scanner/.m2/repository/org/eclipse/jetty/jetty-servlet/9.4.11.v20180605/jetty-servlet-9.4.11.v20180605.jar,/home/wss-scanner/.m2/repository/org/eclipse/jetty/jetty-servlet/9.4.11.v20180605/jetty-servlet-9.4.11.v20180605.jar

Dependency Hierarchy:

• dropwizard-jetty-1.3.5.jar (Root Library)
  • ❌ jetty-servlet-9.4.11.v20180605.jar (Vulnerable Library)

jetty-server-9.4.11.v20180605.jar

The core jetty server artifact.

Library home page: http://www.eclipse.org/jetty

Path to dependency file: legend-sdlc/legend-sdlc-server-shared/pom.xml

Path to vulnerable library: canner/.m2/repository/org/eclipse/jetty/jetty-server/9.4.11.v20180605/jetty-server-9.4.11.v20180605.jar,/home/wss-scanner/.m2/repository/org/eclipse/jetty/jetty-server/9.4.11.v20180605/jetty-server-9.4.11.v20180605.jar

Dependency Hierarchy:

• ❌ jetty-server-9.4.11.v20180605.jar (Vulnerable Library)

Found in HEAD commit: b2f937f6a53111607cfaaa3be4705b6c290b4a73

Found in base branch: master

Vulnerability Details

In Eclipse Jetty version 9.2.26 and older, 9.3.25 and older, and 9.4.15 and older, the server is vulnerable to XSS conditions if a remote client USES a specially formatted URL against the DefaultServlet or ResourceHandler that is configured for showing a Listing of directory contents.

Publish Date: 2019-04-22

URL: CVE-2019-10241

CVSS 3 Score Details (6.1)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: Required
  • Scope: Changed
• Impact Metrics:
  • Confidentiality Impact: Low
  • Integrity Impact: Low
  • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10241

Release Date: 2019-04-22

Fix Resolution: org.eclipse.jetty:jetty-server:9.2.27,9.3.26,9.4.16,org.eclipse.jetty:jetty-servlet:9.2.27,9.3.26,9.4.16,org.eclipse.jetty:jetty-util:9.2.27,9.3.26,9.4.16

Gitlab starts using main as their default branch. Right now we hard-coded this to master

The strategy we need to adopt is:

1. Long Term Dynamically handle this with a new logic centralized at the getBranch() function: i.e. Gitlab project API provides information about which is the default branch - See https://docs.gitlab.com/ee/api/projects.html#get-single-project
2. Short Term Tell user to configure the default branch on Gitlab at group level to master

OIDC Config for SDLC Authentication

Hi Team,

   We have pulled the latest SDLC Docker image and have it integrated with our Gitlab onprem server and its working fine.

When we try to switch over the OIDC authentication to generic OIDC Client, we are facing below issue and Can anyone of You

please provide guidance on how to move forward with this issue?

HTTP ERROR 500 org.pac4j.core.exception.TechnicalException: configuration cannot be null</h2>

URI: /sdlc/auth/authorize
Status:  500
Message: org.pac4j.core.exception.TechnicalException: configuration cannot be null
Servlet: jersey
Caused By: org.pac4j.core.exception.TechnicalException: configuration cannot be null

The config we tried are below:

"clients": [
{
"org.pac4j.oidc.client.OidcClient": {
"name": "OidcClient",
"clientId": "",
"secret": "",
"discoveryUri": "https://xxxxx/.well-known/openid-configuration",
"scope": "openid profile api"
}
}
],

"clients": [
{
"org.pac4j.oidc.client.AzureAdClient": {
"name": "AzureAd",
"clientId": "",
"secret": "",
"discoveryUri": "https://xxxxx/.well-known/openid-configuration",
"scope": "openid profile api"
}
}
],

I've added the build.yml to match the other projects, but the build fails to upload artifacts - @maoo does it need secrets installing for the repo to do this successfully?

Feature Request

Description of Problem:

...what problem are you trying to solve that the project doesn't currently solve?

...please resist the temptation to describe your request in terms of a solution. Job Story form ("When [triggering condition], I want to [motivation/goal], so I can [outcome].") can help ensure you're expressing a problem statement.

Potential Solutions:

...clearly and concisely describe what you want to happen. Add any considered drawbacks.

... if you've considered alternatives, clearly and concisely describe those too.

Importing a project involves the following steps:

1. Create a workspace in GitLab.
2. Add the project structure in the workspace.
3. Create a merge request for the workspace.
4. Update the project with tag.

Steps to Reproduce:

1. Create a GitLab user account with permission to create workspace and merge requests, but not to update project.
2. Invoke import project endpoint through the same account.
3. Check the response returned from the endpoint. Excepted Response - '403 Forbidden'.
4. Go to GitLab project overview and check for workspace and merge request created for project structure.

Expected Result:
During project import, if updating the project with tag fails, the workspace and merge request created for project structure must be deleted.

Actual Result:
Workspace and merge request created for project structure exists in GitLab despite error from import project endpoint.

CVE-2017-18640 - High Severity Vulnerability

Vulnerable Library - snakeyaml-1.24.jar

YAML 1.1 parser and emitter for Java

Library home page: http://www.snakeyaml.org

Path to dependency file: legend-sdlc/legend-sdlc-server/pom.xml

Path to vulnerable library: /home/wss-scanner/.m2/repository/org/yaml/snakeyaml/1.24/snakeyaml-1.24.jar,/home/wss-scanner/.m2/repository/org/yaml/snakeyaml/1.24/snakeyaml-1.24.jar

Dependency Hierarchy:

• dropwizard-configuration-1.3.5.jar (Root Library)
  • jackson-dataformat-yaml-2.10.3.jar
    • ❌ snakeyaml-1.24.jar (Vulnerable Library)

Found in HEAD commit: b2f937f6a53111607cfaaa3be4705b6c290b4a73

Found in base branch: master

Vulnerability Details

The Alias feature in SnakeYAML 1.18 allows entity expansion during a load operation, a related issue to CVE-2003-1564.

Publish Date: 2019-12-12

URL: CVE-2017-18640

CVSS 3 Score Details (7.5)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: None
  • Integrity Impact: None
  • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://bitbucket.org/asomov/snakeyaml/commits/da11ddbd91c1f8392ea932b37fa48110fa54ed8c

Release Date: 2020-03-08

Fix Resolution: 1.26

It would be great if we have a way to authorize API call using Gitlab private access token. This is good for automated tests in order to quickly setup test projects for example. Also this will allow us to test SDLC in a more e2e like manner. Or when somebody needs to setup system users/bots to do stuffs through the SDLC server. There are a few things to consider/do:

• Come up with a way for the client to pass the private token to the SDLC Server
• Cone up with a distinction in the session between private and OAuth tokens - we'll then need to keep track of what kind of token you have
• Come up with logic to use that distinction to create the GitLabApi - private access tokens and OAuth tokens are communicated to GitLab in different ways

Also, we'd need to think about how this would work with authentication, do we separately authenticate the user? Or do we use the token to authenticate?