Bugzilla Bug 105954

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 an attachment (id=68451) [details]
cryptlib 3.2.2 ebuild

Ebuild for cryptlib 3.2.2 with odbc support

Created an attachment (id=68452) [details]
The patch that the ebuild applies

Created an attachment (id=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 an attachment (id=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.

(From update of attachment 68452 [details])
This path is not needed with cryptlib-3.2.3a

Version 3.2.3a is out.

Created an attachment (id=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 an attachment (id=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 an attachment (id=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.