|The Package Type must be specified when the repository is created, and once set, cannot be changed.|
|The Repository Key is a mandatory identifier for the repository and must be unique within an Artifactory instance. It cannot begin with a number or contain spaces or special characters. For local repositories we recommend using a "-local" suffix (e.g. "libs-release-local").|
|Sets the layout that the repository should use for storing and identifying modules. Artifactory will suggest a layout that corresponds to the package type defined, and index packages uploaded and calculate metadata accordingly.|
|A free text field that describes the content and purpose of the repository.|
|A free text field to add additional notes about the repository. These are only visible to the Artifactory administrator.|
Include and Exclude Patterns
The Include Patterns and the Exclude Patterns fields provide a way to filter out specific repositories when trying to resolve the location of different artifacts.
In each field you can specify a list of Ant-like patterns to filter in and filter out artifact queries. Filtering works by subtracting the excluded patterns (default is none) from the included patterns (default is all).
Consider that the Include Patterns and Exclude Patterns for a repository are as follows:
In this case, Artifactory will search the repository for
JFrog Xray Integration
|If Artifactory is connected to an instance of Xray, indicates if the repository is indexed for analysis.|
This section explains how to use Exclude Patterns to avoid the following security risks.
Any proprietary artifacts you deploy to Artifactory are stored within local repositories so that they are available for secured and authorized internal use.
Anyone searching for one of your internal artifacts by name will extract it through Artifactory from the local repository.
However, consider what happens if a request for an internal artifact is inadvertently directed outside of the organization.
Two examples of how this could happen are:
In this case, since Artifactory does not find the requested artifact in a local repository, it continues to search through the remote repositories defined in the system. Artifactory will, in fact, search through all the remote repositories defined in your system before returning "Not found".
This presents a security risk since any request made on a remote repository may be logged exposing all details of the query including the full artifact name which may include sensitive business information.
To avoid exposing sensitive business information as described above, we strongly recommend the following best practices:
Proxying a public remote repository that is not a trusted repository or is compromised can expose you to malicious artifacts. Sometimes these repositories allow anyone to deploy custom packages. For example, for npm, the public repository is
npmjs, and anyone can deploy any version of any package he/she is the owner of. If a package does not have an owner (no one has previously deployed a version of it) anyone can deploy it and claim it.
For example, let's assume you have a library called "
almo-common-utils" and its source is publicly accessible, if, for instance, it is bundled as part of publicly accessible products or web applications, it’s written in Node and JFrog Artifactory has a set of remote (proxying the public repository), local (for sharing modules internally), and virtual repositories.
Consider the following:
almo-common-utils"(unless there is a name conflict).
almo-common-utils" in the public repository (because it’s an internal corporate library), so there is no name conflict.
almo-common-utils" using a version range. For example, a range specifying the latest version compatible with a major version.
This presents a security risk, as an attacker can try to attack an unprotected organization by just having prior knowledge of the library "
almo-common-utils\", the major version of the library in use (let’s say they know version 3 is used widely in the organization), and the content of the source code.
An attacker can clone and modify the source, embedding any malware inside, but still maintain compatibility with the original code, and upload it to the repository as "
:3.99.99". This will create a version update hijacking of an internal library, when "
almo-common-utils:^3.0.0" is requested, the fake "
almo-common-utils" from the repository is fetched.
To avoid exposing internal packages and internal packages version hijacking, we strongly recommend the following:
.npm/almo*/**), by scope (
.npm/@almo/*) or by name (
.npm/almo-encoder/**). By setting these exclude patterns on any public remote repository, you are effectively not merging those packages from the public repositories.
In a typical scenario, Artifactory will reference large all-purpose repositories such as or Maven Central for resolving artifacts.
In addition, Artifactory may reference any number of additional repositories which may host a more specialized and specific set of of artifacts.
If Artifactory receives a request for a deterministic set of artifacts (e.g. a specific version of an artifact), then it searches through the different repositories according to its resolution order until the artifact is found.
However, if Artifactory receives a request for a non-deterministic set of artifacts ( e.g. all versions of
maven-metadata.xml) then it must search through all of the repositories it references until it can provide a complete response.
In most cases, the majority of artifacts downloaded by an organization will come from one of the large all-purpose repositories, but in non-deterministic requests performance is downgraded because Artifactory continues to search through all the specialized repositories before it can return a response.
To avoid performing needless and wasteful search when responding to non-deterministic requests we strongly recommend that all specialized repositories be configured with an appropriate Include Pattern specifying only the set of artifacts that the organization might need.
In this case, non-deterministic requests for artifacts that are typically found in general purpose repositories will skip over the specialized repositories thereby improving performance.
In addition to the settings above, Local and Remote repositories share the following settings in the type-specific section for relevant package types.
Max Unique Snapshots
Specifies the maximum number of unique snapshots of the same artifact that should be stored. Once this number is reached and a new snapshot is uploaded, the oldest stored snapshot is removed automatically.
Blank (default) indicates that there is no limit on the number of unique snapshots.
|If set, Artifactory allows you to deploy release artifacts into this repository.|
|If set, Artifactory allows you to deploy snapshot artifacts into this repository.|