Gregor Hermann writes:

On Mon, 18 Sep 2023 17:48:33 +0200, Francesco P. Lovergine wrote:

[...] Maybe a wrapper could be tought for packages that have some optional dep on that? [...]

Given that we've had to patch only 3 packages (in pkg-perl) over the
last decades and that the patch is trivial, and given that a
Mozilla::CA package doing different things on Debian than upstream
would cause confusion, I recommend against going that way.

Let's see what others on the list say.

For example, the Mozilla::CA requirement can be removed from Alien::Build::Plugin::Fetch::HTTPTiny in libalien-build-perl and be
replaced by a dependency on ca-certificates.

https://github.com/PerlAlien/Alien-Build/blob/cfdc0e74364c05d62c50ed77345b480c93eb90ce/lib/Alien/Build/Plugin/Fetch/HTTPTiny.pm#L62

HTTP::Tiny uses the system's certificates if Mozilla::CA is not available.

https://github.com/chansen/p5-http-tiny/blob/2f17ba0a6c979b8c37feef830861eeb633484358/lib/HTTP/Tiny.pm#L1640

I've been using a personal libalien-build-perl package without
Mozilla::CA for a long time.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Sep 19, 2023 at 12:35:02PM +0200, Francesco P. Lovergine wrote:

Mmmmhhh, it's me or the idea of potentially patching 79 rev-deps on >Mozilla::CA seems not a great idea?

https://metacpan.org/module/Mozilla::CA/requires?p=1&size=100

Of course, probably some rdeps could be adaptive and skip Mozilla::CA
when not available, but anyway...

... and of course, users that use cpan/cpanm would anyway install their own Mozilla::CA
with the embedded version of certs, potentially not up-to-date with ca-certificates
at a certain point in time. Even that, not a great service for users.

--
Francesco P. Lovergine

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Sep 19, 2023 at 11:45:41AM +0200, Andreas Vögele wrote:

Gregor Hermann writes:

On Mon, 18 Sep 2023 17:48:33 +0200, Francesco P. Lovergine wrote:

[...] Maybe a wrapper could be tought for packages that have some optional dep on that? [...]

Given that we've had to patch only 3 packages (in pkg-perl) over the
last decades and that the patch is trivial, and given that a
Mozilla::CA package doing different things on Debian than upstream
would cause confusion, I recommend against going that way.

Let's see what others on the list say.

For example, the Mozilla::CA requirement can be removed from >Alien::Build::Plugin::Fetch::HTTPTiny in libalien-build-perl and be
replaced by a dependency on ca-certificates.

https://github.com/PerlAlien/Alien-Build/blob/cfdc0e74364c05d62c50ed77345b480c93eb90ce/lib/Alien/Build/Plugin/Fetch/HTTPTiny.pm#L62

HTTP::Tiny uses the system's certificates if Mozilla::CA is not available.

https://github.com/chansen/p5-http-tiny/blob/2f17ba0a6c979b8c37feef830861eeb633484358/lib/HTTP/Tiny.pm#L1640

I've been using a personal libalien-build-perl package without
Mozilla::CA for a long time.

Mmmmhhh, it's me or the idea of potentially patching 79 rev-deps on Mozilla::CA seems not a great idea?

https://metacpan.org/module/Mozilla::CA/requires?p=1&size=100

Of course, probably some rdeps could be adaptive and skip Mozilla::CA
when not available, but anyway...


--
Francesco P. Lovergine

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Francesco P. Lovergine wrote:

I would simply patch Mozilla::CA to have SSL_ca_file() returning the
Debian directory /usr/share/ca-certificates/mozilla instead of the
cacert.pem file. That would avoid to patch third-parties code that
eventually use explicitly the modules. This is compatible with the IO::Socket::SSL module.

Does it make sense?

Fedora patches Mozilla::CA: https://src.fedoraproject.org/rpms/perl-Mozilla-CA/tree/rawhide

I'd use /etc/ssl/certs/ca-certificates.crt instead of /usr/share/ca-certificates/mozilla, though.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Sep 20, 2023 at 08:06:57AM +0200, Andreas Vögele wrote:

Francesco P. Lovergine wrote:

I would simply patch Mozilla::CA to have SSL_ca_file() returning the
Debian directory /usr/share/ca-certificates/mozilla instead of the >>cacert.pem file. That would avoid to patch third-parties code that >>eventually use explicitly the modules. This is compatible with the >>IO::Socket::SSL module.

Does it make sense?

Fedora patches Mozilla::CA: >https://src.fedoraproject.org/rpms/perl-Mozilla-CA/tree/rawhide

I'd use /etc/ssl/certs/ca-certificates.crt instead of >/usr/share/ca-certificates/mozilla, though.

Yes, it makes sense for me for the reasons I already expressed. I see
they are removing the bundle already installed by previois versions
of the package (probably). And yes, for some reason we have both
the unified file and the single pems in place. Using
a single file is optional for the SSL Perl module, but it does not hurt.

If anyone had not more objections, I would manage for that solution.

--
Francesco P. Lovergine

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 20 Sep 2023 08:06:57 +0200, Andreas V�gele wrote:

Francesco P. Lovergine wrote:

I would simply patch Mozilla::CA to have SSL_ca_file() returning the
Debian directory /usr/share/ca-certificates/mozilla instead of the cacert.pem file. That would avoid to patch third-parties code that eventually use explicitly the modules. This is compatible with the IO::Socket::SSL module.
Does it make sense?

Fedora patches Mozilla::CA: https://src.fedoraproject.org/rpms/perl-Mozilla-CA/tree/rawhide
I'd use /etc/ssl/certs/ca-certificates.crt instead of /usr/share/ca-certificates/mozilla, though.

I'm still not convinced that this is actually useful but if we go
that way, I also suggest to use /etc/ssl/certs/ca-certificates.crt.

Cf. liblwp-protocol-https-perl/debian/patches/cert.patch:

(Simplified pseudo-patch)

- $ssl_opts{SSL_ca_file} = Mozilla::CA::SSL_ca_file();
+ $ssl_opts{SSL_ca_file} = '/etc/ssl/certs/ca-certificates.crt';


Cheers,
gregor

--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-

-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmULC6lfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ qgZzHw//fn7O4AxEwNX/phNH0MJZfxoSRQEdDrXhRCUsJzFoPUIBDtZN8wM2xyDf cOPTATnpWy6t/ypvMLFP3UujEO2CuH40b35RRp8QHKrg5+NZdprZmWQjXE0dnxpt NjvYR4bKzG4ANRcdyUskp/u6f82CqEIyY2zc/Qvyb3JwvKJ4CUFGmUijcapwsPqL KJ+hJtsAZACgCillhj7NbBnrMnzeEhNyqJ+jqUILUvpb4i/k5QkhYRWokKicGVvk cCxmIKpt10Iyulvo1ZgusWw0w8rci9CSE2LcrPNT3TLRKzKvOpP9LoqkRQgkYCeh loPqoHJopDzC2qBGVos/czFspVB7RgQzP/n1VlzLMamLAwo3uMSVM/K3cRiS8I3Z 3CEVlth7cQeJPua9Jr24/fX4uv2Nsnt0Ppr0E8fFHgQP0z0Z6lgaTDXg+q0dasX4 G4JfEBSc03wQ0lAuQ66/E67eALSHsExOk00BP1rypWm5tXLMrFGOhFTzZHJQ0Kwp
iss3AD+F

On Wed, Sep 20, 2023 at 05:11:27PM +0200, gregor herrmann wrote:

On Wed, 20 Sep 2023 08:06:57 +0200, Andreas Vögele wrote:

Francesco P. Lovergine wrote:

I would simply patch Mozilla::CA to have SSL_ca_file() returning the
Debian directory /usr/share/ca-certificates/mozilla instead of the
cacert.pem file. That would avoid to patch third-parties code that
eventually use explicitly the modules. This is compatible with the
IO::Socket::SSL module.
Does it make sense?

Fedora patches Mozilla::CA:
https://src.fedoraproject.org/rpms/perl-Mozilla-CA/tree/rawhide
I'd use /etc/ssl/certs/ca-certificates.crt instead of
/usr/share/ca-certificates/mozilla, though.

I'm still not convinced that this is actually useful but if we go
that way, I also suggest to use /etc/ssl/certs/ca-certificates.crt.

Cf. liblwp-protocol-https-perl/debian/patches/cert.patch:

(Simplified pseudo-patch)

- $ssl_opts{SSL_ca_file} = Mozilla::CA::SSL_ca_file();
+ $ssl_opts{SSL_ca_file} = '/etc/ssl/certs/ca-certificates.crt';

Just done in the git repo, and even updated for a minor copyright issue.

--
Francesco P. Lovergine

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)