Project

General

Profile

Actions

Regression #14876

closed

``ca_setup_trust_store()`` behavior conflicts with ``certctl``

Added by Lev Prokofev 6 months ago. Updated 6 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Certificates
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
23.09
Release Notes:
Force Exclusion
Affected Version:
Affected Architecture:

Description

When you add a commit ID, it generates a proper link, for example, id 01d6aeb62f876fc9b6f9e1083e7586b1866c725b

but the package fails to fetch the content.

Package version 2.2.6

tested on

23.09-BETA (amd64)
built on Fri Oct 13 6:00:00 UTC 2023
FreeBSD 14.0-CURRENT

Files

Actions #1

Updated by Danilo Zrenjanin 6 months ago

  • Status changed from New to Confirmed

I can confirm this behavior.

23.09-BETA (amd64)
built on Fri Oct 13 6:00:00 UTC 2023
FreeBSD 14.0-CURRENT
Actions #2

Updated by Christopher Cope 6 months ago

It looks to be related to SSL, disabling curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true); in the download_file function allows it to fetch successfully.

Since there aren't any CA certificates at /etc/ssl/certs/, in the beta or 23.05.1, this seems to be an issue with the ones specified at build.

This would most likely affect more than just the system patches.

Actions #3

Updated by Jim Pingle 6 months ago

  • Project changed from pfSense Packages to pfSense
  • Subject changed from System_Patches fails to fetch a commit content. to ``ca_setup_trust_store()`` behavior conflicts with ``certctl``
  • Category changed from System Patches to Certificates
  • Assignee set to Jim Pingle
  • Target version set to 2.8.0
  • Plus Target Version set to 23.09
  • Release Notes set to Default

This is really a base system issue and likely the same root cause as other issues we've seen.

certctl rehash is writing its list of trusted certificates to /etc/ssl/certs which is also where the certificate manager writes its trusted CA certificates in ca_setup_trust_store(). The problem is that ca_setup_trust_store() removes all of the *.0 files from that directory before writing its own.

The quickest fix is to have that function re-run certctl rehash after it's done, but that may not be the best long-term fix. Ideally we should be writing our own CA certs elsewhere also also feeding them through certctl, though a quick attempt at using a custom directory for that didn't appear to work properly for whatever reason.

We may want to go the quick route for now and work on a better fix for the next release.

Actions #4

Updated by Jim Pingle 6 months ago

  • Release Notes changed from Default to Force Exclusion
Actions #5

Updated by Jim Pingle 6 months ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100
Actions #6

Updated by Danilo Zrenjanin 6 months ago

It works fine on:

23.09.b.20231018.0600

I am marking this ticket as resolved.

Actions #7

Updated by Jim Pingle 6 months ago

  • Status changed from Feedback to Resolved
Actions #8

Updated by Jim Pingle 6 months ago

  • Target version changed from 2.8.0 to 2.7.1
Actions

Also available in: Atom PDF