Safeguard against malicious public packages

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

With Azure Artifacts upstream sources, developers gain the convenience of using a unified feed to both publish and consume packages from Artifact feeds and popular public registries like NuGet.org or npmjs.com.

This feature enables developers to control whether they want to consume package versions from public registries such as NuGet.org or npmjs.com.

Once the Allow External Versions toggle is enabled for a specific package, versions from the public registry become available for download. By default, this option is disabled, adding an extra layer of security by preventing exposure to potentially malicious packages from public registries. You must be a Feed Owner to enable the allow externally sourced versions feature.

The following section outlines common scenarios where external versions (packages from public registries) are either blocked or allowed from being saved to the feed. In the rest of this article, we refer to packages from public registries as public packages and packages in an Azure Artifacts feed as private packages.

• Private package version made public
• Having both private and public packages

In this scenario, a team has a private package that was made public. The external versions setting in this case will cause the feed to block consumption of any new versions with that package name from a public source.

In this scenario, if a team uses a combination of private and public packages, disallowing externally sourced packages blocks any new package versions from the public registry.

• All packages are private
• All packages are public
• Public package made private

If all existing packages are private, and the team has no plans to use any public packages, the external versions setting has no effect on the team's workflow in this scenario.

In this scenario, if the team exclusively consumes public packages, whether from the public registry or other open-source repositories, the setting doesn't affect their workflow in any way.

In this situation, when a public package is converted to a private package, the external versions setting doesn't affect the team's workflow in any way.

1. Sign in to your Azure DevOps organization, and then navigate to your project.

2. Select Artifacts, and then select your feed from the dropdown menu.

3. Select your package, and then select the ellipsis button for more options. Select Allow externally-sourced versions.

   

4. Select the toggle button to allow external versions. Select Close when you're done.

   

1. Create a personal access token with Packaging > Read, write, & manage permissions.

   

2. Create an environment variable for your personal access token.

   $env:PATVAR = "YOUR_PERSONAL_ACCESS_TOKEN"
   

3. Convert your personal access token to baser64 encoded string and construct the HTTP request header.

   $token = [Convert]::ToBase64String(([Text.Encoding]::ASCII.GetBytes("username:$env:PatVar")))
   $headers = @{
       Authorization = "Basic $token"
   }
   

4. Construct your endpoint url. Example: //pkgs.dev.azure.com/MyOrg/MyProject/_apis/packaging/feeds/MyFeed/nuget/packages/pkg1.0.0.nupkg/upstreaming?api-version=6.1-preview.1

   • Project-scoped feed:

     $url = "https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/<PROJECT_NAME>/_apis/packaging/feeds/<FEED_NAME>/<PROTOCOL>/packages/<PACKAGE_NAME>/upstreaming?api-version=6.1-preview.1"
     

   • Organization-scoped feed:

     $url = "https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/_apis/packaging/feeds/<FEED_NAME>/<PROTOCOL>/packages/<PACKAGE_NAME>/upstreaming?api-version=6.1-preview.1"
     

Invoke-RestMethod -Uri $url -Headers $headers

$body = '{"versionsFromExternalUpstreams": "AllowExternalVersions"}'

Invoke-RestMethod -Uri $url -Headers $headers -Body $body -Method Patch -ContentType "application/json"

$body = '{"versionsFromExternalUpstreams": "Auto"}'

Invoke-RestMethod -Uri $url -Headers $headers -Body $body -Method Patch -ContentType "application/json"

• Understand upstream sources
• Manage dependencies with upstream sources
• Best practices