Cryptlib can use databases to store certificates, crls, ... . The easiest way to do it is to use the odbc interface. I have changed the ebuild to add support to the odbc inteface in linux using unixODBC (available in portage). The way to active odbc support is to add two "defines" in misc/config.h (it's explained in the cryptlib manual). I have created a patch to add those defines if odbc use flag (already defined in use.desc) is set, and I have added the dev-db/unixODBC dependency. I submmit the ebuild and the patch that the ebuild applies. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 68451 [details] cryptlib 3.2.2 ebuild Ebuild for cryptlib 3.2.2 with odbc support
Created attachment 68452 [details, diff] The patch that the ebuild applies
Created attachment 71915 [details] Updated ebuild New ebuild based in the new official ebuild in portage. The patch is the same.
Daniel - FYI I'll need to fix these bugs too first. >>> Install cryptlib-3.2.2-r1 into /var/tmp/portage/cryptlib-3.2.2-r1/image/ category dev-libs man: making executable: /usr/lib/libcl.so.3.2.2 QA Notice: the following files contain runtime text relocations Text relocations require a lot of extra work to be preformed by the dynamic linker which will cause serious performance impact on IA-32 and might not function properly on other architectures hppa for example. If you are a programmer please take a closer look at this package and consider writing a patch which addresses this problem. TEXTREL usr/lib/libcl.so.3.2.2 QA Notice: the following files contain executable stacks Files with executable stacks will not work properly (or at all!) on some architectures/operating systems. A bug should be filed at http://bugs.gentoo.org/ to make sure the file is fixed. RWX --- --- usr/lib/libcl.so.3.2.2 >>> Completed installing cryptlib-3.2.2-r1 into /var/tmp/portage/cryptlib-3.2.2-r1/image/
(In reply to comment #4) Text relocations problem is solved in the latest snapshot of cryptlib. So next upstream stable release won't have text relocations. About executable stacks, I've installed cryptlib in x86 and amd64 and I don't get the error neither.
Created attachment 91365 [details] dev-libs/cryptlib-3.2.3 ebuild
Cryptlib 3.2.3 is out. See attached ebuild for cryptlib 3.2.3 with odbc support. This version doesn't have text relocations.
Comment on attachment 68452 [details, diff] The patch that the ebuild applies This path is not needed with cryptlib-3.2.3a
Version 3.2.3a is out.
Created attachment 95549 [details] cryptlib ebuild for 3.2.3a version Ebuild for last version (based on cryptlib-3.2.2.ebuild in portage) with odbc support.
This needs to get pushed out ASAP, as all versions of cryptlib currently in portage fail to compile with gcc 4.1.1. 3.2.3a compiles and works.
I'm thinking this product needs a bit more work. Have you got time to look into solutions for these problems. http://www.gentoo.org/proj/en/hardened/pic-fix-guide.xml http://www.gentoo.org/proj/en/hardened/gnu-stack.xml there are a few more references on the bottom of http://www.gentoo.org/proj/en/hardened/ QA Notice: the following shared libraries lack a SONAME /var/tmp/portage/cryptlib-3.2.3a/image/usr/lib/libcl.so.3.2.3 QA Notice: the following files contain runtime text relocations Text relocations force the dynamic linker to perform extra work at startup, waste system resources, and may pose a security risk. On some architectures, the code may not even function properly, if at all. For more information, see http://hardened.gentoo.org/pic-fix-guide.xml Please include this file in your report: /var/tmp/portage/cryptlib-3.2.3a/temp/scanelf-textrel.log TEXTREL usr/lib/libcl.so.3.2.3 QA Notice: the following files contain executable stacks Files with executable stacks will not work properly (or at all!) on some architectures/operating systems. A bug should be filed at http://bugs.gentoo.org/ to make sure the file is fixed. For more information, see http://hardened.gentoo.org/gnu-stack.xml Please include this file in your report: /var/tmp/portage/cryptlib-3.2.3a/temp/scanelf-execstack.log RWX --- --- usr/lib/libcl.so.3.2.3 !!! ERROR: dev-libs/cryptlib-3.2.3a failed.
Created attachment 96004 [details] cryptlib-3.2.3a.ebuild fixes minor stuff
The file doesn't exist anywhere: <snip> >>> Downloading 'http://www.cypherpunks.to/~peter/cl323a.zip' --10:19:27-- http://www.cypherpunks.to/~peter/cl323a.zip => `/usr/portage/distfiles/cl323a.zip' Resolving www.cypherpunks.to... 82.94.251.194, 2001:888:2133:0:b7:a9:69:b8 Connecting to www.cypherpunks.to|82.94.251.194|:80... connected. HTTP request sent, awaiting response... 404 Not Found 10:19:27 ERROR 404: Not Found. </snip>
*** Bug 148469 has been marked as a duplicate of this bug. ***
Created attachment 97615 [details] Cryptlib 3.3 ebuild New ebuild for version 3.3. Compile and works fine but still have QA problems.
OK, 3.2.3 at least compiles w/ gcc-4.1.1. In addition to Comment #12, I also get QA Notice: pre-stripped files found: /var/tmp/portage/cryptlib-3.2.3/image/usr/lib/libcl.so.3.2.3 Well, at least it compiles, someone should stick it into the tree. No idea where 3.2.3a grows.
(In reply to comment #17) Library is automagically striped in makefile. Should be added RESTRICT="nostrip" in ebuild?
# pquery --raw --revdep dev-libs/cryptlib dev-python/cryptlib_py-3.2.2 dev-python/cryptlib_py is one of 3 || ( ) deps for dev-python/tlslite so we can live without it just fine. So, crypto folks, unless this can be fixed, I'd suggest sending this thing to treecleaners, been sitting here for over a year (and while the new versions compile, they have many QA issues).
This was next in my list :) Version bump to 3.3 was committed. I've removed assembly parts, and added some minor modifications. So it will run slow, but run. If someone thinks that without the assembly part this package is useless, reopen and reassign to treecleaner.
