Bug 2379903

Summary:	Moving of off /etc/pki/tls/certs/ca-bundle.crt
Product:	[Fedora] Fedora	Reporter:	Frantisek Krenzelok <fkrenzel>
Component:	perl-HTTP-Tiny	Assignee:	Michal Josef Spacek <mspacek>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	jplesnik, mspacek, perl-devel, ppisar, stig
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:
Clones:	2380121 (view as bug list)		Environment:
Last Closed:	2025-07-16 11:24:44 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Frantisek Krenzelok 2025-07-14 12:42:46 UTC

Hello in anticipation of https://fedoraproject.org/wiki/Changes/dropingOfCertPemFile fedora change proposal, which is taking effect during the fedora rawhide mass rebuild (starting 23th of July), we would like you to validate this and if applicable, consider using the file `/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem` instead of the `/etc/pki/tls/certs/ca-certificates.crt` certificate bundle which was found in the source-code.

```
./lib/HTTP/Tiny.pm:1672:        "/etc/pki/tls/certs/ca-bundle.crt",       # Fedora/RHEL
```

Comment 1 stig 2025-07-16 11:09:14 UTC

HTTP::Tiny should get the directory-hash path automatically from IO::Socket::SSL::default_ca(), so I don't believe that any changes are needed here:

$ perl -MIO::Socket::SSL -MData::Dumper -E 'say Dumper { IO::Socket::SSL::default_ca() }'
$VAR1 = {
          'SSL_ca_file' => '/etc/pki/tls/cert.pem',
          'SSL_ca_path' => '/etc/pki/tls/certs'
        };

Comment 2 Michal Josef Spacek 2025-07-16 11:24:44 UTC

I am closing the issue for now.  
Feel free to reopen this issue if there are any problems.

Comment 3 Frantisek Krenzelok 2025-07-21 12:45:07 UTC

Thanks Michal for looking into this