Security, Licensing, and Reliability Considerations - DevExpress NuGet Packages

• Mar 18, 2024
• 4 minutes to read

How to Protect Your Private NuGet Feed and Safely Consume the Feed From External Systems

Our NuGet feed URL and authorization key are not encrypted. You should protect this sensitive information against unauthorized use by untrusted third parties. For instance, do not share nuget.config and other secret files with our NuGet feed URL or authorization key on GitHub, public Support Center tickets, Stack Overflow, and on other public online resources. If you accidentally exposed your NuGet feed to the public, submit a new ticket to the DevExpress Support Center so that we can regenerate your NuGet feed.

To help protect private NuGet feeds in your CI/CD system and other secured environments such as Azure DevOps, Docker, Kubernetes, GitHub, or GitLab, we support NuGet authentication using personal access tokens. Options include:

• Azure DevOps – Add your private NuGet URL or authorization key as a Secret variable and select its Keep this value secret option within Azure DevOps UI. You’ll need to explicitly set secret variables as environment variables to reference them in YAML pipelines. Secret variables are encrypted and are available on the agent for tasks and scripts to use. Alternatively, use Azure Key Vault secrets and query their values in your pipeline.
• .NET CLI (the dotnet tool) or NuGet CLI – Pass the authorization key as a parameter to your CLI commands when you add NuGet packages.
• Docker and Kubernetes – If you use BuildKit to build a Docker image, you can specify the --secret flag to safely pass the NuGet source URL.

• GitHub Actions - Add your private NuGet URL or authorization key as a Secret within GitHub Actions UI. Then you can pass your secret name to GitHub Actions CLI scripts as an environment variable. GitHub Actions can only read a secret if you explicitly include the secret in a workflow. You can also control access to secrets at the environment, organization, and repository levels.

  Example: deploy-app-farm.yaml:

  run: dotnet nuget add source ${{ secrets.DEVEXPRESS_NUGET_URL }} -n devexpress-nuget
  

• GitLab - Add your private NuGet URL or authorization key as a Variable and select its Mask variable option within GitLab UI. Then you can pass your secret Variable name to GitLab CLI scripts as an environment variable. The variable’s Value will be masked in job logs during dotnet build or dotnet restore command execution.

  Example: gitlab-ci.yml:

  build-job:
      script:
          - dotnet build --source "https://api.nuget.org/v3/index.json" --source "https://nuget.devexpress.com/$DEVEXPRESS_NUGET_KEY/api/v3/index.json"
  

NuGet Licensing Best Practices for Multi-License Holders & CI/CD

If you are working within a team, a license holder (typically a team lead or company owner) assigns individual DevExpress licenses to each developer using the Assign Licenses menu on our website. An individual DevExpress license assigned to a developer grants this developer the right to use the DevExpress Unified Component Installer or individual NuGet feed credentials.

Question: Which NuGet feed should a team of multiple developers use for a shared CI/CD pipeline?

Answer: For a shared CI/CD pipeline, use individual NuGet feed credentials for a developer with a valid DevExpress license (it does not matter whether this individual is a team lead/developer/company owner). This developer can also develop with valid DevExpress products within Visual Studio or another IDE. All other developers within the team who use DevExpress products must also own valid DevExpress licenses.

If the primary license holder assigned all available licenses to developers within the team, the license holder cannot use their NuGet feed for a shared CI/CD pipeline or any other development purposes. Nothing changes regarding NuGet in this regard – this has always been the case for our Unified Component Installer – primary license holders without a license cannot install our products (whether through NuGet or the Unified Installer).

Cache NuGet Packages for the Best Performance and Reliability

We strongly recommend that you configure your CI/CD pipelines to cache NuGet packages. Caching NuGet packages will help your team reduce your build time and also avoid any downtime should outages occur (with https://nuget.devexpress.com/ or with external NuGet servers like https://www.nuget.org/). For instance, with Azure DevOps, you can follow best practices outlined in the following document: Cache NuGet packages | Microsoft Azure DevOps documentation. Contact to your CI/CD system vendor for more information and review our NuGet feed integration help topic for additional assistance.