Changes to Azure Artifacts Upstream Behavior

Michael Omokoh

February 9th, 20219 0

We live in a world that has walls and those walls need to be guarded by people with swords.

Eh… not a literal sword in this case😀, but with behaviors that can help keep your assets more secure and protect against bad actors.

Previously, Azure Artifacts feeds presented package versions from all of its upstream sources. This includes package versions that were originally pushed to an Azure Artifacts feed (internally sourced) and package versions from common public repositories like npmjs.com , NuGet.org , Maven Central, and PyPI (externally sourced).

Today, we’re excited to announce a new behavior that provides additional security for your private feeds by limiting access to externally sourced packages when internally sources packages are already present. This provides a new layer of security, which prevents malicious packages from a public registry being inadvertently consumed. These changes will not affect any package versions that are already in use or cached in your feed.

The security behavior applies:

when an internally sourced version is already in your feed, or
when consuming a package from your feed for the first time (i.e. it is not yet in your feed), and at least one of the versions available from an upstream is internally sourced.

With the new behavior, any versions from the public registry will be blocked and not made available to download. You are able to configure the upstream behavior to allow externally sourced package versions if you choose to.

Learn more about common package scenarios where you need to allow externally sourced package versions along with a few other scenarios where no blockage to the public packages is needed and how to configure the upstream behavior.

Organizations that wish to opt out of this additional protective behavior can disable a newly added organization-wide security policy. To do this,

Go to organization settings
Click on policies under the security section
In the security policies section, toggle off ‘Additional protections when using public package registries’

Other Resources

Learn more about protecting private package feeds: Ways to Mitigate Risk Using Private Package Feeds

We want to hear your feedback!

As always, we want our Artifact Services to meet the evolving needs of our community. Post a comment or use the Developer community to provide feedback or ask questions about these changes to upstream behavior.

Michael Omokoh Program Manager, Azure DevOps

9 comments

Comments are closed. Login to edit/delete your existing comments

Brown, Christopher February 10, 2021 8:39 am 0

Literally spent an hour supporting builds failing because of this. “Why are upstream sources failing to get the latest version.”

Maybe features that block functionality should be an Opt-in, instead of an opt out.

Further added pain: This forced-opt-in feature forces a user to re-enable every library to be downloaded from external sources.
- Stefan Koell February 13, 2021 3:43 am 0
  
  I think having this feature off by default is a good thing but the UX/discoverability is really bad. You have to wildly click around on icons on that page to reveal that switch.
  - Michael Omokoh February 18, 2021 11:49 am 0
    
    @Stefan, thanks for your feedback on the UX/discoverability. We are working on improving the experience for customers.
- Michael Omokoh February 22, 2021 3:24 pm 0
  
  @Brown, We’re sorry that you were inconvenienced by the upstream behavior change.
  For most package usage scenarios the new behavior should not interrupt existing flows. There are less common scenarios where explicitly allowing external versions is needed, as explained here.
- Michael Omokoh February 22, 2021 3:29 pm 0
  
  @Brown We would like to hear about cases where there’s been greater than expected disruption. If you’re interested in sharing your scenario, please use our Developer Community site to submit feedback, and we can engage with you there.
  The feature is was enabled by default because it relates to security for our customers. The vulnerability with some package managers/project configurations has been publicly disclosed, so in this particular case we chose to prioritize secure-by-default over any possible disruption. If you need to opt-out of the new behavior, you can disable the security policy in the organization settings.
Matt Minet March 4, 2021 2:57 am 0

Alright, but its not showing up.
In the section you mention it literally does not exist.
- Michael Omokoh March 5, 2021 10:58 am 0
  
  @Matt. Thanks for you message. If you mean the security section,
  You have to go to the organization setting to see that. The reason you may not be able to see the section is that you are in your project settings.
Jin Dong March 11, 2021 2:15 pm 0
Spent a lot of time resolving issues caused by this change. As a developer without these permissions to change the settings mentioned, how can I resolve this scenario:
1. I need the latest version of, say, newtonsoft.json or jQuery from nuget.org. I use them from my feed the first time.
2. I need a package from an internal feed, say, FeedA.
3. FeedA uses only an old version of newtonsoft.json, which is included in FeedA itself.
4. With FeedA as an upstream, I cannot get the latest version of newtonsoft.json from nuget.org as per the new behavior.
5. Since I use the package the first time, it hasn’t appeared in my feed list. So I cannot even enable the “allow externally-sourced versions” option.
This situation happens literally many many packages that I use from nuget.org. Now I cannot find them just because one of the internal upstreams use an old version and include the old package in it.
- Jin Dong March 31, 2021 1:07 pm 0
  
  @Michael Can you please share some solutions to such a scenario.
  
  Thank you!