Giter Site home page Giter Site logo

nexb / dejacode Goto Github PK

View Code? Open in Web Editor NEW
17.0 17.0 5.0 68.13 MB

Automate open source license compliance and ensure software supply chain integrity

Home Page: https://dejacode.readthedocs.io

License: GNU Affero General Public License v3.0

Dockerfile 0.04% Makefile 0.11% Python 77.32% HTML 10.14% CSS 0.62% JavaScript 11.60% Shell 0.01% Handlebars 0.17%
cyclonedx foss-compliance license open-source package-url purl sca scancode spdx vulnerabilities

dejacode's Issues

adding {%csrf_token%}

dejacode/dje/templates/registration/login.html

Line 27 in 01cf3b0

<form method="{{ form.helper.form_method }}" action="{{ form.helper.form_action }}" id="{{ form.helper.form_id }}" class="{{ form.helper.form_class }}">

Hello , while setting up this repository, I noticed that this form does not have csrf_token which is required according to django documentation. Is this an error or is it by design cause , after adding this I was able to view my /home/ tab

Add user process to compare/sync/merge two or more packages

When adding new packages to DejaCode, there are often several URLs for the same package (for instance when adding PyPI packages there can be multiple wheels and sdist for the same package).

Then once the scans are completed, one may update one of the packages, usually to fill in fields that are blank.

Once this is done for one package it would be great to have a convenient way to compare, sync and possibly merge the new attribute values of the updated package with the other packages created for the same version, or perhaps even gather attribute values from previous versions of the same package.

Otherwise, the user typically needs to follow an error prone and work intensive sequence of actions using multiple browser tabs and copy/paste:

  • in a new browser tab, find the most recent version of the same package and visually compare the field values with the tab that contains the recently updated package and selectively copy and paste some field values.
  • in a new browser tab, open the other related packages and visually compare the field values with the tab that contains the recently updated package and selectively copy and paste some field values multiple times.

Some detail design is needed of course, but this would be a great enhancement to package maintenance usability. The recent enhancements to PurlDB for the package_set feature might be helpful here.

Store Dependencies as Packages and support multiple dependency types in the DejaCode model

We should store Dependencies as Packages in DejaCode. Also, in addition to simply creating Product Packages, we really need to provide the necessary qualifiers for Dependencies, especially whether they are declared as required or optional. Needs design. The processes that import Product Inventory Items from ScanCode results, or from an SBOM that provides dependency details, need to be enhanced as well as the model and the corresponding UI presentation in DejaCode.

As we do for Package, the Dependency model should be aligned with the ScanCode-toolkit and ScanCode.io ones:

Note that this improvement would enhance both license compliance and vulnerability management processes in DejaCode.

Drill down from package to package details

When a package is in DejaCode and has been furthered scanned, or is in the purldb I would like to drill down aka. navigate to its scan details either in ScanCode.io or the PurlDB.
In particular I would like to see details about license detection results (and scores), license clarity scores and navigate to the resource details

Report presentation UI problems

DejaCode Reports are being presented now with the columns compressed to squeeze them into the available screen space, rather than a more natural column width that spreads them out more legibly. This is a recently occurring problem. See attached screenshot of the 2-Product Package SBOM report run in the nexB dataspace. The problem exists with all the Reports.

Report presentation problem 2024-01-19 at 09 36 25

Provide new command option to "Improve Packages from PurlDB" on Product "Scan" dropdown

Importing an SBOM into a DejaCode Product can be disappointing if the SBOM does not have much license information. A nice feature would be to provide a new command option to "Improve Packages from PurlDB" on the Product "Scan" dropdown:

Step through the Product Packages
Use the PURL to find an entry in the PurlDB
Apply PurlDB field values to empty fields in the Product Package and corresponding Package definitions.

Add a "has_vulnerability" property on Package and Component to support Queries and Column Templates and Product Review

To get more value out of our VulnerableCodeDB integration, it would be great if we could add a "has_vulnerability" property to both the Package model and the Component model to support queries and column templates.

This is complicated by the fact that the DejaCode Report system is made to work on the DejaCode Database values, I'm not sure how we'll be able to accomplish since the Vulnerability data is stored in an external DB.

One idea would be to fetch both list of all vulnerable PURLs and CPEs references in the VulnerableCodeDB and store this the DejaCode cache. These lists could be updated in the cache on a daily basis. This would required new specialized API endpoints on the VulnerableCode side. (Also, as a first step before implementing any of this, we should get some stats about the amount of data stored in the VulnerableCodeDB and how it will evolve.)

We have a working prototype for this but we do not have the infrastructure in place for periodic async tasks (the celerybeat worker service need to be setup, or alternatively we could complete the migration to RQ that has direct support for periodic tasks. ( @tdruez please update this remark if the RQ migration complete is now complete ).

Also we might consider a few additional things (maybe they belong in different issues, but perhaps best discussed in this context first):

  • Think about automatically setting a (new) Product Inventory Status of “Vulnerability review required” when a vulnerable package is assigned to a product. Perhaps we do that in addition to a background process that looks at updated vulnerabilities (VulnerableCodeDB history dates are coming soon) and sets/resets those status values appropriately. An advantage of such an approach is that we can already filter by Product Inventory status (product relation status).
  • Alternatively (or also) provide a command on Product Inventory that filters to show just the items (packages mostly) with vulnerabilities.
  • And, if we end up doing the primary point of this issue, perhaps we can have a filter on the user view packages list that filters to show only packages with vulnerabilities.

Problems creating a package from a SourceForge download URL

Perhaps this is a user "pilot" error, but when I create a Package in DejaCode from a SourceForge download URL, I get strange results. A recent Add Package using
https://sourceforge.net/projects/scribus/files/scribus/1.6.0/scribus-1.6.0.tar.gz/download
resulted in a Package with a filename of download rather than scribus-1.6.0.tar.gz.
It also resulted in the rather verbose PURL value of
pkg:generic/download?download_url=https://sourceforge.net/projects/scribus/files/scribus/1.6.0/scribus-1.6.0.tar.gz/download

I scanned the package, using the same download URL, directly in SCIO v32.0.8, and it returned a PURL value of
pkg:autotools/scribus-1.6.0
in the key_files_packages section

So it appears that the rather eccentric download conventions of SourceForge are messing things up a bit.

  • Can we improve DejaCode to interpret the results of such a scan differently?
  • Does such an improvement rather belong in SCIO?
  • or should we prompt the DejaCode user with instructions how to provide a different, better, less eccentric download URL when processing a SourceForge package?

Make the assignment of Keywords in DejaCode more flexible

We should use the ComponentKeyword as suggestions in the keyword autocomplete fields and remove the validation to allow any keywords values.

In DejaCode, at the moment, only keywords existing as ComponentKeyword in the Dataspace are allowed. This approach is not compatible with automatically adding arbitrary keywords from Scan results or other integration processes.

Background: Scan results from SCTK returns keywords such as:

wrapper
proxy
decorator
Development Status :: 5 - Production/Stable
Programming Language :: Python :: 2
Programming Language :: Python :: 2.7
Programming Language :: Python :: 3
Programming Language :: Python :: 3.5
Programming Language :: Python :: 3.6
Programming Language :: Python :: 3.7
Programming Language :: Python :: 3.8
Programming Language :: Python :: 3.9
Programming Language :: Python :: 3.10
Programming Language :: Python :: 3.11
Programming Language :: Python :: Implementation :: CPython
Programming Language :: Python :: Implementation :: PyPy

Package `update_from_scan` is not triggered from already existing scans

From #26 (comment)

one other observation, which is not directly related to this issue, but something that is somewhat perplexing. DejaCode found the existing scans that I created yesterday for the 4 packages (good) and apparently they did not get re-scanned (fine I think) but it did not perform any of the auto-updates to fields on the package (not so good), such as the license-expression, even though 3 of the 4 scans have a declared license. See attached.

Note that this is not urgent as this is not a usual use case as it's more a side effect of a testing behavior (removing and re-adding already scanned packages)

Support download of both ScanCode Summary and Details for a package scan

While analyzing a Package in DejaCode recently created from https://github.com/VictoriaMetrics/VictoriaMetrics/archive/refs/tags/v1.93.9.tar.gz I used the Download Scan data button to get a copy of the scan results, and discovered that when I examined the downloaded file that there was no summary information in it, such as the license clarity scoring details. I submitted the same package directly to ScanCode.io and discovered that it produces two scan results files, summary-<timestamp>.json and scancode-<timestamp>.json and that the summary file has the information that I needed.

Currently the scan results page on Package only gives me the ability to download the scan result details. I think we should improve that by either:

  • improving the existing button to download both files, OR
  • providing 2 buttons Download Scan summary and Download Scan details

The summary has a lot of information that is useful to the user wanting to know more about the Package.

Introduce VEX Import (VEX Ingest) capability to DejaCode

Introduce VEX Import (VEX Ingest) capability to DejaCode

Refer to #15 for background details, especially the suggested improvements to the DejaCode Product and Product Package models.

The initial challenge is to identify the specific standard VEX formats to support. We want to support all the commonly implemented formats.

More details to follow.

Enhance DejaCode product attribution support for custom templates

It would be very useful to enable a DejaCode superuser administrator to make a copy of the standard attribution template and style sheet used by DejaCode and modify it to meet specific business requirements. Such a feature might include:

  • the ability to identify the default attribution template for a dataspace
  • the ability to identify a specific attribution template for a Product
  • the ability to select a specific attribution template, other than the default, at attribution generation time
  • a standard place to store one or more attribution templates to make selection easier
  • documentation (how-to, tutorial) to explain the concepts and capabilities of attribution templates in DejaCode and how to customize them, and how to identify the product and product inventory attributes that are available for attribution
  • retaining the existing "legacy" attribution template to support existing customers

Ideally, this enhancement would use much of the same code as ScanCode.io (SCIO), such as:

  • Use the same CSS style as SCIO
  • Full "pkg:" purls displayed to identify packages
  • Render the licenses, in expressions and lists, using the SPDX ID (ie: SPDX key or "LicenseRef-dejacode-{key}"
  • When available, provide licensedb_url in the license details (note that specific customer dataspaces will probably include local license definitions that are not in the LicenseDB).

The documentation should also explain the differences between product attribution documents and SBOMs, including the purpose of each.

Improve ABOUT file visibility in DejaCode

ABOUT File Visibility and the DejaCode UI
DejaCode currently provides a simple and convenient interface that enables a user to generate an ABOUT file (and associated files) for a Package or Component; however, the DejaCode user does not actually see what the ABOUT file is going to look like or what it looks like after the file is generated. The ABOUT file is in the user’s file system, separate from the DejaCode application and its database; only the single user sees the ABOUT file unless it is shared with the user’s team by some other technology.

Consider a new tab in the Package details user view, perhaps called “ABOUT”, that offers a rendering of its ABOUT file exactly as it will appear in a generated .yml file. This “preview” would allow the user to evaluate the Package data as it exists in DejaCode, complete with any curations, before it is actually generated. The same “preview” would also provide an appropriate means to confirm the successful Import ( see #43 ) of an ABOUT file into the DejaCode database, where the Import would either create or update a Package identified by the PURL.

If a DejaCode user updates Package details, then after those changes are saved the proposed ABOUT tab would show any impact on the ABOUT file fields as a preview of an ABOUT file that can potentially be generated.

Improve the "Add Package" process on the Package Vulnerabilities tab

When you view the Vulnerabilities tab of a Package (see example screenshot) it presents the purl(s) of Fixed package(s) when available. If the Fixed package is not define in your dataspace, it activates a + icon to enable an "Add Package" process, which currently presents the Add Package form with only the available purl fields populated. An improved process would do the following (or something better and equivalent):

  • Use the purl to search the PurlDB (the one integrated with the current DejaCode Dataspace) for a match and, if found, fetch the data of the PurlDB entry to populate the Add Package form.
  • If no Download URL is available, attempt to infer it from the available data.
  • Initiate a scan when the new package is saved.

This improved process takes advantage of available integrations (VCIO, SCIO) and data resources when adding a new Package to DejaCode.

Example Package Vulnerabilities tab

Add option to replace previous Package/Component version in "Add to Product"

When adding a package to a product after upgrading the version in the codebase:

  • I'm adding this package to DejaCode
  • Get the automated scan results and generate an ABOUT file that I place along the dist package in the codebase
  • Use "Add to Product" to assign this package to my current product/version
  • I need to manually remove the previous ProductPackage entry and I lost field values such as the purpose

We could add an option to the "Add to Product", to enable automatic replacement of the ProductPackage entry, keeping some of the field values such as purpose.

This would only be applied in case there's 1 entry with the same purl (different version).

@DennisClark Let me know your thoughts on this.

Improve the presentation of "multi-values" in DejaCode Reports

Currently when we have a Report Query that returns a field with multiple values (for instance multiple tags for a license), they are presented as a list of values separated by commas such as in True, False, True, True
When two columns have similarly "aligned" values such as a license key, it is therefore hard to see which license has which tag:

Component License                Redistribution
ABC       apache-2.0,            False, False,
          mit, bsd,              False, True
          gpl-2.0

An alternative approach would be to separate each of the multi-values with a new line instead of a comma, enabling us to present a visual alignment of the values:

Component License                Redistribution
ABC       apache-2.0             False
          mit                    False
          bsd                    False
          gpl-2.0                True

Note that the solution is a bit complicated because of the multiple Report output formats supported:

  • the DejaCode UI preview of the Report
  • the export formats: doc, html, json, xls, xlsx (the default), and yaml.

Any solution needs to work with all supported formats.

BUG: Web does not start due to gunicorn parameters

Describe the bug

Following the installation docs, the web component will not start correctly, leading to a "Bad Gateway" error in nginx.

To Reproduce

Steps to reproduce the behavior:

  1. Install Docker from the official Linux Mint Vera sources.
  2. Follow the installation docs.
  3. Observe gunicorn: error: unrecognized arguments: --workers 4
  4. Go to http://localhost and see an nginx error page.

Expected behavior

With the default parameter configuration/installation docs, the service should start cleanly.

Context

Removing the continuation backslash in

dejacode/docker-compose.yml

Line 33 in 024697b

gunicorn dejacode.wsgi:application --bind :8000 --timeout 600 \
seems to resolve the issue.

DOC: `docker-compose` versus `docker compose`

The installation docs and the Makefile are using the docker compose command. This is unknown to the Docker version shipped on Ubuntu 22.04 (Docker version 24.0.5, build 24.0.5-0ubuntu1~22.04.1), which only knows docker-compose.

With this, the default installation and all Makefile commands will not work out of the box.

Enhancement request: add support to scan package manifest

Following recent changes in SCIO we no longer can import product's data from package manifest

I would like to have the ability to simply upload a package manifest or lockfile as a product like in the former "import_manifest" feature.

We could do it best IMHO as two imports: import SBOM and import_manifest that would other behave the same.

Improve the hiding of empty fields in User View Details forms

DejaCode currently hides empty fields in the Component User Details view (although this needs to be reviewed and confirmed), but it should be enhanced to do that in all of the major application objects (Owners, Licenses, Packages, Products), perhaps with a button to "Show unused fields" in the UI.

Enhancement request: provide hint in package tree navigation

Is your enhancement request related to a problem? Please describe.

When navigating through the hierarchy, it is not apparent which package/dep has further deps.

For example in the following screenshot all the packages seem the same.

image

But if you click on Qt, it clearly has several dependencies.

image

What are the benefits of the requested enhancement?

It would make navigating the package hierarchy easier.

Describe the solution you would like

I think a visual indicator – e.g. a connector dot on the right-edge of the package bubble – would be enough.

Introduce VEX Export Capability to DejaCode

Introduce VEX Support to DejaCode

  • enhance data model to support a Product VEX List
  • provide Export capabilities to product VEX documents that comply with industry-recognized formats

Here are a few suggested details (subject to improvement upon review):

A VEX (Vulnerability Exploitability Exchange) is an assertion about the status of a vulnerability in specific products.

In DejaCode a VEX exists only in the context of a Product. Our first implementation of VEX support will apply only to Product Packages.

The standard VEX Status can be:
● Not affected – No remediation is required regarding this vulnerability.
● Affected – Actions are recommended to remediate or address this vulnerability.
● Fixed – Represents that these product versions contain a fix for the vulnerability.
● Under Investigation – It is not yet known whether these product versions are affected by the vulnerability. An update will be provided in a later release.

DejaCode should support the standard VEX Status list. To avoid adding too much complexity to the data model, this could simply be coded into DejaCode, rather than creating a new VEX Status code table.

Given that a Product Package can have more than one vulnerability (VCID) and that a vulnerability can apply to more than one Product Package, it is probably best to consider defining a VEX in DejaCode as relating to an overall Product. Consider an on-demand process (button or command) in DejaCode that collects all the Vulnerabilities currently associated with Product Packages and creates or refreshes a list that we can call “Product VEX List” (working title) and presents them on a new tab (“VEX List”) of the Product User View.

The “logical” key of a Product VEX List is Product+VCID+PackageID, and the presentation should be in that order, with one row for each Product VEX. Supporting data elements should include:

  • VEX Status (default value “Under Investigation”) – modifiable
  • VEX Action. modifiable. free form text. If the status is Affected, a valid VEX must have an action statement that tells the product user what to do.
  • VEX Impact modifiable. free form text. If the status is Not affected, a valid VEX must have an impact statement to further explain details.
  • VEX Notes. modifiable. free form text. Additional notes to explain the VEX.

DejaCode Processing:

  • From the Product VEX list, ability to open a Product VEX detail form.
  • From the Product VEX list, provide a navigation link to the Product Package details.
  • Provide full support for Product VEX in Reporting.
  • Provide full support for Product VEX in the DejaCode API.
  • (future) Generate DejaCode Notifications when a Product VEX is created and when the VEX Status is modified. Provide a link to the Product VEX from the Notification.

Some useful files, background, and links:

See the example VEX at

There is a descriptive overview of the CycloneDX approach to VEX here

Note that we are primarily interested in what they call the "Independent BOM and VEX BOM" rather that an SBOM with embedded VEX info, mainly because it is always important to remember that an SBOM is essentially static, associated with a specific Version of a package (or in our case a Product defined in DejaCode) while the VEX is intended to report time-critical information about potential impact of a software vulnerability and how it is being addressed.

The CSAF standard format, recommended by the CycloneDX team, is described here:
https://www.oasis-open.org/2022/11/28/common-security-advisory-framework-version-2-0-oasis-standard-is-now-published/

The CSAF also provides a downloadable package of the spec here:
https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.zip

The most useful file in that package for us is probably csaf_json_schema.json

Additional guidelines from CISA 2023-11-06 attached.
When-to-Issue-a-VEX-508c.pdf.zip

Interesting commentary from Tom Alrich attached.
When will there be VEX tools.pdf

Add plugin/extension mechnism for additional reports

I would like to have a way to contribute additional custom reporting as new code in DejaCode.
This would not be code that is part of the standard DejaCode, but rather a separate project that I could install as its own wheel.

We could reuse the same approach as in ScanCode toolkit plugins or for ScanCode.io pipelines

Provide ability to Import an ABOUT file into DejaCode

See related issue #42

DejaCode currently provides a simple and convenient interface that enables a user to generate an ABOUT file (and associated files) for a Package or Component; however, the direction is only outbound from DejaCode.

Consider enhancing DejaCode to support the ability to import an ABOUT file, with the result being either the creation of a new Package or updates to a Package already defined in DejaCode.

  • Note that the PURL of a DejaCode Package is (must be) exactly the same as the PURL in a corresponding ABOUT file (perhaps obvious but worth emphasizing).
  • It might also make sense for this proposed Import process to query the PurlDB to find and use any additional useful details that could be useful when creating a new Package, but are not provided in the ABOUT file being imported.

Once the import is completed, then the DejaCode user would be able to see all the Package details in the standard DejaCode details view, and also reproduced in the ABOUT tab.

RFC: Store additional license details on the Package model

Problem: provide more clarity for "Declared License" vs "Concluded License" .

Benefit: support the completeness of an SBOM.

Create an additional declared_license field on Package. When a package scan is completed update both the current assigned_license field and this new declared_license field with the same values. The intention is to retain the declared_license as an historical record, so that the assigned_license field essentially becomes the "concluded license" (we can change the help text on that field).

Store the additional licenses from the scan results on the package model as well. This will support deeper analysis and reporting, enabling users to comment on why specific additional licenses impact or do not impact the licensing terms as the package is expected to be used in an organization.

More design details to follow.

Assign a category+usage-policy to a license-expression to clarify license WITH exception cases

See related issue nexB/scancode-toolkit#2897

We should assign a category+usage-policy to a license-expression to clarify license WITH exception cases.

It could be that all exceptions to a Copyleft license turn a license expression into a Copyleft-limited

It's important to clarify that the scope of this improvement is limited to "license WITH exception" cases and not more complex license expressions that express multiple licenses connected by the "AND" operator; that is, the "(license WITH exception)", ideally surrounded by parentheses, can be thought of as its own unit (a molecule?) and we can apply a category to that. Since the most common cases exist with the general rule that the category of the exception prevails over the category of the target license, we can make that the default behavior, but ultimately this should be controlled by SCTK detection rules to handle odd cases where that is not what is actually happening, for example, "exceptions" that simply tell you what you are allowed to do but don't really modify the target license terms.

Enhance Product Compare to allow user to save the results

The results of a DejaCode Product Compare can be very useful in the ongoing analysis and communication activities that happen during product SCA or the defining of a new product version.

It would be extremely helpful for the User to be able to save the results in Excel format. Other nice formats would be a Word document (where the results would be in a Word document table, if possible) and/or html and/or pdf. But the most important and useful output format would probably be Excel, in order to support analysis, editing, and annotation among product stakeholders.

Note that there are some non-editable workarounds:

  • You can do a browser "Save Page As..." on the Product Comparison, and select "Web Page Complete" (or equivalent, depending on browser), which generates an html file, but with some formatting issues.
  • You can Print the Product Comparison using your browser, perhaps using the save-to-PDF option.

Create a standard API between DejaCode Requests and Atlassian JIRA

We need a way for a DejaCode Superuser, who is also an Atlassian JIRA administrator, to use the DejaCode UI to configure integration between DejaCode Requests and JIRA Issues (requests, tickets, whatever). Design needed of course. Potential approaches include the following:

  1. Submit a JIRA issue on DejaCode Request addition:

We could use the DejaCode Webhook system (already supported for Slack), to add a mapping for JIRA.

  1. Create a DejaCode Request on JIRA issue addition:

A JIRA Webhook needs to be configured, providing a DejaCode URL that would receive the data from JIRA and map it into a DejaCode issue creation. See

Provide Scan import feature endpoints

In the context of automation, we should add the following Product features in the REST API:

  • Import from Scan
  • Load Packages from SBOMs
  • Pull Project data from ScanCode.io

This would allow to automatically feed new DejaCode Products from a CI workflow, such as using https://github.com/nexB/scancode-action, for example:

  • On pushing a new release/tag in my repo
  • The scancode-action is triggered to run a scan_codebase pipeline
  • The scan results are uploaded to a DejaCode instance into a new product, and/or to a ScanCode.io instance for review of the results.

Update links for DejaCode documentation

Our primary DejaCode documentation is now at: https://dejacode.readthedocs.io/en/latest/, but there is no link to it from the DjC Home page.

Design an enhanced DejaCode Package model to identify source code relationships

The working idea here is to come up with the best way to identify cross-package relationships, especially to be able to get to
(1) the source code
and
(2) more complete copyright+license data, which usually comes from the source code.

We could start by displaying the values for contains_source_code, source_packages, code_view_url, and vcs_url in the "Detected Package" section of the Scan tab (when a value is available). The ScanCode package model has this support for source code relationships (which are also in PurlDB):

  • the `contains_source_code` boolean flags tells if the package itself contains source code: https://github.com/nexB/scancode-toolkit/blob/0465269543eb338086c10bdeb1e81d3013522b4d/src/packagedcode/models.py#L452

  • the `source_packages` field is a list of Package URLs that may exist for this package https://github.com/nexB/scancode-toolkit/blob/0465269543eb338086c10bdeb1e81d3013522b4d/src/packagedcode/models.py#L457

  • the `code_view_url` and `vcs_url` provide reference URLs to view or fetch actual source code https://github.com/nexB/scancode-toolkit/blob/0465269543eb338086c10bdeb1e81d3013522b4d/src/packagedcode/models.py#L414

Now that we have standardized on PURL as the package identifier, we should be able to pursue this DejaCode improvement using package-set values via integration with the PurlDB.

Add pagination on the Product Inventory tab

We need to add add pagination on the Product Inventory tab, since the number of Inventory Items can easily be well over 100.

Also, we need to fix the default ordering (which is currently based on pk) and provide sorting options (perhaps on the column headers).

Problems with the Filter dropdown on the DejaCode PurlDB view

On the DejaCode PurlDB view, if I use the Filter dropdown and enter gem and click the Filter button (or simply press return), the application is updating the URL with all the possible Filter parameters like this

https://public.dejacode.com/purldb/?type__iexact=gem&namespace__iexact=&name__iexact=&version__iexact=&download_url__iexact=&filename__iexact=&sha1=&md5=&size=&release_date=&purl=&q=&sort=

which is not actually filtering by a type of gem and it continues to show all of the packages in the PurlDB.

Improve documentation for DejaCode integration with SCIO, VulnerableCode and PURLDB

Our current instructions for installing DjC provides references to PURLDB and VulnerableCode in the Application Settings section, but there is no mention of the settings for SCIO integration.

The current documentation does not provide any information about which DejaCode features require integration with one or more of SCIO, VulnerableCode or PURLDB or the current options for installing these modules.

We need to document the functionality that depends on the installation and integration of other AboutCode projects and the current options for integration. We do not need to provide installation details that are better handled by the documentation for each project, but we need the big picture perspective from DejaCode.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.