Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #17508 > unrolled thread

hashlib and sha384

Started byRene Engelhard <rene@debian.org>
First post2026-05-31 10:40 +0200
Last post2026-05-31 16:40 +0200
Articles 6 — 2 participants

Back to article view | Back to linux.debian.maint.python

Contents

  hashlib and sha384 Rene Engelhard <rene@debian.org> - 2026-05-31 10:40 +0200
    Re: hashlib and sha384 Andrey Rakhmatullin <wrar@debian.org> - 2026-05-31 10:50 +0200
      Re: hashlib and sha384 Rene Engelhard <rene@debian.org> - 2026-05-31 11:10 +0200
        Re: hashlib and sha384 Andrey Rakhmatullin <wrar@debian.org> - 2026-05-31 11:40 +0200
          Re: hashlib and sha384 Rene Engelhard <rene@debian.org> - 2026-05-31 13:30 +0200
            Re: hashlib and sha384 Andrey Rakhmatullin <wrar@debian.org> - 2026-05-31 16:40 +0200

#17508 — hashlib and sha384

FromRene Engelhard <rene@debian.org>
Date2026-05-31 10:40 +0200
Subjecthashlib and sha384
Message-ID<N0JS9-9dZ8-1@gated-at.bofh.it>
Hi,

while trying to get python-xmlsec in shape for xmlsec1 1.3.11 (which will be a transition, and one needed for openssl 4.0.0) I came about the following

After applying the support patch to 1.3.17 - see ##1138515 - (thanks Alexandre for doing the upgrade in the archive so quick) I get a passing test where it segfaulted before
but

tests/test_xmlsec.py .                                                   [100%]Traceback (most recent call last):
   File "<frozen runpy>", line 198, in _run_module_as_main
   File "<frozen runpy>", line 88, in _run_code
   File "/usr/lib/python3/dist-packages/pytest/__main__.py", line 9, in <module>
     raise SystemExit(pytest.console_main())
                      ~~~~~~~~~~~~~~~~~~~^^
   File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 223, in console_main
     code = main()
   File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 199, in main
     ret: ExitCode | int = config.hook.pytest_cmdline_main(config=config)
                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^
   File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 512, in __call__
     return self._hookexec(self.name, self._hookimpls.copy(), kwargs, firstresult)
            ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 120, in _hookexec
     return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
            ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 167, in _multicall
     raise exception
   File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 121, in _multicall
     res = hook_impl.function(*args)
   File "/usr/lib/python3/dist-packages/_pytest/main.py", line 365, in pytest_cmdline_main
     return wrap_session(config, _main)
   File "/usr/lib/python3/dist-packages/_pytest/main.py", line 353, in wrap_session
     config.hook.pytest_sessionfinish(
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
         session=session, exitstatus=session.exitstatus
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     )
     ^
   File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 512, in __call__
     return self._hookexec(self.name, self._hookimpls.copy(), kwargs, firstresult)
            ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 120, in _hookexec
     return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
            ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 167, in _multicall
     raise exception
   File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 139, in _multicall
     teardown.throw(exception)
     ~~~~~~~~~~~~~~^^^^^^^^^^^
   File "/usr/lib/python3/dist-packages/_pytest/logging.py", line 873, in pytest_sessionfinish
     return (yield)
             ^^^^^
   File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 152, in _multicall
     teardown.send(result)
     ~~~~~~~~~~~~~^^^^^^^^
   File "/usr/lib/python3/dist-packages/_pytest/terminal.py", line 970, in pytest_sessionfinish
     self.config.hook.pytest_terminal_summary(
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
         terminalreporter=self, exitstatus=exitstatus, config=self.config
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     )
     ^
   File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 512, in __call__
     return self._hookexec(self.name, self._hookimpls.copy(), kwargs, firstresult)
            ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 120, in _hookexec
     return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
            ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 167, in _multicall
     raise exception
   File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 139, in _multicall
     teardown.throw(exception)
     ~~~~~~~~~~~~~~^^^^^^^^^^^
   File "/usr/lib/python3/dist-packages/_pytest/terminal.py", line 992, in pytest_terminal_summary
     return (yield)
             ^^^^^
   File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 139, in _multicall
     teardown.throw(exception)
     ~~~~~~~~~~~~~~^^^^^^^^^^^
   File "/usr/lib/python3/dist-packages/_pytest/warnings.py", line 109, in pytest_terminal_summary
     return (yield)
             ^^^^^
   File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 121, in _multicall
     res = hook_impl.function(*args)
   File "/usr/lib/python3/dist-packages/_hypothesis_pytestplugin.py", line 400, in pytest_terminal_summary
     from hypothesis.internal.observability import _WROTE_TO
   File "/usr/lib/python3/dist-packages/hypothesis/__init__.py", line 20, in <module>
     from hypothesis._settings import HealthCheck, Phase, Verbosity, settings
   File "/usr/lib/python3/dist-packages/hypothesis/_settings.py", line 35, in <module>
     from hypothesis.internal.conjecture.providers import AVAILABLE_PROVIDERS
   File "/usr/lib/python3/dist-packages/hypothesis/internal/conjecture/providers.py", line 37, in <module>
     from hypothesis.internal.conjecture.choice import (
     ...<6 lines>...
     )
   File "/usr/lib/python3/dist-packages/hypothesis/internal/conjecture/choice.py", line 24, in <module>
     from hypothesis.internal.conjecture.utils import identity
   File "/usr/lib/python3/dist-packages/hypothesis/internal/conjecture/utils.py", line 69, in <module>
     SAMPLE_IN_SAMPLER_LABEL = calc_label_from_name("a sample() in Sampler")
   File "/usr/lib/python3/dist-packages/hypothesis/internal/conjecture/utils.py", line 35, in calc_label_from_name
     hashed = hashlib.sha384(name.encode()).digest()
              ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^
_hashlib.UnsupportedDigestmodError: unsupported hash type sha384

happens. (for both 3.13 and 3.14)

 From what I read in https://docs.python.org/3/library/hashlib.html sha384 should have been supported in python anyways and
xmlsec1s build has
checking for SHA384 support... yes
(if it even matters, python3s _hashlib doesn't use xmlsec..)

Am I missing something obvious?

Any idea on why this could fail?

Regards,

Rene

[toc] | [next] | [standalone]

#17509

FromAndrey Rakhmatullin <wrar@debian.org>
Date2026-05-31 10:50 +0200
Message-ID<N0K1P-9e2F-3@gated-at.bofh.it>
In reply to#17508

[Multipart message — attachments visible in raw view] — view raw

On Sun, May 31, 2026 at 10:31:48AM +0200, Rene Engelhard wrote:
>  File "/usr/lib/python3/dist-packages/hypothesis/internal/conjecture/utils.py", line 35, in calc_label_from_name
>    hashed = hashlib.sha384(name.encode()).digest()
>             ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^
>_hashlib.UnsupportedDigestmodError: unsupported hash type sha384
>
>happens. (for both 3.13 and 3.14)
>
>From what I read in https://docs.python.org/3/library/hashlib.html sha384 should have been supported in python anyways and
>xmlsec1s build has
>checking for SHA384 support... yes
>(if it even matters, python3s _hashlib doesn't use xmlsec..)

Considering that sha384(b'').digest() works for me in sid Python you may 
want to describe your environment better. E.g. do you have anything from 
experimental installed (like the aforementioned openssl 4)? Is it a clean chroot?

>Am I missing something obvious?

No, to my knowledge.


-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#17510

FromRene Engelhard <rene@debian.org>
Date2026-05-31 11:10 +0200
Message-ID<N0Klc-9eqb-7@gated-at.bofh.it>
In reply to#17509
Hi,

Am 31.05.26 um 10:41 schrieb Andrey Rakhmatullin:
> On Sun, May 31, 2026 at 10:31:48AM +0200, Rene Engelhard wrote:
>>  File "/usr/lib/python3/dist-packages/hypothesis/internal/conjecture/utils.py", line 35, in calc_label_from_name
>>    hashed = hashlib.sha384(name.encode()).digest()
>>             ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^
>> _hashlib.UnsupportedDigestmodError: unsupported hash type sha384
>>
>> happens. (for both 3.13 and 3.14)
>>
>> From what I read in https://docs.python.org/3/library/hashlib.html sha384 should have been supported in python anyways and
>> xmlsec1s build has
>> checking for SHA384 support... yes
>> (if it even matters, python3s _hashlib doesn't use xmlsec..)
>
> Considering that sha384(b'').digest() works for me in sid Python you may want to describe your environment better. E.g. do you have anything from experimental installed (like the aforementioned openssl 4)? Is it a clean chroot?

all kinds of build-depends of LO (and other packages) as in my standard systemd-nspawn "working sid machine".

(and yes, xmlsec1 from experimental, since that is the point of this test.,.. No, no openssl 4 yet.)


Indeed it works in a clean deboostrap unstable + apt build-dep python-xmlsec + add experimental  to s.l. + apt -t experimental libxmlsec1-dev chroot...


Regards,


Rene

[toc] | [prev] | [next] | [standalone]

#17511

FromAndrey Rakhmatullin <wrar@debian.org>
Date2026-05-31 11:40 +0200
Message-ID<N0KOe-9eAb-7@gated-at.bofh.it>
In reply to#17510

[Multipart message — attachments visible in raw view] — view raw

On Sun, May 31, 2026 at 11:07:08AM +0200, Rene Engelhard wrote:
>>> File "/usr/lib/python3/dist-packages/hypothesis/internal/conjecture/utils.py", line 35, in calc_label_from_name
>>>   hashed = hashlib.sha384(name.encode()).digest()
>>>            ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^
>>>_hashlib.UnsupportedDigestmodError: unsupported hash type sha384
>>>
>>>happens. (for both 3.13 and 3.14)
>>>
>>>From what I read in https://docs.python.org/3/library/hashlib.html sha384 should have been supported in python anyways and
>>>xmlsec1s build has
>>>checking for SHA384 support... yes
>>>(if it even matters, python3s _hashlib doesn't use xmlsec..)
>>
>>Considering that sha384(b'').digest() works for me in sid Python you may want to describe your environment better. E.g. do you have anything from experimental installed (like the aforementioned openssl 4)? Is it a clean chroot?

1:
>all kinds of build-depends of LO (and other packages) as in my standard systemd-nspawn "working sid machine".
>
>(and yes, xmlsec1 from experimental, since that is the point of this test.,.. No, no openssl 4 yet.)

2:
>Indeed it works in a clean deboostrap unstable + apt build-dep python-xmlsec + add experimental  to s.l. + apt -t experimental libxmlsec1-dev chroot...

Are the only differences between 1 and 2 that 1 has some more build-deps 
installed? That's weird.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#17512

FromRene Engelhard <rene@debian.org>
Date2026-05-31 13:30 +0200
Message-ID<N0MwF-9fLu-5@gated-at.bofh.it>
In reply to#17511
Hi,

Am 31.05.26 um 11:30 schrieb Andrey Rakhmatullin:
> On Sun, May 31, 2026 at 11:07:08AM +0200, Rene Engelhard wrote:
>>>>  File "/usr/lib/python3/dist-packages/hypothesis/internal/conjecture/utils.py", line 35, in calc_label_from_name
>>>>    hashed = hashlib.sha384(name.encode()).digest()
>>>>             ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^
>>>> _hashlib.UnsupportedDigestmodError: unsupported hash type sha384
>>>>
>>>> happens. (for both 3.13 and 3.14)
>>>>
>>>> From what I read in https://docs.python.org/3/library/hashlib.html sha384 should have been supported in python anyways and
>>>> xmlsec1s build has
>>>> checking for SHA384 support... yes
>>>> (if it even matters, python3s _hashlib doesn't use xmlsec..)
>>>
>>> Considering that sha384(b'').digest() works for me in sid Python you may want to describe your environment better. E.g. do you have anything from experimental installed (like the aforementioned openssl 4)? Is it a clean chroot?
>
> 1:
>> all kinds of build-depends of LO (and other packages) as in my standard systemd-nspawn "working sid machine".
>>
>> (and yes, xmlsec1 from experimental, since that is the point of this test.,.. No, no openssl 4 yet.)
>
> 2:
>> Indeed it works in a clean deboostrap unstable + apt build-dep python-xmlsec + add experimental  to s.l. + apt -t experimental libxmlsec1-dev chroot...
>
> Are the only differences between 1 and 2 that 1 has some more build-deps installed? That's weird.
It is.

But I can reproduce it with the following:

- debootstrap clean unstable, add deb-src (and mount /proc)

- apt build-dep python-xmlsec

works

- add experimental  to s.l. + apt -t experimental libxmlsec1-dev

works (with the mentioned patch)

- apt build-dep libreoffice

still works

- apt build-dep apache-arrow [1]

-> boom


Regards,


Rene

[1] http://people.debian.org/~rene/apache-arrow-apt-build-dep.log

[toc] | [prev] | [next] | [standalone]

#17513

FromAndrey Rakhmatullin <wrar@debian.org>
Date2026-05-31 16:40 +0200
Message-ID<N0Pux-9hHl-3@gated-at.bofh.it>
In reply to#17512

[Multipart message — attachments visible in raw view] — view raw

I can now repdocue and somewhat minimize it but I didn't find the reason.

How to reproduce it: 
1. Get python-xmlsec 1.3.17-2 (currently in incoming).
2. Add B-D: libxmlsec1-dev (= 1.3.11-1) (currently in experimental, so 
adjust your build command accordingly).
3. Add B-D: python3-pytest-arraydiff.
4. Build.

None of python3-pytest-arraydiff is actually needed for this, you can 
replace all of /usr/lib/python3/dist-packages/pytest_arraydiff/plugin.py 
with "import hashlib".

And the failing test is test_init_shutdown_module in tests/test_xmlsec.py 
which does "xmlsec.init(); xmlsec.shutdown()" which (especially the 
comment in it) sounds like it *could* be problematic, whatever that 
actually does, if you want to use OpenSSL after it.

So it looks like three things are required: libxmlsec1-dev from experimental,
importing hashlib early enough, and running that test. This doesn't answer 
what to do though.

-- 
WBR, wRAR

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web