Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#895089: postfix: Please replace 'c_rehash' with 'openssl rehash'
131 views
Skip to first unread message
Sven Joachim
Jan 20, 2023, 4:10:04 PM1/20/23
to
Control: severity -1 important
Control: tags -1 patch
On 2018-04-07 00:48 +0200, Sebastian Andrzej Siewior wrote:
> Source: postfix
> Version: 3.3.0-1
> Severity: normal
> Tags: sid buster
> User: pkg-open...@lists.alioth.debian.org
> Usertags: c_rehash
>
> This package is using the c_rehash command which is part of the
> openssl package. The c_rehash script is considered by upstream as a
> fallback script and will disappear at some point. The recommended way
> is to use the "openssl rehash" command instead which appeared in
> 1.1.0. Please make sure that this package does not use the c_rehash
> command anymore.
>
> The "openssl rehash" command creates half that many symlinks (one per
> certificate instead of two) because it uses only the newer hash.
> There is also the -compat option which creates both symlinks (and
> behaves like c_rehash currently does). The hash changed from md5 to
> sha1 during the 0.9.8 to 1.0.0 transition so I doubt that the
> "compat" mode will be required.
This is now causing real problems in Bookworm. At least two people,
namely Charles Curley (CC'ed) and myself, have experienced long delays
in the postfix startup process, because the hashes get recomputed on
_every_ start. In Charles' case this even exceeded the default systemd
timeout of 90 seconds. See the thread starting at [1] for details.
Changing 'c_rehash' to 'openssl rehash' in
/usr/lib/postfix/configure-instance.sh reduced the time of
"systemctl restart postfix.service" on my laptop from ~30 seconds to 2,
I have attached at patch for your convenience.
> Should the c_rehash script be mentioned in the source code or script
> of this package but is not used during the build process or in the
> final package then feel free to close the bug saying so.
There are more occurrences of c_rehash in the current source code, but
only in documentation and comments, so it should not be necessary to
change them.
Cheers,
Sven
1. https://lists.debian.org/debian-user/2023/01/threads.html#00294
Control: tags -1 patch
On 2018-04-07 00:48 +0200, Sebastian Andrzej Siewior wrote:
> Source: postfix
> Version: 3.3.0-1
> Severity: normal
> Tags: sid buster
> User: pkg-open...@lists.alioth.debian.org
> Usertags: c_rehash
>
> This package is using the c_rehash command which is part of the
> openssl package. The c_rehash script is considered by upstream as a
> fallback script and will disappear at some point. The recommended way
> is to use the "openssl rehash" command instead which appeared in
> 1.1.0. Please make sure that this package does not use the c_rehash
> command anymore.
>
> The "openssl rehash" command creates half that many symlinks (one per
> certificate instead of two) because it uses only the newer hash.
> There is also the -compat option which creates both symlinks (and
> behaves like c_rehash currently does). The hash changed from md5 to
> sha1 during the 0.9.8 to 1.0.0 transition so I doubt that the
> "compat" mode will be required.
This is now causing real problems in Bookworm. At least two people,
namely Charles Curley (CC'ed) and myself, have experienced long delays
in the postfix startup process, because the hashes get recomputed on
_every_ start. In Charles' case this even exceeded the default systemd
timeout of 90 seconds. See the thread starting at [1] for details.
Changing 'c_rehash' to 'openssl rehash' in
/usr/lib/postfix/configure-instance.sh reduced the time of
"systemctl restart postfix.service" on my laptop from ~30 seconds to 2,
I have attached at patch for your convenience.
> Should the c_rehash script be mentioned in the source code or script
> of this package but is not used during the build process or in the
> final package then feel free to close the bug saying so.
There are more occurrences of c_rehash in the current source code, but
only in documentation and comments, so it should not be necessary to
change them.
Cheers,
Sven
1. https://lists.debian.org/debian-user/2023/01/threads.html#00294
Scott Kitterman
Jan 20, 2023, 6:50:04 PM1/20/23
to
On Friday, January 20, 2023 3:58:07 PM EST you wrote:
> Control: severity -1 important
> Control: tags -1 patch
Thanks. Patch is committed in git. I expect 3.7.4 out this weekend and this
> Control: severity -1 important
> Control: tags -1 patch
will be included when I upload that.
Scott K
0 new messages