Acknowledgement sent
to Steve Langasek <[email protected]>:
New Bug report received and forwarded. Copy sent to Debian GnuTLS Maintainers <[email protected]>.
(Wed, 19 Oct 2011 22:48:05 GMT) (full text, mbox, link).
Source: p11-kit
Version: 0.7-2
Severity: important
User: [email protected]
Usertags: origin-ubuntu precise
Hi Andreas,
I see that the p11-kit package in unstable is converted for multiarch.
Great to see! However, it looks like libp11-kit0 is meant to integrate with
pkcs modules from other packages, all of which currently install to
/usr/lib/pkcs11 - whereas because the library is multiarched, it only looks
in /usr/lib/$(DEB_HOST_MULTIARCH)/pkcs11, and will never find these
modules.
Should libp11-kit0 declare a Breaks: against the versions of these packages
which install to /usr/lib/pkcs11, and a transition done? Or should
libp11-kit0 be patched to support looking up modules in both locations?
For reference, here is the list of packages affected according to the
Contents files for the archive:
beid-common
coolkey
gnome-keyring
libopencryptoki0
opencryptoki
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/[email protected][email protected]
Acknowledgement sent
to Andreas Metzler <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <[email protected]>.
(Thu, 20 Oct 2011 18:21:03 GMT) (full text, mbox, link).
Subject: Re: Bug#645959: p11-kit looks in /usr/lib/$arch/pkcs11 for
modules, nothing installs there?
Date: Thu, 20 Oct 2011 20:18:10 +0200
On 2011-10-20 Steve Langasek <[email protected]> wrote:
[...]
> I see that the p11-kit package in unstable is converted for
> multiarch. Great to see! However, it looks like libp11-kit0 is
> meant to integrate with pkcs modules from other packages, all of
> which currently install to /usr/lib/pkcs11 - whereas because the
> library is multiarched, it only looks in
> /usr/lib/$(DEB_HOST_MULTIARCH)/pkcs11, and will never find these
> modules.
> Should libp11-kit0 declare a Breaks: against the versions of these packages
> which install to /usr/lib/pkcs11, and a transition done?
Hello,
a transition using Breaks looks too heavy-handed to me. Installing
multi-arched p11-kit does not break other software's use of PKCS#11
modules. Also at least on Debian using relative paths and relying on
the module search path simply has never worked, the initial p11-kit
(0.3-1) upload already used the multi-arch path. Ubuntu was quicker
(first upload July 28) but I doubt there are many active users yet. If
the currently available modules moved, p11-kit users could make use of
them without specifying the full path in the configuration file.
I guess the critical part of the transition is to not break other
PKCS#11 users with the new path.
> Or should libp11-kit0 be patched to support looking up modules in
> both locations?
[...]
Won't this introduce problems on partial upgrades to multiarch? Evil
things might happen if a i386 p11-kit tried to load a amd64 module
from /usr/lib/.
cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Acknowledgement sent
to Steve Langasek <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <[email protected]>.
(Thu, 20 Oct 2011 18:33:05 GMT) (full text, mbox, link).
On Thu, Oct 20, 2011 at 08:18:10PM +0200, Andreas Metzler wrote:
> a transition using Breaks looks too heavy-handed to me. Installing
> multi-arched p11-kit does not break other software's use of PKCS#11
> modules. Also at least on Debian using relative paths and relying on
> the module search path simply has never worked, the initial p11-kit
> (0.3-1) upload already used the multi-arch path. Ubuntu was quicker
> (first upload July 28) but I doubt there are many active users yet. If
> the currently available modules moved, p11-kit users could make use of
> them without specifying the full path in the configuration file.
> I guess the critical part of the transition is to not break other
> PKCS#11 users with the new path.
Yes, given that there are other consumers of these modules, that is
certainly a concern.
> > Or should libp11-kit0 be patched to support looking up modules in
> > both locations?
> [...]
> Won't this introduce problems on partial upgrades to multiarch? Evil
> things might happen if a i386 p11-kit tried to load a amd64 module
> from /usr/lib/.
"Evil things" - the only thing that happens is that dlopen() will return
NULL. Which is, after all, the same result you would get if you tried to
open a non-existent file, so I don't think this is a major problem provided
that the code is written to allow for this.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/[email protected][email protected]
Acknowledgement sent
to Wouter Verhelst <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <[email protected]>.
(Wed, 17 Feb 2016 15:27:08 GMT) (full text, mbox, link).
Hi,
What's the status of this bug?
Apparently p11-kit was multiarch-aware at some point, but this was
reverted for some reason.
Is this going to be reintroduced at some point? If not, why not? If so,
what is the reason it was reverted originally?
--
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
people in the world who think they really understand all of its rules,
and pretty much all of them are just lying to themselves too.
-- #debian-devel, OFTC, 2016-02-12
Acknowledgement sent
to Andreas Metzler <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <[email protected]>.
(Sun, 21 Aug 2016 16:39:08 GMT) (full text, mbox, link).
On 2016-02-17 Wouter Verhelst <[email protected]> wrote:
> What's the status of this bug?
> Apparently p11-kit was multiarch-aware at some point, but this was
> reverted for some reason.
> Is this going to be reintroduced at some point? If not, why not? If so,
> what is the reason it was reverted originally?
[...]
Hello,
p11-kit multiarch-ification was not reverted. Its module search-path is
still /usr/lib/$arch/pkcs11. (See p11tool --provider foo)
This bug is not about p11kit switching to multiarch but about (possibly)
transitioning all pkcs11 modules from /usr/lib/pkcs11 to
/usr/lib/$arch/pkcs11 so they can be used via p11-kit by specifiying a
relative instead of an absolute path.
ATM we seem to be split about 50/50: opensc-pkcs1, gnome-keyring and
p11-kit-modules itself install to the multi-arch path, opencryptoki
and coolkey use /usr/lib/pkcs11.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.