Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -53,7 +53,7 @@ In Step 3, _Basic information for your Custom App_, enter "Cloudsmith" (without

### Step 7

In Step 4, _Service Provider Details_, enter: `https://cloudsmith.io/MY_ORG_NAME/saml/acs/` as the _ACS URL_ and _Entity ID_, where "MY_ORG_NAME" is replaced with your organization's slug (i.e. what your normally see in the URL bar for your organization).
In Step 4, _Service Provider Details_, enter: `https://cloudsmith.io/orgs/MY_ORG_NAME/saml/acs/` as the _ACS URL_ and _Entity ID_, where "MY_ORG_NAME" is replaced with your organization's slug (i.e. what you normally see in the URL bar for your organization).

Leave the _Signed Response_ checkbox _unchecked_ (this is very important). Then for the _Name ID Format_, ensure that "EMAIL" is chosen from the dropdown list. Then click on _NEXT_ on the bottom right:

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -50,7 +50,7 @@ For the next step, you'll need to generate a public and private key used to sign
<BlockImage src={img010954d_HngkhoO} alt=""></BlockImage>

### Step 6
Next, we'll fill in **SP Entity ID** and **ACS URL** with the same value. To determine the value we use the following format: `https://cloudsmith.io/MY_ORG_NAME/saml/acs/` where "MY_ORG_NAME" is replaced with your organization's slug e.g. for the `cloudsmith` org we use `https://cloudsmith.io/cloudsmith/saml/acs/` (you can find your organization's slug in the URL bar when you are logged into Cloudsmith, or browsing to [User Settings > Workspaces](https://app.cloudsmith.com/settings/workspaces)):
Next, we'll fill in **SP Entity ID** and **ACS URL** with the same value. To determine the value we use the following format: `https://cloudsmith.io/orgs/MY_ORG_NAME/saml/acs/` where "MY_ORG_NAME" is replaced with your organization's slug e.g. for the `cloudsmith` org we use `https://cloudsmith.io/orgs/cloudsmith/saml/acs/` (you can find your organization's slug in the URL bar when you are logged into Cloudsmith, or browsing to [User Settings > Workspaces](https://app.cloudsmith.com/settings/workspaces)):

<BlockImage src={img8e49768_hAcXDjT} alt=""></BlockImage>

Expand Down
15 changes: 12 additions & 3 deletions src/content/formats/generic-repository.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -135,7 +135,13 @@ curl -sLf -H "X-Api-Key: API-KEY" -O "https://generic.cloudsmith.io/OWNER/REPOSI

**Authentication when using the Download domain (dl.cloudsmith.io):**

The `dl.cloudsmith.io` domain only supports path-based authentication with entitlement tokens embedded in the URL path. HTTP Basic Auth with credentials in the userinfo portion of the URL (e.g., `token:TOKEN@dl.cloudsmith.io`) is not supported on this domain.
The `dl.cloudsmith.io` domain most commonly uses path-based authentication with entitlement tokens embedded in the URL path. There are some exceptions:

HTTP Basic Auth with credentials in the userinfo portion of the URL (e.g., `token:TOKEN@dl.cloudsmith.io`) is only supported for the `/basic/...` download route on this domain and is not supported for the default `/TOKEN/...` path-based URLs.

```shell
curl -sLf -O "https://token:TOKEN@dl.cloudsmith.io/basic/OWNER/REPOSITORY/generic/download/UPSTREAM_PREFIX/path/to/file.gz"
```

Include `generic/download/` in the URL path before the upstream prefix to ensure requests are routed correctly.

Expand All @@ -147,14 +153,17 @@ curl -sLf -O "https://dl.cloudsmith.io/TOKEN/OWNER/REPOSITORY/generic/download/U

A URL follows the structure: `scheme://userinfo@host/path`

- **Userinfo** (`token:TOKEN@`): Credentials placed before the host. This is HTTP Basic Auth and only works on `generic.cloudsmith.io`.
- **Userinfo** (`token:TOKEN@`): Credentials placed before the host.
- **Path** (`/TOKEN/...`): Token embedded after the domain in the URL path. This only works on `dl.cloudsmith.io`.

| Domain | Authentication Method | Token Location |
| :----- | :-------------------- | :------------- |
| `generic.cloudsmith.io` | Basic Auth | Userinfo |
| `generic.cloudsmith.io` | API Key | HTTP header |
| `dl.cloudsmith.io` | Path-based |
| `dl.cloudsmith.io` | Path-based | Path |
| `dl.cloudsmith.io` | Basic Auth | Userinfo |

Note: Not all forms of Basic Auth are supported on this domain. See the documented example, HTTP Basic Auth with credentials in the userinfo portion of the URL.

<Note variant="note" headline="When to use the download domain">
Use `dl.cloudsmith.io` instead of `generic.cloudsmith.io` when:
Expand Down
69 changes: 69 additions & 0 deletions src/content/formats/signing-swift-packages.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
import { Note } from '@/components'

# Signing Swift Packages
<Note variant="note" headline="Early Access">
Swift Package signing is currently in Early Access. To use this feature please contact us.
</Note>

## How it works
Swift packages are signed using an ECDSA private key and X.509 Certificate combination, with the certificate containing the private key’s
corresponding public key. When Swift package signing is enabled for a repository, an ECDSA key pair and X.509 certificate are created, and
all Swift packages uploaded or resynchronized to the repository will be signed automatically.

## Note on signing existing packages

<Note variant="note" headline="Signing of existing packages">
Signing a Swift package mutates its state, and may cause builds employing the package as a dependency to break. This can be rectified by
removing the stored fingerprint(s) for the relevant manifest and source archive.
</Note>

Signing a Swift package mutates the package's state, as package manifest signatures are added to the manifest files themselves, modifying the checksum
of the overall source archive. As Swift performs checksum Trust On First Use (TOFU), signing a Swift package may cause builds to break where those
packages have already been consumed locally as dependencies.

Consequently, to sign packages already used as dependencies, the stored fingerprint(s) for the relevant manifest and source archive must
be removed. These can be viewed and modified in the ~/.swiftpm/security/fingerprint directory.

## Configuring the Swift CLI to verify packages
When the Swift CLI consumes a signed package, it validates the signature for both the manifest and the source archive. These signatures
are in Cryptographic Message Syntax (CMS) format and are base64 encoded. The signatures vary slightly:
* A manifest signature is an attached signature; it is included directly within the manifest file (see [here](https://github.com/swiftlang/swift-package-manager/blob/main/Documentation/PackageRegistry/PackageRegistryUsage.md#package-manifests) for example).
* A source archive signature is a detached signature; it is included within the metadata response when fetching a package for a specific scope/name/version. Swift determines whether the package is signed by inspecting the signing attribute in the metadata response. For more information see [here](https://github.com/swiftlang/swift-package-manager/blob/main/Documentation/PackageRegistry/Registry.md).

The source archive signature is generated after the manifest(s) are signed.

The Swift CLI registry security configuration is specified at the user level in a registries.json file. For more information on this configuration see [here](https://github.com/swiftlang/swift-package-manager/blob/main/Documentation/PackageRegistry/PackageRegistryUsage.md#security-configuration).

## Adding a Trusted Certificate
A certificate is trusted by Swift if it is chained to any root in SwiftPM’s trusted store (which can be in two locations). To ensure that the certificate
used by Cloudsmith to sign Swift your packages is trusted you’ll need to perform the following steps, which will fetch the intermediate CA certificate used
to sign the repository-level certificate, and place it in Swift’s default trust store.
1. Fetch the certificate chain for the signing certificate and assign it to a variable. The chain contains both the root CA certificate and intermediate CA
certificate (it does not include the actual signing certificate):
```
CERTIFICATE_CHAIN="$(curl --location '<https://api.cloudsmith.io/repos/<org-name>/<repo-name>/x509-ecdsa/' \\
--header 'Accept: application/json' \\
--header 'X-Api-Key: <api-key>' \\ | jq -r .certificate_chain)"
```
2. Write the chain to a .pem file.
```
echo $CERTIFICATE_CHAIN >> cert_chain.pem
```
3. Swift requires that the certificate be in .der (Distinguished Encoding Rules) format. To do that, convert the .pem file to .der.
Note that a certificate chain can’t be represented in the DER format, however only the intermediate CA certificate is required.
This can be achieved by the following:
```
openssl x509 -in cert_chain.pem -out cert.der -outform DER
```
4. Now place this trusted certificate in the following path:
```
~/.swiftpm/security/trusted-root-certs/
```
5. Add the trustedRootCertificatesPath to your security configuration, as shown [here](https://github.com/swiftlang/swift-package-manager/blob/main/Documentation/PackageRegistry/PackageRegistryUsage.md#security-configuration). Confusingly, the CLI doesn’t seem to like the relative path in the example shown,
so you might have to change it to an absolute path.

Once the above steps are complete, you will be able to consume fully verifiable and signed swift packages from Cloudsmith.




4 changes: 2 additions & 2 deletions src/content/formats/swift-registry.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -337,8 +337,8 @@ Please see our [Upstream Proxying](/repositories/upstreams) documentation for fu

## Key Signing Support

<Tag variant="red" theme="legacy">Not supported</Tag>
<Tag variant="dark-green" theme="legacy">Supported</Tag>

## Troubleshooting

Please see the [Troubleshooting](/troubleshooting) page for further help and information.
Please see the [Troubleshooting](/troubleshooting) page for further help and information.
8 changes: 7 additions & 1 deletion src/content/menu.json
Original file line number Diff line number Diff line change
Expand Up @@ -150,7 +150,13 @@
},
{
"title": "Swift",
"path": "/formats/swift-registry"
"path": "/formats/swift-registry",
"children": [
{
"title": "Signing Swift Packages",
"path": "/formats/signing-swift-packages"
}
]
},
{
"title": "Terraform",
Expand Down
4 changes: 2 additions & 2 deletions src/content/open-source-hosting-policy.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@ To qualify for an open-source repository, we have a few simple rules for you:

If you need clarity on any of these, please feel free to [contact us](https://cloudsmith.com/company/contact-us) to ask. We'll be delighted to help.

We currently pre-authorize open-source repositories and then check them later on. In other words, feel free to create the open-source repositories you need today, and as long as you're following the rules above, you'll be able to use them immediately.
We don't require advance permission to create open-source repositories. (We might check them later, to confirm they qualify.) In other words, feel free to create the open-source repositories you need today, and as long as you're following the rules above, you'll be able to use them immediately.

If your repository doesn't fit within our rules, this is usually something simple that can be fixed, such as using the wrong license. For more severe cases, we may have to suspend the open-source repository (e.g., doesn't have attribution, or is for a fork, etc.)

Expand Down Expand Up @@ -92,4 +92,4 @@ Some examples of open-source projects we've sponsored formally:
- [HoneyDB](https://honeydb.io)
- [Shields](http://shields.io)
- [Pony Language](https://www.ponylang.io)
- [CloudPosse](https://github.com/cloudposse/packages)
- [CloudPosse](https://github.com/cloudposse/packages)
4 changes: 2 additions & 2 deletions src/content/policy-management/block-until-scan.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,7 @@ To verify the functionality of Block Until Scan, follow these steps:

Browse to your Workspace Settings and [create a new vulnerability policy](/policy-management/vulnerability-policy). Define your policy with:
- A name.
- A [package Search Query](/artifact-management/search-filter-sort-packages) to scope the filter to `format:python AND requests`. We're targeting only packages named `requets` from Python, following the example in the next step. Adjust the policy to affect only to your desired scope if you use a different package for this example.
- A [package Search Query](/artifact-management/search-filter-sort-packages) to scope the filter to `format:python AND requests`. We're targeting only packages named `requests` from Python, following the example in the next step. Adjust the policy so that it applies only to your desired scope if you use a different package for this example.
- A severity threshold set to `High`.
- A Quarantine action enabled.

Expand Down Expand Up @@ -87,4 +87,4 @@ While this scanning happens before you can download packages, the advantages are
- **Enforce Security Policies across all your organization**: It blocks any package downloads until security checks has been completed. Only approved software components are used in your workloads, guaranteeing compliance with organizational standards and practices.
- **Reduced Risk**: checking packages before running them reduces your exposure to non-compliant software.

In short, Block Until Scan is a crucial tool for securing and reducing risk in your software supply chain.
In short, Block Until Scan is a crucial tool for securing and reducing risk in your software supply chain.
Loading