This article will describe how to download an image from a (docker) container registry.
| [!Manual Download of Container Images with wget and curl](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | Manual Download of Container Images with wget and curl |
Intro
Remember the good `'ol days when you could just download software by visiting a website and click "download"?
Even apt and yum repositories were just simple HTTP servers that you could just curl (or wget) from. Using the package manager was, of course, more secure and convenient -- but you could always just download packages manually, if you wanted.
But have you ever tried to curl an image from a container registry, such as docker? Well friends, I have tried. And I have the scars to prove it.
It was a remarkably complex process that took me weeks to figure-out. Lucky you, this article will break it down.
Examples
Specifically, we'll look at how to download files from two OCI registries.
Terms
First, here's some terminology used by OCI
- OCI - Open Container Initiative
- blob - A "blob" in the OCI spec just means a file
- manifest - A "manifest" in the OCI spec means a list of files
Prerequisites
This guide was written in 2024, and it uses the following software and versions:
- debian 12 (bookworm)
- curl 7.88.1
- OCI Distribution Spec v1.1.0 (which, unintuitively, uses the '/v2/' endpoint)
Of course, you'll need 'curl' installed. And, to parse json, 'jq' too.
sudo apt-get install curl jq
What is OCI?
OCI stands for Open Container Initiative.
OCI was originally formed in June 2015 for Docker and CoreOS. Today it's a wider, general-purpose (and annoyingly complex) way that many projects host files (that are extremely non-trivial to download).
One does not simply download a file from an OCI-complianet container registry. You must:
- Generate an authentication token for the API
- Make an API call to the registry, requesting to download a JSON "Manifest"
- Parse the JSON Manifest to figure out the hash of the file that you want
- Determine the download URL from the hash
- Download the file (which might actually be many distinct file "layers")
| [!One does not simply download from a container registry](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | One does not simply download from a container registry |
In order to figure out how to make an API call to the registry, you must first read (and understand) the OCI specs here.
- <https://opencontainers.org/release-notices/overview/>
OCI APIs
OCI maintains three distinct specifications:
- image spec
- runtime spec
- distribution spec
OCI "Distribution Spec" API
To figure out how to download a file from a container registry, we're interested in the "distribution spec". At the time of writing, the latest "distribution spec" can be downloaded here:
- <https://github.com/opencontainers/distribution-spec/releases/tag/v1.1.0>
- <https://github.com/opencontainers/distribution-spec/releases/download/v1.1.0/oci-distribution-spec-v1.1.0.pdf>
The above PDF file defines a set of API endpoints that we can use to query, parse, and then figure out how to download a file from a container registry. The table from the above PDF is copied below:
| ID | Method | API Endpoint | Success | Failure |
|------|----------|------------------------------------|--------|-----------|
| end-1 | GET | /v2/ | 200 | 404/401 |
| end-2 | GET / HEAD | /v2/<name>/blobs/<digest> | 200 | 404 |
| end-3 | GET / HEAD | /v2/<name>/manifests/<reference> | 200 | 404 |
| end-4a | POST | /v2/<name>/blobs/uploads/ | 202 | 404 |
| end-4b | POST | /v2/<name>/blobs/uploads/?digest=<digest> | 201/202 | 404/400 |
| end-5 | PATCH | /v2/<name>/blobs/uploads/<reference> | 202 | 404/416 |
| end-6 | PUT | /v2/<name>/blobs/uploads/<reference>?digest=<digest> | 201 | 404/400 |
| end-7 | PUT | /v2/<name>/manifests/<reference> | 201 | 404 |
| end-8a | GET | /v2/<name>/tags/list | 200 | 404 |
| end-8b | GET | /v2/<name>/tags/list?n=<integer>&last=<integer> | 200 | 404 |
| end-9 | DELETE | /v2/<name>/manifests/<reference> | 202 | 404/400/405 |
| end-10 | DELETE | /v2/<name>/blobs/<digest> | 202 | 404/405 |
| end-11 | POST | /v2/<name>/blobs/uploads/?mount=<digest>&from=<other_name> | 201 | 404 |
| end-12a | GET | /v2/<name>/referrers/<digest> | 200 | 404/400 |
| end-12b | GET | /v2/<name>/referrers/<digest>?artifactType=<artifactType> | 200 | 404/400 |
| end-13 | GET | /v2/<name>/blobs/uploads/<reference> | 204 | 404 |
In OCI, files are (cryptically) called "blobs". In order to figure out the file that we want to download, we must first reference the list of files (called a "manifest").
The above table shows us how we can download a list of files (manifest) and then download the actual file (blob).
Examples
Let's look at how to download files from a couple different OCI registries:
Docker Hub
To see the full example of downloading images from docker hub, click here
GitHub Packages
To see the full example of downloading files from GitHub Packages, click here.
Why?
I wrote this article because many, many folks have inquired about how to manually download files from OCI registries on the Internet, but their simple queries are usually returned with a barrage of useless counter-questions: why the heck would you want to do that!?!
The answer is varied.
Some people need to get files onto a restricted environment. Either their org doesn't grant them permission to install software on the machine, or the system has firewall-restricted internet access -- or doesn't have internet access at all.
3TOFU
Personally, the reason that I wanted to be able to download files from an OCI registry was for 3TOFU.
| [!Verifying Unsigned Releases with 3TOFU](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | Verifying Unsigned Releases with 3TOFU |
Unfortunaetly, most apps using OCI registries are extremely insecure. Docker, for example, will happily download malicious images. By default, it doesn't do any authenticity verifications on the payloads it downloaded. Even if you manually enable DCT, there's loads of pending issues with it.
Likewise, the macOS package manager brew has this same problem: it will happily download and install malicious code, because it doesn't use cryptography to verify the authenticity of anything that it downloads. This introduces watering hole vulnerabilities when developers use brew to install dependencies in their CI pipelines.
My solution to this? 3TOFU. And that requires me to be able to download the file (for verification) on three distinct linux VMs using curl or wget.
> ⚠ NOTE: 3TOFU is an approach to harm reduction. > > It is not wise to download and run binaries or code whose authenticity you cannot verify using a cryptographic signature from a key stored offline. However, sometimes we cannot avoid it. If you're going to proceed with running untrusted code, then following a 3TOFU procedure may reduce your risk, but it's better to avoid running unauthenticated code if at all possible.
Registry (ab)use
Container registries were created in 2013 to provide a clever & complex solution to a problem: how to package and serve multiple versions of simplified sources to various consumers spanning multiple operating systems and architectures -- while also packaging them into small, discrete "layers".
However, if your project is just serving simple files, then the only thing gained by uploading them to a complex system like a container registry is headaches. Why do developers do this?
In the case of brew, their free hosing provider (JFrog's Bintray) shutdown in 2021. Brew was already hosting their code on GitHub, so I guess someone looked at "GitHub Packages" and figured it was a good (read: free) replacement.
Many developers using Container Registries don't need the complexity, but -- well -- they're just using it as a free place for their FOSS project to store some files, man.
This article will describe how to download an image from a (docker) container registry.
| [!Manual Download of Container Images with wget and curl](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | Manual Download of Container Images with wget and curl |
Intro
Remember the good `'ol days when you could just download software by visiting a website and click "download"?
Even apt and yum repositories were just simple HTTP servers that you could just curl (or wget) from. Using the package manager was, of course, more secure and convenient -- but you could always just download packages manually, if you wanted.
But have you ever tried to curl an image from a container registry, such as docker? Well friends, I have tried. And I have the scars to prove it.
It was a remarkably complex process that took me weeks to figure-out. Lucky you, this article will break it down.
Examples
Specifically, we'll look at how to download files from two OCI registries.
Terms
First, here's some terminology used by OCI
- OCI - Open Container Initiative
- blob - A "blob" in the OCI spec just means a file
- manifest - A "manifest" in the OCI spec means a list of files
Prerequisites
This guide was written in 2024, and it uses the following software and versions:
- debian 12 (bookworm)
- curl 7.88.1
- OCI Distribution Spec v1.1.0 (which, unintuitively, uses the '/v2/' endpoint)
Of course, you'll need 'curl' installed. And, to parse json, 'jq' too.
sudo apt-get install curl jq
What is OCI?
OCI stands for Open Container Initiative.
OCI was originally formed in June 2015 for Docker and CoreOS. Today it's a wider, general-purpose (and annoyingly complex) way that many projects host files (that are extremely non-trivial to download).
One does not simply download a file from an OCI-complianet container registry. You must:
- Generate an authentication token for the API
- Make an API call to the registry, requesting to download a JSON "Manifest"
- Parse the JSON Manifest to figure out the hash of the file that you want
- Determine the download URL from the hash
- Download the file (which might actually be many distinct file "layers")
| [!One does not simply download from a container registry](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | One does not simply download from a container registry |
In order to figure out how to make an API call to the registry, you must first read (and understand) the OCI specs here.
- <https://opencontainers.org/release-notices/overview/>
OCI APIs
OCI maintains three distinct specifications:
- image spec
- runtime spec
- distribution spec
OCI "Distribution Spec" API
To figure out how to download a file from a container registry, we're interested in the "distribution spec". At the time of writing, the latest "distribution spec" can be downloaded here:
- <https://github.com/opencontainers/distribution-spec/releases/tag/v1.1.0>
- <https://github.com/opencontainers/distribution-spec/releases/download/v1.1.0/oci-distribution-spec-v1.1.0.pdf>
The above PDF file defines a set of API endpoints that we can use to query, parse, and then figure out how to download a file from a container registry. The table from the above PDF is copied below:
| ID | Method | API Endpoint | Success | Failure |
|------|----------|------------------------------------|--------|-----------|
| end-1 | GET | /v2/ | 200 | 404/401 |
| end-2 | GET / HEAD | /v2/<name>/blobs/<digest> | 200 | 404 |
| end-3 | GET / HEAD | /v2/<name>/manifests/<reference> | 200 | 404 |
| end-4a | POST | /v2/<name>/blobs/uploads/ | 202 | 404 |
| end-4b | POST | /v2/<name>/blobs/uploads/?digest=<digest> | 201/202 | 404/400 |
| end-5 | PATCH | /v2/<name>/blobs/uploads/<reference> | 202 | 404/416 |
| end-6 | PUT | /v2/<name>/blobs/uploads/<reference>?digest=<digest> | 201 | 404/400 |
| end-7 | PUT | /v2/<name>/manifests/<reference> | 201 | 404 |
| end-8a | GET | /v2/<name>/tags/list | 200 | 404 |
| end-8b | GET | /v2/<name>/tags/list?n=<integer>&last=<integer> | 200 | 404 |
| end-9 | DELETE | /v2/<name>/manifests/<reference> | 202 | 404/400/405 |
| end-10 | DELETE | /v2/<name>/blobs/<digest> | 202 | 404/405 |
| end-11 | POST | /v2/<name>/blobs/uploads/?mount=<digest>&from=<other_name> | 201 | 404 |
| end-12a | GET | /v2/<name>/referrers/<digest> | 200 | 404/400 |
| end-12b | GET | /v2/<name>/referrers/<digest>?artifactType=<artifactType> | 200 | 404/400 |
| end-13 | GET | /v2/<name>/blobs/uploads/<reference> | 204 | 404 |
In OCI, files are (cryptically) called "blobs". In order to figure out the file that we want to download, we must first reference the list of files (called a "manifest").
The above table shows us how we can download a list of files (manifest) and then download the actual file (blob).
Examples
Let's look at how to download files from a couple different OCI registries:
Docker Hub
To see the full example of downloading images from docker hub, click here
GitHub Packages
To see the full example of downloading files from GitHub Packages, click here.
Why?
I wrote this article because many, many folks have inquired about how to manually download files from OCI registries on the Internet, but their simple queries are usually returned with a barrage of useless counter-questions: why the heck would you want to do that!?!
The answer is varied.
Some people need to get files onto a restricted environment. Either their org doesn't grant them permission to install software on the machine, or the system has firewall-restricted internet access -- or doesn't have internet access at all.
3TOFU
Personally, the reason that I wanted to be able to download files from an OCI registry was for 3TOFU.
| [!Verifying Unsigned Releases with 3TOFU](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | Verifying Unsigned Releases with 3TOFU |
Unfortunaetly, most apps using OCI registries are extremely insecure. Docker, for example, will happily download malicious images. By default, it doesn't do any authenticity verifications on the payloads it downloaded. Even if you manually enable DCT, there's loads of pending issues with it.
Likewise, the macOS package manager brew has this same problem: it will happily download and install malicious code, because it doesn't use cryptography to verify the authenticity of anything that it downloads. This introduces watering hole vulnerabilities when developers use brew to install dependencies in their CI pipelines.
My solution to this? 3TOFU. And that requires me to be able to download the file (for verification) on three distinct linux VMs using curl or wget.
> ⚠ NOTE: 3TOFU is an approach to harm reduction. > > It is not wise to download and run binaries or code whose authenticity you cannot verify using a cryptographic signature from a key stored offline. However, sometimes we cannot avoid it. If you're going to proceed with running untrusted code, then following a 3TOFU procedure may reduce your risk, but it's better to avoid running unauthenticated code if at all possible.
Registry (ab)use
Container registries were created in 2013 to provide a clever & complex solution to a problem: how to package and serve multiple versions of simplified sources to various consumers spanning multiple operating systems and architectures -- while also packaging them into small, discrete "layers".
However, if your project is just serving simple files, then the only thing gained by uploading them to a complex system like a container registry is headaches. Why do developers do this?
In the case of brew, their free hosing provider (JFrog's Bintray) shutdown in 2021. Brew was already hosting their code on GitHub, so I guess someone looked at "GitHub Packages" and figured it was a good (read: free) replacement.
Many developers using Container Registries don't need the complexity, but -- well -- they're just using it as a free place for their FOSS project to store some files, man.
This article will describe how to download an image from a (docker) container registry.
| [!Manual Download of Container Images with wget and curl](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | Manual Download of Container Images with wget and curl |
Intro
Remember the good `'ol days when you could just download software by visiting a website and click "download"?
Even apt and yum repositories were just simple HTTP servers that you could just curl (or wget) from. Using the package manager was, of course, more secure and convenient -- but you could always just download packages manually, if you wanted.
But have you ever tried to curl an image from a container registry, such as docker? Well friends, I have tried. And I have the scars to prove it.
It was a remarkably complex process that took me weeks to figure-out. Lucky you, this article will break it down.
Examples
Specifically, we'll look at how to download files from two OCI registries.
Terms
First, here's some terminology used by OCI
- OCI - Open Container Initiative
- blob - A "blob" in the OCI spec just means a file
- manifest - A "manifest" in the OCI spec means a list of files
Prerequisites
This guide was written in 2024, and it uses the following software and versions:
- debian 12 (bookworm)
- curl 7.88.1
- OCI Distribution Spec v1.1.0 (which, unintuitively, uses the '/v2/' endpoint)
Of course, you'll need 'curl' installed. And, to parse json, 'jq' too.
sudo apt-get install curl jq
What is OCI?
OCI stands for Open Container Initiative.
OCI was originally formed in June 2015 for Docker and CoreOS. Today it's a wider, general-purpose (and annoyingly complex) way that many projects host files (that are extremely non-trivial to download).
One does not simply download a file from an OCI-complianet container registry. You must:
- Generate an authentication token for the API
- Make an API call to the registry, requesting to download a JSON "Manifest"
- Parse the JSON Manifest to figure out the hash of the file that you want
- Determine the download URL from the hash
- Download the file (which might actually be many distinct file "layers")
| [!One does not simply download from a container registry](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | One does not simply download from a container registry |
In order to figure out how to make an API call to the registry, you must first read (and understand) the OCI specs here.
- <https://opencontainers.org/release-notices/overview/>
OCI APIs
OCI maintains three distinct specifications:
- image spec
- runtime spec
- distribution spec
OCI "Distribution Spec" API
To figure out how to download a file from a container registry, we're interested in the "distribution spec". At the time of writing, the latest "distribution spec" can be downloaded here:
- <https://github.com/opencontainers/distribution-spec/releases/tag/v1.1.0>
- <https://github.com/opencontainers/distribution-spec/releases/download/v1.1.0/oci-distribution-spec-v1.1.0.pdf>
The above PDF file defines a set of API endpoints that we can use to query, parse, and then figure out how to download a file from a container registry. The table from the above PDF is copied below:
| ID | Method | API Endpoint | Success | Failure |
|------|----------|------------------------------------|--------|-----------|
| end-1 | GET | /v2/ | 200 | 404/401 |
| end-2 | GET / HEAD | /v2/<name>/blobs/<digest> | 200 | 404 |
| end-3 | GET / HEAD | /v2/<name>/manifests/<reference> | 200 | 404 |
| end-4a | POST | /v2/<name>/blobs/uploads/ | 202 | 404 |
| end-4b | POST | /v2/<name>/blobs/uploads/?digest=<digest> | 201/202 | 404/400 |
| end-5 | PATCH | /v2/<name>/blobs/uploads/<reference> | 202 | 404/416 |
| end-6 | PUT | /v2/<name>/blobs/uploads/<reference>?digest=<digest> | 201 | 404/400 |
| end-7 | PUT | /v2/<name>/manifests/<reference> | 201 | 404 |
| end-8a | GET | /v2/<name>/tags/list | 200 | 404 |
| end-8b | GET | /v2/<name>/tags/list?n=<integer>&last=<integer> | 200 | 404 |
| end-9 | DELETE | /v2/<name>/manifests/<reference> | 202 | 404/400/405 |
| end-10 | DELETE | /v2/<name>/blobs/<digest> | 202 | 404/405 |
| end-11 | POST | /v2/<name>/blobs/uploads/?mount=<digest>&from=<other_name> | 201 | 404 |
| end-12a | GET | /v2/<name>/referrers/<digest> | 200 | 404/400 |
| end-12b | GET | /v2/<name>/referrers/<digest>?artifactType=<artifactType> | 200 | 404/400 |
| end-13 | GET | /v2/<name>/blobs/uploads/<reference> | 204 | 404 |
In OCI, files are (cryptically) called "blobs". In order to figure out the file that we want to download, we must first reference the list of files (called a "manifest").
The above table shows us how we can download a list of files (manifest) and then download the actual file (blob).
Examples
Let's look at how to download files from a couple different OCI registries:
Docker Hub
To see the full example of downloading images from docker hub, click here
GitHub Packages
To see the full example of downloading files from GitHub Packages, click here.
Why?
I wrote this article because many, many folks have inquired about how to manually download files from OCI registries on the Internet, but their simple queries are usually returned with a barrage of useless counter-questions: why the heck would you want to do that!?!
The answer is varied.
Some people need to get files onto a restricted environment. Either their org doesn't grant them permission to install software on the machine, or the system has firewall-restricted internet access -- or doesn't have internet access at all.
3TOFU
Personally, the reason that I wanted to be able to download files from an OCI registry was for 3TOFU.
| [!Verifying Unsigned Releases with 3TOFU](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | Verifying Unsigned Releases with 3TOFU |
Unfortunaetly, most apps using OCI registries are extremely insecure. Docker, for example, will happily download malicious images. By default, it doesn't do any authenticity verifications on the payloads it downloaded. Even if you manually enable DCT, there's loads of pending issues with it.
Likewise, the macOS package manager brew has this same problem: it will happily download and install malicious code, because it doesn't use cryptography to verify the authenticity of anything that it downloads. This introduces watering hole vulnerabilities when developers use brew to install dependencies in their CI pipelines.
My solution to this? 3TOFU. And that requires me to be able to download the file (for verification) on three distinct linux VMs using curl or wget.
> ⚠ NOTE: 3TOFU is an approach to harm reduction. > > It is not wise to download and run binaries or code whose authenticity you cannot verify using a cryptographic signature from a key stored offline. However, sometimes we cannot avoid it. If you're going to proceed with running untrusted code, then following a 3TOFU procedure may reduce your risk, but it's better to avoid running unauthenticated code if at all possible.
Registry (ab)use
Container registries were created in 2013 to provide a clever & complex solution to a problem: how to package and serve multiple versions of simplified sources to various consumers spanning multiple operating systems and architectures -- while also packaging them into small, discrete "layers".
However, if your project is just serving simple files, then the only thing gained by uploading them to a complex system like a container registry is headaches. Why do developers do this?
In the case of brew, their free hosing provider (JFrog's Bintray) shutdown in 2021. Brew was already hosting their code on GitHub, so I guess someone looked at "GitHub Packages" and figured it was a good (read: free) replacement.
Many developers using Container Registries don't need the complexity, but -- well -- they're just using it as a free place for their FOSS project to store some files, man.
This article will describe how to download an image from a (docker) container registry.
| [!Manual Download of Container Images with wget and curl](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | Manual Download of Container Images with wget and curl |
Intro
Remember the good `'ol days when you could just download software by visiting a website and click "download"?
Even apt and yum repositories were just simple HTTP servers that you could just curl (or wget) from. Using the package manager was, of course, more secure and convenient -- but you could always just download packages manually, if you wanted.
But have you ever tried to curl an image from a container registry, such as docker? Well friends, I have tried. And I have the scars to prove it.
It was a remarkably complex process that took me weeks to figure-out. Lucky you, this article will break it down.
Examples
Specifically, we'll look at how to download files from two OCI registries.
Terms
First, here's some terminology used by OCI
- OCI - Open Container Initiative
- blob - A "blob" in the OCI spec just means a file
- manifest - A "manifest" in the OCI spec means a list of files
Prerequisites
This guide was written in 2024, and it uses the following software and versions:
- debian 12 (bookworm)
- curl 7.88.1
- OCI Distribution Spec v1.1.0 (which, unintuitively, uses the '/v2/' endpoint)
Of course, you'll need 'curl' installed. And, to parse json, 'jq' too.
sudo apt-get install curl jq
What is OCI?
OCI stands for Open Container Initiative.
OCI was originally formed in June 2015 for Docker and CoreOS. Today it's a wider, general-purpose (and annoyingly complex) way that many projects host files (that are extremely non-trivial to download).
One does not simply download a file from an OCI-complianet container registry. You must:
- Generate an authentication token for the API
- Make an API call to the registry, requesting to download a JSON "Manifest"
- Parse the JSON Manifest to figure out the hash of the file that you want
- Determine the download URL from the hash
- Download the file (which might actually be many distinct file "layers")
| [!One does not simply download from a container registry](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | One does not simply download from a container registry |
In order to figure out how to make an API call to the registry, you must first read (and understand) the OCI specs here.
- <https://opencontainers.org/release-notices/overview/>
OCI APIs
OCI maintains three distinct specifications:
- image spec
- runtime spec
- distribution spec
OCI "Distribution Spec" API
To figure out how to download a file from a container registry, we're interested in the "distribution spec". At the time of writing, the latest "distribution spec" can be downloaded here:
- <https://github.com/opencontainers/distribution-spec/releases/tag/v1.1.0>
- <https://github.com/opencontainers/distribution-spec/releases/download/v1.1.0/oci-distribution-spec-v1.1.0.pdf>
The above PDF file defines a set of API endpoints that we can use to query, parse, and then figure out how to download a file from a container registry. The table from the above PDF is copied below:
| ID | Method | API Endpoint | Success | Failure |
|------|----------|------------------------------------|--------|-----------|
| end-1 | GET | /v2/ | 200 | 404/401 |
| end-2 | GET / HEAD | /v2/<name>/blobs/<digest> | 200 | 404 |
| end-3 | GET / HEAD | /v2/<name>/manifests/<reference> | 200 | 404 |
| end-4a | POST | /v2/<name>/blobs/uploads/ | 202 | 404 |
| end-4b | POST | /v2/<name>/blobs/uploads/?digest=<digest> | 201/202 | 404/400 |
| end-5 | PATCH | /v2/<name>/blobs/uploads/<reference> | 202 | 404/416 |
| end-6 | PUT | /v2/<name>/blobs/uploads/<reference>?digest=<digest> | 201 | 404/400 |
| end-7 | PUT | /v2/<name>/manifests/<reference> | 201 | 404 |
| end-8a | GET | /v2/<name>/tags/list | 200 | 404 |
| end-8b | GET | /v2/<name>/tags/list?n=<integer>&last=<integer> | 200 | 404 |
| end-9 | DELETE | /v2/<name>/manifests/<reference> | 202 | 404/400/405 |
| end-10 | DELETE | /v2/<name>/blobs/<digest> | 202 | 404/405 |
| end-11 | POST | /v2/<name>/blobs/uploads/?mount=<digest>&from=<other_name> | 201 | 404 |
| end-12a | GET | /v2/<name>/referrers/<digest> | 200 | 404/400 |
| end-12b | GET | /v2/<name>/referrers/<digest>?artifactType=<artifactType> | 200 | 404/400 |
| end-13 | GET | /v2/<name>/blobs/uploads/<reference> | 204 | 404 |
In OCI, files are (cryptically) called "blobs". In order to figure out the file that we want to download, we must first reference the list of files (called a "manifest").
The above table shows us how we can download a list of files (manifest) and then download the actual file (blob).
Examples
Let's look at how to download files from a couple different OCI registries:
Docker Hub
To see the full example of downloading images from docker hub, click here
GitHub Packages
To see the full example of downloading files from GitHub Packages, click here.
Why?
I wrote this article because many, many folks have inquired about how to manually download files from OCI registries on the Internet, but their simple queries are usually returned with a barrage of useless counter-questions: why the heck would you want to do that!?!
The answer is varied.
Some people need to get files onto a restricted environment. Either their org doesn't grant them permission to install software on the machine, or the system has firewall-restricted internet access -- or doesn't have internet access at all.
3TOFU
Personally, the reason that I wanted to be able to download files from an OCI registry was for 3TOFU.
| [!Verifying Unsigned Releases with 3TOFU](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | Verifying Unsigned Releases with 3TOFU |
Unfortunaetly, most apps using OCI registries are extremely insecure. Docker, for example, will happily download malicious images. By default, it doesn't do any authenticity verifications on the payloads it downloaded. Even if you manually enable DCT, there's loads of pending issues with it.
Likewise, the macOS package manager brew has this same problem: it will happily download and install malicious code, because it doesn't use cryptography to verify the authenticity of anything that it downloads. This introduces watering hole vulnerabilities when developers use brew to install dependencies in their CI pipelines.
My solution to this? 3TOFU. And that requires me to be able to download the file (for verification) on three distinct linux VMs using curl or wget.
> ⚠ NOTE: 3TOFU is an approach to harm reduction. > > It is not wise to download and run binaries or code whose authenticity you cannot verify using a cryptographic signature from a key stored offline. However, sometimes we cannot avoid it. If you're going to proceed with running untrusted code, then following a 3TOFU procedure may reduce your risk, but it's better to avoid running unauthenticated code if at all possible.
Registry (ab)use
Container registries were created in 2013 to provide a clever & complex solution to a problem: how to package and serve multiple versions of simplified sources to various consumers spanning multiple operating systems and architectures -- while also packaging them into small, discrete "layers".
However, if your project is just serving simple files, then the only thing gained by uploading them to a complex system like a container registry is headaches. Why do developers do this?
In the case of brew, their free hosing provider (JFrog's Bintray) shutdown in 2021. Brew was already hosting their code on GitHub, so I guess someone looked at "GitHub Packages" and figured it was a good (read: free) replacement.
Many developers using Container Registries don't need the complexity, but -- well -- they're just using it as a free place for their FOSS project to store some files, man.
This article will describe how to download an image from a (docker) container registry.
| [!Manual Download of Container Images with wget and curl](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | Manual Download of Container Images with wget and curl |
Intro
Remember the good `'ol days when you could just download software by visiting a website and click "download"?
Even apt and yum repositories were just simple HTTP servers that you could just curl (or wget) from. Using the package manager was, of course, more secure and convenient -- but you could always just download packages manually, if you wanted.
But have you ever tried to curl an image from a container registry, such as docker? Well friends, I have tried. And I have the scars to prove it.
It was a remarkably complex process that took me weeks to figure-out. Lucky you, this article will break it down.
Examples
Specifically, we'll look at how to download files from two OCI registries.
Terms
First, here's some terminology used by OCI
- OCI - Open Container Initiative
- blob - A "blob" in the OCI spec just means a file
- manifest - A "manifest" in the OCI spec means a list of files
Prerequisites
This guide was written in 2024, and it uses the following software and versions:
- debian 12 (bookworm)
- curl 7.88.1
- OCI Distribution Spec v1.1.0 (which, unintuitively, uses the '/v2/' endpoint)
Of course, you'll need 'curl' installed. And, to parse json, 'jq' too.
sudo apt-get install curl jq
What is OCI?
OCI stands for Open Container Initiative.
OCI was originally formed in June 2015 for Docker and CoreOS. Today it's a wider, general-purpose (and annoyingly complex) way that many projects host files (that are extremely non-trivial to download).
One does not simply download a file from an OCI-complianet container registry. You must:
- Generate an authentication token for the API
- Make an API call to the registry, requesting to download a JSON "Manifest"
- Parse the JSON Manifest to figure out the hash of the file that you want
- Determine the download URL from the hash
- Download the file (which might actually be many distinct file "layers")
| [!One does not simply download from a container registry](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | One does not simply download from a container registry |
In order to figure out how to make an API call to the registry, you must first read (and understand) the OCI specs here.
- <https://opencontainers.org/release-notices/overview/>
OCI APIs
OCI maintains three distinct specifications:
- image spec
- runtime spec
- distribution spec
OCI "Distribution Spec" API
To figure out how to download a file from a container registry, we're interested in the "distribution spec". At the time of writing, the latest "distribution spec" can be downloaded here:
- <https://github.com/opencontainers/distribution-spec/releases/tag/v1.1.0>
- <https://github.com/opencontainers/distribution-spec/releases/download/v1.1.0/oci-distribution-spec-v1.1.0.pdf>
The above PDF file defines a set of API endpoints that we can use to query, parse, and then figure out how to download a file from a container registry. The table from the above PDF is copied below:
| ID | Method | API Endpoint | Success | Failure |
|------|----------|------------------------------------|--------|-----------|
| end-1 | GET | /v2/ | 200 | 404/401 |
| end-2 | GET / HEAD | /v2/<name>/blobs/<digest> | 200 | 404 |
| end-3 | GET / HEAD | /v2/<name>/manifests/<reference> | 200 | 404 |
| end-4a | POST | /v2/<name>/blobs/uploads/ | 202 | 404 |
| end-4b | POST | /v2/<name>/blobs/uploads/?digest=<digest> | 201/202 | 404/400 |
| end-5 | PATCH | /v2/<name>/blobs/uploads/<reference> | 202 | 404/416 |
| end-6 | PUT | /v2/<name>/blobs/uploads/<reference>?digest=<digest> | 201 | 404/400 |
| end-7 | PUT | /v2/<name>/manifests/<reference> | 201 | 404 |
| end-8a | GET | /v2/<name>/tags/list | 200 | 404 |
| end-8b | GET | /v2/<name>/tags/list?n=<integer>&last=<integer> | 200 | 404 |
| end-9 | DELETE | /v2/<name>/manifests/<reference> | 202 | 404/400/405 |
| end-10 | DELETE | /v2/<name>/blobs/<digest> | 202 | 404/405 |
| end-11 | POST | /v2/<name>/blobs/uploads/?mount=<digest>&from=<other_name> | 201 | 404 |
| end-12a | GET | /v2/<name>/referrers/<digest> | 200 | 404/400 |
| end-12b | GET | /v2/<name>/referrers/<digest>?artifactType=<artifactType> | 200 | 404/400 |
| end-13 | GET | /v2/<name>/blobs/uploads/<reference> | 204 | 404 |
In OCI, files are (cryptically) called "blobs". In order to figure out the file that we want to download, we must first reference the list of files (called a "manifest").
The above table shows us how we can download a list of files (manifest) and then download the actual file (blob).
Examples
Let's look at how to download files from a couple different OCI registries:
Docker Hub
To see the full example of downloading images from docker hub, click here
GitHub Packages
To see the full example of downloading files from GitHub Packages, click here.
Why?
I wrote this article because many, many folks have inquired about how to manually download files from OCI registries on the Internet, but their simple queries are usually returned with a barrage of useless counter-questions: why the heck would you want to do that!?!
The answer is varied.
Some people need to get files onto a restricted environment. Either their org doesn't grant them permission to install software on the machine, or the system has firewall-restricted internet access -- or doesn't have internet access at all.
3TOFU
Personally, the reason that I wanted to be able to download files from an OCI registry was for 3TOFU.
| [!Verifying Unsigned Releases with 3TOFU](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | Verifying Unsigned Releases with 3TOFU |
Unfortunaetly, most apps using OCI registries are extremely insecure. Docker, for example, will happily download malicious images. By default, it doesn't do any authenticity verifications on the payloads it downloaded. Even if you manually enable DCT, there's loads of pending issues with it.
Likewise, the macOS package manager brew has this same problem: it will happily download and install malicious code, because it doesn't use cryptography to verify the authenticity of anything that it downloads. This introduces watering hole vulnerabilities when developers use brew to install dependencies in their CI pipelines.
My solution to this? 3TOFU. And that requires me to be able to download the file (for verification) on three distinct linux VMs using curl or wget.
> ⚠ NOTE: 3TOFU is an approach to harm reduction. > > It is not wise to download and run binaries or code whose authenticity you cannot verify using a cryptographic signature from a key stored offline. However, sometimes we cannot avoid it. If you're going to proceed with running untrusted code, then following a 3TOFU procedure may reduce your risk, but it's better to avoid running unauthenticated code if at all possible.
Registry (ab)use
Container registries were created in 2013 to provide a clever & complex solution to a problem: how to package and serve multiple versions of simplified sources to various consumers spanning multiple operating systems and architectures -- while also packaging them into small, discrete "layers".
However, if your project is just serving simple files, then the only thing gained by uploading them to a complex system like a container registry is headaches. Why do developers do this?
In the case of brew, their free hosing provider (JFrog's Bintray) shutdown in 2021. Brew was already hosting their code on GitHub, so I guess someone looked at "GitHub Packages" and figured it was a good (read: free) replacement.
Many developers using Container Registries don't need the complexity, but -- well -- they're just using it as a free place for their FOSS project to store some files, man.
This article will describe how to download an image from a (docker) container registry.
| [!Manual Download of Container Images with wget and curl](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | Manual Download of Container Images with wget and curl |
Intro
Remember the good `'ol days when you could just download software by visiting a website and click "download"?
Even apt and yum repositories were just simple HTTP servers that you could just curl (or wget) from. Using the package manager was, of course, more secure and convenient -- but you could always just download packages manually, if you wanted.
But have you ever tried to curl an image from a container registry, such as docker? Well friends, I have tried. And I have the scars to prove it.
It was a remarkably complex process that took me weeks to figure-out. Lucky you, this article will break it down.
Examples
Specifically, we'll look at how to download files from two OCI registries.
Terms
First, here's some terminology used by OCI
- OCI - Open Container Initiative
- blob - A "blob" in the OCI spec just means a file
- manifest - A "manifest" in the OCI spec means a list of files
Prerequisites
This guide was written in 2024, and it uses the following software and versions:
- debian 12 (bookworm)
- curl 7.88.1
- OCI Distribution Spec v1.1.0 (which, unintuitively, uses the '/v2/' endpoint)
Of course, you'll need 'curl' installed. And, to parse json, 'jq' too.
sudo apt-get install curl jq
What is OCI?
OCI stands for Open Container Initiative.
OCI was originally formed in June 2015 for Docker and CoreOS. Today it's a wider, general-purpose (and annoyingly complex) way that many projects host files (that are extremely non-trivial to download).
One does not simply download a file from an OCI-complianet container registry. You must:
- Generate an authentication token for the API
- Make an API call to the registry, requesting to download a JSON "Manifest"
- Parse the JSON Manifest to figure out the hash of the file that you want
- Determine the download URL from the hash
- Download the file (which might actually be many distinct file "layers")
| [!One does not simply download from a container registry](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | One does not simply download from a container registry |
In order to figure out how to make an API call to the registry, you must first read (and understand) the OCI specs here.
- <https://opencontainers.org/release-notices/overview/>
OCI APIs
OCI maintains three distinct specifications:
- image spec
- runtime spec
- distribution spec
OCI "Distribution Spec" API
To figure out how to download a file from a container registry, we're interested in the "distribution spec". At the time of writing, the latest "distribution spec" can be downloaded here:
- <https://github.com/opencontainers/distribution-spec/releases/tag/v1.1.0>
- <https://github.com/opencontainers/distribution-spec/releases/download/v1.1.0/oci-distribution-spec-v1.1.0.pdf>
The above PDF file defines a set of API endpoints that we can use to query, parse, and then figure out how to download a file from a container registry. The table from the above PDF is copied below:
| ID | Method | API Endpoint | Success | Failure |
|------|----------|------------------------------------|--------|-----------|
| end-1 | GET | /v2/ | 200 | 404/401 |
| end-2 | GET / HEAD | /v2/<name>/blobs/<digest> | 200 | 404 |
| end-3 | GET / HEAD | /v2/<name>/manifests/<reference> | 200 | 404 |
| end-4a | POST | /v2/<name>/blobs/uploads/ | 202 | 404 |
| end-4b | POST | /v2/<name>/blobs/uploads/?digest=<digest> | 201/202 | 404/400 |
| end-5 | PATCH | /v2/<name>/blobs/uploads/<reference> | 202 | 404/416 |
| end-6 | PUT | /v2/<name>/blobs/uploads/<reference>?digest=<digest> | 201 | 404/400 |
| end-7 | PUT | /v2/<name>/manifests/<reference> | 201 | 404 |
| end-8a | GET | /v2/<name>/tags/list | 200 | 404 |
| end-8b | GET | /v2/<name>/tags/list?n=<integer>&last=<integer> | 200 | 404 |
| end-9 | DELETE | /v2/<name>/manifests/<reference> | 202 | 404/400/405 |
| end-10 | DELETE | /v2/<name>/blobs/<digest> | 202 | 404/405 |
| end-11 | POST | /v2/<name>/blobs/uploads/?mount=<digest>&from=<other_name> | 201 | 404 |
| end-12a | GET | /v2/<name>/referrers/<digest> | 200 | 404/400 |
| end-12b | GET | /v2/<name>/referrers/<digest>?artifactType=<artifactType> | 200 | 404/400 |
| end-13 | GET | /v2/<name>/blobs/uploads/<reference> | 204 | 404 |
In OCI, files are (cryptically) called "blobs". In order to figure out the file that we want to download, we must first reference the list of files (called a "manifest").
The above table shows us how we can download a list of files (manifest) and then download the actual file (blob).
Examples
Let's look at how to download files from a couple different OCI registries:
Docker Hub
To see the full example of downloading images from docker hub, click here
GitHub Packages
To see the full example of downloading files from GitHub Packages, click here.
Why?
I wrote this article because many, many folks have inquired about how to manually download files from OCI registries on the Internet, but their simple queries are usually returned with a barrage of useless counter-questions: why the heck would you want to do that!?!
The answer is varied.
Some people need to get files onto a restricted environment. Either their org doesn't grant them permission to install software on the machine, or the system has firewall-restricted internet access -- or doesn't have internet access at all.
3TOFU
Personally, the reason that I wanted to be able to download files from an OCI registry was for 3TOFU.
| [!Verifying Unsigned Releases with 3TOFU](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | Verifying Unsigned Releases with 3TOFU |
Unfortunaetly, most apps using OCI registries are extremely insecure. Docker, for example, will happily download malicious images. By default, it doesn't do any authenticity verifications on the payloads it downloaded. Even if you manually enable DCT, there's loads of pending issues with it.
Likewise, the macOS package manager brew has this same problem: it will happily download and install malicious code, because it doesn't use cryptography to verify the authenticity of anything that it downloads. This introduces watering hole vulnerabilities when developers use brew to install dependencies in their CI pipelines.
My solution to this? 3TOFU. And that requires me to be able to download the file (for verification) on three distinct linux VMs using curl or wget.
> ⚠ NOTE: 3TOFU is an approach to harm reduction. > > It is not wise to download and run binaries or code whose authenticity you cannot verify using a cryptographic signature from a key stored offline. However, sometimes we cannot avoid it. If you're going to proceed with running untrusted code, then following a 3TOFU procedure may reduce your risk, but it's better to avoid running unauthenticated code if at all possible.
Registry (ab)use
Container registries were created in 2013 to provide a clever & complex solution to a problem: how to package and serve multiple versions of simplified sources to various consumers spanning multiple operating systems and architectures -- while also packaging them into small, discrete "layers".
However, if your project is just serving simple files, then the only thing gained by uploading them to a complex system like a container registry is headaches. Why do developers do this?
In the case of brew, their free hosing provider (JFrog's Bintray) shutdown in 2021. Brew was already hosting their code on GitHub, so I guess someone looked at "GitHub Packages" and figured it was a good (read: free) replacement.
Many developers using Container Registries don't need the complexity, but -- well -- they're just using it as a free place for their FOSS project to store some files, man.
This article will describe how to download an image from a (docker) container registry.
| [!Manual Download of Container Images with wget and curl](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | Manual Download of Container Images with wget and curl |
Intro
Remember the good `'ol days when you could just download software by visiting a website and click "download"?
Even apt and yum repositories were just simple HTTP servers that you could just curl (or wget) from. Using the package manager was, of course, more secure and convenient -- but you could always just download packages manually, if you wanted.
But have you ever tried to curl an image from a container registry, such as docker? Well friends, I have tried. And I have the scars to prove it.
It was a remarkably complex process that took me weeks to figure-out. Lucky you, this article will break it down.
Examples
Specifically, we'll look at how to download files from two OCI registries.
Terms
First, here's some terminology used by OCI
- OCI - Open Container Initiative
- blob - A "blob" in the OCI spec just means a file
- manifest - A "manifest" in the OCI spec means a list of files
Prerequisites
This guide was written in 2024, and it uses the following software and versions:
- debian 12 (bookworm)
- curl 7.88.1
- OCI Distribution Spec v1.1.0 (which, unintuitively, uses the '/v2/' endpoint)
Of course, you'll need 'curl' installed. And, to parse json, 'jq' too.
sudo apt-get install curl jq
What is OCI?
OCI stands for Open Container Initiative.
OCI was originally formed in June 2015 for Docker and CoreOS. Today it's a wider, general-purpose (and annoyingly complex) way that many projects host files (that are extremely non-trivial to download).
One does not simply download a file from an OCI-complianet container registry. You must:
- Generate an authentication token for the API
- Make an API call to the registry, requesting to download a JSON "Manifest"
- Parse the JSON Manifest to figure out the hash of the file that you want
- Determine the download URL from the hash
- Download the file (which might actually be many distinct file "layers")
| [!One does not simply download from a container registry](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | One does not simply download from a container registry |
In order to figure out how to make an API call to the registry, you must first read (and understand) the OCI specs here.
- <https://opencontainers.org/release-notices/overview/>
OCI APIs
OCI maintains three distinct specifications:
- image spec
- runtime spec
- distribution spec
OCI "Distribution Spec" API
To figure out how to download a file from a container registry, we're interested in the "distribution spec". At the time of writing, the latest "distribution spec" can be downloaded here:
- <https://github.com/opencontainers/distribution-spec/releases/tag/v1.1.0>
- <https://github.com/opencontainers/distribution-spec/releases/download/v1.1.0/oci-distribution-spec-v1.1.0.pdf>
The above PDF file defines a set of API endpoints that we can use to query, parse, and then figure out how to download a file from a container registry. The table from the above PDF is copied below:
| ID | Method | API Endpoint | Success | Failure |
|------|----------|------------------------------------|--------|-----------|
| end-1 | GET | /v2/ | 200 | 404/401 |
| end-2 | GET / HEAD | /v2/<name>/blobs/<digest> | 200 | 404 |
| end-3 | GET / HEAD | /v2/<name>/manifests/<reference> | 200 | 404 |
| end-4a | POST | /v2/<name>/blobs/uploads/ | 202 | 404 |
| end-4b | POST | /v2/<name>/blobs/uploads/?digest=<digest> | 201/202 | 404/400 |
| end-5 | PATCH | /v2/<name>/blobs/uploads/<reference> | 202 | 404/416 |
| end-6 | PUT | /v2/<name>/blobs/uploads/<reference>?digest=<digest> | 201 | 404/400 |
| end-7 | PUT | /v2/<name>/manifests/<reference> | 201 | 404 |
| end-8a | GET | /v2/<name>/tags/list | 200 | 404 |
| end-8b | GET | /v2/<name>/tags/list?n=<integer>&last=<integer> | 200 | 404 |
| end-9 | DELETE | /v2/<name>/manifests/<reference> | 202 | 404/400/405 |
| end-10 | DELETE | /v2/<name>/blobs/<digest> | 202 | 404/405 |
| end-11 | POST | /v2/<name>/blobs/uploads/?mount=<digest>&from=<other_name> | 201 | 404 |
| end-12a | GET | /v2/<name>/referrers/<digest> | 200 | 404/400 |
| end-12b | GET | /v2/<name>/referrers/<digest>?artifactType=<artifactType> | 200 | 404/400 |
| end-13 | GET | /v2/<name>/blobs/uploads/<reference> | 204 | 404 |
In OCI, files are (cryptically) called "blobs". In order to figure out the file that we want to download, we must first reference the list of files (called a "manifest").
The above table shows us how we can download a list of files (manifest) and then download the actual file (blob).
Examples
Let's look at how to download files from a couple different OCI registries:
Docker Hub
To see the full example of downloading images from docker hub, click here
GitHub Packages
To see the full example of downloading files from GitHub Packages, click here.
Why?
I wrote this article because many, many folks have inquired about how to manually download files from OCI registries on the Internet, but their simple queries are usually returned with a barrage of useless counter-questions: why the heck would you want to do that!?!
The answer is varied.
Some people need to get files onto a restricted environment. Either their org doesn't grant them permission to install software on the machine, or the system has firewall-restricted internet access -- or doesn't have internet access at all.
3TOFU
Personally, the reason that I wanted to be able to download files from an OCI registry was for 3TOFU.
| [!Verifying Unsigned Releases with 3TOFU](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | Verifying Unsigned Releases with 3TOFU |
Unfortunaetly, most apps using OCI registries are extremely insecure. Docker, for example, will happily download malicious images. By default, it doesn't do any authenticity verifications on the payloads it downloaded. Even if you manually enable DCT, there's loads of pending issues with it.
Likewise, the macOS package manager brew has this same problem: it will happily download and install malicious code, because it doesn't use cryptography to verify the authenticity of anything that it downloads. This introduces watering hole vulnerabilities when developers use brew to install dependencies in their CI pipelines.
My solution to this? 3TOFU. And that requires me to be able to download the file (for verification) on three distinct linux VMs using curl or wget.
> ⚠ NOTE: 3TOFU is an approach to harm reduction. > > It is not wise to download and run binaries or code whose authenticity you cannot verify using a cryptographic signature from a key stored offline. However, sometimes we cannot avoid it. If you're going to proceed with running untrusted code, then following a 3TOFU procedure may reduce your risk, but it's better to avoid running unauthenticated code if at all possible.
Registry (ab)use
Container registries were created in 2013 to provide a clever & complex solution to a problem: how to package and serve multiple versions of simplified sources to various consumers spanning multiple operating systems and architectures -- while also packaging them into small, discrete "layers".
However, if your project is just serving simple files, then the only thing gained by uploading them to a complex system like a container registry is headaches. Why do developers do this?
In the case of brew, their free hosing provider (JFrog's Bintray) shutdown in 2021. Brew was already hosting their code on GitHub, so I guess someone looked at "GitHub Packages" and figured it was a good (read: free) replacement.
Many developers using Container Registries don't need the complexity, but -- well -- they're just using it as a free place for their FOSS project to store some files, man.
This article will describe how to download an image from a (docker) container registry.
| [!Manual Download of Container Images with wget and curl](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | Manual Download of Container Images with wget and curl |
Intro
Remember the good `'ol days when you could just download software by visiting a website and click "download"?
Even apt and yum repositories were just simple HTTP servers that you could just curl (or wget) from. Using the package manager was, of course, more secure and convenient -- but you could always just download packages manually, if you wanted.
But have you ever tried to curl an image from a container registry, such as docker? Well friends, I have tried. And I have the scars to prove it.
It was a remarkably complex process that took me weeks to figure-out. Lucky you, this article will break it down.
Examples
Specifically, we'll look at how to download files from two OCI registries.
Terms
First, here's some terminology used by OCI
- OCI - Open Container Initiative
- blob - A "blob" in the OCI spec just means a file
- manifest - A "manifest" in the OCI spec means a list of files
Prerequisites
This guide was written in 2024, and it uses the following software and versions:
- debian 12 (bookworm)
- curl 7.88.1
- OCI Distribution Spec v1.1.0 (which, unintuitively, uses the '/v2/' endpoint)
Of course, you'll need 'curl' installed. And, to parse json, 'jq' too.
sudo apt-get install curl jq
What is OCI?
OCI stands for Open Container Initiative.
OCI was originally formed in June 2015 for Docker and CoreOS. Today it's a wider, general-purpose (and annoyingly complex) way that many projects host files (that are extremely non-trivial to download).
One does not simply download a file from an OCI-complianet container registry. You must:
- Generate an authentication token for the API
- Make an API call to the registry, requesting to download a JSON "Manifest"
- Parse the JSON Manifest to figure out the hash of the file that you want
- Determine the download URL from the hash
- Download the file (which might actually be many distinct file "layers")
| [!One does not simply download from a container registry](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | One does not simply download from a container registry |
In order to figure out how to make an API call to the registry, you must first read (and understand) the OCI specs here.
- <https://opencontainers.org/release-notices/overview/>
OCI APIs
OCI maintains three distinct specifications:
- image spec
- runtime spec
- distribution spec
OCI "Distribution Spec" API
To figure out how to download a file from a container registry, we're interested in the "distribution spec". At the time of writing, the latest "distribution spec" can be downloaded here:
- <https://github.com/opencontainers/distribution-spec/releases/tag/v1.1.0>
- <https://github.com/opencontainers/distribution-spec/releases/download/v1.1.0/oci-distribution-spec-v1.1.0.pdf>
The above PDF file defines a set of API endpoints that we can use to query, parse, and then figure out how to download a file from a container registry. The table from the above PDF is copied below:
| ID | Method | API Endpoint | Success | Failure |
|------|----------|------------------------------------|--------|-----------|
| end-1 | GET | /v2/ | 200 | 404/401 |
| end-2 | GET / HEAD | /v2/<name>/blobs/<digest> | 200 | 404 |
| end-3 | GET / HEAD | /v2/<name>/manifests/<reference> | 200 | 404 |
| end-4a | POST | /v2/<name>/blobs/uploads/ | 202 | 404 |
| end-4b | POST | /v2/<name>/blobs/uploads/?digest=<digest> | 201/202 | 404/400 |
| end-5 | PATCH | /v2/<name>/blobs/uploads/<reference> | 202 | 404/416 |
| end-6 | PUT | /v2/<name>/blobs/uploads/<reference>?digest=<digest> | 201 | 404/400 |
| end-7 | PUT | /v2/<name>/manifests/<reference> | 201 | 404 |
| end-8a | GET | /v2/<name>/tags/list | 200 | 404 |
| end-8b | GET | /v2/<name>/tags/list?n=<integer>&last=<integer> | 200 | 404 |
| end-9 | DELETE | /v2/<name>/manifests/<reference> | 202 | 404/400/405 |
| end-10 | DELETE | /v2/<name>/blobs/<digest> | 202 | 404/405 |
| end-11 | POST | /v2/<name>/blobs/uploads/?mount=<digest>&from=<other_name> | 201 | 404 |
| end-12a | GET | /v2/<name>/referrers/<digest> | 200 | 404/400 |
| end-12b | GET | /v2/<name>/referrers/<digest>?artifactType=<artifactType> | 200 | 404/400 |
| end-13 | GET | /v2/<name>/blobs/uploads/<reference> | 204 | 404 |
In OCI, files are (cryptically) called "blobs". In order to figure out the file that we want to download, we must first reference the list of files (called a "manifest").
The above table shows us how we can download a list of files (manifest) and then download the actual file (blob).
Examples
Let's look at how to download files from a couple different OCI registries:
Docker Hub
To see the full example of downloading images from docker hub, click here
GitHub Packages
To see the full example of downloading files from GitHub Packages, click here.
Why?
I wrote this article because many, many folks have inquired about how to manually download files from OCI registries on the Internet, but their simple queries are usually returned with a barrage of useless counter-questions: why the heck would you want to do that!?!
The answer is varied.
Some people need to get files onto a restricted environment. Either their org doesn't grant them permission to install software on the machine, or the system has firewall-restricted internet access -- or doesn't have internet access at all.
3TOFU
Personally, the reason that I wanted to be able to download files from an OCI registry was for 3TOFU.
| [!Verifying Unsigned Releases with 3TOFU](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | Verifying Unsigned Releases with 3TOFU |
Unfortunaetly, most apps using OCI registries are extremely insecure. Docker, for example, will happily download malicious images. By default, it doesn't do any authenticity verifications on the payloads it downloaded. Even if you manually enable DCT, there's loads of pending issues with it.
Likewise, the macOS package manager brew has this same problem: it will happily download and install malicious code, because it doesn't use cryptography to verify the authenticity of anything that it downloads. This introduces watering hole vulnerabilities when developers use brew to install dependencies in their CI pipelines.
My solution to this? 3TOFU. And that requires me to be able to download the file (for verification) on three distinct linux VMs using curl or wget.
> ⚠ NOTE: 3TOFU is an approach to harm reduction. > > It is not wise to download and run binaries or code whose authenticity you cannot verify using a cryptographic signature from a key stored offline. However, sometimes we cannot avoid it. If you're going to proceed with running untrusted code, then following a 3TOFU procedure may reduce your risk, but it's better to avoid running unauthenticated code if at all possible.
Registry (ab)use
Container registries were created in 2013 to provide a clever & complex solution to a problem: how to package and serve multiple versions of simplified sources to various consumers spanning multiple operating systems and architectures -- while also packaging them into small, discrete "layers".
However, if your project is just serving simple files, then the only thing gained by uploading them to a complex system like a container registry is headaches. Why do developers do this?
In the case of brew, their free hosing provider (JFrog's Bintray) shutdown in 2021. Brew was already hosting their code on GitHub, so I guess someone looked at "GitHub Packages" and figured it was a good (read: free) replacement.
Many developers using Container Registries don't need the complexity, but -- well -- they're just using it as a free place for their FOSS project to store some files, man.
This article will describe how to download an image from a (docker) container registry.
| [!Manual Download of Container Images with wget and curl](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | Manual Download of Container Images with wget and curl |
Intro
Remember the good `'ol days when you could just download software by visiting a website and click "download"?
Even apt and yum repositories were just simple HTTP servers that you could just curl (or wget) from. Using the package manager was, of course, more secure and convenient -- but you could always just download packages manually, if you wanted.
But have you ever tried to curl an image from a container registry, such as docker? Well friends, I have tried. And I have the scars to prove it.
It was a remarkably complex process that took me weeks to figure-out. Lucky you, this article will break it down.
Examples
Specifically, we'll look at how to download files from two OCI registries.
Terms
First, here's some terminology used by OCI
- OCI - Open Container Initiative
- blob - A "blob" in the OCI spec just means a file
- manifest - A "manifest" in the OCI spec means a list of files
Prerequisites
This guide was written in 2024, and it uses the following software and versions:
- debian 12 (bookworm)
- curl 7.88.1
- OCI Distribution Spec v1.1.0 (which, unintuitively, uses the '/v2/' endpoint)
Of course, you'll need 'curl' installed. And, to parse json, 'jq' too.
sudo apt-get install curl jq
What is OCI?
OCI stands for Open Container Initiative.
OCI was originally formed in June 2015 for Docker and CoreOS. Today it's a wider, general-purpose (and annoyingly complex) way that many projects host files (that are extremely non-trivial to download).
One does not simply download a file from an OCI-complianet container registry. You must:
- Generate an authentication token for the API
- Make an API call to the registry, requesting to download a JSON "Manifest"
- Parse the JSON Manifest to figure out the hash of the file that you want
- Determine the download URL from the hash
- Download the file (which might actually be many distinct file "layers")
| [!One does not simply download from a container registry](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | One does not simply download from a container registry |
In order to figure out how to make an API call to the registry, you must first read (and understand) the OCI specs here.
- <https://opencontainers.org/release-notices/overview/>
OCI APIs
OCI maintains three distinct specifications:
- image spec
- runtime spec
- distribution spec
OCI "Distribution Spec" API
To figure out how to download a file from a container registry, we're interested in the "distribution spec". At the time of writing, the latest "distribution spec" can be downloaded here:
- <https://github.com/opencontainers/distribution-spec/releases/tag/v1.1.0>
- <https://github.com/opencontainers/distribution-spec/releases/download/v1.1.0/oci-distribution-spec-v1.1.0.pdf>
The above PDF file defines a set of API endpoints that we can use to query, parse, and then figure out how to download a file from a container registry. The table from the above PDF is copied below:
| ID | Method | API Endpoint | Success | Failure |
|------|----------|------------------------------------|--------|-----------|
| end-1 | GET | /v2/ | 200 | 404/401 |
| end-2 | GET / HEAD | /v2/<name>/blobs/<digest> | 200 | 404 |
| end-3 | GET / HEAD | /v2/<name>/manifests/<reference> | 200 | 404 |
| end-4a | POST | /v2/<name>/blobs/uploads/ | 202 | 404 |
| end-4b | POST | /v2/<name>/blobs/uploads/?digest=<digest> | 201/202 | 404/400 |
| end-5 | PATCH | /v2/<name>/blobs/uploads/<reference> | 202 | 404/416 |
| end-6 | PUT | /v2/<name>/blobs/uploads/<reference>?digest=<digest> | 201 | 404/400 |
| end-7 | PUT | /v2/<name>/manifests/<reference> | 201 | 404 |
| end-8a | GET | /v2/<name>/tags/list | 200 | 404 |
| end-8b | GET | /v2/<name>/tags/list?n=<integer>&last=<integer> | 200 | 404 |
| end-9 | DELETE | /v2/<name>/manifests/<reference> | 202 | 404/400/405 |
| end-10 | DELETE | /v2/<name>/blobs/<digest> | 202 | 404/405 |
| end-11 | POST | /v2/<name>/blobs/uploads/?mount=<digest>&from=<other_name> | 201 | 404 |
| end-12a | GET | /v2/<name>/referrers/<digest> | 200 | 404/400 |
| end-12b | GET | /v2/<name>/referrers/<digest>?artifactType=<artifactType> | 200 | 404/400 |
| end-13 | GET | /v2/<name>/blobs/uploads/<reference> | 204 | 404 |
In OCI, files are (cryptically) called "blobs". In order to figure out the file that we want to download, we must first reference the list of files (called a "manifest").
The above table shows us how we can download a list of files (manifest) and then download the actual file (blob).
Examples
Let's look at how to download files from a couple different OCI registries:
Docker Hub
To see the full example of downloading images from docker hub, click here
GitHub Packages
To see the full example of downloading files from GitHub Packages, click here.
Why?
I wrote this article because many, many folks have inquired about how to manually download files from OCI registries on the Internet, but their simple queries are usually returned with a barrage of useless counter-questions: why the heck would you want to do that!?!
The answer is varied.
Some people need to get files onto a restricted environment. Either their org doesn't grant them permission to install software on the machine, or the system has firewall-restricted internet access -- or doesn't have internet access at all.
3TOFU
Personally, the reason that I wanted to be able to download files from an OCI registry was for 3TOFU.
| [!Verifying Unsigned Releases with 3TOFU](https://tech.michaelaltfield.net/2024/09/03/container-download-curl-wget) | |:--:| | Verifying Unsigned Releases with 3TOFU |
Unfortunaetly, most apps using OCI registries are extremely insecure. Docker, for example, will happily download malicious images. By default, it doesn't do any authenticity verifications on the payloads it downloaded. Even if you manually enable DCT, there's loads of pending issues with it.
Likewise, the macOS package manager brew has this same problem: it will happily download and install malicious code, because it doesn't use cryptography to verify the authenticity of anything that it downloads. This introduces watering hole vulnerabilities when developers use brew to install dependencies in their CI pipelines.
My solution to this? 3TOFU. And that requires me to be able to download the file (for verification) on three distinct linux VMs using curl or wget.
> ⚠ NOTE: 3TOFU is an approach to harm reduction. > > It is not wise to download and run binaries or code whose authenticity you cannot verify using a cryptographic signature from a key stored offline. However, sometimes we cannot avoid it. If you're going to proceed with running untrusted code, then following a 3TOFU procedure may reduce your risk, but it's better to avoid running unauthenticated code if at all possible.
Registry (ab)use
Container registries were created in 2013 to provide a clever & complex solution to a problem: how to package and serve multiple versions of simplified sources to various consumers spanning multiple operating systems and architectures -- while also packaging them into small, discrete "layers".
However, if your project is just serving simple files, then the only thing gained by uploading them to a complex system like a container registry is headaches. Why do developers do this?
In the case of brew, their free hosing provider (JFrog's Bintray) shutdown in 2021. Brew was already hosting their code on GitHub, so I guess someone looked at "GitHub Packages" and figured it was a good (read: free) replacement.
Many developers using Container Registries don't need the complexity, but -- well -- they're just using it as a free place for their FOSS project to store some files, man.
3TOFU: Verifying Unsigned Releases
By Michael Altfield License: CC BY-SA 4.0 https://tech.michaelaltfield.net
This article introduces the concept of \"3TOFU\" \-- a harm-reduction process when downloading software that cannot be verified cryptographically.
| [!Verifying Unsigned Releases with 3TOFU](https://tech.michaelaltfield.net/2024/08/04/3tofu/) | |:--:| | Verifying Unsigned Releases with 3TOFU |
> ⚠ NOTE: This article is about harm reduction. > > It is dangerous to download and run binaries (or code) whose authenticity you cannot verify (using a cryptographic signature from a key stored offline). However, sometimes we cannot avoid it. If you\'re going to proceed with running untrusted code, then following the steps outlined in this guide may reduce your risk.
TOFU
TOFU stands for Trust On First Use. It\'s a (often abused) concept of downloading a person or org\'s signing key and just blindly trusting it (instead of verifying it).
3TOFU
3TOFU is a process where a user downloads something three times at three different locations. If-and-only-if all three downloads are identical, then you trust it.
Why 3TOFU?
During the Crypto Wars of the 1990s, it was illegal to export cryptography from the United States. In 1996, after intense public pressure and legal challenges, the government officially permitted export with the 56-bit DES cipher \-- which was a known-vulnerable cipher.
| [!Photo of Paul Kocher holding a very large circuit board](https://tech.michaelaltfield.net/2024/08/04/3tofu/) | |:--:| | The EFF\'s Deep Crack proved DES to be insecure and pushed a switch to 3DES. |
But there was a simple way to use insecure DES to make secure messages: just use it three times.
3DES (aka \"Triple DES\") is the process encrypting a message using the insecure symmetric block cipher (DES) three times on each block, to produce an actually secure message (from known attacks at the time).
3TOFU (aka \"Triple TOFU\") is the process of downloading a payload using the insecure method (TOFU) three times, to obtain the payload that\'s magnitudes less likely to be maliciously altered.
3TOFU Process
To best mitigate targeted attacks, 3TOFU should be done:
- On three distinct days
- On three distinct machines (or VMs)
- Exiting from three distinct countries
- Exiting using three distinct networks
For example, I\'ll usually execute
- TOFU #1/3 in TAILS (via Tor)
- TOFU #2/3 in a Debian VM (via VPN)
- TOFU #3/3 on my daily laptop (via ISP)
The possibility of an attacker maliciously modifying something you download over your ISP\'s network are quite high, depending on which country you live-in.
The possibility of an attacker maliciously modifying something you download onto a VM with a freshly installed OS over an encrypted VPN connection (routed internationally and exiting from another country) is much less likely, but still possible \-- especially for a well-funded adversary.
The possibility of an attacker maliciously modifying something you download onto a VM running a hardened OS (like Whonix or TAILS) using a hardened browser (like Tor Browser) over an anonymizing network (like Tor) is quite unlikely.
The possibility for someone to execute a network attack on all three downloads is very near-zero \-- especially if the downloads were spread-out over days or weeks.
3TOFU bash Script
I provide the following bash script as an example snippet that I run for each of the 3TOFUs.
``` REMOTE_FILES="https://tails.net/tails-signing.key"
CURL="/usr/bin/curl" WGET="/usr/bin/wget --retry-on-host-error --retry-connrefused" PYTHON="/usr/bin/python3"
in tails, we must torify
if [[ "whoami" == "amnesia" ]] ; then
CURL="/usr/bin/torify ${CURL}"
WGET="/usr/bin/torify ${WGET}"
PYTHON="/usr/bin/torify ${PYTHON}"
fi
tmpDir=mktemp -d
pushd "${tmpDir}"
first get some info about our internet connection
${CURL} -s https://ifconfig.co/country | head -n1 ${CURL} -s https://check.torproject.org | grep Congratulations | head -n1
and today's date
date -u +"%Y-%m-%d"
get the file
for file in ${REMOTE_FILES}; do wget ${file} done
checksum
date -u +"%Y-%m-%d" sha256sum *
gpg fingerprint
gpg --with-fingerprint --with-subkey-fingerprint --keyid-format 0xlong * ```
Here\'s one example execution of the above script (on a debian DispVM, executed with a VPN).
``` /tmp/tmp.xT9HCeTY0y ~ Canada 2024-05-04 --2024-05-04 14:58:54-- https://tails.net/tails-signing.key Resolving tails.net (tails.net)... 204.13.164.63 Connecting to tails.net (tails.net)|204.13.164.63|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 1387192 (1.3M) [application/octet-stream] Saving to: ‘tails-signing.key’
tails-signing.key 100%[===================>] 1.32M 1.26MB/s in 1.1s
2024-05-04 14:58:56 (1.26 MB/s) - ‘tails-signing.key’ saved [1387192/1387192]
2024-05-04 8c641252767dc8815d3453e540142ea143498f8fbd76850066dc134445b3e532 tails-signing.key gpg: WARNING: no command supplied. Trying to guess what you mean ... pub rsa4096/0xDBB802B258ACD84F 2015-01-18 [C] [expires: 2025-01-25] Key fingerprint = A490 D0F4 D311 A415 3E2B B7CA DBB8 02B2 58AC D84F uid Tails developers (offline long-term identity key) <tails@boum.org> uid Tails developers <tails@boum.org> sub rsa4096/0x3C83DCB52F699C56 2015-01-18 [S] [expired: 2018-01-11] sub rsa4096/0x98FEC6BC752A3DB6 2015-01-18 [S] [expired: 2018-01-11] sub rsa4096/0xAA9E014656987A65 2015-01-18 [S] [revoked: 2015-10-29] sub rsa4096/0xAF292B44A0EDAA41 2016-08-30 [S] [expired: 2018-01-11] sub rsa4096/0xD21DAD38AF281C0B 2017-08-28 [S] [expires: 2025-01-25] sub rsa4096/0x3020A7A9C2B72733 2017-08-28 [S] [revoked: 2020-05-29] sub ed25519/0x90B2B4BD7AED235F 2017-08-28 [S] [expires: 2025-01-25] sub rsa4096/0xA8B0F4E45B1B50E2 2018-08-30 [S] [revoked: 2021-10-14] sub rsa4096/0x7BFBD2B902EE13D0 2021-10-14 [S] [expires: 2025-01-25] sub rsa4096/0xE5DBA2E186D5BAFC 2023-10-03 [S] [expires: 2025-01-25] ```
The TOFU output above shows that the release signing key from the TAILS project is a 4096-bit RSA key with a full fingerprint of \"A490 D0F4 D311 A415 3E2B B7CA DBB8 02B2 58AC D84F\". The key file itself has a sha256 hash of \"8c641252767dc8815d3453e540142ea143498f8fbd76850066dc134445b3e532\".
When doing a 3TOFU, save the output of each execution. After collecting output from all 3 executions (intentionally spread-out over 3 days or more), diff the output.
If the output of all three TOFUs match, then the confidence of the file\'s authenticity is very high.
Why do 3TOFU?
Unfortunately, many developers think that hosting their releases on a server with https is sufficient to protect their users from obtaining a maliciously-modified release. But https won\'t protect you if:
- Your DNS or publishing infrastructure is compromised (it happens), or
- An attacker has just one (subordinate) CA in the user\'s PKI root store (it happens)
Generally speaking, publishing infrastructure compromises are detected and resolved within days and MITM attacks using compromised CAs are targeted attacks (to avoid detection). Therefore, a 3TOFU verification should thwart these types of attacks.
> ⚠ Note on hashes: Unfortunately, many well-meaning developers erroneously think that cryptographic hashes provide authenticity, but cryptographic hashes do not provide authenticity \-- they provide integrity. > > Integrity checks are useful to detect corrupted data on-download; it does not protect you from maliciously altered data unless those hashes are cryptographically signed with a key whose private key isn\'t stored on the publishing infrastructure.
Improvements
There are some things you can do to further improve the confidence of the authenticity of a file you download from the internet.
Distinct Domains
If possible, download your payload from as many distinct domains as possible.
An adversary may successfully compromise the publishing infrastructure of a software project, but it\'s far less likely for them to compromise the project website (eg \'tails.net\') and their forge (eg \'github.com\') and their mastodon instance (eg \'mastodon.social\').
Use TAILS
| [!TAILS Logo](https://tech.michaelaltfield.net/2024/08/04/3tofu/) | |:--:| | TAILS is by far the best OS to use for security-critical situations. |
If you are a high-risk target (investigative journalist, activist, or political dissident) then you should definitely use TAILS for one of your TOFUs.
Signature Verification
It\'s always better to verify the authenticity of a file using cryptographic signatures than with 3TOFU.
Unfortunately, some companies like Microsoft don\'t sign their releases, so the only option to verify the authenticity of something like a Windows .iso is with 3TOFU.
Still, whenever you encounter some software that is not signed using an offline key, please do us all a favor and create a bug report asking the developer to sign their releases with PGP (or minisign or signify or something).
4TOFU
3TOFU is easy because Tor is free and most people have access to a VPN (corporate or commercial or an ssh socks proxy).
But, if you\'d like, you could also add i2p or some other proxy network into the mix (and do 4TOFU).
3TOFU: Verifying Unsigned Releases
By Michael Altfield License: CC BY-SA 4.0 https://tech.michaelaltfield.net
This article introduces the concept of \"3TOFU\" \-- a harm-reduction process when downloading software that cannot be verified cryptographically.
| [!Verifying Unsigned Releases with 3TOFU](https://tech.michaelaltfield.net/2024/08/04/3tofu/) | |:--:| | Verifying Unsigned Releases with 3TOFU |
> ⚠ NOTE: This article is about harm reduction. > > It is dangerous to download and run binaries (or code) whose authenticity you cannot verify (using a cryptographic signature from a key stored offline). However, sometimes we cannot avoid it. If you\'re going to proceed with running untrusted code, then following the steps outlined in this guide may reduce your risk.
TOFU
TOFU stands for Trust On First Use. It\'s a (often abused) concept of downloading a person or org\'s signing key and just blindly trusting it (instead of verifying it).
3TOFU
3TOFU is a process where a user downloads something three times at three different locations. If-and-only-if all three downloads are identical, then you trust it.
Why 3TOFU?
During the Crypto Wars of the 1990s, it was illegal to export cryptography from the United States. In 1996, after intense public pressure and legal challenges, the government officially permitted export with the 56-bit DES cipher \-- which was a known-vulnerable cipher.
| [!Photo of Paul Kocher holding a very large circuit board](https://tech.michaelaltfield.net/2024/08/04/3tofu/) | |:--:| | The EFF\'s Deep Crack proved DES to be insecure and pushed a switch to 3DES. |
But there was a simple way to use insecure DES to make secure messages: just use it three times.
3DES (aka \"Triple DES\") is the process encrypting a message using the insecure symmetric block cipher (DES) three times on each block, to produce an actually secure message (from known attacks at the time).
3TOFU (aka \"Triple TOFU\") is the process of downloading a payload using the insecure method (TOFU) three times, to obtain the payload that\'s magnitudes less likely to be maliciously altered.
3TOFU Process
To best mitigate targeted attacks, 3TOFU should be done:
- On three distinct days
- On three distinct machines (or VMs)
- Exiting from three distinct countries
- Exiting using three distinct networks
For example, I\'ll usually execute
- TOFU #1/3 in TAILS (via Tor)
- TOFU #2/3 in a Debian VM (via VPN)
- TOFU #3/3 on my daily laptop (via ISP)
The possibility of an attacker maliciously modifying something you download over your ISP\'s network are quite high, depending on which country you live-in.
The possibility of an attacker maliciously modifying something you download onto a VM with a freshly installed OS over an encrypted VPN connection (routed internationally and exiting from another country) is much less likely, but still possible \-- especially for a well-funded adversary.
The possibility of an attacker maliciously modifying something you download onto a VM running a hardened OS (like Whonix or TAILS) using a hardened browser (like Tor Browser) over an anonymizing network (like Tor) is quite unlikely.
The possibility for someone to execute a network attack on all three downloads is very near-zero \-- especially if the downloads were spread-out over days or weeks.
3TOFU bash Script
I provide the following bash script as an example snippet that I run for each of the 3TOFUs.
``` REMOTE_FILES="https://tails.net/tails-signing.key"
CURL="/usr/bin/curl" WGET="/usr/bin/wget --retry-on-host-error --retry-connrefused" PYTHON="/usr/bin/python3"
in tails, we must torify
if [[ "whoami" == "amnesia" ]] ; then
CURL="/usr/bin/torify ${CURL}"
WGET="/usr/bin/torify ${WGET}"
PYTHON="/usr/bin/torify ${PYTHON}"
fi
tmpDir=mktemp -d
pushd "${tmpDir}"
first get some info about our internet connection
${CURL} -s https://ifconfig.co/country | head -n1 ${CURL} -s https://check.torproject.org | grep Congratulations | head -n1
and today's date
date -u +"%Y-%m-%d"
get the file
for file in ${REMOTE_FILES}; do wget ${file} done
checksum
date -u +"%Y-%m-%d" sha256sum *
gpg fingerprint
gpg --with-fingerprint --with-subkey-fingerprint --keyid-format 0xlong * ```
Here\'s one example execution of the above script (on a debian DispVM, executed with a VPN).
``` /tmp/tmp.xT9HCeTY0y ~ Canada 2024-05-04 --2024-05-04 14:58:54-- https://tails.net/tails-signing.key Resolving tails.net (tails.net)... 204.13.164.63 Connecting to tails.net (tails.net)|204.13.164.63|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 1387192 (1.3M) [application/octet-stream] Saving to: ‘tails-signing.key’
tails-signing.key 100%[===================>] 1.32M 1.26MB/s in 1.1s
2024-05-04 14:58:56 (1.26 MB/s) - ‘tails-signing.key’ saved [1387192/1387192]
2024-05-04 8c641252767dc8815d3453e540142ea143498f8fbd76850066dc134445b3e532 tails-signing.key gpg: WARNING: no command supplied. Trying to guess what you mean ... pub rsa4096/0xDBB802B258ACD84F 2015-01-18 [C] [expires: 2025-01-25] Key fingerprint = A490 D0F4 D311 A415 3E2B B7CA DBB8 02B2 58AC D84F uid Tails developers (offline long-term identity key) <tails@boum.org> uid Tails developers <tails@boum.org> sub rsa4096/0x3C83DCB52F699C56 2015-01-18 [S] [expired: 2018-01-11] sub rsa4096/0x98FEC6BC752A3DB6 2015-01-18 [S] [expired: 2018-01-11] sub rsa4096/0xAA9E014656987A65 2015-01-18 [S] [revoked: 2015-10-29] sub rsa4096/0xAF292B44A0EDAA41 2016-08-30 [S] [expired: 2018-01-11] sub rsa4096/0xD21DAD38AF281C0B 2017-08-28 [S] [expires: 2025-01-25] sub rsa4096/0x3020A7A9C2B72733 2017-08-28 [S] [revoked: 2020-05-29] sub ed25519/0x90B2B4BD7AED235F 2017-08-28 [S] [expires: 2025-01-25] sub rsa4096/0xA8B0F4E45B1B50E2 2018-08-30 [S] [revoked: 2021-10-14] sub rsa4096/0x7BFBD2B902EE13D0 2021-10-14 [S] [expires: 2025-01-25] sub rsa4096/0xE5DBA2E186D5BAFC 2023-10-03 [S] [expires: 2025-01-25] ```
The TOFU output above shows that the release signing key from the TAILS project is a 4096-bit RSA key with a full fingerprint of \"A490 D0F4 D311 A415 3E2B B7CA DBB8 02B2 58AC D84F\". The key file itself has a sha256 hash of \"8c641252767dc8815d3453e540142ea143498f8fbd76850066dc134445b3e532\".
When doing a 3TOFU, save the output of each execution. After collecting output from all 3 executions (intentionally spread-out over 3 days or more), diff the output.
If the output of all three TOFUs match, then the confidence of the file\'s authenticity is very high.
Why do 3TOFU?
Unfortunately, many developers think that hosting their releases on a server with https is sufficient to protect their users from obtaining a maliciously-modified release. But https won\'t protect you if:
- Your DNS or publishing infrastructure is compromised (it happens), or
- An attacker has just one (subordinate) CA in the user\'s PKI root store (it happens)
Generally speaking, publishing infrastructure compromises are detected and resolved within days and MITM attacks using compromised CAs are targeted attacks (to avoid detection). Therefore, a 3TOFU verification should thwart these types of attacks.
> ⚠ Note on hashes: Unfortunately, many well-meaning developers erroneously think that cryptographic hashes provide authenticity, but cryptographic hashes do not provide authenticity \-- they provide integrity. > > Integrity checks are useful to detect corrupted data on-download; it does not protect you from maliciously altered data unless those hashes are cryptographically signed with a key whose private key isn\'t stored on the publishing infrastructure.
Improvements
There are some things you can do to further improve the confidence of the authenticity of a file you download from the internet.
Distinct Domains
If possible, download your payload from as many distinct domains as possible.
An adversary may successfully compromise the publishing infrastructure of a software project, but it\'s far less likely for them to compromise the project website (eg \'tails.net\') and their forge (eg \'github.com\') and their mastodon instance (eg \'mastodon.social\').
Use TAILS
| [!TAILS Logo](https://tech.michaelaltfield.net/2024/08/04/3tofu/) | |:--:| | TAILS is by far the best OS to use for security-critical situations. |
If you are a high-risk target (investigative journalist, activist, or political dissident) then you should definitely use TAILS for one of your TOFUs.
Signature Verification
It\'s always better to verify the authenticity of a file using cryptographic signatures than with 3TOFU.
Unfortunately, some companies like Microsoft don\'t sign their releases, so the only option to verify the authenticity of something like a Windows .iso is with 3TOFU.
Still, whenever you encounter some software that is not signed using an offline key, please do us all a favor and create a bug report asking the developer to sign their releases with PGP (or minisign or signify or something).
4TOFU
3TOFU is easy because Tor is free and most people have access to a VPN (corporate or commercial or an ssh socks proxy).
But, if you\'d like, you could also add i2p or some other proxy network into the mix (and do 4TOFU).
3TOFU: Verifying Unsigned Releases
By Michael Altfield License: CC BY-SA 4.0 https://tech.michaelaltfield.net
This article introduces the concept of \"3TOFU\" \-- a harm-reduction process when downloading software that cannot be verified cryptographically.
| [!Verifying Unsigned Releases with 3TOFU](https://tech.michaelaltfield.net/2024/08/04/3tofu/) | |:--:| | Verifying Unsigned Releases with 3TOFU |
> ⚠ NOTE: This article is about harm reduction. > > It is dangerous to download and run binaries (or code) whose authenticity you cannot verify (using a cryptographic signature from a key stored offline). However, sometimes we cannot avoid it. If you\'re going to proceed with running untrusted code, then following the steps outlined in this guide may reduce your risk.
TOFU
TOFU stands for Trust On First Use. It\'s a (often abused) concept of downloading a person or org\'s signing key and just blindly trusting it (instead of verifying it).
3TOFU
3TOFU is a process where a user downloads something three times at three different locations. If-and-only-if all three downloads are identical, then you trust it.
Why 3TOFU?
During the Crypto Wars of the 1990s, it was illegal to export cryptography from the United States. In 1996, after intense public pressure and legal challenges, the government officially permitted export with the 56-bit DES cipher \-- which was a known-vulnerable cipher.
| [!Photo of Paul Kocher holding a very large circuit board](https://tech.michaelaltfield.net/2024/08/04/3tofu/) | |:--:| | The EFF\'s Deep Crack proved DES to be insecure and pushed a switch to 3DES. |
But there was a simple way to use insecure DES to make secure messages: just use it three times.
3DES (aka \"Triple DES\") is the process encrypting a message using the insecure symmetric block cipher (DES) three times on each block, to produce an actually secure message (from known attacks at the time).
3TOFU (aka \"Triple TOFU\") is the process of downloading a payload using the insecure method (TOFU) three times, to obtain the payload that\'s magnitudes less likely to be maliciously altered.
3TOFU Process
To best mitigate targeted attacks, 3TOFU should be done:
- On three distinct days
- On three distinct machines (or VMs)
- Exiting from three distinct countries
- Exiting using three distinct networks
For example, I\'ll usually execute
- TOFU #1/3 in TAILS (via Tor)
- TOFU #2/3 in a Debian VM (via VPN)
- TOFU #3/3 on my daily laptop (via ISP)
The possibility of an attacker maliciously modifying something you download over your ISP\'s network are quite high, depending on which country you live-in.
The possibility of an attacker maliciously modifying something you download onto a VM with a freshly installed OS over an encrypted VPN connection (routed internationally and exiting from another country) is much less likely, but still possible \-- especially for a well-funded adversary.
The possibility of an attacker maliciously modifying something you download onto a VM running a hardened OS (like Whonix or TAILS) using a hardened browser (like Tor Browser) over an anonymizing network (like Tor) is quite unlikely.
The possibility for someone to execute a network attack on all three downloads is very near-zero \-- especially if the downloads were spread-out over days or weeks.
3TOFU bash Script
I provide the following bash script as an example snippet that I run for each of the 3TOFUs.
``` REMOTE_FILES="https://tails.net/tails-signing.key"
CURL="/usr/bin/curl" WGET="/usr/bin/wget --retry-on-host-error --retry-connrefused" PYTHON="/usr/bin/python3"
in tails, we must torify
if [[ "whoami" == "amnesia" ]] ; then
CURL="/usr/bin/torify ${CURL}"
WGET="/usr/bin/torify ${WGET}"
PYTHON="/usr/bin/torify ${PYTHON}"
fi
tmpDir=mktemp -d
pushd "${tmpDir}"
first get some info about our internet connection
${CURL} -s https://ifconfig.co/country | head -n1 ${CURL} -s https://check.torproject.org | grep Congratulations | head -n1
and today's date
date -u +"%Y-%m-%d"
get the file
for file in ${REMOTE_FILES}; do wget ${file} done
checksum
date -u +"%Y-%m-%d" sha256sum *
gpg fingerprint
gpg --with-fingerprint --with-subkey-fingerprint --keyid-format 0xlong * ```
Here\'s one example execution of the above script (on a debian DispVM, executed with a VPN).
``` /tmp/tmp.xT9HCeTY0y ~ Canada 2024-05-04 --2024-05-04 14:58:54-- https://tails.net/tails-signing.key Resolving tails.net (tails.net)... 204.13.164.63 Connecting to tails.net (tails.net)|204.13.164.63|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 1387192 (1.3M) [application/octet-stream] Saving to: ‘tails-signing.key’
tails-signing.key 100%[===================>] 1.32M 1.26MB/s in 1.1s
2024-05-04 14:58:56 (1.26 MB/s) - ‘tails-signing.key’ saved [1387192/1387192]
2024-05-04 8c641252767dc8815d3453e540142ea143498f8fbd76850066dc134445b3e532 tails-signing.key gpg: WARNING: no command supplied. Trying to guess what you mean ... pub rsa4096/0xDBB802B258ACD84F 2015-01-18 [C] [expires: 2025-01-25] Key fingerprint = A490 D0F4 D311 A415 3E2B B7CA DBB8 02B2 58AC D84F uid Tails developers (offline long-term identity key) <tails@boum.org> uid Tails developers <tails@boum.org> sub rsa4096/0x3C83DCB52F699C56 2015-01-18 [S] [expired: 2018-01-11] sub rsa4096/0x98FEC6BC752A3DB6 2015-01-18 [S] [expired: 2018-01-11] sub rsa4096/0xAA9E014656987A65 2015-01-18 [S] [revoked: 2015-10-29] sub rsa4096/0xAF292B44A0EDAA41 2016-08-30 [S] [expired: 2018-01-11] sub rsa4096/0xD21DAD38AF281C0B 2017-08-28 [S] [expires: 2025-01-25] sub rsa4096/0x3020A7A9C2B72733 2017-08-28 [S] [revoked: 2020-05-29] sub ed25519/0x90B2B4BD7AED235F 2017-08-28 [S] [expires: 2025-01-25] sub rsa4096/0xA8B0F4E45B1B50E2 2018-08-30 [S] [revoked: 2021-10-14] sub rsa4096/0x7BFBD2B902EE13D0 2021-10-14 [S] [expires: 2025-01-25] sub rsa4096/0xE5DBA2E186D5BAFC 2023-10-03 [S] [expires: 2025-01-25] ```
The TOFU output above shows that the release signing key from the TAILS project is a 4096-bit RSA key with a full fingerprint of \"A490 D0F4 D311 A415 3E2B B7CA DBB8 02B2 58AC D84F\". The key file itself has a sha256 hash of \"8c641252767dc8815d3453e540142ea143498f8fbd76850066dc134445b3e532\".
When doing a 3TOFU, save the output of each execution. After collecting output from all 3 executions (intentionally spread-out over 3 days or more), diff the output.
If the output of all three TOFUs match, then the confidence of the file\'s authenticity is very high.
Why do 3TOFU?
Unfortunately, many developers think that hosting their releases on a server with https is sufficient to protect their users from obtaining a maliciously-modified release. But https won\'t protect you if:
- Your DNS or publishing infrastructure is compromised (it happens), or
- An attacker has just one (subordinate) CA in the user\'s PKI root store (it happens)
Generally speaking, publishing infrastructure compromises are detected and resolved within days and MITM attacks using compromised CAs are targeted attacks (to avoid detection). Therefore, a 3TOFU verification should thwart these types of attacks.
> ⚠ Note on hashes: Unfortunately, many well-meaning developers erroneously think that cryptographic hashes provide authenticity, but cryptographic hashes do not provide authenticity \-- they provide integrity. > > Integrity checks are useful to detect corrupted data on-download; it does not protect you from maliciously altered data unless those hashes are cryptographically signed with a key whose private key isn\'t stored on the publishing infrastructure.
Improvements
There are some things you can do to further improve the confidence of the authenticity of a file you download from the internet.
Distinct Domains
If possible, download your payload from as many distinct domains as possible.
An adversary may successfully compromise the publishing infrastructure of a software project, but it\'s far less likely for them to compromise the project website (eg \'tails.net\') and their forge (eg \'github.com\') and their mastodon instance (eg \'mastodon.social\').
Use TAILS
| [!TAILS Logo](https://tech.michaelaltfield.net/2024/08/04/3tofu/) | |:--:| | TAILS is by far the best OS to use for security-critical situations. |
If you are a high-risk target (investigative journalist, activist, or political dissident) then you should definitely use TAILS for one of your TOFUs.
Signature Verification
It\'s always better to verify the authenticity of a file using cryptographic signatures than with 3TOFU.
Unfortunately, some companies like Microsoft don\'t sign their releases, so the only option to verify the authenticity of something like a Windows .iso is with 3TOFU.
Still, whenever you encounter some software that is not signed using an offline key, please do us all a favor and create a bug report asking the developer to sign their releases with PGP (or minisign or signify or something).
4TOFU
3TOFU is easy because Tor is free and most people have access to a VPN (corporate or commercial or an ssh socks proxy).
But, if you\'d like, you could also add i2p or some other proxy network into the mix (and do 4TOFU).
3TOFU: Verifying Unsigned Releases
By Michael Altfield License: CC BY-SA 4.0 https://tech.michaelaltfield.net
This article introduces the concept of \"3TOFU\" \-- a harm-reduction process when downloading software that cannot be verified cryptographically.
| [!Verifying Unsigned Releases with 3TOFU](https://tech.michaelaltfield.net/2024/08/04/3tofu/) | |:--:| | Verifying Unsigned Releases with 3TOFU |
> ⚠ NOTE: This article is about harm reduction. > > It is dangerous to download and run binaries (or code) whose authenticity you cannot verify (using a cryptographic signature from a key stored offline). However, sometimes we cannot avoid it. If you\'re going to proceed with running untrusted code, then following the steps outlined in this guide may reduce your risk.
TOFU
TOFU stands for Trust On First Use. It\'s a (often abused) concept of downloading a person or org\'s signing key and just blindly trusting it (instead of verifying it).
3TOFU
3TOFU is a process where a user downloads something three times at three different locations. If-and-only-if all three downloads are identical, then you trust it.
Why 3TOFU?
During the Crypto Wars of the 1990s, it was illegal to export cryptography from the United States. In 1996, after intense public pressure and legal challenges, the government officially permitted export with the 56-bit DES cipher \-- which was a known-vulnerable cipher.
| [!Photo of Paul Kocher holding a very large circuit board](https://tech.michaelaltfield.net/2024/08/04/3tofu/) | |:--:| | The EFF\'s Deep Crack proved DES to be insecure and pushed a switch to 3DES. |
But there was a simple way to use insecure DES to make secure messages: just use it three times.
3DES (aka \"Triple DES\") is the process encrypting a message using the insecure symmetric block cipher (DES) three times on each block, to produce an actually secure message (from known attacks at the time).
3TOFU (aka \"Triple TOFU\") is the process of downloading a payload using the insecure method (TOFU) three times, to obtain the payload that\'s magnitudes less likely to be maliciously altered.
3TOFU Process
To best mitigate targeted attacks, 3TOFU should be done:
- On three distinct days
- On three distinct machines (or VMs)
- Exiting from three distinct countries
- Exiting using three distinct networks
For example, I\'ll usually execute
- TOFU #1/3 in TAILS (via Tor)
- TOFU #2/3 in a Debian VM (via VPN)
- TOFU #3/3 on my daily laptop (via ISP)
The possibility of an attacker maliciously modifying something you download over your ISP\'s network are quite high, depending on which country you live-in.
The possibility of an attacker maliciously modifying something you download onto a VM with a freshly installed OS over an encrypted VPN connection (routed internationally and exiting from another country) is much less likely, but still possible \-- especially for a well-funded adversary.
The possibility of an attacker maliciously modifying something you download onto a VM running a hardened OS (like Whonix or TAILS) using a hardened browser (like Tor Browser) over an anonymizing network (like Tor) is quite unlikely.
The possibility for someone to execute a network attack on all three downloads is very near-zero \-- especially if the downloads were spread-out over days or weeks.
3TOFU bash Script
I provide the following bash script as an example snippet that I run for each of the 3TOFUs.
``` REMOTE_FILES="https://tails.net/tails-signing.key"
CURL="/usr/bin/curl" WGET="/usr/bin/wget --retry-on-host-error --retry-connrefused" PYTHON="/usr/bin/python3"
in tails, we must torify
if [[ "whoami" == "amnesia" ]] ; then
CURL="/usr/bin/torify ${CURL}"
WGET="/usr/bin/torify ${WGET}"
PYTHON="/usr/bin/torify ${PYTHON}"
fi
tmpDir=mktemp -d
pushd "${tmpDir}"
first get some info about our internet connection
${CURL} -s https://ifconfig.co/country | head -n1 ${CURL} -s https://check.torproject.org | grep Congratulations | head -n1
and today's date
date -u +"%Y-%m-%d"
get the file
for file in ${REMOTE_FILES}; do wget ${file} done
checksum
date -u +"%Y-%m-%d" sha256sum *
gpg fingerprint
gpg --with-fingerprint --with-subkey-fingerprint --keyid-format 0xlong * ```
Here\'s one example execution of the above script (on a debian DispVM, executed with a VPN).
``` /tmp/tmp.xT9HCeTY0y ~ Canada 2024-05-04 --2024-05-04 14:58:54-- https://tails.net/tails-signing.key Resolving tails.net (tails.net)... 204.13.164.63 Connecting to tails.net (tails.net)|204.13.164.63|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 1387192 (1.3M) [application/octet-stream] Saving to: ‘tails-signing.key’
tails-signing.key 100%[===================>] 1.32M 1.26MB/s in 1.1s
2024-05-04 14:58:56 (1.26 MB/s) - ‘tails-signing.key’ saved [1387192/1387192]
2024-05-04 8c641252767dc8815d3453e540142ea143498f8fbd76850066dc134445b3e532 tails-signing.key gpg: WARNING: no command supplied. Trying to guess what you mean ... pub rsa4096/0xDBB802B258ACD84F 2015-01-18 [C] [expires: 2025-01-25] Key fingerprint = A490 D0F4 D311 A415 3E2B B7CA DBB8 02B2 58AC D84F uid Tails developers (offline long-term identity key) <tails@boum.org> uid Tails developers <tails@boum.org> sub rsa4096/0x3C83DCB52F699C56 2015-01-18 [S] [expired: 2018-01-11] sub rsa4096/0x98FEC6BC752A3DB6 2015-01-18 [S] [expired: 2018-01-11] sub rsa4096/0xAA9E014656987A65 2015-01-18 [S] [revoked: 2015-10-29] sub rsa4096/0xAF292B44A0EDAA41 2016-08-30 [S] [expired: 2018-01-11] sub rsa4096/0xD21DAD38AF281C0B 2017-08-28 [S] [expires: 2025-01-25] sub rsa4096/0x3020A7A9C2B72733 2017-08-28 [S] [revoked: 2020-05-29] sub ed25519/0x90B2B4BD7AED235F 2017-08-28 [S] [expires: 2025-01-25] sub rsa4096/0xA8B0F4E45B1B50E2 2018-08-30 [S] [revoked: 2021-10-14] sub rsa4096/0x7BFBD2B902EE13D0 2021-10-14 [S] [expires: 2025-01-25] sub rsa4096/0xE5DBA2E186D5BAFC 2023-10-03 [S] [expires: 2025-01-25] ```
The TOFU output above shows that the release signing key from the TAILS project is a 4096-bit RSA key with a full fingerprint of \"A490 D0F4 D311 A415 3E2B B7CA DBB8 02B2 58AC D84F\". The key file itself has a sha256 hash of \"8c641252767dc8815d3453e540142ea143498f8fbd76850066dc134445b3e532\".
When doing a 3TOFU, save the output of each execution. After collecting output from all 3 executions (intentionally spread-out over 3 days or more), diff the output.
If the output of all three TOFUs match, then the confidence of the file\'s authenticity is very high.
Why do 3TOFU?
Unfortunately, many developers think that hosting their releases on a server with https is sufficient to protect their users from obtaining a maliciously-modified release. But https won\'t protect you if:
- Your DNS or publishing infrastructure is compromised (it happens), or
- An attacker has just one (subordinate) CA in the user\'s PKI root store (it happens)
Generally speaking, publishing infrastructure compromises are detected and resolved within days and MITM attacks using compromised CAs are targeted attacks (to avoid detection). Therefore, a 3TOFU verification should thwart these types of attacks.
> ⚠ Note on hashes: Unfortunately, many well-meaning developers erroneously think that cryptographic hashes provide authenticity, but cryptographic hashes do not provide authenticity \-- they provide integrity. > > Integrity checks are useful to detect corrupted data on-download; it does not protect you from maliciously altered data unless those hashes are cryptographically signed with a key whose private key isn\'t stored on the publishing infrastructure.
Improvements
There are some things you can do to further improve the confidence of the authenticity of a file you download from the internet.
Distinct Domains
If possible, download your payload from as many distinct domains as possible.
An adversary may successfully compromise the publishing infrastructure of a software project, but it\'s far less likely for them to compromise the project website (eg \'tails.net\') and their forge (eg \'github.com\') and their mastodon instance (eg \'mastodon.social\').
Use TAILS
| [!TAILS Logo](https://tech.michaelaltfield.net/2024/08/04/3tofu/) | |:--:| | TAILS is by far the best OS to use for security-critical situations. |
If you are a high-risk target (investigative journalist, activist, or political dissident) then you should definitely use TAILS for one of your TOFUs.
Signature Verification
It\'s always better to verify the authenticity of a file using cryptographic signatures than with 3TOFU.
Unfortunately, some companies like Microsoft don\'t sign their releases, so the only option to verify the authenticity of something like a Windows .iso is with 3TOFU.
Still, whenever you encounter some software that is not signed using an offline key, please do us all a favor and create a bug report asking the developer to sign their releases with PGP (or minisign or signify or something).
4TOFU
3TOFU is easy because Tor is free and most people have access to a VPN (corporate or commercial or an ssh socks proxy).
But, if you\'d like, you could also add i2p or some other proxy network into the mix (and do 4TOFU).
3TOFU: Verifying Unsigned Releases
By Michael Altfield License: CC BY-SA 4.0 https://tech.michaelaltfield.net
This article introduces the concept of \"3TOFU\" \-- a harm-reduction process when downloading software that cannot be verified cryptographically.
| [!Verifying Unsigned Releases with 3TOFU](https://tech.michaelaltfield.net/2024/08/04/3tofu/) | |:--:| | Verifying Unsigned Releases with 3TOFU |
> ⚠ NOTE: This article is about harm reduction. > > It is dangerous to download and run binaries (or code) whose authenticity you cannot verify (using a cryptographic signature from a key stored offline). However, sometimes we cannot avoid it. If you\'re going to proceed with running untrusted code, then following the steps outlined in this guide may reduce your risk.
TOFU
TOFU stands for Trust On First Use. It\'s a (often abused) concept of downloading a person or org\'s signing key and just blindly trusting it (instead of verifying it).
3TOFU
3TOFU is a process where a user downloads something three times at three different locations. If-and-only-if all three downloads are identical, then you trust it.
Why 3TOFU?
During the Crypto Wars of the 1990s, it was illegal to export cryptography from the United States. In 1996, after intense public pressure and legal challenges, the government officially permitted export with the 56-bit DES cipher \-- which was a known-vulnerable cipher.
| [!Photo of Paul Kocher holding a very large circuit board](https://tech.michaelaltfield.net/2024/08/04/3tofu/) | |:--:| | The EFF\'s Deep Crack proved DES to be insecure and pushed a switch to 3DES. |
But there was a simple way to use insecure DES to make secure messages: just use it three times.
3DES (aka \"Triple DES\") is the process encrypting a message using the insecure symmetric block cipher (DES) three times on each block, to produce an actually secure message (from known attacks at the time).
3TOFU (aka \"Triple TOFU\") is the process of downloading a payload using the insecure method (TOFU) three times, to obtain the payload that\'s magnitudes less likely to be maliciously altered.
3TOFU Process
To best mitigate targeted attacks, 3TOFU should be done:
- On three distinct days
- On three distinct machines (or VMs)
- Exiting from three distinct countries
- Exiting using three distinct networks
For example, I\'ll usually execute
- TOFU #1/3 in TAILS (via Tor)
- TOFU #2/3 in a Debian VM (via VPN)
- TOFU #3/3 on my daily laptop (via ISP)
The possibility of an attacker maliciously modifying something you download over your ISP\'s network are quite high, depending on which country you live-in.
The possibility of an attacker maliciously modifying something you download onto a VM with a freshly installed OS over an encrypted VPN connection (routed internationally and exiting from another country) is much less likely, but still possible \-- especially for a well-funded adversary.
The possibility of an attacker maliciously modifying something you download onto a VM running a hardened OS (like Whonix or TAILS) using a hardened browser (like Tor Browser) over an anonymizing network (like Tor) is quite unlikely.
The possibility for someone to execute a network attack on all three downloads is very near-zero \-- especially if the downloads were spread-out over days or weeks.
3TOFU bash Script
I provide the following bash script as an example snippet that I run for each of the 3TOFUs.
``` REMOTE_FILES="https://tails.net/tails-signing.key"
CURL="/usr/bin/curl" WGET="/usr/bin/wget --retry-on-host-error --retry-connrefused" PYTHON="/usr/bin/python3"
in tails, we must torify
if [[ "whoami" == "amnesia" ]] ; then
CURL="/usr/bin/torify ${CURL}"
WGET="/usr/bin/torify ${WGET}"
PYTHON="/usr/bin/torify ${PYTHON}"
fi
tmpDir=mktemp -d
pushd "${tmpDir}"
first get some info about our internet connection
${CURL} -s https://ifconfig.co/country | head -n1 ${CURL} -s https://check.torproject.org | grep Congratulations | head -n1
and today's date
date -u +"%Y-%m-%d"
get the file
for file in ${REMOTE_FILES}; do wget ${file} done
checksum
date -u +"%Y-%m-%d" sha256sum *
gpg fingerprint
gpg --with-fingerprint --with-subkey-fingerprint --keyid-format 0xlong * ```
Here\'s one example execution of the above script (on a debian DispVM, executed with a VPN).
``` /tmp/tmp.xT9HCeTY0y ~ Canada 2024-05-04 --2024-05-04 14:58:54-- https://tails.net/tails-signing.key Resolving tails.net (tails.net)... 204.13.164.63 Connecting to tails.net (tails.net)|204.13.164.63|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 1387192 (1.3M) [application/octet-stream] Saving to: ‘tails-signing.key’
tails-signing.key 100%[===================>] 1.32M 1.26MB/s in 1.1s
2024-05-04 14:58:56 (1.26 MB/s) - ‘tails-signing.key’ saved [1387192/1387192]
2024-05-04 8c641252767dc8815d3453e540142ea143498f8fbd76850066dc134445b3e532 tails-signing.key gpg: WARNING: no command supplied. Trying to guess what you mean ... pub rsa4096/0xDBB802B258ACD84F 2015-01-18 [C] [expires: 2025-01-25] Key fingerprint = A490 D0F4 D311 A415 3E2B B7CA DBB8 02B2 58AC D84F uid Tails developers (offline long-term identity key) <tails@boum.org> uid Tails developers <tails@boum.org> sub rsa4096/0x3C83DCB52F699C56 2015-01-18 [S] [expired: 2018-01-11] sub rsa4096/0x98FEC6BC752A3DB6 2015-01-18 [S] [expired: 2018-01-11] sub rsa4096/0xAA9E014656987A65 2015-01-18 [S] [revoked: 2015-10-29] sub rsa4096/0xAF292B44A0EDAA41 2016-08-30 [S] [expired: 2018-01-11] sub rsa4096/0xD21DAD38AF281C0B 2017-08-28 [S] [expires: 2025-01-25] sub rsa4096/0x3020A7A9C2B72733 2017-08-28 [S] [revoked: 2020-05-29] sub ed25519/0x90B2B4BD7AED235F 2017-08-28 [S] [expires: 2025-01-25] sub rsa4096/0xA8B0F4E45B1B50E2 2018-08-30 [S] [revoked: 2021-10-14] sub rsa4096/0x7BFBD2B902EE13D0 2021-10-14 [S] [expires: 2025-01-25] sub rsa4096/0xE5DBA2E186D5BAFC 2023-10-03 [S] [expires: 2025-01-25] ```
The TOFU output above shows that the release signing key from the TAILS project is a 4096-bit RSA key with a full fingerprint of \"A490 D0F4 D311 A415 3E2B B7CA DBB8 02B2 58AC D84F\". The key file itself has a sha256 hash of \"8c641252767dc8815d3453e540142ea143498f8fbd76850066dc134445b3e532\".
When doing a 3TOFU, save the output of each execution. After collecting output from all 3 executions (intentionally spread-out over 3 days or more), diff the output.
If the output of all three TOFUs match, then the confidence of the file\'s authenticity is very high.
Why do 3TOFU?
Unfortunately, many developers think that hosting their releases on a server with https is sufficient to protect their users from obtaining a maliciously-modified release. But https won\'t protect you if:
- Your DNS or publishing infrastructure is compromised (it happens), or
- An attacker has just one (subordinate) CA in the user\'s PKI root store (it happens)
Generally speaking, publishing infrastructure compromises are detected and resolved within days and MITM attacks using compromised CAs are targeted attacks (to avoid detection). Therefore, a 3TOFU verification should thwart these types of attacks.
> ⚠ Note on hashes: Unfortunately, many well-meaning developers erroneously think that cryptographic hashes provide authenticity, but cryptographic hashes do not provide authenticity \-- they provide integrity. > > Integrity checks are useful to detect corrupted data on-download; it does not protect you from maliciously altered data unless those hashes are cryptographically signed with a key whose private key isn\'t stored on the publishing infrastructure.
Improvements
There are some things you can do to further improve the confidence of the authenticity of a file you download from the internet.
Distinct Domains
If possible, download your payload from as many distinct domains as possible.
An adversary may successfully compromise the publishing infrastructure of a software project, but it\'s far less likely for them to compromise the project website (eg \'tails.net\') and their forge (eg \'github.com\') and their mastodon instance (eg \'mastodon.social\').
Use TAILS
| [!TAILS Logo](https://tech.michaelaltfield.net/2024/08/04/3tofu/) | |:--:| | TAILS is by far the best OS to use for security-critical situations. |
If you are a high-risk target (investigative journalist, activist, or political dissident) then you should definitely use TAILS for one of your TOFUs.
Signature Verification
It\'s always better to verify the authenticity of a file using cryptographic signatures than with 3TOFU.
Unfortunately, some companies like Microsoft don\'t sign their releases, so the only option to verify the authenticity of something like a Windows .iso is with 3TOFU.
Still, whenever you encounter some software that is not signed using an offline key, please do us all a favor and create a bug report asking the developer to sign their releases with PGP (or minisign or signify or something).
4TOFU
3TOFU is easy because Tor is free and most people have access to a VPN (corporate or commercial or an ssh socks proxy).
But, if you\'d like, you could also add i2p or some other proxy network into the mix (and do 4TOFU).
After almost 2 years, Privacy Guides has added a new Hardware Recommendations section to their website.
Thanks to Daniel Nathan Gray and others for implementing this new hardware guide
After almost 2 years, Privacy Guides has added a new Hardware Recommendations section to their website.
Thanks to Daniel Nathan Gray and others for implementing this new hardware guide
After almost 2 years, Privacy Guides has added a new Hardware Recommendations section to their website.
Thanks to Daniel Nathan Gray and others for implementing this new hardware guide
After almost 2 years, Privacy Guides has added a new Hardware Recommendations section to their website.
Thanks to Daniel Nathan Gray and others for implementing this new hardware guide
After almost 2 years, Privacy Guides has added a new Hardware Recommendations section to their website.
Thanks to Daniel Nathan Gray and others for implementing this new hardware guide
After almost 2 years, Privacy Guides has added a new Hardware Recommendations section to their website.
Thanks to Daniel Nathan Gray and others for implementing this new hardware guide
Hi, Michael Altfield here. I was the sysadmin for OSE from 2017-2020.
Everything OSE does is transparent, so you can just check the OSE websites to see what everyone is currently working-on. OSE contributors log their hours in a worklog called "OSE Dev". There you can quickly see who is working on what.
The above graphs show 4 contributors in the past ~10 weeks (one is me; we had some issues with the apache config recently). There's no direct link, but you can then check the wiki to see people's work logs (just search for the person's name and Log):
- https://wiki.opensourceecology.org/wiki/Marcin_Log
- https://wiki.opensourceecology.org/wiki/Catarina_Log
- https://wiki.opensourceecology.org/wiki/Alexa_Log
- https://wiki.opensourceecology.org/wiki/Maltfield_Log
I also like to look at the MediaWiki "Recent Changes" page to peak at what people are up-to as well:
I told Marcin about Lemmy back in June 2023. Another OSE contributor even created an OSE community on the slrpnk.net instance, but it appears to have been abandoned. I'll email him about this thread to see if he'll bite and publish updates in this community since there's clearly interest :)
Also, shameless plug: I started an org that's very similar in spirit to OSE called Eco-Libre, with a focus on projects to sustainably enfranchise human rights in smaller communities. We're currently accepting volunteers ;)
Personally I wouldn't run a lemmy instance because of this (and also many other concerns)
I recommend [a] letting the lemmy devs know (eg on GitHub) that this issue is preventing you from running a lemmy instance and [b] donating to alternative projects that actually care about data privacy rights.
The fines usually are a percent of revenue or millions of Euros, whichever is higher.
So if your revenue is 0 EUR then they can fine you the millions of Euros instead. The point of the “percent of revenue” alternative was for larger corporations that can get fined tens or hundreds of millions of Euros (or, as it happened to Meta, in some cases -- billions of Euros for a single GDPR violation).
The fines usually are a percent of revenue or millions of Euros, whichever is higher.
So if your revenue is 0 EUR then they can fine you the millions of Euros instead. The point of the “percent of revenue” alternative was for larger corporations that can get fined tens or hundreds of millions of Euros (or, as it happened to Meta, in some cases -- billions of Euros for a single GDPR violation).
That would be true if their instance wasn't federating. If the instance is federating, then it's downloading content from other users, even if the user isn't registered on the instance. And that content is publicly available.
So if someone discovers their content on their instance and sends them a GDPR request (eg Erasure), then they are legally required to process it.
It's definitely not impossible to contact all instances; it's a finite list. But we should have a tool to make this easier. Something that can take a given username or post, do a search, find out all the instances that it federated-to, get the contact for all of those instances, and then send-out a formal "GDPR Erasure Request" to all of the relevant admins.
Did you read the article and the feedback that you've received from your other users?
Any FOSS platform has capacity issues. I run my own FOSS projects with zero grant funds and where I'm the only developer. I understand this issue.
What we're talking about here is prioritization. My point is that you should not prioritize "new features" when existing features are a legal, moral, and grave financial risk to your community. And this isn't just "my priority" -- it's clearly been shown that this is the desired priority of your community.
Please prioritize your GDPR issues.
Very nice. Unfortunately it doesn't look like Boost is available on F-Droid.
Fortunately, in my case, my image was "orphaned" and never actually attached to a post or comment, so it wouldn't have federated.
If the image has already federated then that's a whole next level problem :(
Unfortunately, the Lemmy devs literally said it would take years to fix this issue. If you think this should be a priority for them, please advocate for them to prioritize it on GitHub:
Hi, unfortunate author here 😅
The issue happened in Jerboa. I opened a few tickets in the Jerboa app's GitHub to address this:
- jerboa #1361: UI for deleting uploaded files
- jerboa #1362: Setting to hide "upload media" button
- jerboa #1363: Add "confirm upload" step to UX
Can you please tell us which Lemmy client apps you use that store the delete token and have a UI to delete uploaded images?
This is a big problem. At the time of writing:
- Users cannot delete their images on Lemmy
- If a user deletes their account, their images don't get deleted
- There is no WUI for admins to delete images on Lemmy
- It is very difficult for admins to find & delete images on Lemmy (via the CLI)
- The Lemmy team didn't bother documenting how admins can delete images on Lemmy
How to purge images in Lemmy
pict-rs is a third-party simple image hosting service that runs along-side Lemmy for instances that allow users to upload media.
At the time of writing, there is no WUI for admins to find and delete images. You have to manually query the pict-rs database and execute an API call from the command-line. Worse: Lemmy has no documentation telling instance admins how to delete images 🤦
For the purposes of this example, let's assume you're trying to delete the following image
https://monero.town/pictrs/image/001665df-3b25-415f-8a59-3d836bb68dd1.webp
There are two API endpoints in pict-rs that can be used to delete an image
Method One: /image/delete/{delete_token}/{alias}
This API call is publicly-accessible, but it first requires you to
obtain the image's `delete_token`
The `delete_token` is first returned by Lemmy when POSTing to the
`/pictrs/image` endpoint
{
"msg":"ok",
"files":[
{
"file":"001665df-3b25-415f-8a59-3d836bb68dd1.webp",
"delete_token":"d88b7f32-a56f-4679-bd93-4f334764d381"
}
]
}
Two pieces of information are returned here:
- file (aka the "alias") is the server filename of the uploaded image
- delete_token is the token needed to delete the image
Of course, if you didn't capture this image's `delete_token` at
upload-time, then you must fetch it from the postgres DB.
First, open a shell on your running postgres container. If you installed
Lemmy with docker compose, use `docker compose ps` to get the
"SERVICE" name of your postgres host, and then enter it with
`docker exec`
docker compose ps --format "table {{.Service}}\t{{.Image}}\t{{.Name}}"
docker compose exec <docker_service_name> /bin/bash
For example:
user@host:/home/user/lemmy# docker compose ps --format "table {{.Service}}\t{{.Image}}\t{{.Name}}"
SERVICE IMAGE NAME
lemmy dessalines/lemmy:0.19.3 lemmy-lemmy-1
lemmy-ui dessalines/lemmy-ui:0.19.3 lemmy-lemmy-ui-1
pictrs docker.io/asonix/pictrs:0.5.4 lemmy-pictrs-1
postfix docker.io/mwader/postfix-relay lemmy-postfix-1
postgres docker.io/postgres:15-alpine lemmy-postgres-1
proxy docker.io/library/nginx lemmy-proxy-1
user@host:/home/user/lemmy#
user@host:/home/user/lemmy# docker compose exec postgres /bin/bash
postgres:/#
Connect to the database as the `lemmy` user
psql -U lemmy
For example
postgres:/# psql -U lemmy
psql (15.5)
Type "help" for help.
lemmy=#
Query for the image by the "alias" (the filename)
select * from image_upload where pictrs_alias = '<image_filename>';
For example
lemmy=# select * from image_upload where pictrs_alias = '001665df-3b25-415f-8a59-3d836bb68dd1.webp';
local_user_id | pictrs_alias | pictrs_delete_token | published
---------------+--------------+---------------------+-----------
1149 | 001665df-3b25-415f-8a59-3d836bb68dd1.webp | d88b7f32-a56f-4679-bd93-4f334764d381 | 2024-02-07 11:10:17.158741+00
(1 row)
lemmy=#
Now, take the `pictrs_delete_token` from the above output, and use
it to delete the image.
The following command should be able to be run on any computer connected to the internet.
curl -i "https://<instance_domain>/pictrs/image/delete/<pictrs_delete_token>/<image_filename>"
For example:
user@disp9140:~$ curl -i "https://monero.town/pictrs/image/delete/d88b7f32-a56f-4679-bd93-4f334764d381/001665df-3b25-415f-8a59-3d836bb68dd1.webp"
HTTP/2 204 No Content
server: nginx
date: Fri, 09 Feb 2024 15:37:48 GMT
vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers
cache-control: private
referrer-policy: same-origin
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 1; mode=block
X-Firefox-Spdy: h2
user@disp9140:~$
ⓘ Note: If you get an `
incorrect_login` error, then try [a] logging into the instance in your web browser and then [b] pasting the "https://<instance_domain>/pictrs/image/delete/<pictrs_delete_token>/<image_filename>" URL into your web browser.
The image should be deleted.
Method Two: /internal/purge?alias={alias}
Alternatively, you could execute the deletion directly inside the pictrs
container. This eliminates the need to fetch the `delete_token`.
First, open a shell on your running `pictrs` container. If you
installed Lemmy with docker compose, use `docker compose ps` to get
the "SERVICE" name of your postgres host, and then enter it with
`docker exec`
docker compose ps --format "table {{.Service}}\t{{.Image}}\t{{.Name}}"
docker compose exec <docker_service_name> /bin/sh
For example:
user@host:/home/user/lemmy# docker compose ps --format "table {{.Service}}\t{{.Image}}\t{{.Name}}"
SERVICE IMAGE NAME
lemmy dessalines/lemmy:0.19.3 lemmy-lemmy-1
lemmy-ui dessalines/lemmy-ui:0.19.3 lemmy-lemmy-ui-1
pictrs docker.io/asonix/pictrs:0.5.4 lemmy-pictrs-1
postfix docker.io/mwader/postfix-relay lemmy-postfix-1
postgres docker.io/postgres:15-alpine lemmy-postgres-1
proxy docker.io/library/nginx lemmy-proxy-1
user@host:/home/user/lemmy#
user@host:/home/user/lemmy# docker compose exec pictrs /bin/sh
~ $
Execute the following command inside the `pictrs` container.
wget --server-response --post-data "" --header "X-Api-Token: ${PICTRS__SERVER__API_KEY}" "http://127.0.0.1:8080/internal/purge?alias=<image_filename>"
For example:
~ $ wget --server-response --post-data "" --header "X-Api-Token: ${PICTRS__SERVER__API_KEY}" "http://127.0.0.1:8080/internal/purge?alias=001665df-3b25-415f-8a59-3d836bb68dd1.webp"
Connecting to 127.0.0.1:8080 (127.0.0.1:8080)
HTTP/1.1 200 OK
content-length: 67
connection: close
content-type: application/json
date: Wed, 14 Feb 2024 12:56:24 GMT
saving to 'purge?alias=001665df-3b25-415f-8a59-3d836bb68dd1.webp'
purge?alias=001665df 100% |*****************************************************************************************************************************************************************************************************************************| 67 0:00:00 ETA
'purge?alias=001665df-3b25-415f-8a59-3d836bb68dd1.webp' saved
~ $
ⓘ Note: There's an error in the pict-rs reference documentation. It says you can POST to `/internal/delete`, but that just returns
404 Not Found.
The image should be deleted
Further Reading
Unfortunately, it seems that the Lemmy develoeprs are not taking these moral and legal (GDPR) risks seriously (they said it may take years before they address them), and they threatened to ban me for trying to highlight the severity of this risk, get them to tag GDPR-related bugs, and to prioritize them.
- lemmy #4433: Deleted Account should delete uploaded media (pictures) too
- lemmy #4441: Users unable to delete their images (pictrs API)
- lemmy #4434: Unapproved users cannot delete their accounts/data
- lemmy #3973: Banned users cannot delete their accounts/data
- lemmy #4445: Create an interface for local users to view and remove images
- lemmy-ui #2359: Allow users to delete images they uploaded
- lemmy-ui #2360: Allow admins to view & delete uploaded images
- lemmy-ui #2361: private_message_disclaimer to include user's matrix handle
- jerboa #1361: UI for deleting uploaded files
- jerboa #1362: Setting to hide "upload media" button
- jerboa #1363: Add "confirm upload" step to UX
- lemmy-docs #293: Document image moderation
If GDPR-compliance is important to you on the fediverse, then please provide feedback to the Lemmy developers in the GitHub links above.
Attribution
This comment was copied from the following article: Nightmare on Lemmy Street (A Fediverse GDPR Horror Story)
 |
|---|
| Nightmare on Lemmy Street (A Fediverse GDPR Horror Story) |
This seems to suggest that you have to get it from lemmy when you first uploaded the image
Thanks, but I'm asking because I didn't find the reference documentation especially helpful.
It says I need the "delete token" or "alias". How do I get that for a given URL?
I'm looking for an example that describes how to construct the commands for the API calls knowing only the URL of the image.
You definitely can do that, but if you're afraid that you might stand-up and forget you're using it, then you probably shouldn't.
It's probably enough to just use the default trigger that locks your screen. Or, once you get comfortable with it, set it to shut down your computer. Most people don't need to shred their FDE keys, unless they're facing torture.
In fact, we make it difficult to use "destructive" triggers (like the LUKS Header Shredder that wipes the FDE header) and intentionally do not include the ability to switch to it in the app. To use it, you have to do a lot of extra work. So most users don't have this issue.
Why? It defaults to just locking your screen. So you stand-up, the magnetic breakaway cable separates, and then you just have to type your password...
If you're the type of person that would forget to lock your computer before standing up and walking away, then it's exactly what you'd want.
Thank you for your input, but I think it's worth mentioning that that's absolutely not true.
To be clear: I'm not asking for a no-KYC solution. I'm happy to auth with my company's official government-issued registration records, with my personal government-issued ID, etc.
I'm not aware of any regulations that require a phone number. There are regulations (eg UK's PSD2) that effectively require 2FA -- and many banks chose to implement this requirement via phone numbers.
Hopefully one day the regulations will explicitly prohibit 2FA OTPs from being transmitted at all (ie so banks are forced to use secure 2FA methods like TOTP or U2F instead of insecure methods like SMS, email, etc). But currently I'm not aware of any KYC regulations that require a phone number from the customer.
You associate everything that can be bought with cryptocurrency as a scam? It sounds like you haven't even read the post. I spent a lot of time making it easily accessible here on Lemmy. You don't even have to click the link. Just scroll-up and read :)
Yes, it's clearly disclosed in my profile that I am the founder of the BusKill project.
This is a PSA that our sale has started. I've had inquiries from members of our community asking about Black Friday sales.
10% off is barely any discount anyway.
Sorry, we're a very small open-source shop. I’ve paid myself nothing so-far. The price just barely breaks-even for the business.
All of this is explained in-detail in “The Finances” section here.
Prices would drop dramatically if we could do production runs (and actually sell) >10,000 units at a time. Currently we only sell a few cables per month. If you want to help, please tell all your security-conscious friends about BusKill :)
maltfield @monero.town I make and sell BusKill laptop kill cords. Monero is accepted.
https://michaelaltfield.net