Unannounced soname bump: openssl-pkcs11 (libp11.so.3 -> libp11.so.4) affects nextcloud-client-libs, rng-tools

[Adam Williamson]

openssl-pkcs11-0.4.19-1.fc45 -
https://bodhi.fedoraproject.org/updates/FEDORA-2026-94c710a662 - bumped
the soname of libp11 from libp11.so.3 to libp11.so.4.
soname bumps are supposed to be announced on devel@ and to maintainers
of dependent packages - https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_rawhide

Per rmdepcheck, nextcloud-client-libs and rng-tools are now
uninstallable: https://artifacts.dev.testing-farm.io/91178d76-a981-4969-ba17-2fbd9be1fc7b/
I'm CCing their maintainers. rng-tools is required by the compose
process, so this caused today's compose to fail -
https://forge.fedoraproject.org/releng/compose-tracker-issues/issues/9471#is...
As this is a critical issue, I'll use PP privs to rebuild rng-tools
(assuming it succeeds).

In future please remember to announce bumps to the soname, and co-
ordinate rebuilds and a sidetag update with the dependent package
maintainers.

Thanks!

[Adam Williamson]

On Thu, 2026-07-23 at 09:25 -0700, Adam Williamson wrote:
> openssl-pkcs11-0.4.19-1.fc45 -
> https://bodhi.fedoraproject.org/updates/FEDORA-2026-94c710a662 - bumped
> the soname of libp11 from libp11.so.3 to libp11.so.4.
> soname bumps are supposed to be announced on devel@ and to maintainers
> of dependent packages - https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_rawhide
>
> Per rmdepcheck, nextcloud-client-libs and rng-tools are now
> uninstallable: https://artifacts.dev.testing-farm.io/91178d76-a981-4969-ba17-2fbd9be1fc7b/
> I'm CCing their maintainers. rng-tools is required by the compose
> process, so this caused today's compose to fail -
> https://forge.fedoraproject.org/releng/compose-tracker-issues/issues/9471#is...
> As this is a critical issue, I'll use PP privs to rebuild rng-tools
> (assuming it succeeds).

The rng-tools rebuild failed, in a way that looks like this openssl-
pkcs11 bump is just fundamentally broken?

https://kojipkgs.fedoraproject.org/work/tasks/767/148200767/build.log

In file included from rngd_pkcs11.c:28:
/usr/include/libp11.h:28:10: fatal error: p11_ver.h: No such file or directory
   28 | #include "p11_ver.h"
      |          ^~~~~~~~~~~

/usr/include/libp11.h is part of libp11-devel - which is built from
openssl-pkcs11. It presumably should also include this p11_ver.h header
file, or depend on something else that includes it, but it does not
appear to. I don't think this is anything rng-tools can fix, I think
the libp11-devel package is just wrong. I'm going to request an untag.

[Adam Williamson]

On Thu, 2026-07-23 at 09:40 -0700, Adam Williamson wrote:
> On Thu, 2026-07-23 at 09:25 -0700, Adam Williamson wrote:
> > openssl-pkcs11-0.4.19-1.fc45 -
> > https://bodhi.fedoraproject.org/updates/FEDORA-2026-94c710a662 - bumped
> > the soname of libp11 from libp11.so.3 to libp11.so.4.
> > soname bumps are supposed to be announced on devel@ and to maintainers
> > of dependent packages - https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_rawhide
> >
> > Per rmdepcheck, nextcloud-client-libs and rng-tools are now
> > uninstallable: https://artifacts.dev.testing-farm.io/91178d76-a981-4969-ba17-2fbd9be1fc7b/
> > I'm CCing their maintainers. rng-tools is required by the compose
> > process, so this caused today's compose to fail -
> > https://forge.fedoraproject.org/releng/compose-tracker-issues/issues/9471#is...
> > As this is a critical issue, I'll use PP privs to rebuild rng-tools
> > (assuming it succeeds).
>
> The rng-tools rebuild failed, in a way that looks like this openssl-
> pkcs11 bump is just fundamentally broken?
>
> https://kojipkgs.fedoraproject.org/work/tasks/767/148200767/build.log
>
> In file included from rngd_pkcs11.c:28:
> /usr/include/libp11.h:28:10: fatal error: p11_ver.h: No such file or directory
>    28 | #include "p11_ver.h"
>       |          ^~~~~~~~~~~
>
> /usr/include/libp11.h is part of libp11-devel - which is built from
> openssl-pkcs11. It presumably should also include this p11_ver.h header
> file, or depend on something else that includes it, but it does not
> appear to. I don't think this is anything rng-tools can fix, I think
> the libp11-devel package is just wrong. I'm going to request an untag.

Ah, looks like this needs
https://github.com/OpenSC/libp11/commit/007043d355a9f7f1cd3cb6e80d16cad609fd...
.

[Jakub Jelen]

Thank you for catching this and untagging the build.

My bad, I should have double-checked the dependencies and the soname.
Unfortunately the spec file is written in a way that did not catch it.

I will get to fix that.

Jakub

On Thu, Jul 23, 2026 at 6:44 PM Adam Williamson 
wrote:
> On Thu, 2026-07-23 at 09:40 -0700, Adam Williamson wrote:
> > On Thu, 2026-07-23 at 09:25 -0700, Adam Williamson wrote:
> > > openssl-pkcs11-0.4.19-1.fc45 -
> > > https://bodhi.fedoraproject.org/updates/FEDORA-2026-94c710a662 -
>
> bumped
> > > the soname of libp11 from libp11.so.3 to libp11.so.4.
> > > soname bumps are supposed to be announced on devel@ and to maintainers
> > > of dependent packages -
>
> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_rawhide
> > > Per rmdepcheck, nextcloud-client-libs and rng-tools are now
> > > uninstallable:
>
> https://artifacts.dev.testing-farm.io/91178d76-a981-4969-ba17-2fbd9be1fc7b/
> > > I'm CCing their maintainers. rng-tools is required by the compose
> > > process, so this caused today's compose to fail -
>
> https://forge.fedoraproject.org/releng/compose-tracker-issues/issues/9471#is...
> > > As this is a critical issue, I'll use PP privs to rebuild rng-tools
> > > (assuming it succeeds).
> >
> > The rng-tools rebuild failed, in a way that looks like this openssl-
> > pkcs11 bump is just fundamentally broken?
> >
> > https://kojipkgs.fedoraproject.org/work/tasks/767/148200767/build.log
> >
> > In file included from rngd_pkcs11.c:28:
> > /usr/include/libp11.h:28:10: fatal error: p11_ver.h: No such file or
>
> directory
> > 28 | #include "p11_ver.h"
> >       |          ^~~~~~~~~~~
> >
> > /usr/include/libp11.h is part of libp11-devel - which is built from
> > openssl-pkcs11. It presumably should also include this p11_ver.h header
> > file, or depend on something else that includes it, but it does not
> > appear to. I don't think this is anything rng-tools can fix, I think
> > the libp11-devel package is just wrong. I'm going to request an untag.
>
> Ah, looks like this needs
>
> https://github.com/OpenSC/libp11/commit/007043d355a9f7f1cd3cb6e80d16cad609fd...
> .
> --
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @[e-mail]
> https://www.happyassassin.net

[Jakub Jelen]

Sounds like the so version is confusingly based on the major openssl
version so I guess this should have been caught by the openssl 4 rebuild.

Anyway, I just built the openssl-pkcs11 (libp11) in side tag
(f45-build-side-144557):

https://koji.fedoraproject.org/koji/taskinfo?taskID=148239999

Please, rebuild the rng-tools and nextcloud-client (it fails to build due
to requirement on openssl engine and is in the non-responsive maintainer
territory now):

fedpkg build --target=f45-build-side-144557

rng-tools should work without any issues (at least worked in mock for me):

fedpkg mockbuild -- --addrepo='
https://kojipkgs.fedoraproject.org/repos/f45-build-side-144557/latest/x86_64

the nextcloud-client needs removal of openssl-devel-engine and migration to
OpenSSL 4, which did not happen. Currently the build still fails:

/builddir/build/BUILD/nextcloud-client-4.0.7-build/desktop-4.0.7/src/libsync/clientsideencryption.cpp:
In member function ‘std::pair<QByteArray, OCC::PKey>
OCC::ClientSideEncryption::generateCSR(OCC::PKey, OCC::PKey)’:
/builddir/build/BUILD/nextcloud-client-4.0.7-build/desktop-4.0.7/src/libsync/clientsideencryption.cpp:2030:42:
error: invalid conversion from ‘const X509_name_st*’ to ‘X509_NAME*’ {aka
‘X509_name_st*’} [-fpermissive]
 2030 |         ret = X509_NAME_add_entry_by_txt(x509_name, v.first,
 MBSTRING_ASC, (const unsigned char*) v.second, -1, -1, 0);
      |                                          ^~~~~~~~~
      |                                          |
      |                                          const X509_name_st*
In file included from /usr/include/libp11.h:34,
                 from
/builddir/build/BUILD/nextcloud-client-4.0.7-build/desktop-4.0.7/src/libsync/clientsideencryptionprimitives.h:11,
                 from
/builddir/build/BUILD/nextcloud-client-4.0.7-build/desktop-4.0.7/src/libsync/clientsideencryption.h:11,
                 from
/builddir/build/BUILD/nextcloud-client-4.0.7-build/desktop-4.0.7/src/libsync/clientsideencryption.cpp:6:
/usr/include/openssl/x509.h:1072:43: note: initializing argument 1 of ‘int
X509_NAME_add_entry_by_txt(X509_NAME*, const char*, int, const unsigned
char*, int, int, int)’
 1072 | int X509_NAME_add_entry_by_txt(X509_NAME *name, const char *field,
int type,
      |                                ~~~~~~~~~~~^~~~

Jakub

On Fri, Jul 24, 2026 at 9:46 AM Jakub Jelen  wrote:
> Thank you for catching this and untagging the build.
>
> My bad, I should have double-checked the dependencies and the soname.
> Unfortunately the spec file is written in a way that did not catch it.
>
> I will get to fix that.
>
> Jakub
>
> On Thu, Jul 23, 2026 at 6:44 PM Adam Williamson <
> [e-mail]> wrote:
> > On Thu, 2026-07-23 at 09:40 -0700, Adam Williamson wrote:
> > > On Thu, 2026-07-23 at 09:25 -0700, Adam Williamson wrote:
> > > > openssl-pkcs11-0.4.19-1.fc45 -
> > > > https://bodhi.fedoraproject.org/updates/FEDORA-2026-94c710a662 -
> >
> > bumped
> > > > the soname of libp11 from libp11.so.3 to libp11.so.4.
> > > > soname bumps are supposed to be announced on devel@ and to
> >
> > maintainers
> > > > of dependent packages -
> >
> > https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_rawhide
> > > > Per rmdepcheck, nextcloud-client-libs and rng-tools are now
> > > > uninstallable:
> >
> > https://artifacts.dev.testing-farm.io/91178d76-a981-4969-ba17-2fbd9be1fc7b/
> > > > I'm CCing their maintainers. rng-tools is required by the compose
> > > > process, so this caused today's compose to fail -
> >
> > https://forge.fedoraproject.org/releng/compose-tracker-issues/issues/9471#is...
> > > > As this is a critical issue, I'll use PP privs to rebuild rng-tools
> > > > (assuming it succeeds).
> > >
> > > The rng-tools rebuild failed, in a way that looks like this openssl-
> > > pkcs11 bump is just fundamentally broken?
> > >
> > > https://kojipkgs.fedoraproject.org/work/tasks/767/148200767/build.log
> > >
> > > In file included from rngd_pkcs11.c:28:
> > > /usr/include/libp11.h:28:10: fatal error: p11_ver.h: No such file or
> >
> > directory
> > > 28 | #include "p11_ver.h"
> > >       |          ^~~~~~~~~~~
> > >
> > > /usr/include/libp11.h is part of libp11-devel - which is built from
> > > openssl-pkcs11. It presumably should also include this p11_ver.h header
> > > file, or depend on something else that includes it, but it does not
> > > appear to. I don't think this is anything rng-tools can fix, I think
> > > the libp11-devel package is just wrong. I'm going to request an untag.
> >
> > Ah, looks like this needs
> >
> > https://github.com/OpenSC/libp11/commit/007043d355a9f7f1cd3cb6e80d16cad609fd...
> > .
> > --
> > Adam Williamson (he/him/his)
> > Fedora QA
> > Fedora Chat: @adamwill:fedora.im | Mastodon: @[e-mail]
> > https://www.happyassassin.net

[Michael J Gruber]

Jakub Jelen via devel venit, vidit, dixit 2026-07-24 10:45:31:
> Sounds like the so version is confusingly based on the major openssl
> version so I guess this should have been caught by the openssl 4 rebuild.
>
> Anyway, I just built the openssl-pkcs11 (libp11) in side tag
> (f45-build-side-144557):
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=148239999
>
> Please, rebuild the rng-tools and nextcloud-client (it fails to build due
> to requirement on openssl engine and is in the non-responsive maintainer
> territory now):
>
> fedpkg build --target=f45-build-side-144557
>
> rng-tools should work without any issues (at least worked in mock for me):
>
> fedpkg mockbuild -- --addrepo='
> https://kojipkgs.fedoraproject.org/repos/f45-build-side-144557/latest/x86_64
>
> the nextcloud-client needs removal of openssl-devel-engine and migration to
> OpenSSL 4, which did not happen. Currently the build still fails:
>
> /builddir/build/BUILD/nextcloud-client-4.0.7-build/desktop-4.0.7/src/libsync/clientsideencryption.cpp:
> In member function ‘std::pair<QByteArray, OCC::PKey>
> OCC::ClientSideEncryption::generateCSR(OCC::PKey, OCC::PKey)’:
> /builddir/build/BUILD/nextcloud-client-4.0.7-build/desktop-4.0.7/src/libsync/clientsideencryption.cpp:2030:42:
> error: invalid conversion from ‘const X509_name_st*’ to ‘X509_NAME*’ {aka
> ‘X509_name_st*’} [-fpermissive]
>  2030 |         ret = X509_NAME_add_entry_by_txt(x509_name, v.first,
>  MBSTRING_ASC, (const unsigned char*) v.second, -1, -1, 0);
>       |                                          ^~~~~~~~~
>       |                                          |
>       |                                          const X509_name_st*
> In file included from /usr/include/libp11.h:34,
>                  from
> /builddir/build/BUILD/nextcloud-client-4.0.7-build/desktop-4.0.7/src/libsync/clientsideencryptionprimitives.h:11,
>                  from
> /builddir/build/BUILD/nextcloud-client-4.0.7-build/desktop-4.0.7/src/libsync/clientsideencryption.h:11,
>                  from
> /builddir/build/BUILD/nextcloud-client-4.0.7-build/desktop-4.0.7/src/libsync/clientsideencryption.cpp:6:
> /usr/include/openssl/x509.h:1072:43: note: initializing argument 1 of ‘int
> X509_NAME_add_entry_by_txt(X509_NAME*, const char*, int, const unsigned
> char*, int, int, int)’
>  1072 | int X509_NAME_add_entry_by_txt(X509_NAME *name, const char *field,
> int type,
>       |                                ~~~~~~~~~~~^~~~

FTR:

There's an easy fix for that one, which can be backported. The more
severe problem is the lack of engine support. Even on its develop
branch (34.something), nextcloud-client includes openssl/engine.h.

Now, curiously, nextcloud-client 4.0.11 (with the const fix, engine dep
removed) builds until this one:

/usr/bin/ld.bfd: ../../bin/libnextcloudsync.so.4.0.11: undefined reference to `ENGINE_get_default_RSA'

Does this mean we still have the header in Fedora's openssl, but not the
symbol in the lib?

Is Fedora doing something different in openssl compared to upstream?
Otherwise every distro would face the same problem as we do.

Michael

[Dmitry Belyavskiy]

Hello,

AFAICS, Fedora doesn't do anythings specific to engine

On Fri, Jul 24, 2026 at 12:42 PM Michael J Gruber 
wrote:
> Jakub Jelen via devel venit, vidit, dixit 2026-07-24 10:45:31:
> > Sounds like the so version is confusingly based on the major openssl
> > version so I guess this should have been caught by the openssl 4 rebuild.
> >
> > Anyway, I just built the openssl-pkcs11 (libp11) in side tag
> > (f45-build-side-144557):
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=148239999
> >
> > Please, rebuild the rng-tools and nextcloud-client (it fails to build due
> > to requirement on openssl engine and is in the non-responsive maintainer
> > territory now):
> >
> > fedpkg build --target=f45-build-side-144557
> >
> > rng-tools should work without any issues (at least worked in mock for
>
> me):
> > fedpkg mockbuild -- --addrepo='
>
> https://kojipkgs.fedoraproject.org/repos/f45-build-side-144557/latest/x86_64
> > the nextcloud-client needs removal of openssl-devel-engine and migration
>
> to
> > OpenSSL 4, which did not happen. Currently the build still fails:
>
> /builddir/build/BUILD/nextcloud-client-4.0.7-build/desktop-4.0.7/src/libsync/clientsideencryption.cpp:
> > In member function ‘std::pair<QByteArray, OCC::PKey>
> > OCC::ClientSideEncryption::generateCSR(OCC::PKey, OCC::PKey)’:
>
> /builddir/build/BUILD/nextcloud-client-4.0.7-build/desktop-4.0.7/src/libsync/clientsideencryption.cpp:2030:42:
> > error: invalid conversion from ‘const X509_name_st*’ to ‘X509_NAME*’ {aka
> > ‘X509_name_st*’} [-fpermissive]
> >  2030 |         ret = X509_NAME_add_entry_by_txt(x509_name, v.first,
> >  MBSTRING_ASC, (const unsigned char*) v.second, -1, -1, 0);
> >       |                                          ^~~~~~~~~
> >       |                                          |
> >       |                                          const X509_name_st*
> > In file included from /usr/include/libp11.h:34,
> >                  from
>
> /builddir/build/BUILD/nextcloud-client-4.0.7-build/desktop-4.0.7/src/libsync/clientsideencryptionprimitives.h:11,
> >              from
>
> /builddir/build/BUILD/nextcloud-client-4.0.7-build/desktop-4.0.7/src/libsync/clientsideencryption.h:11,
> >              from
>
> /builddir/build/BUILD/nextcloud-client-4.0.7-build/desktop-4.0.7/src/libsync/clientsideencryption.cpp:6:
> > /usr/include/openssl/x509.h:1072:43: note: initializing argument 1 of
>
> ‘int
> > X509_NAME_add_entry_by_txt(X509_NAME*, const char*, int, const unsigned
> > char*, int, int, int)’
> >  1072 | int X509_NAME_add_entry_by_txt(X509_NAME *name, const char
>
> *field,
> > int type,
> >       |                                ~~~~~~~~~~~^~~~
>
> FTR:
>
> There's an easy fix for that one, which can be backported. The more
> severe problem is the lack of engine support. Even on its develop
> branch (34.something), nextcloud-client includes openssl/engine.h.
>
> Now, curiously, nextcloud-client 4.0.11 (with the const fix, engine dep
> removed) builds until this one:
>
> /usr/bin/ld.bfd: ../../bin/libnextcloudsync.so.4.0.11: undefined reference
> to `ENGINE_get_default_RSA'
>
> Does this mean we still have the header in Fedora's openssl, but not the
> symbol in the lib?
>
> Is Fedora doing something different in openssl compared to upstream?
> Otherwise every distro would face the same problem as we do.
> Michael
>
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it:
> https://forge.fedoraproject.org/infra/tickets/issues/new