Created attachment 275593 [details] build.log See attached build.log Portage 2.2.0_alpha37 (default/linux/amd64/10.0/desktop/kde, gcc-4.5.2, glibc-2.13-r2, 2.6.39-gentoo x86_64) ================================================================= System uname: Linux-2.6.39-gentoo-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_5000+-with-gentoo-2.0.2 Timestamp of tree: Thu, 02 Jun 2011 05:45:01 +0000 distcc 3.1 x86_64-pc-linux-gnu [disabled] app-shells/bash: 4.2_p10 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.1-r1, 3.1.3-r1, 3.2 dev-util/cmake: 2.8.4-r1 sys-apps/baselayout: 2.0.2 sys-apps/openrc: 0.8.2-r1 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1-r1 sys-devel/binutils: 2.21 sys-devel/gcc: 4.5.2 sys-devel/gcc-config: 1.4.1-r1 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82 sys-kernel/linux-headers: 2.6.38 (virtual/os-headers) sys-libs/glibc: 2.13-r2 Repositories: gentoo kde pcsx2 oss-overlay sunrise qt-symbian-overlay gamerlay-stable local Installed sets: @kdebase ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-pipe -O2 -march=athlon64-sse3 -ftree-vectorize" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/themes/oxygen-gtk/gtk-2.0 /var/lib/neatx/home" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /e tc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-pipe -O2 -march=athlon64-sse3 -ftree-vectorize" DISTDIR="/var/cache/portage/distfiles" EMERGE_DEFAULT_OPTS="--depclean-lib-check n --with-bdeps y --keep-going" FEATURES="assume-digests binpkg-logs distlocks ebuild-locks fixlafiles fixpackages news parallel-fetch preserve-libs protect-owned sandbox sfperms sign strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="" GENTOO_MIRRORS="ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ http://distfiles.gentoo.org" LANG="en_GB.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,--hash-style=gnu" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/var/cache/portage/packages" PORTAGE_COMPRESS="xz" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/cache/portage/gentoo" PORTDIR_OVERLAY="/var/cache/portage/layman/kde /var/cache/portage/layman/pcsx2 /var/cache/portage/layman/oss-overlay /var/cache/portage/layman/sunrise /var/cache/portage/layman/qt-symbian-overlay /var/cache/portage/layman/gamerlay /var/cache/portage/local" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Lovely, so truecrypt tries to find the PKCS#11 headr from OpenSC, but that's gone with 0.12.0 since the interface is the usual PKCS#11 one. I guess one solution would be to have a pkcs11-headers package somewhere that depends on one of the many PKCS#11 implementations. And if you're not sure about what I'm saying, see http://blog.flameeyes.eu/2011/04/25/network-security-services-nss-and-pkcs-11 and related posts.
Diego, I read through your post. I think I understand what you're getting at. I do not however understand it well enough (nor have the hardware) to even begin to try to fix/test this. Any input on the best way to fix this (especially if you can test it) would be greatly helpful. Thanks!
Alon can I ask your opinion on this as well? I think one approach we can have here is: a) create virtual/pkcs11, which depends on || ( opensc opencryptoki nss scute .. ) b) make it install some /usr/include/pkcs11.h file And this is definitely not limited to truecrypt, although other packages simply use their own pkcs11.h header. do you know where we could find an "official" header for this at all?
Hello, PKCS#11 header files are needed only at compile time. A product that is using PKCS#11 is expected to contain the headers in the version of the spec it expect/implements. The problem is that RSA security requires adding advertising clause, so their header are not GNU compatible. If this is not an issue, and I don't think that in truecrypt this is an issue as it has its own license, I would have downloaded proper PKCS#11 files and place them under ${WORKDIR}/pkcs11 or something, and add -I CPPFLAGS. RSA Security PKCS#11 files may be found here[1]. At open source projects we use a different headers taken from scute[2], this is a free re-written headers files which should be compatible with the RSA security's one. Again, I would have added this to SRC_URI and use it while building. No extra dependencies should be added. What do you think? [1] http://www.rsa.com/rsalabs/node.asp?id=2133 [2] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=scute.git;a=blob;f=src/pkcs11.h;h=03e904b763d84cd738b83a14bff8b97637fbd740;hb=HEAD
Any news? The problem persists...
This should be fixed in -r5. + 15 Jul 2011; Dane Smith <c1pher@gentoo.org> truecrypt-7.0a-r5.ebuild: + Allow for the inclusion of our own pkcs11.h if using >=opensc-0.12 wrt + bug 369781. No revbump. Thanks to Alon Bar-Lev and Diego Elio Petteno + for help with the fix. + I cannot however, test if it is using opensc correctly. I know for sure it compiles fine, but beyond that, I don't have the hardware. If someone could test it for me and get back to me it would be handy. Thanks! Closing test-request.
Not good. You should drop the: || ( dev-libs/pkcs11-helper dev-libs/opensc ) dependency. You should also remove the: if ! has_version dev-libs/pkcs11-helper && \ has_version "=dev-libs/opensc-0.12*"; then Use only the embed PKCS#11. The pkcs11_include_directory should always use the embed.
Created attachment 280133 [details, diff] truecrypt-7.0a-r5.ebuild.diff Something like this. Did not test as don't use and have no wxGTK on system. Are you sure both: append-flags -I"${S}"/pkcs11 And: PKCS11_INC="${S}/pkcs11" Are needed?
Created attachment 280135 [details, diff] truecrypt-7.0a-r5.ebuild.diff Also there is no reason why to touch "${S}" with out of tarball files. Use "${T}".
(In reply to comment #7) > Not good. > > You should drop the: > || ( dev-libs/pkcs11-helper dev-libs/opensc ) > > dependency. > > You should also remove the: > if ! has_version dev-libs/pkcs11-helper && \ > has_version "=dev-libs/opensc-0.12*"; then > > > Use only the embed PKCS#11. > > The pkcs11_include_directory should always use the embed. Why should the dependency be dropped? Just because we provide the header in the ebuild now doesn't mean the library will be present. Also, why should we be forcing that header if the user is using pkcs11-helper which has it's own headers installed? I only put that pkcs11.h file there for >=opensc-0.12 I am extremely unfamiliar with the pkcs11 foo as I have no way to test it, so if I'm being stupid, feel free to tell me. (In reply to comment #8) > Created attachment 280133 [details, diff] > truecrypt-7.0a-r5.ebuild.diff > > Something like this. > > Did not test as don't use and have no wxGTK on system. > > Are you sure both: > append-flags -I"${S}"/pkcs11 > And: > PKCS11_INC="${S}/pkcs11" > Are needed? They wouldn't both be necessary no. I have the append-flags line there because I was forcing it to use the one included in ${S} if it didn't fine the one on the normal file system.
(In reply to comment #10) > Why should the dependency be dropped? Just because we provide the header in the > ebuild now doesn't mean the library will be present. > Also, why should we be forcing that header if the user is using pkcs11-helper > which has it's own headers installed? I only put that pkcs11.h file there for > >=opensc-0.12 PKCS#11 is an interface. Not bound to any specific implementation. You can use PKCS#11 interface with *ANY* PKCS#11 provider we have a few in portage and many other. Application is PKCS#11 enabled - does not mean one or any implementation should exists. > > Are you sure both: > > append-flags -I"${S}"/pkcs11 > > And: > > PKCS11_INC="${S}/pkcs11" > > Are needed? > > They wouldn't both be necessary no. I have the append-flags line there because > I was forcing it to use the one included in ${S} if it didn't fine the one on > the normal file system. So leave only the PKCS11_INC statement. Better local change and use build features than global change.
Created attachment 280137 [details, diff] truecrypt-7.0a-r5.ebuild.diff
Done in -r6. Thanks for the help Alon. Let me know if it all looks Ok. +*truecrypt-7.0a-r6 (15 Jul 2011) + + 15 Jul 2011; Dane Smith <c1pher@gentoo.org> +truecrypt-7.0a-r6.ebuild: + Rev bump. Include our own headers by default. Removed dependency on a + pkcs11 implementation. Should work with any of them now. Thanks Alon + Bar-Lev for the help. Bump to EAPI 4. Bug 369781
(In reply to comment #11) > PKCS#11 is an interface. > Not bound to any specific implementation. > You can use PKCS#11 interface with *ANY* PKCS#11 provider we have a few in > portage and many other. Doesn't that qualify it for a virtual? I.e. virtual/pkcs11 and DEPEND="pkcs11? (virtual/pkcs11)" in truecrypt.
Quite possibly, yes, and it would be nice to have indeed, the problem is that in most cases, people would have one provided already, although it is a mess to configure it (NSS).
(In reply to comment #14) > (In reply to comment #11) > > PKCS#11 is an interface. > > Not bound to any specific implementation. > > You can use PKCS#11 interface with *ANY* PKCS#11 provider we have a few in > > portage and many other. > Doesn't that qualify it for a virtual? I.e. virtual/pkcs11 and DEPEND="pkcs11? > (virtual/pkcs11)" in truecrypt. No. The fact that you allow application to support PKCS#11, does not mean that a provider must exist in order application to work. Also if you have a provider out side of tree you should not be forced to install a unneeded provider just to make it work. The virtual keyword is good if a component is actually needed but have few options, and once built application detects this option and proceed. This is not the case in PKCS#11.
