jens-maus / amissl

:closed_lock_with_key: AmiSSL is the AmigaOS/MorphOS/AROS port of OpenSSL. It wraps the full functionality of OpenSSL into a full-fledged Amiga shared library that makes it possible for Amiga applications to use the full OpenSSL API through a standard Amiga shared library interface (e.g. web browsers wanting to support HTTPS, etc.)...

The AmiSSL project is a collaborative effort to develop a port of OpenSSL in a shared library for Amiga-based systems (AmigaOS, MorphOS, AROS, etc). OpenSSL (www.openssl.org) is "an open source project that provides a robust, commercial-grade, and full-featured toolkit for the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols. It is also a general-purpose cryptography library."

The library together with its provided software development kit (SDK) tries to be 100% API/ABI compatible to the OpenSSL version it is based on. Due to it being a shared library, it can be used by several Amiga applications at the same time, without wasting resources.

AmiSSL v5 is a new major release which has been updated with full compatibility with OpenSSL 3.3. This includes important security related fixes, a built-in HTTP(S) client and comes with the latest encryption ciphers which are required nowadays to connect to modern SSL-based services such as HTTPS and SSH.

General

AmiSSL consists of four major components: the shared libraries, the public root CA certificates, a port of the OpenSSL command-line tool and the developer SDK.

Libraries

The main library is amisslmaster.library which acts as a proxy and opens the appropriate AmiSSL library (with compatibility to a certain OpenSSL version) for the programs using AmiSSL. This mechanism allows different AmiSSL versions to be installed in parallel, due to different applications potentially requiring different versions. For this reason, it is important that the latest version of amisslmaster.library is always installed.

The actual OpenSSL implementations are located in the shared libraries that are usually stored inside the AmiSSL:Libs/AmiSSL directory. With the exception of AmiSSL v1 libraries, none of them should be opened directly, but instead via amisslmaster.library. The technical details on this can be found in AmiSSL SDK documentation (see README-SDK).

The previous versions of libraries in AmiSSL directory should be kept when a new version of AmiSSL is released since they may still be used, as sometimes changes in the OpenSSL API/ABI or public structures mean that backwards compatibility cannot be maintained, usually for major OpenSSL updates only. When this is not an issue, the installer will delete any old versions that are no longer required and applications will benefit automatically from using the latest version without themselves needing to be recompiled/updated.

Root CA Certificates

Each AmiSSL version is supplied with a full set of root CA certificates which have been synchronized to the ones the Mozilla group usually distribute with their products (e.g. Mozilla Firefox, etc.) and are stored in the AmiSSL:Certs directory. When installing new updated AmiSSL versions, these certificates are updated and expired ones are removed.

It is recommended that you do not manually add certificates to the AmiSSL:Certs directory, but if you did, you should back them up and copy them back after installing the latest AmiSSL. Normally, you should add and maintain your own certificates in the AmiSSL:UserCerts directory, so that no future AmiSSL release will delete them. Applications should store certificates in AmiSSL:UserCerts and private keys in AmiSSL:Private.

The 'OpenSSL' command-line tool

A port of the OpenSSL tool is also included and usually installed to AmiSSL: or C: during installation. It is a "command line tool for using the various cryptography functions of OpenSSL's crypto library from the shell". The documentation for the OpenSSL tool is included in the archive and can also be reviewed online. A sample openssl.cnf file is also installed to AmiSSL:, if it doesn't already exist, along with the CA.pl helper script, both of which aid the certificate generation features of the OpenSSL tool. The tsget.pl script is also included.

Developer SDK

The AmiSSL SDK contains everything a developer needs to use OpenSSL in their applications, including C header files, Autodocs, autoopen link library, stub link library, examples and library interface description files. The first point of call being the README-SDK file which explains what needs to be done.

Backwards Compatibility

All applications compiled to use previous versions of AmiSSL v5 will automatically use the latest version once installed. Old applications will continue to use AmiSSL v4 or older and will need to be recompiled with the updated SDK in order to start using AmiSSL v5. Besides this difference, AmiSSL v5 can be installed on top of any previous AmiSSL versions, which ensures that applications compiled for AmiSSL v1/v2/v3/v4 continue to work.

Requirements

AmiSSL requires an Amiga-compatible operating system being installed (AmigaOS, MorphOS, AROS) with exec.library v38+ compatibility. Currently, AmiSSL is compatible with AmigaOS 4.0+/PPC, AmigaOS 3.0+/68020+ and MorphOS.

Installation

AmiUpdate may be used by AmigaOS 4.x users to automatically download and install any new AmiSSL version. Otherwise, the latest release archive can be downloaded from any of the following URLs:

https://github.com/jens-maus/amissl/releases
http://aminet.net/search?query=amissl-5

Once downloaded it should be unarchived to a temporary directory and the "Install" script used accordingly.

Legal information

AmiSSL v1    Copyright (c) 1999-2006 Andrija Antonijevic.
AmiSSL v2/v3 Copyright (c) 2002-2006 Andrija Antonijevic and Stefan Burstroem.
AmiSSL v4/v5 Copyright (c) 2014-2024 AmiSSL Open Source Team.
All Rights Reserved.

OpenSSL Cryptography and SSL/TLS Toolkit
Copyright (c) 1995-2024 The OpenSSL Project Authors. All Rights Reserved.

AmiSSL uses a modified version of OpenSSL. Both AmiSSL and OpenSSL
are licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License in the file LICENSE in the
source distribution or at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

68060 optimised 64-bit multiplication routines
Copyright (c) 2001-2022 Frank Wille. All Rights Reserved.

OpenSSL BIGNUM 68020-68040 optimised routines
Copyright (c) 2002 by Howard Chu <[email protected]>

Authors

AmiSSL is a collaborative effort with Amiga-specific code being contributed by the following people:

• Andrija Antonijevic
• Thore Böckelmann
• Stefan Burstroem
• Howard Chu
• Jens Maus
• Gunther Nikl
• Oliver Roberts
• Frank Wille

amissl's Issues

implement a general Amiga compatible "test script"

implement a general Amiga compatible "test script" that allows to execute all OpenSSL test utilities in one run and returns potentially found errors. This would then allow to check AmiSSL in one run rather than having to run each test utility manually.

OpenSSL 1.1.1

Any plans on updating AmiSSL to OpenSSL 1.1.1a?

After messing around with gcc's build system for the last few days, I finally managed to compile a working gcc 4.0.4 cross compiler from adtools on my Ubuntu PC and then managed to compile some working amissl libraries using it, so I might give this work a try as well.

FWIW I'm mainly interested in having this newer version so that I can add support for ed25519 keys in ssh2-handler.

AmiUpdate fails to install due to lacking AutoInstall script

Hello.

AmiUpdate found the new AmiSSL4. It downloaded fine but then failed to install due to missing AutoInstall script. I understand the archive is multi platform but can one be added so AmiUdate gives no errors?

openssl/asn1.h header redefinitions in Storm C 4

Hi all,
When including openssl/asn1.h from AmiSSL 4.6 in a project, the compilation fails with many errors "Identifier... redefined". This is using the Stormc 4 compiler with the target as AmigaOS3. I also have errors using their GCC mode

11.Workbench:> stormc:stormsys/stormc webclientclass.c
StormC:include/openssl/asn1.h, Line 482, Col. 1:
Fehler 50: Identifier "ASN1_SEQUENCE_ANY" redefined.
StormC:include/openssl/asn1.h, Line 521, Col. 1:
Fehler 50: Identifier "ASN1_TYPE" redefined.
StormC:include/openssl/asn1.h, Line 521, Col. 1:
Fehler 50: Identifier "ASN1_TYPE" redefined.
StormC:include/openssl/asn1.h, Line 537, Col. 1:
Fehler 50: Identifier "ASN1_OBJECT" redefined.
StormC:include/openssl/asn1.h, Line 560, Col. 1:
Fehler 50: Identifier "ASN1_BIT_STRING" redefined.
StormC:include/openssl/asn1.h, Line 560, Col. 1:
Fehler 50: Identifier "ASN1_BIT_STRING" redefined.
StormC:include/openssl/asn1.h, Line 560, Col. 1:
Fehler 50: Identifier "ASN1_BIT_STRING" redefined.
StormC:include/openssl/asn1.h, Line 573, Col. 1:
Fehler 50: Identifier "ASN1_INTEGER" redefined.
StormC:include/openssl/asn1.h, Line 573, Col. 1:
Fehler 50: Identifier "ASN1_INTEGER" redefined.
StormC:include/openssl/asn1.h, Line 573, Col. 1:
Fehler 50: Identifier "ASN1_INTEGER" redefined.
StormC:include/openssl/asn1.h, Line 579, Col. 1:
Fehler 50: Identifier "ASN1_ENUMERATED" redefined.
StormC:include/openssl/asn1.h, Line 579, Col. 1:
Fehler 50: Identifier "ASN1_ENUMERATED" redefined.
StormC:include/openssl/asn1.h, Line 579, Col. 1:
Fehler 50: Identifier "ASN1_ENUMERATED" redefined.
StormC:include/openssl/asn1.h, Line 599, Col. 1:
Fehler 50: Identifier "ASN1_OCTET_STRING" redefined.
StormC:include/openssl/asn1.h, Line 599, Col. 1:
Fehler 50: Identifier "ASN1_OCTET_STRING" redefined.
StormC:include/openssl/asn1.h, Line 599, Col. 1:
Fehler 50: Identifier "ASN1_OCTET_STRING" redefined.
StormC:include/openssl/asn1.h, Line 606, Col. 1:
Fehler 50: Identifier "ASN1_VISIBLESTRING" redefined.
StormC:include/openssl/asn1.h, Line 606, Col. 1:
Fehler 50: Identifier "ASN1_VISIBLESTRING" redefined.
StormC:include/openssl/asn1.h, Line 606, Col. 1:
Fehler 50: Identifier "ASN1_VISIBLESTRING" redefined.
StormC:include/openssl/asn1.h, Line 607, Col. 1:
Fehler 50: Identifier "ASN1_UNIVERSALSTRING" redefined.

Is there a fix or workaround for it?

Thanks!

Function assigned to variable causes linker errors m68k/gcc

This follows on from my comment #15 (comment)_

Build target is m68k GCC.

In https://github.com/curl/curl/blob/ff7e5a29c781802ae5f37730e076df44a3936717/lib/vtls/openssl.c#L823 sk_X509_pop_free(ca, X509_free); causes the following linker error when the lib is used:

../lib/.libs/libcurl.a()(.text+0x58d6):: undefined reference to `_X509_free'
../lib/.libs/libcurl.a()(.text+0x59be):: undefined reference to `_X509_free'
../lib/.libs/libcurl.a()(.text+0x5bee):: undefined reference to `_X509_free'

Normal usage of X509_free() in the same file is fine, so I think this is an AmiSSL includes (inline?) issue with the X509_free function being used as a parameter.

There appears to be a related issue with the MD5 functions where they are assigned to a variable before being used and this is also causing the same linker errors.

Crashes when no FPU present

Unfortunately, AmiSSL crashes on on 68020 or 68030 with no FPU present. This is because the library is being compiled with the -m68020-60 option, which allows FPU instructions to be generated as -mhard-float becomes the default. At the very least we must explicitly specify -msoft-float to fix the crashes.

R language

I am working in R language and I have this issue can anybody help me.
if(LCL == 0){Pin1 <- sum(dbinom(LCL:UCL, n, P1, False))}
Warning message:
In if (LCL == 0) { :
the condition has length > 1 and only the first element will be used

Recommend changing macros in inline4/amissl.h to inline stubs

I'm using USE_INLINE in one of my projects, and ended up with a linker error because the code stores a pointer to SSL_CTX_free(). Needless to say, that doesn't work when that function is a C macro.

This is a general problem with the USE_INLINE stubs for AmigaOS libraries on OS4 because IDLTool generates the macros. Either way, it would be good if the AmiSSL headers could be changed to use inline stubs.

AmiSSL4 ToDo: Things to look at and fix until the final release

This ticket should be a continued ticket for minor things that we should look at and fix until the final AmiSSL4 release.

1. IIntuition/BIO_vsnprintf reference required? (https://github.com/jens-maus/amissl/blob/master/src/amisslmaster_library.c#L49-L55)
2. OpenSSL_cleanup() somewhere required! (https://github.com/jens-maus/amissl/blob/master/src/amissl_init.c#L117-L120)
3. AmiSSLAbort() not required anymore? (https://github.com/jens-maus/amissl/blob/master/src/amissl_library.c#L365-L371)
4. fix all fixable compiler warnings
5. implement travis build support for the github repository.
6. implement a "make release" target in our Makefile to generate a proper release archive with Installer script, etc.

Over time we will add/remove things in here as we stumble over certain things...

Alert 0x01000009 memory already free, when calling CRYPTO_free()

Running under AmigaOS 4 "latest beta" I have come across this crashy a number of times.
I've seen it in two pieces of software, my AmiSSL based port of pythons _ssl.so and my recently updated build of AWeb.

I will attach the whole GR reports but here is a typical stack trace:

Stack trace:
    native kernel module kernel+0x000149b0
    native kernel module kernel+0x0001b60c
    native kernel module kernel+0x00017ca8
    [free.c:25] libs:amissl/amissl_v110e.library:free()+0x6c (section 1 @ 0x215878)
    libs:amissl/amissl_v110e.library:CRYPTO_free()+0xe0 (section 1 @ 0x16BDB0)
    libs:amissl/amissl_v110e.library:ERR_clear_error()+0x84 (section 1 @ 0x148550)
    libs:amissl/amissl_v110e.library:X509_STORE_set_default_paths()+0x70 (section 1 @ 0x1C0870)
    libs:amissl/amissl_v110e.library:SSL_CTX_set_default_verify_paths()+0x14 (section 1 @ 0x99EF0)
    libs:amissl/amissl_v110e.library:LIB_SSL_CTX_set_default_verify_paths()+0x1c (section 1 @ 0x117B0)
    AWeb:_Assl_openssl()+0xbc (section 1 @ 0xA8388)
    AWeb:Httptask()+0x25c (section 1 @ 0x5A984)
    AWeb:Subtask()+0xec (section 1 @ 0x8D198)
    native kernel module dos.library.kmod+0x00026698
    native kernel module kernel+0x0003e9a8
    native kernel module kernel+0x0003e9f0

OS3/m68k issue: 'digest check failed'

With the latest master branch the OS3/m68k build fails to establish ssl3 connections with an error message like:

error:1408C095:SSL routines:ssl3_get_finished:digest check failed

The problem seems to originate from openssl/ssl/s3_both.c where a CRYPTO_memcmp() returns non-zero for some unknown reason. The CRYPTO_memcmp() however seems to work fine if debugging info is added to the function in openssl/crypto/cryptlib.c.

It is, however, still unknown why this error is only returned if an application like YAM is being used but the openssl s_client -connect pop.gmail.com:995 -ssl3 works as expected and doesn't seem to return any error.

The install script doesn't copy the OpenSSL Program to c:

The install script doesn't copy the OpenSSL Program to c:
Sorry for the one line but nothing other to say. :-)

Alternative backend (WolfSSL)

Greetings! First off, thanks so much for keeping AmiSSL alive. It's nice for my Amiga to be able to use a web browser on the modern Internet still. I found the project via aminet as was pleasantly surprised to find someone is still maintaining it. In a related topic to #22 I was wondering what the future of this library looks like. My understanding is that "legacy" architectures and operating systems (including 68k, PPC, and AmigaOS) are being removed from OpenSSL after the 1.0.2. Being unaware of this project being active, I was planning on using WolfSSL and seeing if AmiSSL could be ported to this. WolfSSL is designed for embedded systems (meaning it's a small code base), still supports 68k and PPC processors, implements modern technologies like TTLS1.2 and TLS1.3, and has an OpenSSL compatibility layer. I figured it would at least be worth opening a discussion if there was interest in collaborating on an effort to add WolfSSL to AmiSSL or if the maintainers already had other plans...

Openssl command fails when using the -out parameter

Running the following command:
openssl ecparam -name secp521r1 -genkey -param_enc named_curve -out "ram:key"

will fail with the following warning and error:
*** WARNING (BIO_new_fp): 5A1CE7B8 is neither stdin (5A1C8048), stdout (5A1C80B0) nor stderr (5A1C8118) in GetFileBPTR in stubs, returning NULL!
unable to write elliptic curve parameters
1415989712:error:09072007:PEM routines:PEM_write_bio:BUF lib:../../openssl/crypto/pem/pem_lib.c:658:

It works just fine without the -out parameter, but then it's writing to stdout instead of a file.

The file itself is created, but empty.

OpenSSL can't open amisslmaster.library v4

I installed this version on top of a old installation.
Now both the libraries live in AmiSSL:libs/AmiSSL:
amissl_v097g.library
amissl_v110e.library

But OpenSSL won't find the lib:
OpenSSL> Couldn't open amisslmaster.library v4

Bug in https.c example?

I'm new to AmiSSL and I saw the following lines in the https.c example:

if (AmiSSLBase)
{
#if defined(__amigaos4__)
	if (IAmiSSL)
	{
		CleanupAmiSSL(TAG_DONE);
		DropInterface((struct Interface *)IAmiSSL);
		IAmiSSL = NULL;
	}
#endif

	CloseAmiSSL();
	AmiSSLBase = NULL;
} 

Shouldn't CleanupAmiSSL() be called on other platforms as well and not only on OS4? So I think the code should be like this instead:

if (AmiSSLBase)
{
	CleanupAmiSSL(TAG_DONE);
#if defined(__amigaos4__)
	if (IAmiSSL)
	{
		DropInterface((struct Interface *)IAmiSSL);
		IAmiSSL = NULL;
	}
#endif

	CloseAmiSSL();
	AmiSSLBase = NULL;
} 

Or am I getting something wrong here?

MorphOS: finalize compilation and test baserel support

The current state of our AmiSSL sources actually almost compiles for MorphOS/PPC. However, even though the sources might properly compile we need to properly test the 'baserel' support and how we have to setup baserel handling on MorphOS. Perhaps we also need some help from MorphOS developers having some more experience with compiling baserel aware shared libraries for MorphOS.

Includes don't work on vbcc

AmiSSL includes don't work with vbcc either. There are these lines in proto/amissl.h:

 #elif defined(__VBCC__)
  #ifndef __PPC__
   #include <inline/amissl_protos.h>
  #endif /* __PPC__ */

But the file inline/amissl_protos.h isn't there. Same for amisslmaster.

Please fix.

Merging new OpenSSL as described in README.update-openssl fails

Trying to merge in OpenSSL 1.1.1a as described in the README.update-openssl file results in the following error:

$ git subtree pull --prefix openssl --squash https://github.com/openssl/openssl.git OpenSSL_1_1_1a
From https://github.com/openssl/openssl
 * tag                     OpenSSL_1_1_1a -> FETCH_HEAD
fatal: ambiguous argument '3ff855e048b924a2db5133e596da9c25e9aaee27^0': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
could not rev-parse split hash 3ff855e048b924a2db5133e596da9c25e9aaee27 from commit d62c916138a4ec9be10f9417f912692727013ee7
Can't squash-merge: 'openssl' was never added.

Any idea what it means?

Originally posted by @salass00 in #24 (comment)

AmiSSL Installer documentation location

The OS4 AmiSSL installation places the OpenSSL and AmiSSL documentation in SYS:Documentation. The OS4 installer places the AmiSSL documentation in SYS:Documentation/AmiSSL. It could be very confusing for a user who finds the wrong AmiSSL documentation when AmiSSL V4 is installed on his/her system. The installer should install the AmiSSL documentation in SYS:Documentation/AmiSSL.

On real 68k hardware certain connections are being dropped during SSL handshake

In a recent YAM issue ticket (see jens-maus/yam#651) a user is reporting connection problems with his real A1200/68060 system. After some investigation it seems that not YAM can be blamed, but the problem already appear if he is using the openssl command-line tool to initiate a test connection via the following command sequence:

openssl s_client -debug -connect pop3.live.com:995

After execution of the command the openssl command doesn't switch to interactive connection mode and the POP3 server doesn't report with plain text +OK that the connection succeeded. Looking at the debug output one can see that after outputting the certificate chain it actually output some write:errno=32 error which means "Broken pipe":

[...]
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization Validation CA - SHA256 - G2
verify return:1
depth=0 C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = *.hotmail.com
verify return:1
write to 0x60ca7a7c [0x60c5f40c] (166 bytes => -1 (0xFFFFFFFF))
write:errno=32
[...]

As said, errno=32 stands for "Broken pipe" and could easily mean the mail server had already canceled/dropped the connection to to waiting to long for a response. The current suspicion is that due to unknown reasons certain cipher/certificate digest calculations might take to long so that the server drops connection and the openssl tries to continue communication with the server, but fails of course.

Some debugging are required and thus we should generate a openssl command line binary with more debugging output between the certificate output and the successive write commands. In addition, some timing information have to be added to be able to verify if some calculations are really taking to long.

Openssl fails when generating a self-signed certificate due to missing AmiSSL:/openssl.cnf

As the subject says, the default AmiSSL installation is missing the openssl.cnf file, which means that the openssl command will fail to generate certificates.

Here's the command line for generating a cert:
openssl req -new -x509 -key "key.pem" -days 730 -subj "/CN=localhost" -out "server.pem"

You'll get this error:
Can't open AmiSSL:/openssl.cnf for reading, No such file or directory

OS3/m68k issue: build fails with "Internal compiler error: program cc1 got fatal signal 11"

When trying to compile our latest openssl-1.1.x branch sources compilation for m68k-amigaos fails with a fatal compiler error:

[...]
m68k-amigaos-gcc -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSLDIR="\"AmiSSL:\"" -DENGINESDIR="\"AmiSSL:engines\"" -m68020-60 -msoft-float -DNO_INLINE_VARARGS -D__NO_NET_API -DB_ENDIAN -DOPENSSL_SYS_AMIGA -D__amigaos3__ -DOPENSSL_NO_STDIO -I../../include -I../../include/netinclude -W -Wall -O1 -g -gstabs -DBN_DEBUG -DCONF_DEBUG -DDEBUG  -resident32 -DAMISSL_COMPILE -I../../libcmt/include  -Iinclude -I../../openssl -I../../openssl/crypto/include -I../../openssl/include -Icrypto/include -c -o crypto/dh/dh_rfc5114.o ../../openssl/crypto/dh/dh_rfc5114.c
In file included from ../../openssl/crypto/dh/dh_rfc5114.c:63:
../../openssl/crypto/include/internal/bn_dh.h:6: warning: `extern' is not at beginning of declaration
m68k-amigaos-gcc: Internal compiler error: program cc1 got fatal signal 11
Makefile:3402: recipe for target 'crypto/dh/dh_rfc5114.o' failed

Looking at the output of dmesg cc1 seems to crash with a segmentation fault:

[1299419.719277] cc1[16431]: segfault at 14 ip 0000000008198a8f sp 00000000ffed7538 error 4 in cc1[8048000+1e1000]

After further investigation I was able to manually try to investigate this issue with debugging in gdb:

(1) Compile dh_rfc5441.c sources with -savetemps so that the compiler saves the *.i and *.s file accordingly:

$ cd build_os3/openssl
$ m68k-amigaos-gcc -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSLDIR="\"AmiSSL:\"" -DENGINESDIR="\"AmiSSL:engines\"" -m68020-60 -msoft-float -DNO_INLINE_VARARGS -D__NO_NET_API -DB_ENDIAN -DOPENSSL_SYS_AMIGA -D__amigaos3__ -DOPENSSL_NO_STDIO -I../../include -I../../include/netinclude -W -Wall -O1 -g -gstabs -DBN_DEBUG -DCONF_DEBUG -DDEBUG  -resident32 -DAMISSL_COMPILE -I../../libcmt/include  -Iinclude -I../../openssl -I../../openssl/crypto/include -I../../openssl/include -Icrypto/include -c -o crypto/dh/dh_rfc5114.o ../../openssl/crypto/dh/dh_rfc5114.c -save-temps

(2) Run cc1 manually to trigger the issue:

$ /opt/m68k-amigaos/lib-clib2/gcc-lib/m68k-amigaos/2.95.3/cc1 dh_rfc5114.i -dumpbase dh_rfc5114.c -da -m68020-60 -msoft-float -g -gstabs -O1 -W -Wall -version -fbaserel32 -o /tmp/ccNJom9s.s
[...]
Segmentation fault (core dumped)

(3) Run the same command in a gdb session:

$ gdb /opt/m68k-amigaos/lib-clib2/gcc-lib/m68k-amigaos/2.95.3/cc1
[...]
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /opt/m68k-amigaos/lib-clib2/gcc-lib/m68k-amigaos/2.95.3/cc1...done.
(gdb)

(4) Now run cc1 with the run gdb command to actually trigger the issue:

(gdb) run dh_rfc5114.i -dumpbase dh_rfc5114.c -da -m68020-60 -msoft-float -g -gstabs -O1 -W -Wall -version -fbaserel32 -o /tmp/ccNJom9s.s
[...]
Program received signal SIGSEGV, Segmentation fault.
0x08198a8f in amigaos_put_in_text (decl=0x84fae54)
    at /home/damato/projekte/Amiga/amigaos-cross-toolchain/.build-m68k/sources/gcc-2.95.3/gcc/config/m68k/amigaos.c:63
63    return (TREE_INT_CST_HIGH (TYPE_SIZE (type)) == 0
(gdb)

(5) run where to see the backtrace:

(gdb) where
#0  0x08198a8f in amigaos_put_in_text (decl=0x84fae54)
    at /home/damato/projekte/Amiga/amigaos-cross-toolchain/.build-m68k/sources/gcc-2.95.3/gcc/config/m68k/amigaos.c:63
#1  0x080b15e8 in make_decl_rtl (decl=0x84fae54, asmspec=0x0, top_level=1)
    at /home/damato/projekte/Amiga/amigaos-cross-toolchain/.build-m68k/sources/gcc-2.95.3/gcc/varasm.c:783
#2  0x0804beaf in rest_of_decl_compilation (decl=0x84fae54, asmspec=0x0, top_level=1, at_end=0)
    at /home/damato/projekte/Amiga/amigaos-cross-toolchain/.build-m68k/sources/gcc-2.95.3/gcc/toplev.c:3526
#3  0x081ac431 in finish_decl (decl=0x84fae54, init=0x0, asmspec_tree=0x0)
    at /home/damato/projekte/Amiga/amigaos-cross-toolchain/.build-m68k/sources/gcc-2.95.3/gcc/c-decl.c:4103
#4  0x081a04ac in yyparse () at c-parse.y:1015
#5  0x0804b761 in compile_file (name=0xffffd5bd "dh_rfc5114.i")
    at /home/damato/projekte/Amiga/amigaos-cross-toolchain/.build-m68k/sources/gcc-2.95.3/gcc/toplev.c:3270
#6  0x0804eeb1 in main (argc=16, argv=0xffffd404)
    at /home/damato/projekte/Amiga/amigaos-cross-toolchain/.build-m68k/sources/gcc-2.95.3/gcc/toplev.c:5454

Obviously there seems to be a problem in code generation that needs to be investigated in the gcc-295.3 sources.

Compile problems with gcc

hello,

i trying to compile libCurl with AmiSSL under cygwin. (m68k target)
i use cahirwpz's amigaos-cross-toolchain. i get the following errors:

In file included from /home/anchor/amissl/include/proto/amissl.h:79,
                 from vtls/openssl.c:42:
/home/anchor/amissl/include/amissl/inline.h: In function `sk_SCT_new':
/home/anchor/amissl/include/amissl/inline.h:123: warning: implicit declaration of function `LP1FP'
/home/anchor/amissl/include/amissl/inline.h:123: parse error before `OPENSSL_STACK'
/home/anchor/amissl/include/amissl/inline.h:123: warning: unused parameter `compare'
/home/anchor/amissl/include/amissl/inline.h:123: warning: control reaches end of non-void function
...

screen shot #1
screen shot #2

can i get some advice? :)

thanks

SimpleMail guru, maybe AmiSSL related?

Please take a look at sba1/simplemail#28.

Newlib libamisslauto.a fails to link with undefined reference to 'errno'

As the subject line says, attempting to use the autoinit stub with newlib results in the "undefined reference to 'errno'" linking error.

Looking at the makefile, it's likely that -mcrt=clib2 is still in the command line when compiling the autoinit stub for newlib, resulting in the linking error.

Fix cert files for 4.4

In the 4.3 release, something appears to have gone wrong with the generation of the cert files in Certs. Specifically, 5ad8a5d6.0 and b0ed035a.0 both contain a complete multi-cert bundle instead of the 2 certs they should contain.

Optional installation of include?

Just save 8 MB for a non-developer.
How about a separate dev archive..?

Trying to compile with vbcc the https.c

I am trying to compile with vbcc the example code https.c, but I am getting errors. I am using a cross compiling environment, with AmigaOS 4 SDK and latest AmiSSL 4.4 dev files installed.

I am using the following command to compile it:
vc +aosppc +newlib -I/opt/sdk/ppc-amigaos/Include/include_h -I/opt/sdk/ppc-amigaos/Include/netinclude -I/opt/sdk/ppc-amigaos/newlib/include -I/opt/sdk/AmiSSL/include -lauto https.c -o https -v

I get a few errors and a lot of warnings. I think that I am missing something.

vc frontend for vbcc (c) in 1995-2016 by Volker Barthelmann
vbccppc -quiet "https.c" -o= "/tmp/file3LINRb.asm" -I/opt/sdk/ppc-amigaos/Include/include_h -I/opt/sdk/ppc-amigaos/Include/netinclude -I/opt/sdk/ppc-amigaos/newlib/include -I/opt/sdk/AmiSSL/include -elf -no-regnames -no-multiple-ccs -madd -c99 -use-commons  -O=1 -I$VBCC/targets/ppc-amigaos/include -D__amigaos4__
>	BPTR err = ErrorOutput();
warning 161 in line 48 of "https.c": implicit declaration of function <ErrorOutput>
>	return(err ? err : Output());
warning 161 in line 50 of "https.c": implicit declaration of function <Output>
>						Printf("SSL connection using %s\n", SSL_get_cipher(ssl));
warning 161 in line 119 of "https.c": implicit declaration of function <Printf>
>								FPrintf(GetStdErr(), "Warning: couldn't read subject name in certificat
warning 161 in line 134 of "https.c": implicit declaration of function <FPrintf>
>									FWrite(Output(), buffer, ssl_err, 1);
warning 161 in line 157 of "https.c": implicit declaration of function <FWrite>
>								FFlush(Output());
warning 161 in line 159 of "https.c": implicit declaration of function <FFlush>
>					CloseSocket(sock);
warning 161 in line 181 of "https.c": implicit declaration of function <CloseSocket>
>	if (!(SocketBase = OpenLibrary("bsdsocket.library", 4)))
warning 161 in line 215 of "https.c": implicit declaration of function <OpenLibrary>
>	if (!(SocketBase = OpenLibrary("bsdsocket.library", 4)))
error 39 in line 215 of "https.c": invalid types for assignment
>	else if (!(ISocket = (struct SocketIFace *)GetInterface(SocketBase, "main", 1,
warning 161 in line 218 of "https.c": implicit declaration of function <GetInterface>
>	                                          AMISSLMASTER_MIN_VERSION)))
error 39 in line 222 of "https.c": invalid types for assignment
>	else if (!InitAmiSSLMaster(AMISSL_CURRENT_VERSION, TRUE))
warning 161 in line 230 of "https.c": implicit declaration of function <InitAmiSSLMaster>
>	else if (!(AmiSSLBase = OpenAmiSSL()))
warning 161 in line 232 of "https.c": implicit declaration of function <OpenAmiSSL>
>	else if (!(AmiSSLBase = OpenAmiSSL()))
error 39 in line 232 of "https.c": invalid types for assignment
>	                    TAG_DONE) != 0)
warning 161 in line 242 of "https.c": implicit declaration of function <InitAmiSSL>
>			CleanupAmiSSL(TAG_DONE);
warning 161 in line 265 of "https.c": implicit declaration of function <CleanupAmiSSL>
>			DropInterface((struct Interface *)IAmiSSL);
warning 161 in line 266 of "https.c": implicit declaration of function <DropInterface>
>		CloseAmiSSL();
warning 161 in line 273 of "https.c": implicit declaration of function <CloseAmiSSL>
>	CloseLibrary(AmiSSLMasterBase);
warning 161 in line 282 of "https.c": implicit declaration of function <CloseLibrary>
>	if ((sock = socket(AF_INET, SOCK_STREAM, 0)) >= 0)
warning 161 in line 306 of "https.c": implicit declaration of function <socket>
>			addr.sin_addr.s_addr = inet_addr(proxy);
warning 161 in line 313 of "https.c": implicit declaration of function <inet_addr>
>		if (connect(sock, (struct sockaddr *)&addr, sizeof(addr)) >= 0)
warning 161 in line 322 of "https.c": implicit declaration of function <connect>
>				if (send(sock, buffer, strlen(buffer), 0) >= 0)
warning 161 in line 340 of "https.c": implicit declaration of function <send>
>					if ((len = recv(sock, buffer, sizeof(buffer) - 1, 0)) >= 0)
warning 161 in line 347 of "https.c": implicit declaration of function <recv>
3 errors found!
vbccppc -quiet "https.c" -o= "/tmp/file3LINRb.asm" -I/opt/sdk/ppc-amigaos/Include/include_h -I/opt/sdk/ppc-amigaos/Include/netinclude -I/opt/sdk/ppc-amigaos/newlib/include -I/opt/sdk/AmiSSL/include -elf -no-regnames -no-multiple-ccs -madd -c99 -use-commons  -O=1 -I$VBCC/targets/ppc-amigaos/include -D__amigaos4__ failed

I tried to use PosixLib as well, but no luck.

Any idea what I am missing there?

OS3/m68k build: "openssl s_client -connect google.com:443" doesn't work

Due to some problems the current sources compiled for OS3/m68k aren't able to initiate connections to google.com:443. When using the openssl command-line client the following output is shown:

$ openssl s_client -cipher "ECDHE-RSA-CHACHA20-POLY1305" -connect google.com:443
CONNECTED(00000000)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com
verify return:1
0:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:../../openssl/ssl/record/rec_layer_s3.c:1394:SSL alert number 20
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIH7TCCBtWgAwIBAgIIBeYggpOQQCwwDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE
BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl
cm5ldCBBdXRob3JpdHkgRzIwHhcNMTYxMTAzMDE0OTQxWhcNMTcwMTI2MDExMzAw
WjBmMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN
TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEVMBMGA1UEAwwMKi5n
b29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt7pS6S+Z
TDX9tGBRTxM7wcbH9z3+A0TfG0MKxTywnXviFySw2ff08QpG7NlBlPSWLlB2tQIG
OuutvHW5FPo4Z+Ie5tJ30wxbiF9ibkl43g85wiEM0Xz+xAC7YoH6WbYOP8BqOhtO
cJwjY0MSzgdD8YZOhENnWGK8uUEyTV5un1+/PTLoG/+oj7Xvwxpw+XmJMcihuxy5
W3L/sMvoWw0ZhbJIlzhNDQwjyGcVYiniJS1FS22WdCMYgLfCE63BXjdjS5P4jkA+
DgCcmz8meMevQe2mmC2VSUTBvv9mhwTc961l9DaHM3pTLRLTvOAcy1oN8M3Au9gw
b5ozrBzBfHk5swIDAQABo4IEujCCBLYwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsG
AQUFBwMCMIIDhgYDVR0RBIIDfTCCA3mCDCouZ29vZ2xlLmNvbYINKi5hbmRyb2lk
LmNvbYIWKi5hcHBlbmdpbmUuZ29vZ2xlLmNvbYISKi5jbG91ZC5nb29nbGUuY29t
ghYqLmdvb2dsZS1hbmFseXRpY3MuY29tggsqLmdvb2dsZS5jYYILKi5nb29nbGUu
Y2yCDiouZ29vZ2xlLmNvLmlugg4qLmdvb2dsZS5jby5qcIIOKi5nb29nbGUuY28u
dWuCDyouZ29vZ2xlLmNvbS5hcoIPKi5nb29nbGUuY29tLmF1gg8qLmdvb2dsZS5j
b20uYnKCDyouZ29vZ2xlLmNvbS5jb4IPKi5nb29nbGUuY29tLm14gg8qLmdvb2ds
ZS5jb20udHKCDyouZ29vZ2xlLmNvbS52boILKi5nb29nbGUuZGWCCyouZ29vZ2xl
LmVzggsqLmdvb2dsZS5mcoILKi5nb29nbGUuaHWCCyouZ29vZ2xlLml0ggsqLmdv
b2dsZS5ubIILKi5nb29nbGUucGyCCyouZ29vZ2xlLnB0ghIqLmdvb2dsZWFkYXBp
cy5jb22CDyouZ29vZ2xlYXBpcy5jboIUKi5nb29nbGVjb21tZXJjZS5jb22CESou
Z29vZ2xldmlkZW8uY29tggwqLmdzdGF0aWMuY26CDSouZ3N0YXRpYy5jb22CCiou
Z3Z0MS5jb22CCiouZ3Z0Mi5jb22CFCoubWV0cmljLmdzdGF0aWMuY29tggwqLnVy
Y2hpbi5jb22CECoudXJsLmdvb2dsZS5jb22CFioueW91dHViZS1ub2Nvb2tpZS5j
b22CDSoueW91dHViZS5jb22CFioueW91dHViZWVkdWNhdGlvbi5jb22CCyoueXRp
bWcuY29tghphbmRyb2lkLmNsaWVudHMuZ29vZ2xlLmNvbYILYW5kcm9pZC5jb22C
G2RldmVsb3Blci5hbmRyb2lkLmdvb2dsZS5jboIEZy5jb4IGZ29vLmdsghRnb29n
bGUtYW5hbHl0aWNzLmNvbYIKZ29vZ2xlLmNvbYISZ29vZ2xlY29tbWVyY2UuY29t
ghlwb2xpY3kubXRhLXN0cy5nb29nbGUuY29tggp1cmNoaW4uY29tggp3d3cuZ29v
Lmdsggh5b3V0dS5iZYILeW91dHViZS5jb22CFHlvdXR1YmVlZHVjYXRpb24uY29t
MGgGCCsGAQUFBwEBBFwwWjArBggrBgEFBQcwAoYfaHR0cDovL3BraS5nb29nbGUu
Y29tL0dJQUcyLmNydDArBggrBgEFBQcwAYYfaHR0cDovL2NsaWVudHMxLmdvb2ds
ZS5jb20vb2NzcDAdBgNVHQ4EFgQUcyFEjIFx7LZzVeInfNE27yi31cIwDAYDVR0T
AQH/BAIwADAfBgNVHSMEGDAWgBRK3QYWG7z2aLV29YG2u2IaulqBLzAhBgNVHSAE
GjAYMAwGCisGAQQB1nkCBQEwCAYGZ4EMAQICMDAGA1UdHwQpMCcwJaAjoCGGH2h0
dHA6Ly9wa2kuZ29vZ2xlLmNvbS9HSUFHMi5jcmwwDQYJKoZIhvcNAQELBQADggEB
ADOD/tov1yJDMuXXMDhol9oufYXouKtD8VkQFouNYDU0qoULpQh3sjs+n8JlHhHg
EiAYnP/S4UvIsl0rM6nSfvARdGDO69pbn9TsBef662OE+2PiROGTIS+YCxBI4HtF
aOwL8omkWwKjLEA1DdhMyOtctQr+6pzZ0VvDRzCN1E4JAEzNDNfHQ3aAeZ+RBWQB
TFUYu4hfW80Gy0Ag/kEa5zC0flLND+/8FNSE7p5+2F89MXF6hw1Bm5mF1JbPT9F2
oTDl4+YGq3XRtw32f31K7V3nLmA82d6YeBFmINtyIx2BMG8lTIPuH/A1xMD2izMB
HGvFmiBcnd517wVzteZbiNU=
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4352 bytes and written 261 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-CHACHA20-POLY1305
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-CHACHA20-POLY1305
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 5051C5AA207195CD5A73889B2630EFF28A01CF8B046163B55565EFECC3F05DDCB962B9B1DBB52A9F6491B73892236FAE
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1479037411
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---

At the end of this output openssl doesn't change into interactive mode. Also note the following error message at the very top of the output:

0:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:../../openssl/ssl/record/rec_layer_s3.c:1394:SSL alert number 20

After further investigation it seems to be related to the elliptic curve algorithms used which currently only google.com seems to be massively using worldwide. So changing the openssl command line call from:

openssl s_client -cipher "ECDHE-RSA-CHACHA20-POLY1305" -connect google.com:443 -curves X25519

to

openssl s_client -cipher "ECDHE-RSA-CHACHA20-POLY1305" -connect google.com:443 -curves prime256v1

seems to solve the issue and connection can then be initiated to google.com.

"OpenSSL speed" command appears to be broken

Running "OpenSSL speed" appears to hang on the first test. Use "OpenSSL speed mdc2" for a faster test. Same on OS4 and OS3. Works with AmiSSL v3.

Enabling TLS v1.3 results in "no shared cipher" error (AmiSSL 4.3)

TLS v1.3 support appears to be broken. At least, for servers.

If TLSv1.3 is enabled (for servers), then the connection fails with a "no shared cipher" error. I've had this both with my own code, and with openssl's s_server. You can see it by doing the following:

• Generate a self-signed key
• Start the built-in OpenSSL server:
  openssl s_server -key test.key -cert test.crt -verify 0 -accept 443 -WWW verify depth is 0
• Now try to connect to this server using openssl s_client, or Firefox. It will fail, and the server will print the "no shared cipher" error (NOTE: Odyssey will work, because it doesn't support TLSv1.3, forcing it to use a lower protocol)
• Next, stop the server, and rerun it with TLSv1.2 only:
  openssl s_server -tlsv1_2 -key test.key -cert test.crt -verify 0 -accept 443 -WWW verify depth is 0
• When you try to connect again, then it'll work just fine

OS3/m68k issue: 'ssltest -test_cipherlist' fails

When executing the following test command an error is returned for the OS3/m68k build:

cd bin_os3/openssl
ssltest -test_cipherlist

After some debugging the following execution path was identified:

1. openssl/ssl/ssltest.c:3000 – meth = SSLv2_method() returns a SSL_METHOD structure which also contains function pointers
2. openssl/ssl/ssltest.c:3001 – ci = meth->get_cipher(i++) the corresponding callback function is called
3. openssl/ssl/s2_lib.c:306 – ssl2_get_cipher() is the associated callback function referenced via ->get_cipher() call.
4. openssl/ssl/s2_lib.c:306 – in ssl2_get_cipher() the structure ssl2_ciphers is directly referenced but the memory area is incorrectly mapped.

So the call SSLv2_method()->get_cipher() always returns an incorrect address to the ssl2_ciphers[] array. If the same execution is, however, performed directly from within AmiSSL the correct memory is mapped to the ssl2_ciphers[] location. Only direct calls from third-party apps directly using the SSLv2_method() returned function pointer won't work.

vbcc proto/inline issues

1. By just including proto/amissl.h, the resulting binary will increase 40kBytes+, unless at least -O3 is used:

   $ cat EmptyAmiSSLTest.c
   #include <proto/amissl.h>
   
   struct Library *AmiSSLBase;
   
   int EmptyAmiSSLTest(void) {
       return 0;
   }
   $ make EmptyAmiSSLTest EmptyAmiSSLTest_O3                                   
   vc +aos68k -nostdlib -c99 -O2 -lvc -IAmiSSL/Developer/include -o EmptyAmiSSLTest EmptyAmiSSLTest.c
   vc +aos68k -nostdlib -c99 -O3 -lvc -IAmiSSL/Developer/include -o EmptyAmiSSLTest_O3 EmptyAmiSSLTest.c
   $ ls -la EmptyAmiSSLTest EmptyAmiSSLTest_O3                                   
   -rwxr-xr-x  1 patrik  access_bpf  43672  2 Sep 22:12 EmptyAmiSSLTest*
   -rwxr-xr-x  1 patrik  access_bpf     56  2 Sep 22:12 EmptyAmiSSLTest_O3*
   

   This is not normal when using libraries with vbcc or any compiler on/for the Amiga. Also, apart from building very slowly when proto/amissl.h is included, I noticed that it consumes a lot of memory to build this nop-exe - a 16MB Amiga was not enough.

2. If a local instead of global AmiSSLBase is used (together with -D__NOLIBBASE__ or not), it will not compile or link:

   $ cat LocalBaseAmiSSLTest.c 
   #include <proto/amissl.h>
   
   int LocalBaseAmiSSLTest(void) {
   	struct Library *AmiSSLBase;
   	return 0;
   }
   $ make LocalBaseAmiSSLTest
   vc +aos68k -nostdlib -c99 -O2 -lvc -D__NOLIBBASE__ -IAmiSSL/Developer/include -o LocalBaseAmiSSLTest LocalBaseAmiSSLTest.c
   >DEFINE_STACK_OF(SCT)
   error 82 in line 131 of "amissl/inline.h": unknown identifier <AmiSSLBase>
   	included from file "AmiSSL/Developer/include/proto/amissl.h":79
   	included from file "LocalBaseAmiSSLTest.c":1
   >DEFINE_STACK_OF(SCT)
   error 82 in line 131 of "amissl/inline.h": unknown identifier <AmiSSLBase>
   	included from file "AmiSSL/Developer/include/proto/amissl.h":79
   	included from file "LocalBaseAmiSSLTest.c":1
   >DEFINE_STACK_OF(SCT)
   error 82 in line 131 of "amissl/inline.h": unknown identifier <AmiSSLBase>
   	included from file "AmiSSL/Developer/include/proto/amissl.h":79
   	included from file "LocalBaseAmiSSLTest.c":1
   >DEFINE_STACK_OF(SCT)
   error 82 in line 131 of "amissl/inline.h": unknown identifier <AmiSSLBase>
   	included from file "AmiSSL/Developer/include/proto/amissl.h":79
   	included from file "LocalBaseAmiSSLTest.c":1
   >DEFINE_STACK_OF(SCT)
   error 82 in line 131 of "amissl/inline.h": unknown identifier <AmiSSLBase>
   	included from file "AmiSSL/Developer/include/proto/amissl.h":79
   	included from file "LocalBaseAmiSSLTest.c":1
   >DEFINE_STACK_OF(SCT)
   error 82 in line 131 of "amissl/inline.h": unknown identifier <AmiSSLBase>
   	included from file "AmiSSL/Developer/include/proto/amissl.h":79
   	included from file "LocalBaseAmiSSLTest.c":1
   >DEFINE_STACK_OF(SCT)
   error 82 in line 131 of "amissl/inline.h": unknown identifier <AmiSSLBase>
   	included from file "AmiSSL/Developer/include/proto/amissl.h":79
   	included from file "LocalBaseAmiSSLTest.c":1
   >DEFINE_STACK_OF(SCT)
   error 82 in line 131 of "amissl/inline.h": unknown identifier <AmiSSLBase>
   	included from file "AmiSSL/Developer/include/proto/amissl.h":79
   	included from file "LocalBaseAmiSSLTest.c":1
   >DEFINE_STACK_OF(SCT)
   error 82 in line 131 of "amissl/inline.h": unknown identifier <AmiSSLBase>
   	included from file "AmiSSL/Developer/include/proto/amissl.h":79
   	included from file "LocalBaseAmiSSLTest.c":1
   >DEFINE_STACK_OF(SCT)
   error 82 in line 131 of "amissl/inline.h": unknown identifier <AmiSSLBase>
   	included from file "AmiSSL/Developer/include/proto/amissl.h":79
   	included from file "LocalBaseAmiSSLTest.c":1
   Maximum number of errors reached!
   unexpected end of file
   10 errors found!
   vbccm68k -quiet -hunkdebug "LocalBaseAmiSSLTest.c" -o= "/var/tmp/tmp.0.asm" -c99 -D__NOLIBBASE__ -IAmiSSL/Developer/include  -O=1023 -I$VBCC/targets/m68k-amigaos/include -I/opt/sdk/NDK_3.9/Include/include_h failed
   make: *** [LocalBaseAmiSSLTest] Error 1
   

   Also not normal and I think this has something to do with the first issue.

AmiSSLTest.zip

There's no specification how callback parameters should be stored

AmiSSL currently doesn't seem to specify how callback parameters are to be stored. For example, it's completely unclear how parameters should be passed to the callback function passed to SSL_CTX_set_next_proto_select_cb. My tests have shown that they seem to be passed on the stack but there really should be some specification. This is very important when it comes to define trap handlers for MorphOS, for example, to allow PPC native programs call into 68k AmiSSL and vice versa.

Also see this discussion.

Includes don't work on MorphOS

Since AmiSSL isn't available for MorphOS yet, I thought I could just use the 68k version on MorphOS for the time being. But unfortunately, the AmiSSL includes don't seem to work on MorphOS either. The file amissl/inline.h triggers lots of errors when trying to compile on MorphOS. Here are just the first few lines:

In file included from /bin/../lib/gcc-lib/ppc-morphos/4.4.4/../../../../ppc-morphos/include/proto/amissl.h:79,
		 from /bin/../lib/gcc-lib/ppc-morphos/4.4.4/../../../../ppc-morphos/include/openssl/ssl.h:2,
		 from vtls/openssl.c:54:
/bin/../lib/gcc-lib/ppc-morphos/4.4.4/../../../../ppc-morphos/include/amissl/inline.h: In function 'sk_SCT_pop_free':
/bin/../lib/gcc-lib/ppc-morphos/4.4.4/../../../../ppc-morphos/include/amissl/inline.h:125: error: expected expression before 'OPENSSL_STACK'
/bin/../lib/gcc-lib/ppc-morphos/4.4.4/../../../../ppc-morphos/include/amissl/inline.h: In function 'sk_SCT_set_cmp_func':
/bin/../lib/gcc-lib/ppc-morphos/4.4.4/../../../../ppc-morphos/include/amissl/inline.h:125: error: '__fpr' undeclared (first use in this function)
/bin/../lib/gcc-lib/ppc-morphos/4.4.4/../../../../ppc-morphos/include/amissl/inline.h:125: error: (Each undeclared identifier is reported only once
/bin/../lib/gcc-lib/ppc-morphos/4.4.4/../../../../ppc-morphos/include/amissl/inline.h:125: error: for each function it appears in.)
/bin/../lib/gcc-lib/ppc-morphos/4.4.4/../../../../ppc-morphos/include/amissl/inline.h:125: error: expected expression before 'OPENSSL_STACK'
/bin/../lib/gcc-lib/ppc-morphos/4.4.4/../../../../ppc-morphos/include/amissl/inline.h: In function 'sk_CTLOG_pop_free':
/bin/../lib/gcc-lib/ppc-morphos/4.4.4/../../../../ppc-morphos/include/amissl/inline.h:126: error: expected expression before 'OPENSSL_STACK'
/bin/../lib/gcc-lib/ppc-morphos/4.4.4/../../../../ppc-morphos/include/amissl/inline.h: In function 'sk_CTLOG_set_cmp_func':
/bin/../lib/gcc-lib/ppc-morphos/4.4.4/../../../../ppc-morphos/include/amissl/inline.h:126: error: '__fpr' undeclared (first use in this function)
/bin/../lib/gcc-lib/ppc-morphos/4.4.4/../../../../ppc-morphos/include/amissl/inline.h:126: error: expected expression before 'OPENSSL_STACK'
/bin/../lib/gcc-lib/ppc-morphos/4.4.4/../../../../ppc-morphos/include/amissl/inline.h: In function 'sk_X509_ALGOR_pop_free':
/bin/../lib/gcc-lib/ppc-morphos/4.4.4/../../../../ppc-morphos/include/amissl/inline.h:127: error: expected expression before 'OPENSSL_STACK'
/bin/../lib/gcc-lib/ppc-morphos/4.4.4/../../../../ppc-morphos/include/amissl/inline.h: In function 'sk_X509_ALGOR_set_cmp_func':
/bin/../lib/gcc-lib/ppc-morphos/4.4.4/../../../../ppc-morphos/include/amissl/inline.h:127: error: '__fpr' undeclared (first use in this function)
/bin/../lib/gcc-lib/ppc-morphos/4.4.4/../../../../ppc-morphos/include/amissl/inline.h:127: error: expected expression before 'OPENSSL_STACK'
(and lots more, all related to _pop_free and _set_cmp_func)

Please fix.

OpenSSL speed output order issue when redirected

When running for the speed test of the OpenSSL command, it works fine in the shell:

However, if its output is redirected to a file like AmiSSL:OpenSSL speed -evp chacha20-poly1305 >ram:output.txt, the result part of the 16384 size blocks line appears at the last line instead:

10.Ram Disk:> type ram:output.txt 
First we calculate the approximate speed ...
Doing chacha20-poly1305 20480 times on 16 size blocks: 81920 chacha20-poly1305's in 37.08s
Doing chacha20-poly1305 20480 times on 64 size blocks: 20480 chacha20-poly1305's in 27.82s
Doing chacha20-poly1305 20480 times on 256 size blocks: 5120 chacha20-poly1305's in 25.82s
Doing chacha20-poly1305 20480 times on 1024 size blocks: 1280 chacha20-poly1305's in 25.34s
Doing chacha20-poly1305 20480 times on 8192 size blocks: 160 chacha20-poly1305's in 25.16s
Doing chacha20-poly1305 20480 times on 16384 size blocks: OpenSSL 1.1.1l  24 Aug 2021
built on: Wed Aug 25 13:06:38 2021 UTC
options:bn(64,32) md2(char) rc4(char) des(long) aes(partial) idea(int) blowfish(ptr) 
compiler: m68k-amigaos-gcc -resident32 -mcrt=clib2 -m68020-40 -msoft-float -W -Wall -Wno-unused -O1 -I../../libcmt -DAMISSL_COMPILE -D__NO_NET_API -DB_ENDIAN -DOPENSSL_SYS_AMIGA -DOPENSSL_NO_STDIO -D__C_MACROS__ -DNO_INLINE_VARARGS -D__amigaos3__ -DNDEBUG -I../../include -I../../include/netinclude
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
chacha20-poly1305       35.35k       47.11k       50.76k       51.73k       52.10k       52.10k
80 chacha20-poly1305's in 25.16s

Tested this on both 3.1 and 3.2 with the same result.

OS3/m68k issue: build fails with "Internal compiler error in `instantiate_virtual_regs_1', at function.c:3885"

When building our latest AmiSSL sources (with openssl-1.1.x compatibility) the m68k-amigaos build fails if the optimization level is set to -O0:

[...]
m68k-amigaos-gcc -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSLDIR="\"AmiSSL:\"" -DENGINESDIR="\"AmiSSL:engines\"" -m68020-60 -msoft-float -DNO_INLINE_VARARGS -D__NO_NET_API -DB_ENDIAN -DOPENSSL_SYS_AMIGA -D__amigaos3__ -DOPENSSL_NO_STDIO -I../../include -I../../include/netinclude -W -Wall -O0 -g -gstabs -DBN_DEBUG -DCONF_DEBUG -DDEBUG  -resident32 -DAMISSL_COMPILE -I../../libcmt/include  -Iinclude -I../../openssl -I../../openssl/crypto/include -I../../openssl/include -Icrypto/include -c -o crypto/bn/bn_nist.o ../../openssl/crypto/bn/bn_nist.c
../../openssl/crypto/bn/bn_nist.c: In function `BN_nist_mod_192':
../../openssl/crypto/bn/bn_nist.c:491: Internal compiler error in `instantiate_virtual_regs_1', at function.c:3885
Please submit a full bug report.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

When compiling with -O1 this problems doesn't appear anymore (a workaround).

To investigate this issue on the project maintaining the Amiga cross compiler environments I have opened the following issue:

adtools/amigaos-cross-toolchain#29

As soon as this issue is resolved in the GCC 2.95.3 cross compiler we have to revisit this ticket again.

Update installer to allow installation even while AmiSSL is in use

The current installer's behaviour is to quit with an error if AmiSSL is in use. It would be more flexible if it were to simply install the files, and ask the user if he/she wants to reboot to complete the installation.

64bit arguments passing with 68k .library ABI

We're trying to provide some support for AmiSSL in Free Pascal Compiler. This involves creating our own headers for AmiSSL, to talk to the ABI directly, based on the C includes. However, when it comes to the Motorola 68k/AmigaOS3 version, it looks like some of the C inline macros only specify a single register (say, d0) to pass uint64_t or int64_t parameters to the function. One simple example is OPENSSL_init_ssl(), where the flags parameter is uint64_t, yet if I check the inline macros, I only see d0 mentioned. This obviously cannot work properly, however, in the amissl_lib.sfd, clearly (d0-d1) as register pair is specified to be used, but I can't see any trace of this in the inline macros.

So, what's the deal here? The .sfd file is ignored, the inline macros are wrong, did we find an issue, or it works regardless through some C compiler magic I we are not aware of? Thanks.

Installer doesn't work on MorphOS

Apparently, AmiSSL's installer needs some fixing for MorphOS. See here:
https://forums.hollywood-mal.com/viewtopic.php?f=2&t=2328&start=20#p12595

AROS: get sources ported and requirements tested for potential 'baserel' support.

While the top-level Makefile has basic support for compiling AmiSSL for AROS many different things are still missing to actually cleanly compile it for AROS. In addition, requirements are unclear and we potentially have to invite some AROS developers here to contribute their knowledge in getting it properly ported and tested to AROS including 'baserel' support.

Cannot compile SDL example

SORRY!!! I posted in the wrong place! You can delete this issue.

LibreSSL question

Hi,

Thanks for enabling providing openssl-compatible library for Amiga!
I have a question regarding portability. Why openssl was chosen as a base when this implementation exists: https://github.com/libressl-portable/portable ? Would it be possible to incorporate all improvements over standard openssl tree into some patch and try to rebase it on top of libressl?

Crashes on Tabor A1222

I am beta testing Tabor A1222 and the latest AmigaOS running on that machine. I get SSL issues on websites using latest IBrowse 2.5.1 and latest AWeb PPC version, which both use AmiSSL. I also have issues with pythonSSL module (http://os4depot.net/?function=showfile&file=library/misc/pythonssl.lha), which also uses AmiSSL to work.

The problem might be the FPU of the system, which as much as I know, doesn't exist.

OpenSSL command crashes on OS3

The OpenSSL command in AmiSSL 4.2 is fine, but in AmiSSL 4.3 it crashes during startup on OS3. My debugging availability for OS3 is somewhat limited currently, bit SnoopDos shows it crashing after opening locale.library and before it even attempts to open amisslmaster.library. E-UAE shows it crashes while attempting to run some library call, but with a null pointer in A6.

Install script fails to modify user-startup on MorphOS

No lines are added to the S:user-startup file when installing AmiSSL 4.3 on MorphOS with the provided installation script.

If a user doesn't happen to have the assigns from a previous installation/version, he has to dig out the reason why AmiSSL doesn't work after a fresh install, and add them manually.

Installer script doesn't copy the amissl_v111d.library file on MorphOS

The installer script in AmiSSL 4.4 archive doesn't copy the amissl_v111d.library file at all on MorphOS. So, AmiSSL 4.4 doesn't work after installation/update unless you copy the file manually to the correct location.

Cannot use YAM to get emails with AmiSSL 4.3

Hi Jens,
Thanks for AMiSSL4.3.
Unfortunately, YAM latest nightly build as of 23.02.19 can no longer connect to the live server to download emails, though it can connect to the upload server. It was working fine with V4.2. I just tried to re-install 4.2 but it didnt work because traces of 4.3 were still recognised. Real Amiga OS3.9 A1200/060. I hope its not that the real miggy is too slow now.

Random generator init is very slow

With the 68k version of AmiSSL (4.10 tested), the random generator init is very slow, apparently disregarding how fast processor you have. You can however vary the speed of it somewhat by changing the native screenmode - the higher refresh rate, the faster the random generator init runs.

First three runs on an A3000 030@25Mhz, with varying refresh rates from 50-70Hz (PAL, NTSC, Euro72 without VGAOnly). AmiSSL has already been pre-initialized with a run of InitAmiSSLTest, so the first test would not have a distractingly large OpenAmiSSL(). The initialization is taken from the https.c example and the function of interest is RAND_seed():

8.Ram Disk:> sysinfo -p | search vblank 
    19 VBlank Frequency in Hz....................... 50
8.Ram Disk:> pt:InitAmiSSLTest  
OpenLibrary(amisslmaster.library, 4): 0.001344s
InitAmiSSLMaster(16, 0):              0.000067s
OpenAmiSSL():                         0.027808s
InitAmiSSL(0)                         0.000242s
OPENSSL_init_ssl(0020000E, 0):        1.830160s
GenerateRandomSeed(073CACBC, 128):    0.001965s
RAND_seed(073CACBC, 128):             2.269295s

8.Ram Disk:> sysinfo -p | search vblank 
    19 VBlank Frequency in Hz....................... 60
8.Ram Disk:> pt:InitAmiSSLTest  
OpenLibrary(amisslmaster.library, 4): 0.001530s
InitAmiSSLMaster(16, 0):              0.000064s
OpenAmiSSL():                         0.024569s
InitAmiSSL(0)                         0.000238s
OPENSSL_init_ssl(0020000E, 0):        1.812117s
GenerateRandomSeed(073CACBC, 128):    0.001963s
RAND_seed(073CACBC, 128):             1.933553s

If the same thing is run on a comparatively blistering fast UAE in the same manner, the RAND_seed() times are still the same:

 6.Ram Disk:> sysinfo -p | search vblank
    19 VBlank Frequency in Hz....................... 50
6.Ram Disk:> work:InitAmiSSLTest 
OpenLibrary(amisslmaster.library, 4): 0.000001s
InitAmiSSLMaster(16, 0):              0.000000s
OpenAmiSSL():                         0.000507s
InitAmiSSL(0)                         0.000000s
OPENSSL_init_ssl(0020000E, 0):        0.058342s
GenerateRandomSeed(1013863C, 128):    0.000000s
RAND_seed(1013863C, 128):             2.230716s

6.Ram Disk:> sysinfo -p | search vblank
    19 VBlank Frequency in Hz....................... 60
6.Ram Disk:> work:InitAmiSSLTest 
OpenLibrary(amisslmaster.library, 4): 0.000507s
InitAmiSSLMaster(16, 0):              0.000000s
OpenAmiSSL():                         0.001014s
InitAmiSSL(0)                         0.000000s
OPENSSL_init_ssl(0020000E, 0):        0.033483s
GenerateRandomSeed(1013863C, 128):    0.000000s
RAND_seed(1013863C, 128):             1.867976s

Have tested on several different machines with the same result for RAND_seed().

I think the issue is a combination of these two things:

1. timer.device/UNIT_VBLANK is used for the supposedly 1 microsecond delays, but UNIT_VBLANK gives a minimum delay of 1/refreshrate - https://github.com/jens-maus/amissl/blob/master/openssl/crypto/rand/rand_amiga.c#L121
2. For unknown reason (not documented), 3/4 of data produced by these delays is discarded, reasonably making this already unreasonably slow process four times slower - https://github.com/jens-maus/amissl/blob/master/openssl/crypto/rand/rand_amiga.c#L188

Imagine using AmiSSL in a command line tool, disregarding how fast amiga you have, it would still have a minimal execution time of ~2s.

AmiSSLTest.zip