AcornSSL

To save me wrestling with git if I don’t have to, does anyone have any problems with this modification to AcornSSL_CreateSession. I’ve added the CreateSession_NewReuseAuth reason code.

AcornSSL_CreateSession                                         SWI &50F88

Initialises a secure session with an existing socket.

On entry
   R0 = socket handle from Socket_Creat
   R1 = bits 0-7  : reason code
        bits 8-31 : reserved for future use (zero)
   R2-Rx dependent on reason code.

reason code = CreateSession_New                               0
On entry    
   R0 = socket handle from Socket_Creat
   R1 = CreateSession_New
   
On exit
   R0 = ssl handle

Use
   This SWI performs a similar function to AcornSSL_Creat, but allows the
   caller to handover a previously opened socket.

reason code = CreateSession_NewReuseAuth                     1
On entry    
   R0 = socket handle from Socket_Creat
   R1 = CreateSession_NewReuseAuth
   R2 = ssl handle of another secure session already authenticated with the server.

On exit
   R0 = ssl handle

Use
   This SWI performs a similar function to AcornSSL_Creat, but allows the
   caller to handover a previously opened socket.
   Uses the authentication of another authenticated secure session to connect.

Looks ok to me … from my very limited understanding.
The values of CreateSession_New and CreateSession_NewReuseAuth would be useful though.

To the right of the names.

So, rather than enlist the app’s help in storing the extension data, you’re doing it all in the module?

I’m not saying it’s a problem, but the module has to deal with expiry and memory management.

There is no storing of extra data. Here’s the diff file. It all happens in c.api instead of setting up a new authenticated session the session is just copied from one session to the new one.

Colin, where did you get the AcornSSL code from, and when did you get it?

I’ve been in a somewhat embarrassing discussion in csan about your module, and “version hell”, where it has been pointed out that you’re using mbedTLS two versions out of date and with (at least) two published vulnerabilities.

It won’t be AcornSSL that is the latest version. MbedTLS may well be out of date – I’ve just looked and it’s dated 21 Sep 19 – as I slotted AcornSSL into a Disc download I already had in order for AcornSSL to access its dependencies. The module I distributed was only to test if it worked it wasn’t an official distribution. Are you desperate for a version with the latest MbedTLS I have submitted the change to ROOL so hopefully they will produce a new version.

Colin, where did you get the AcornSSL code from, and when did you get it?

Would it not just be easier all around to let the merge request go through and a new AcornSSL version fall out of the nightly build system?

Wouldn’t it be useful to include a bit of info text at the beginning/end of the module that could be read in a text editor

I’ve been in a somewhat embarrassing discussion in csan about your module, and “version hell”,

I’m going to assume that none of the contributors to the criticism were part of the ROOL “management” – that would involve stones and glass houses etc. Besides, I saw the merge in the git updates alongside stuff from Sprow and I’m sure he’d be commenting if something was amiss.

I’m with Colin on this. I’d say that when working on test code the base code can be out of date within the time you’re working simply because there are other people working on other aspects.

Ok I’ve updated the FTPc1.55b distribution above with an up to date MbedTLS. I had updated the date on the module so you could tell it has changed but this time I’ve added ReuseAuth.1 to the help string.