Summary: | app-crypt/truecrypt-7.0a-r5 fails to build with dev-libs/opensc-0.12.0 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dennis Schridde <dschridde+gentoobugs> |
Component: | Current packages | Assignee: | Dane Smith (RETIRED) <c1pher> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | normal | CC: | alon.barlev, crypto+disabled, flameeyes, Martin.Jansa |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=434458 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
truecrypt-7.0a-r5.ebuild.diff truecrypt-7.0a-r5.ebuild.diff truecrypt-7.0a-r5.ebuild.diff |
Description
Dennis Schridde
2011-06-02 10:07:39 UTC
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. |