Project

General

Profile

Actions

Regression #17036

open

pkg.conf PKG_ENV pins SSL_CA_CERT_FILE to a Netgate-only CA bundle, making all third-party pkg repositories unusable on Plus

Added by Andre Brait 2 days ago.

Status:
New
Priority:
High
Assignee:
-
Category:
Package System
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Release Notes:
Default
Affected Plus Version:
26.03
Affected Architecture:

Description

Environment

Reproduced on two Plus releases:

- Plus 26.03.1 (plus-RELENG_26_03_1), amd64, pkg 2.7.5_3 - first-hand, this week.
Pin: /etc/ssl/netgate-ca.pem
- Plus 26.07, pkg on the libfetch backend - reported by an affected user, diagnosed and
confirmed fixed with them.
Pin: /usr/local/share/pfSense/ssl/netgate-zuul-ca.pem

Counter-example on the same OS release: Plus 26.03.1 running pkg 2.5.1 works, and shows
CAfile: /etc/ssl/netgate-ca.pem
CApath: /etc/ssl/certs/
Trust store intact throughout: /etc/ssl/certs holds 155 roots, and fetch(1)/curl(1) succeed
against the same hosts and URLs that pkg rejects.

Why now?

pkg has changed its HTTPS backend twice: libfetch before 1.20.0, libcurl from 1.20.0 through
2.6.2, and back to libfetch from 2.7.0 ("switch back to libfetch", 2.7.0 release notes).

The problem is therefore backend-scoped, not version-scoped. Under libcurl the pin was
survivable because curl retained its own default CApath beside the pinned CAfile - visible in
the 26.03.1 / pkg 2.5.1 counter-example above. Boxes break as pkg rolls forward into 2.7.x with
no configuration change of their own: the 26.03.1 box above was working on pkg 2.5.1 in the
morning and failing the same afternoon on 2.7.5_3.

Requested change

Add one line to the PKG_ENV block:

SSL_CA_CERT_PATH=/etc/ssl/certs

PKG_ENV never sets SSL_CA_CERT_PATH today, and libfetch loads the file and the path into the
same store. The Netgate pin therefore remains fully in force for Netgate's repositories - the
private CAs stay loaded, the client certificate and key are untouched, and peer verification
stays enabled - while third-party repositories can validate against public roots as they do on
CE and on stock FreeBSD.

Verified on the affected box: adding that line, either through the environment or in pkg.conf,
makes the previously failing catalogue update succeed with no other change.

Alternatives

- Apply the PKG_ENV variables with setenv(..., 0) so that an inherited SSL_CA_CERT_PATH
survives, letting callers opt in per invocation.
- Scope the pin to the Netgate repository definitions rather than the global pkg environment.

No data to display

Actions

Also available in: Atom