SecureSockets Bounty

I am prepared to put money up for security software to replace the SecureSockets module.
It sounds to me, but I know little, that something along the lines of what Theo Markettos suggests in the SecureSockets subforum of General is the way to go. Porting Open SSL and mbedTLS and using them as shared libraries sounds easier and easier to keep updated then other solutions.
I hope others and ROOL agree so that we can get this off the ground. After all, email is an important application.

For SSH and SFTP too :)

For SSH and SFTP too :)

Yes :)

I’d contribute.

It’s on my list of things to do, if I can get the time.
I would personally avoid anything “open”, as it is usually tied to the gcc toolchain – great for linux, dreadful for RISC OS IMHO.
But I do like the fact it isn’t GPL!
The mbed TLS also supports Apache 2.0 license which would be a better fit for RISC OS perhaps.
If something was written under the Apache 2.0 license, could it be incorporated into the main line RISC OS?
As personally I think it would be good to have “core” libraries at least hosted by ROOL, so we can have guaranteed support from the wider community.
Any SSL library will require ongoing support and maintenance.
Or should I speak to them about “different needs” if the Apache 2.0 open source licence isn’t applicable?

Is there not a bsd version?

… http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/external/bsd/wpa/dist/src/crypto/tls_openssl.c and thereabout, perhaps?

OpenSSL I’d avoid, simply because it’s got a reputation for being a nasty old code base that’s full of bugs. I’d say focus on mbedTLS, since (a) ARM are backing it (so presumably the performance won’t suck on ARM) and (b) it has a makefile – no autoconf or other Unix-isms needed in order to start trying to compile the code (and apparently it built without any errors when it was thrown at the GCC autobuilder)

If something was written under the Apache 2.0 license, could it be incorporated into the main line RISC OS?

I believe so. The Apache license is very permissive, like BSD.

Read the source code for the CA.pl generator, that’s funny – considering how many people use it!

AMU: Don’t know how to make ‘o.ssl_tls’
AMU: * ‘all’ not re-made because of errors *

Yeah neither do I! There’s a chunk of moving/reconfiguring the MakeFiles to be RISCOS friendly.
Anyone got any ideas on how to do this, e.g. rsa/c needs moving to c.rsa etc and the MakeFile updating.
I’m tempted to install bash (on RISCOS) and use some shell scripting to do it.
As when there is an upgrade, I really don’t want to spend hours moving and renaming files

Anyone got any ideas on how to do this, e.g. rsa/c needs moving to c.rsa etc and the MakeFile updating.

My srcrename tool will help: (Actually, it’s a BASIC clone of Darren Salt’s tool by the same name, although after a bit of searching to find out who the original author was it’s possible that there’s a third version of the tool as well!)

http://www.phlamethrower.co.uk/riscos/srcrename.zip

There’s also ‘rsrcrename’ which renames back to Unix form.

I would personally avoid anything “open”, as it is usually tied to the gcc toolchain – great for linux, dreadful for RISC OS IMHO.

[Citation needed]

As when there is an upgrade, I really don’t want to spend hours moving and renaming files

Isn’t this precisely the problem that the GCCSDK Cross-Compiler was designed to resolve? The ideal goal would be to get a module shell that builds around an unchanged library, so that updates fall out “just like that” whenever the upstream code changes.

For a “core” component my personal belief is that it should use the native toolchain (ie. DDE) whenever possible. The recent ARMv8 SWP instruction mess is an example of why!

For a “core” component my personal belief is that it should use the native toolchain (ie. DDE) whenever possible. The recent ARMv8 SWP instruction mess is an example of why!

That sounds suspiciously like FUD. The OS itself had SWP issues, too, but ROOL got advance notice about fixing them – not a priviledge offered to the UnixLib developers.

Also, the problems were in UnixLib – not GCC. It’s quite possible to use the GCCSDK without ever touching UnixLib: all of my software does.

Finally, the whole point of a new SecureSockets is to ensure that it gets upstream fixes without relying on RISC OS developer time – that’s the reason why the current version is still using code from the 1990s. The GCCSDK is designed to do that kind of thing easily for library code, whereas Malcolm’s posts above suggest that he’s already hit problems with the DDE.

When was SecureSockets a “core” component, anyway?

I forgot that the issues were in UnixLib rather than GCC itself. To be honest, I’m not entirely familiar with GCC; I tried to investigate it some time ago but could only find two or three pages of documentation.

I’m certainly not trying to “put down” GCC; without it we wouldn’t have a large amount of the software that’s currently available. My opinion is simply that native solutions tend to have better compatibility than third-party ones; I’ve seen this time and time again regardless of operating system. If it’s fairly simple to build mbedTLS using the DDE then I’d be all for it. On the other hand, if it’s a big hassle then by all means GCC would be a better use of time.

“Core” probably wasn’t the best word, but I’ve seen so many posts on these forums about sockets, SecureSockets, EasySockets, etc. There is clearly a lot of demand for a decent socket implementation and it’ll likely end up being used in a large number of apps. In effect, it may end up being a de facto standard, so it’d be important to ensure that it works now and into the future.

All of this is just my opinionated ranting though! :)

Just to put my perspective on this, for whatever this is worth.
The reasons for me wanting to use the DDE and not GCC are:
1) I struggled to get the GCC toolchain working on RISC OS. (using a PC and cross compiling for this kind of work is not really nice)
2) SSL/Socket implementation must be in a module (to work as an api)

The “problems” I encountered were after 5 minutes of playing and were initial scoping.
I was hoping for some ideas.
If using GCC and the associated toolsets made it that simple, I would assume there would be a lot more things for RISC OS than there are.

The reason why securesockets hasn’t been updated is because integrating openssl with RISC OS is a nightmare.
Don’t forget the aim isn’t to have a library, if it was then an openssl port using GCC would definately be the way to go.
What we need is something to allow easy SSL and socket implementations.

The other suggestion is to port Java ;-)
I’ve got more reasons for using the DDE over GCC as well for this particular project, but there is no point in boring people!

The other suggestion is to port Java ;-)

Now I know that’s a joke, but it’s poor taste.
I speak as someone who works in an organisation saddled with Java applet implementations with major legacy code issues.
Applet A requires a JRE no later than 6 applet B requires a JRE no older than 8. Square that circle.

There maybe no proof that God exists, but Java Applets are proof that the Devil does!

(using a PC and cross compiling for this kind of work is not really nice)

Depends on how you measure how nice things are.

GCC on x86 will be a lot faster than GCC on RISC OS, and to me short build times are nice. Hell, GCC on ARM Linux should be a lot faster than GCC on RISC OS, if only for the fact you’ll have 2x-4x as many cores to play with.

Plus if you’re cross-compiling you won’t have to mess around renaming files to follow RISC OS conventions, and can interact directly with whatever source control the project uses.

Just make sure you can share the source folder with the RISC OS machine so you can use your favourite text editor.

2) SSL/Socket implementation must be in a module (to work as an api)

GCC has supported modules for many years.

Also you can’t (yet) use UnixLib from modules, so SWP shouldn’t have been an issue either :-)

I’ll admit GCC can be a bit tricky to set up (for the RISC OS version you have to download the right combination of packages, for the cross-compiler you’re at the mercy of things becoming broken by upstream changes, or by having the wrong native tools on your build machine). Just try to remember that it has pros as well as the cons :-)

If using GCC and the associated toolsets made it that simple, I would assume there would be a lot more things for RISC OS than there are.

No matter how simple you make things, it won’t change the fact that most people are stubborn, ignorant, lazy, and stuck in their ways. Myself included!

Interesting about the module, I wasn’t aware – I thought it was rather incomplete.
I didn’t also know it can use the “native” library as my guess is that it is UnixLib that is the nasty piece on RISC OS.
But as for cross compiling – I set that up for ARM Linux compiling when I used to work on guruplugs and the like. I really hated it.
I attempted to upgrade that once, then rolled back quickly and left it working.

I’ll see how it goes using the Norcroft one to start with, if it’s going to be a real ball ache – then GCC it will have to be.
But looking at the Makefiles it looks like once the .c to c. conversion is done it should be relatively straight forward….. (heard that before?)

So sounds like I should really setup a build farm for RISC OS/GCC, I’ve got plenty of CPU and RAM spare.
Going along with the bad taste jokes, how about Unity on RISC OS? RISC OS “Brown” Edition….

Thanks for the clarification. Favourite editor NEdit! Long live motif….

Malcolm:

If using GCC and the associated toolsets made it that simple, I would assume there would be a lot more things for RISC OS than there are.

Problem is, no matter how good the libraries and awesome the toolsets, there are fundamental differences between RISC OS and POSIX based system that would suggest that anything more involved than a command line tool may require…work…to get it operating successfully under RISC OS.

Plus, don’t forget RISC OS conventions are very different – how much is the person doing the port willing to do? There are a depressing number of applications out there that make assumptions that are not necessarily valid on RISC OS. The most recent I remember is UnTarBZ2 which refused to touch a downloaded archive until I suffixed “/bz2” to the name. It’s a small whinge, given the program then worked fine, but it does indicate that doing a full and complete port is never going to be as simple as “recompile” when you’re talking about something as different as RISC OS.

The other suggestion is to port Java ;-)

I’m not sure that will give us better sockets. Or security. Or anything particularly beneficial.
Or do you mean “Java” in the sense of something that can run Android or iOS apps? That would be kinda fun, but GOTO 10 of this post. iOS/Android ain’t RISC OS so…

as my guess is that it is UnixLib that is the nasty piece on RISC OS.

Nasty piece? Isn’t it just a set of more Unix-like functions?
As for SharedCLibrary: http://www.riscos.info/index.php/SharedCLibrary

Though, I note “The SharedCLibrary can create a smaller binary, since programs with UnixLib are presently statically linked, adding around 130KB to the final program.”
Doesn’t GCC have a concept of library, in the LibAOF sense of the word? Linking a whole 130K when only a few functions are needed is kinda dumb (akin to ansilib). If the library is built correctly and isn’t full of collusion, the linker ought to be able to work out which bits aren’t needed and omit them…

how about Unity on RISC OS?

That might help some people that can’t handle the complexities of the RISC OS UI.

But you threaten to port systemd, you’ll no longer be my friend…everybody has their limit… ;-)

RISC OS “Brown” Edition….

I thought the brown one was the last one before they cocked it up introduced Unity, the Unity one being the Yahoo! Purple edition.

Jeffrey:

Depends on how you measure how nice things are.
GCC on x86 will be a lot faster than GCC on RISC OS, and to me short build times are nice.

They are indeed, but around 32W/230V (Pi plus monitor) vs ~140W/230V (Pi plus PC plus monitor); every hour of using the PC would be four and a third hours of Pi time. Faster compiles are nice, but for average applications (not building RISC OS!), the DDE isn’t that slow, and it is a lot nicer when the bloke comes to read the meter. Consider – five hours of cross-platform coding, that’s then versus ~22 hours of Pi only time. Now let’s assume I do that for a week (not including weekends ‘cos I’ll watch telly instead) – 25 hours on the PC becomes equivalent in costs to 108 hours on the Pi. And that’s just for a fictional week, imagine months, seasons, a whole year…

Back to my original point….if I can remember!
Is there a good scripting tool for RISC OS, It could be that the supervisor commands are good enough – I’ve never really used them.
I would want to:
make a directory called c (even I can figure that out!)
move all files in the directory into the c directory
rename the files in the c directory to remove the /c

Also manipulating the make file to reflect the “RISCOS” structure if and when required.

I could do this easily with bash/sed etc. but was wondering if there is a RISC OS way of doing this.

I refer you to my original reply to your original post on the subject :-)

https://www.riscosopen.org/forum/forums/8/topics/5396?page=1#posts-54571

I think Norcroft is at least partially tolerant of Unix filenames in makefiles and in arguments to tools. So you might find that once the files have been moved around it will be happy (although you do still need to manually create a ‘o’ directory)

although you do still need to manually create a ‘o’ directory

Or use the shared makefiles, which create o for you :)

Thanks Jeffrey, missed that in the mess – but couldn’t get it to work.
I’ll just do it by hand, therapy whilst listening to music I suppose.

If someone takes up the bounty, how will the code be tested?