Bug 230414 - security/py-certifi: add option to use certificate bundle from ca_root_nss
Summary: security/py-certifi: add option to use certificate bundle from ca_root_nss
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Kubilay Kocak
URL:
Keywords: feature, needs-qa
Depends on:
Blocks:
 
Reported: 2018-08-06 17:55 UTC by Sergey Akhmatov
Modified: 2018-08-21 01:46 UTC (History)
3 users (show)

See Also:


Attachments
py-certifi use CAs from ca_root_nss (1.63 KB, patch)
2018-08-06 17:55 UTC, Sergey Akhmatov
no flags Details | Diff
py-certifi use CAs from ca_root_nss (1.72 KB, patch)
2018-08-07 10:36 UTC, Sergey Akhmatov
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Akhmatov 2018-08-06 17:55:32 UTC
Created attachment 195946 [details]
py-certifi use CAs from ca_root_nss

The proposed patch adds option to use certificate bundle from security/ca_root_nss instead of one shipped with certifi.

The idea behind this patch is to add ability to trust to some extra local CAs. Such functionality is going to be added to ca_root_nss soon (I hope): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=160387

I think it would be convenient to use trusted certificates from single source.

---
QA: poudriere testport with option ON and OFF builds fine

The behavior doesn't change with option OFF.
With option ON the behavior is as expected:

>>> import certifi
>>> certifi.where()
'/usr/local/etc/ssl/cert.pem'
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2018-08-06 22:53:52 UTC
While the functional changes itself appear OK (except for hardcoding /usr/local), given the certifi project describes itself "Certifi is a carefully curated collection of Root Certificates", and further appears to lean against the addition of addition certs [1], I'm hesitant to modify the default provided certificate bundle, for POLA and matching documentation reasons, both related to user experience.

Yes, in this case the patch includes it only as an OPTION, but I think this feature may ultimately be better served as an upstream issue/pull request, similar to this request for extracting OSX trust roots [2]. There is an additional benefit here of having FreeBSD support added to an upstream project, presumably also in the documentation as such.

[1] https://github.com/certifi/python-certifi/issues/72
[2] https://github.com/certifi/python-certifi/issues/25
Comment 2 Sergey Akhmatov 2018-08-07 10:35:53 UTC
(In reply to Kubilay Kocak from comment #1)

I see your point. But the approach to use certifi as a wrapper to "system" trust store is not uncommon. E.g. OpenBSD and Debian is using it by default:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/devel/py-certifi/patches/patch-certifi_core_py?rev=1.4&content-type=text/x-cvsweb-markup
https://sources.debian.org/src/python-certifi/2018.4.16-1/debian/patches/0001-Use-Debian-provided-etc-ssl-certs-ca-certificates.cr.patch/
Is FreeBSD strictly against such approach?


The main point is not to use "system" truststore, but to be able to add local trusted certificates to certifi, and certifi doesn't seem to implement it:
https://github.com/certifi/python-certifi/issues/22
We could reach this goal if adding local CAs to store would be implemented in ca_root_nss and certifi just using it.

Maybe we should start some discussion on maillists to hear more opinions?
Comment 3 Sergey Akhmatov 2018-08-07 10:36:47 UTC
Created attachment 195973 [details]
py-certifi use CAs from ca_root_nss

Update patch to remove hardcoded /usr/local
Comment 4 Kubilay Kocak freebsd_committer freebsd_triage 2018-08-07 11:29:57 UTC
(In reply to Sergey Akhmatov from comment #2)

I wouldn't say anyone is strictly against anything, particularly since this is a specific (third-party ecosystem) case without an obvious policy/guideline. 

Having said that, not being against something doesn't automatically or necessarily mean being pro/for position a change either.

For what it's worth, it's good to have references to other OS's making similar changes.

I think this ultimately boils down to the distinction you make in your 'main point', which I understand and agree with.

It's one thing to want to extend a provided trust store (1), its another entirely to switch out a specific set with another set ((2), what is proposed here).

Also, if I understand correctly, switching certifi's store out for that provided by security/ca_root_nss, would be the first step to getting the desired feature of local extensions to that store, via bug 160387. I don't think doing (2), in order to achieve (1) is the right approach.

While I understand the value of the feature being described, I also believe that with the above context, the most important thing here is still user-expectation, and principle of least astonishment. Users/developers installing certifi would expect to get the certs/store/trust model the documentation of certifi stipulates, unless options provided (officially) by that package allowed otherwise.

I would still recommend making the case for the added value of the "extend-certifi-store" feature to upstream.