in our application we use request library requests==2.32.3 which is latest as of now. when we use latest request library it is not fetching/updating the latest certifi package. Current certifi package is certifi==2024.2.2 and the vulerability got fixed in certifi==2024.8.30 or above.
so our doubt is on FreeBSD OS when we used request=2.32.3 it is able to update the certifi to latest but on linux/windows when we use the same request version why it is not upgrading to latest version? how can we resolve this high vulnerability issue.
This will entirely depend on where youâre getting certifi from, if youâre using PyPI (like with pip, poetry, uv, etc) then youâd upgrade using python -m pip --upgrade certifi. If youâre getting certifi from FreeBSD OSâs package manager then you would upgrade using that package management tool. If itâs not available yet there, then you need to contact the FreeBSD maintainers of that package distribution (not the certifi maintainers).
The key there is --upgrade-strategy=eager; by default, pip will not update transitive dependencies unless the package(s) it is installing have a lower bound that is higher than what is already installed.
On these OS (Windows, Debian, Fedora, RHEL, etc) the OS manages the TLS certificates for you. Just as you found with FreeBSD.
I think its only macOS where I need to ensure that certifi is up to date. That will be until someone figures out how to use the certificate store managed by Apple on macOS I understand.
actually there is one security vulnerability on certifi ( CVE-2024-39689) where we need to upgrade to 2024 08 30 version. Now we are at 2024 2 2 version.
so as it is transitive dependent package of request package we moved the request package to latest version 2.32.3 but it didnt moved the certifi package on few OS.
our application is not UI based just sdk/API based application and we create executable file.
we dont directly use the certifi module in our application and we do import request alone in our code.
so is this certifi package gets affected if we dont upgrade to latest version?
In your possition I would manage the trust store on an OS by OS basis. That will mean that you need to identify the trust store that is used and update it using the OS specific or PyPI mechanism as appropiate. Do not assume that certifi is the trust store used.
For example on most linux distros the distro manages the trust store and I think certifi may well be ignored.
we just use the request library and dont use the certifi package but because of dependency certifi is getting installed, so our point is we dont use any trust store in our code and while making https request calls as well we dont specify any certifi imports.
in this case are we affected by this cerifi implictly? are we affected here if we dont upgrade to newer certifi version
I looked at the certifi core that is installed from the Fedora RPM.
Its patched to do this:
$ more /usr/lib/python3.12/site-packages/certifi/core.py
"""
certifi.py
~~~~~~~~~~
This module returns the installation location of cacert.pem or its contents.
"""
# The RPM-packaged certifi always uses the system certificates
def where() -> str:
return '/etc/pki/tls/certs/ca-bundle.crt'
def contents() -> str:
with open(where(), encoding='utf=8') as data:
return data.read()
If you are on a RHEL or Fedora system the certifi dependency is installed, but uses the OS managed trust store.
You will need to check specifics on each OS you use.
when i checked on windows its bit different
_CACERT_CTX = as_file(files(âcertifiâ).joinpath(âcacert.pemâ))
_CACERT_PATH = str(_CACERT_CTX.enter())
But our only concern is if we are not using this explicitly still will it be referred here?
i could see list of root certs in the cacert.pem file. only thing is we are not referring this path (cacert.pem) path in our code when making the request calls
example
requests_session = requests.Session()
verify_ssl = false or path of the certs which is not certifi path
response = requests_session.post(url, headers=rest_headers, cookies=rest_cookies, json=request_body,
verify=verify_ssl, timeout= 10)
We dont use the certifi methods like where / contents / path anywhere when we make a request call
so is it still affected ?
what i m trying to say is in the request calls. we are not specifying the certifi package path explicitly so will that be used by the requests module. and one more thing is we are specifying verify=False where in the documentation of the requests it mentioned as it will not verify the server TLS certs.
param verify: (optional) Either a boolean, in which case it controls whether we verify
the serverâs TLS certificate, or a string, in which case it must be a path
to a CA bundle to use. Defaults to ``True`
What we are saying is that youâll need to audit the code if you want to be certain. You canât expect to base a security decision on advice from the internet where the people giving the advice donât have all the information about your app.
I donât honestly understand why you donât simply use the latest version of certifi. Youâve been given advice on how to do that. So presumably thereâs some constraint youâre not explaining that stops you doing that - which is yet more information that we donât know about your appâŚ
we are not deciding to get away from the fix or something. we need to fix this for sure but we have one release next week and we need to create builds and test again and provide them without any breakfixes. already test cycle is completed for this release. So wanted to check the impact of the issue on our application.
we wanted to understand how the request module, if we dont specify the certifi implicitly and if we use verify=False is this issue still applicable so that we can get sometime for the next release which is in december
