[Cryptlib] cryptlib 3.4.4 beta released

[Peter Gutmann]

cryptlib 3.4.4 beta is now available via the link on the download page,
https://www.cs.auckland.ac.nz/~pgut001/cryptlib/download.html. Could people
try this out to make sure there are no problems building it, and it'll be
designated as the final release once any issues have been resolved.

Peter.

_______________________________________________
Cryptlib mailing list
***@mbsks.franken.deAdministration via Mail: cryptlib-***@mbsks.franken.de
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent sp

[Alon Bar-Lev]

On 30 August 2017 at 06:41, Peter Gutmann <***@cs.auckland.ac.nz> wrote:
>
> cryptlib 3.4.4 beta is now available via the link on the download page,
> https://www.cs.auckland.ac.nz/~pgut001/cryptlib/download.html. Could people
> try this out to make sure there are no problems building it, and it'll be
> designated as the final release once any issues have been resolved.

Hi,

Many of the patches I sent you got in, thank you.

I understand that you are not interested in making it work for
cross-compiler, so all other patches were not applied.

Remaining issues are available in practical porting, please help me to
understand if I am wrong and if there are easy fixes for that.

I could not find a way to inject my own cflags, this patch did not get in:
https://github.com/gentoo/gentoo/blob/master/dev-libs/cryptlib/cryptlib-3.4.4_beta.ebuild#L65
https://github.com/gentoo/gentoo/blob/master/dev-libs/cryptlib/files/cryptlib-3.4.4_beta-build.patch

Some other fixes are available in this build series:
mkdir -p, apply destdir, quoting
https://github.com/gentoo/gentoo/blob/master/dev-libs/cryptlib/files/cryptlib-3.4.4_beta-build.patch#L27
relative symlinks
https://github.com/gentoo/gentoo/blob/master/dev-libs/cryptlib/files/cryptlib-3.4.4_beta-build.patch#L64

Package still manage arch specific flags and settings, without
allowing downstream to easily disable behavior.
https://github.com/gentoo/gentoo/blob/master/dev-libs/cryptlib/cryptlib-3.4.4_beta.ebuild#L86

Not sure why MAKE is defined, make knows best how to run make.
https://github.com/gentoo/gentoo/blob/master/dev-libs/cryptlib/cryptlib-3.4.4_beta.ebuild#L95

Internal zlib is still being built although system zlib is to be used?
https://github.com/gentoo/gentoo/blob/master/dev-libs/cryptlib/cryptlib-3.4.4_beta.ebuild#L81
https://github.com/gentoo/gentoo/blob/master/dev-libs/cryptlib/cryptlib-3.4.4_beta.ebuild#L70

Still, python and tests will not be built without manual symlink, as
we do want to use shared version all over.
https://github.com/gentoo/gentoo/blob/master/dev-libs/cryptlib/cryptlib-3.4.4_beta.ebuild#L112

A standard package build even based on scripts should be, nothing more...
./configure
make
make install DESTDIR=
The complexity of this build system is probable the highest but openssl...

No current package in Gentoo requires cryptlib, maybe it is time to
retire this package as effort of maintaining it is too high.

Regards,
Alon

_______________________________________________
Cryptlib mailing list
***@mbsks.franken.deAdministration via Mail: cryptlib-***@mbsks.franken.de
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in o

[Peter Gutmann]

Alon Bar-Lev <***@gmail.com> writes:

>I understand that you are not interested in making it work for cross-
>compiler, so all other patches were not applied.

It's not that I'm not interested, it's that there's a limit to how much
customisation I can do for one particular situation. I applied all the
patches I could, but with others it would have broken someone else's config,
or in a few cases I wasn't sure what the intent of the change was and what to
do with it. It has to work on the largest possible number of platforms,
including things that are nothing like Linux, so I can't make changes that are
specific to one particular version of Linux but that break things on a range
of other systems.

>I could not find a way to inject my own cflags, this patch did not get in:
>https://github.com/gentoo/gentoo/blob/master/dev-libs/cryptlib/cryptlib-3.4.4_beta.ebuild#L65
>https://github.com/gentoo/gentoo/blob/master/dev-libs/cryptlib/files/cryptlib-3.4.4_beta-build.patch

Why not just use 'make CFLAGS=...'?

>Some other fixes are available in this build series:
>mkdir -p, apply destdir, quoting
>https://github.com/gentoo/gentoo/blob/master/dev-libs/cryptlib/files/cryptlib-3.4.4_beta-build.patch#L27
>relative symlinks
>https://github.com/gentoo/gentoo/blob/master/dev-libs/cryptlib/files/cryptlib-3.4.4_beta-build.patch#L64

OK, I've changed that.

The rest are specific to Gentoo and/or Linux, and would cause conflicts with
other systems...

Peter.

_______________________________________________
Cryptlib mailing list
***@mbsks.franken.deAdministration via Mail: cryptlib-***@mbsks.franken.de
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in

[Peter Gutmann]

Ryan Schmidt <***@ryandesign.com> writes:

General note: I'm currently travelling, so replies may be a bit slow.

>autotools, while definitely also crappy in its own way, is the least terrible
>build system I've encountered, and as long as the project was made with a
>reasonably recent version of autotools, and has used it correctly, it builds
>great on macOS. Unlike cryptlib, which has always needed patches.

If someone wants to write the necessary autotools script I'd be happy to adopt
it...

>Maybe if autotools doesn't support all the systems you want, support for
>those systems can be added to autotools, and then you could use it.

I can't imagine that'll ever happen, these are often obscure embedded OSes
using build environments that emulate just enough of what a Unix-like system
expects that things sort-of work most of the time, but that's about it.

>3.4.4beta fails to build on macOS Sierra right at the beginning with:
>
>./misc/os_spec.h:936:12: fatal error: 'endian.h' file not found
> #include <endian.h>
> ^
>1 error generated.

I did some googling and others have run into this as well (118,000 hits on
Google), apparently macOS decided not to include endian.h in the usual place
but put it in machine/endian.h, so just change the code in os_spec.h to:

#ifdef __GNUC__
#if defined( __APPLE__ )
#include <machine/endian.h>
#else
#include <endian.h>
#endif /* Apple vs. everyone else */
#endif /* GCC */

Peter.

_______________________________________________
Cryptlib mailing list
***@mbsks.franken.deAdministration via Mail: cryptlib-***@mbsks.franken.de
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to po

[Peter Gutmann]

Ryan Schmidt <***@ryandesign.com> writes:

>Looks like you're using zlib functions, but not telling the linker to link
>with the zlib library. Add the flag "-lz" somewhere? I see that
>tools/getlibs.sh does return "-lz -lresolv" but I'm not sure which of the
>many places where this script is called from the makefile, if any, are meant
>to result in it being passed to the linker.

Both ccopts.sh and getlibs.sh check for /usr/include/zlib.h and, if it exists,
don't use the built-in zlib code and use -lz for linking, however the dylib
rule skipped the getlibs step because it wasn't needed until now, to fix this
use:

$(DYLIBNAME): $(OBJS) $(EXTRAOBJS) $(TESTOBJS)
@$(LD) -dynamiclib -compatibility_version $(MAJ).$(MIN) \
-current_version $(MAJ).$(MIN).$(PLV) \
`./tools/getlibs.sh autodetect` \
-o $(DYLIBNAME) $(OBJS) $(EXTRAOBJS)

>I see you added an install target to the makefile (thanks!) but it doesn't
>look like it installs the dylib, only the static library and the so file.

Ah, yeah, because the initial request was for the static and shared libs.
What's the command needed for the dylib? I assume it can be adapted from the
existing shared lib form, but I don't know what the conventions are for naming
and locating dylibs on macOS.

Peter.

_______________________________________________
Cryptlib mailing list
***@mbsks.franken.deAdministration via Mail: cryptlib-***@mbsks.franken.de
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post mes