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

[jens-maus]

@Futaura @tboeckel

Please note this ticket and see if you can fix some of these issues in our current master branch.

[Futaura]

@jens-maus OPENSSL_cleanup() was in pretty much the right place and did not crash here - maybe something else was broken which you have since fixed. I moved it to the more technically correct position though.

Regarding AmiSSLAbort(), this was used only in SAS/C as far as I can tell. When linking AmiSSL.library abort() and _XCEXIT() were mapped to call AmiSSLAbort(). The OpenSSL code used to rely on abort() a fair bit. Not sure what happened with the OS4 port to be honest. OpenSSL has been cleaned up since then though. I see somebody added libcmt/abort.c, which essentially replaces AmiSSLAbort(), and probably abort() should actually call OPENSSL_showfatal() (which itself replaced OpenSSLDie()).

[Futaura]

OK, forget the last bit - OPENSSL_die() calls OPENSSL_showfatal() and abort(). Probably the only change required is to just remove AmiSSLAbort, which is no longer required.

[jens-maus]

Ok, thanks for the explanation. This makes sense. Thus I removed AmiSSLAbort() now completely. Also thanks for the OpenSSL_cleanup() fix. So only a few things remain apart from general cleanup, etc.

[Futaura]

Regarding IIntuition/BIO_vsnprintf in amisslmaster.library, it links fine here without them. It would only have been an issue if fprintf() was being used somewhere, which it isn't. Perhaps you had some debug code somewhere (in libcmt() perhaps)?

[jens-maus]

Well, here I am still getting a linker error like:

$ make -j1 OS=os4
[...]
  LD build_os4/amisslmaster.library
./build_os4/libcmt/libcmt.a(fprintf.o): In function `fprintf':
fprintf.c:19: undefined reference to `BIO_vsnprintf'
fprintf.c:29: undefined reference to `IIntuition'
fprintf.c:29: undefined reference to `IIntuition'
collect2: ld returned 1 exit status
Makefile:448: recipe for target 'build_os4/amisslmaster.library' failed

When compiling without debug framework (make -j1 OS=os4 DEBUG=) it works, though. However, it is strange since I think I never used fprintf() directly?!?! So the question really is where does this fprintf() come from??!

[Futaura]

assert-->abort-->perror-->fprintf

Not sure on the ideal solution - also need to consider OPENSSL_die() which displays an error itself before calling abort() which displays another error.

[jens-maus]

Ok, but what wonders me is that assert() should normally be eeplaced by ASSERT() of our own debug framework and I dunno why this redefinition of assert() doesn't work (look at debug.h)

[Futaura]

Yes, but the ASSERT() macro calls abort()

[jens-maus]

Have a look for my latest changes, I think I found a proper way to deal with that by simply using vsnprintf() directly (which we have now in libcmt) and also opening intuition.library in amisslmaster directly.

[Futaura]

Yes, looks OK to me - that was one solution I was thinking of, but was unsure of the state of vsnprintf and whether you perhaps wanted to redirect the abort() output to kprintf() in debug builds. So, I'm happy to go with what you think is best. Hopefully, it is code that will never get called anyway.

[jens-maus]

@tboeckel
Can you please take care of point 7 (make release) of our todo list?

[jens-maus]

Please note that point 6 (travis support) has been integrated.

[Futaura]

Has point 7 actually been started? I can look into this, but I don't want to start if somebody else already has and hasn't committed the changes.

[Futaura]

I shall start work modifying the installer script if there are no objections? I'll use something like your codesets library installer as a reference. Which OS versions will be supported in the initial release - just OS3 and OS4?

[tboeckel]

No objections from my side. Just go ahead.

[Futaura]

Ok. How about the install location? It was always the case that the libs went in AmiSSL:Libs and certs in AmiSSL:Certs where AmiSSL: could be chosen by the user in the installer. However, the version that shipped with OS4 had the libs in LIBS: and AmiSSL: was assigned to DEVS:AmiSSL as it was integrated as a system component. Which way do you think we should go for v4?

[Futaura]

After thinking about this some more, do we even need the AmiSSL: assign at all? Would it be better to install the libs in LIBS: on all systems, like on OS4, instead of allowing the user to choose to install elsewhere?

However, applications do need to know where to find the certs... Perhaps amisslmaster.library could set the assign or we could add an API call(s) so apps can obtain the drawer. Or apps could be changed to use DEVS:AmiSSL/certs instead of AmiSSL:certs.

Also, not sure if DEVS:AmiSSL was the best place to put the certs - perhaps they should be moved to LIBS: AmiSSL?

[raziel-]

What about DEVS:Internet/certs?

It should be available on all AMigaOS derivates(?)...and other programs (YAM, browsers?) could make use of this general path in future versions without putting their own versions (probably even outdated) in other places (easier to keep track of updates too).

imho

[jens-maus]

Back from a short skiing vacation I think that we shouldn't touch the default locations for the global certificates, library locations, etc. at this time. The locations are unfortunately different for all the different AmigaOS incarnations, however, they are somehow fixed now. Thus, OS4 puts the libs directly to LIBS: while on OS3 AmiSSL was always relative to the AmiSSL: assign. The same goes for the global certificate directory. Changing this behaviour now would IMHO just make things more complicated.

@Futaura It would be great if you could work on getting the installer script in a state that it actually works on all platforms. I simply lack the time for that. This, and the missing make release target is actually the last minor thing why there haven't been any new AmiSSLv4 release yet. Technically AmiSSLv4 should be at a state to actually release it to the public. So just have a look at the current installer script (https://github.com/jens-maus/amissl/blob/master/dist/Install-AmiSSL). So looking forward to your changes.

[Futaura]

I guess that kind of makes sense, especially where backwards compatibility is concerned, although maintaining a different Installation layout for OS4 itself complicates matters. Anyway, the installer is pretty much done.

What about the SDK? Are we going to include all the developer files in the release archive instead of maintaining a separate archive like before?

[jens-maus]

@Futaura Ok, then please checkin your changed installer script ASAP and do your changes incremental rather than checkin in thousand of lines of changes at once.

And yes, one file fits it all. We are in 2017 now, so all people should be able to handle a multiple MB large file where the SDK is always shipped with.

[Futaura]

Sorry - I was adding it right after I posted my message, but I had trouble with simplegit not being able to push. Not sure what broke, but it took me this long to figure out a workaround. Install script is there now.

[jens-maus]

Perfect, then we just need someone taking care of the make release target which will compile+construct a full lha distribution archive in one run and then also have some people testing this archive and your installer script.

[Futaura]

I can take a look at that - I could probably take care of most of it, but you'll probably need to tweak it a little for your build environment.

[midwan]

I could help with testing at the very least... Sorry I can't help more at the moment, I'm in the middle of a few other projects (but I've been monitoring this one closely). :)

[Futaura]

I've added a 'make release' target now: e84ef9f

It is in by no means finished and the script is completely untested so may contain typos, but it is a start. Some things left to take care of are icons and stripping the binaries. Also unsure of whether to release the autoinit libs - the old SDK did have them for OS4 only (newlib and clib2 versions).

[jens-maus]

Thanks to @Futaura for the make release and installer script. I did some final latest modifications to both and are about to release 4.0 ASAP.