Interest in config option for TLS cert and key?
Hello, I have an idea for a feature that I would like to write and eventually merge into pacman. I post in this mailing list to find out if there is an interest in it before I start coding. My goal is to have a custom repository that can only be used by me. First I tried to create an ssh host in ~/.ssh/config ... ``` Host Custom Hostname custom.org User root Port 1 IdentityFile /path/to/file ``` ... and then use it /etc/pacman.conf ... ``` [custom] Server = ssh://Custom:~/path/to/repo ``` ... but that doesn't work. But https URLs do work. So if I could specify a TLS certificate that is signed by a certificate authority certificate that I control I could use a regular https URL but still be the only one with the required TLS certificate to connect. From what I saw libalpm uses libcurl. libcurl has options like `CURLOPT_SSLCERT` and `CURLOPT_SSLKEY` that can be set with `curl_easy_setopt`. Those two options could be controlled through the pacman configuration file. Maybe there is a better solution already available without changing any code that I overlooked. Maybe you have a different solution to my goal. Maybe you are a maintainer and know that such a feature is not wanted. I'm interested in hearing all these thoughts. Best regards, nibo
On 16/03/2026 3:41 am, nibo wrote:
Hello,
I have an idea for a feature that I would like to write and eventually merge into pacman. I post in this mailing list to find out if there is an interest in it before I start coding.
My goal is to have a custom repository that can only be used by me.
First I tried to create an ssh host in ~/.ssh/config ...
``` Host Custom Hostname custom.org User root Port 1 IdentityFile /path/to/file ```
... and then use it /etc/pacman.conf ...
``` [custom] Server = ssh://Custom:~/path/to/repo ```
... but that doesn't work.
But https URLs do work. So if I could specify a TLS certificate that is signed by a certificate authority certificate that I control I could use a regular https URL but still be the only one with the required TLS certificate to connect. From what I saw libalpm uses libcurl. libcurl has options like `CURLOPT_SSLCERT` and `CURLOPT_SSLKEY` that can be set with `curl_easy_setopt`. Those two options could be controlled through the pacman configuration file.
Maybe there is a better solution already available without changing any code that I overlooked. Maybe you have a different solution to my goal. Maybe you are a maintainer and know that such a feature is not wanted. I'm interested in hearing all these thoughts.
Hi, https://gitlab.archlinux.org/pacman/pacman/-/issues/261 I have had a quick look at this. It would be difficult (and possibly impossible) to support all options via a configuration file. But perhaps it would be good to select "high priority" options to support and start implementing them, and add other options when a need arises. Allan
On 2026-03-15 10:41, nibo wrote:
My goal is to have a custom repository that can only be used by me. But https URLs do work. So if I could specify a TLS certificate that is signed by a certificate authority certificate that I control I could use a regular https URL but still be the only one with the required TLS certificate to connect. From what I saw libalpm uses libcurl. libcurl has options like `CURLOPT_SSLCERT` and `CURLOPT_SSLKEY` that can be set with `curl_easy_setopt`. Those two options could be controlled through the pacman configuration file. Maybe I'm misunderstanding, but I don't think this would provide what you're looking for. it's trivial to access any site where you don't trust the CA. either bypass the error, or copy cert into your trusted cert store(this is pretty easy to do from any website, by getting the public chain from the initial request/handshake)
TLS is great for e2e encryption, and for authenticity, but it's not really functional as a authentication/authorization control. All I would have to do is `curl -k https://your.private.repo` and I'd be able to see and download any packages you had let me know if I'm not understanding what you're trying to do. Mark
Am 16.03.26 um 16:30 schrieb Mark Hegreberg:
On 2026-03-15 10:41, nibo wrote:
My goal is to have a custom repository that can only be used by me. But https URLs do work. So if I could specify a TLS certificate that is signed by a certificate authority certificate that I control I could use a regular https URL but still be the only one with the required TLS certificate to connect. From what I saw libalpm uses libcurl. libcurl has options like `CURLOPT_SSLCERT` and `CURLOPT_SSLKEY` that can be set with `curl_easy_setopt`. Those two options could be controlled through the pacman configuration file. Maybe I'm misunderstanding, but I don't think this would provide what you're looking for. it's trivial to access any site where you don't trust the CA. either bypass the error, or copy cert into your trusted cert store(this is pretty easy to do from any website, by getting the public chain from the initial request/handshake)
TLS is great for e2e encryption, and for authenticity, but it's not really functional as a authentication/authorization control. All I would have to do is `curl -k https://your.private.repo` and I'd be able to see and download any packages you had
let me know if I'm not understanding what you're trying to do.
Mark
I believe they mean to use TLS client authentication, where not only the server has a certificate, but the client too and the Server decides whether it will accept the certificate the client has. And in that case it is functional as authentication, if the server for example only accepts client certificates of a certain private CA (chain) or has a fingerprint list or something like that. Search Keywords: "TLS client authentication", "TLS client certificates", "Mutual TLS", "mTLS" -- regards, brainpower
On 3/16/26 16:41, brainpower wrote:
Am 16.03.26 um 16:30 schrieb Mark Hegreberg:
On 2026-03-15 10:41, nibo wrote:
My goal is to have a custom repository that can only be used by me. But https URLs do work. So if I could specify a TLS certificate that is signed by a certificate authority certificate that I control I could use a regular https URL but still be the only one with the required TLS certificate to connect. From what I saw libalpm uses libcurl. libcurl has options like `CURLOPT_SSLCERT` and `CURLOPT_SSLKEY` that can be set with `curl_easy_setopt`. Those two options could be controlled through the pacman configuration file. Maybe I'm misunderstanding, but I don't think this would provide what you're looking for. it's trivial to access any site where you don't trust the CA. either bypass the error, or copy cert into your trusted cert store(this is pretty easy to do from any website, by getting the public chain from the initial request/handshake)
TLS is great for e2e encryption, and for authenticity, but it's not really functional as a authentication/authorization control. All I would have to do is `curl -k https://your.private.repo` and I'd be able to see and download any packages you had
let me know if I'm not understanding what you're trying to do.
Mark
I believe they mean to use TLS client authentication, where not only the server has a certificate, but the client too and the Server decides whether it will accept the certificate the client has.
And in that case it is functional as authentication, if the server for example only accepts client certificates of a certain private CA (chain) or has a fingerprint list or something like that.
Search Keywords: "TLS client authentication", "TLS client certificates", "Mutual TLS", "mTLS"
Indeed. Client certificates *do* give you secure authenticated-only access. I wanted exactly the same, and support in pacman was considered out of scope. So I wrote `curl-inject-opt` to inject extra CURL options to requests made by pacman [1][2]. It uses an LD_PRELOAD library to modify calls to CURL and adds additional options. It doesn't support all options, but it does support client certificates and keys. I would love to have support directly in pacman, but maybe this workaround is also useful for you in the mean time. Kind regards, -- Maarten [1]: https://aur.archlinux.org/packages?O=0&K=curl-inject-opt [2]: https://github.com/de-vri-es/curl-inject-opt
But https URLs do work. So if I could specify a TLS certificate that is signed by a certificate authority certificate that I control I could use a regular https URL but still be the only one with the required TLS certificate to connect.
I meant TLS client authentication. Thank you all for your input. I will now try to get familiar with the codebase and will continue discussing the details on the relevant gitlab issues starting at #261.
Hello there, I said I will continue discussing the details on gitlab. Unfortunately my account on accounts.archlinux.org didn't get verified till now so I don't know how to participate other than here on the mailing list. With the attached patch I tried to implement the possibility to provide SSL/TLS configuration for an alpm_db_t. Please criticize and suggest if you want. I would like to be able to use TLS client authentication in pacman by using this patch or another. Best regards, nibo
Hi nibo, why is hosting your private repo (that for some reason can't be public) inside a VPN not an option for you? Regards, Oskar Am Donnerstag, 14. Mai 2026 13:40:47 CEST schrieb nibo:
Hello there,
I said I will continue discussing the details on gitlab. Unfortunately my account on accounts.archlinux.org didn't get verified till now so I don't know how to participate other than here on the mailing list. With the attached patch I tried to implement the possibility to provide SSL/TLS configuration for an alpm_db_t. Please criticize and suggest if you want. I would like to be able to use TLS client authentication in pacman by using this patch or another.
Best regards,
nibo
Hello Oskar,
why is hosting your private repo (that for some reason can't be public) inside a VPN not an option for you?
Using a VPN is definitely an option I could use and it wouldn't require a change to pacman. I recently learned about TLS client authentication and thought I would be a nice addition to the project. Best regards, nibo
participants (6)
-
Allan McRae
-
brainpower
-
Maarten de Vries
-
Mark Hegreberg
-
nibo
-
Oskar Roesler