I've been reading about Stanford's Secure Remote Password protocol, and it looks ideal for the sort of environment in which iPhone apps run. Unfortunately, I haven't been able to find a good Objective-C implementation of the protocol. Nor, as far as I can tell, do the crypto libraries in the SDK implement it.
Does anyone know of such an implementation?
Failing that, what's my best bet going to be, do you think? I could try to build OpenSSL into my app, but that feels like a really big thing to add for this one little piece. I could try to translate the JavaScript or Java implementations into Objective-C, but that violates the #1 rule of crypto (use a known, tested implementation).
Couple of follow-up items: first, it should probably be obvious from context, but I'm going to need something that is compatible with closed-source commercial usage (the JavaScript implementation I linked to, I later noticed, is AGPL).
Also, assuming I do end up going with OpenSSL, I'm having real trouble finding an example of using it to do SRP. Their site claims the code is in there, but I can't find any evidence of it, either in the OpenSSL documentation, or grepping the source code (v 0.9.8k). (Or am I seriously misreading things, and I still have to apply one of their patches to the OpenSSL source?)
EDIT:
What I could really use at this point is ready-to-use code, a fairly complete recipe, or some kind of example of using SRP in OpenSSL. I'm pretty sure I could cobble something together from scratch with the protocol docs, but I'm really trying to avoid reinventing the wheel, if I can help it.
The OpenSSL and GnuTLS implementations of SRP-TLS are the only C-based ones I know that are maintained (TinySRP hasn't been updated since 2001, and there have been many security notices against the underlying OpenSSL version it's based on, though I don't know if they impact TinySRP itself).
That said, every iPhone project I've built has eventually had to include a copy of OpenSSL for something or other. I recommend just biting the bullet and using it. The instructions you link to work fine.
Personally, I build OpenSSL into a Universal library using lipo that has both arm and x86 versions. That way I can link to a single .a for both Simulator and Device. The lipo is very easy. Just build the two libraries and glue them together. Here's the rule from my Makefile:
/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/lipo \
-create \
-arch armv6 iPhoneOS$(SDK_VER)/lib/$(1) \
-arch i386 iPhoneSimulator$(SDK_VER)/lib/$(1) \
-output iPhoneUniversal$(SDK_VER)/lib/$(1)
The implementation of SRP in iOS platform requires OpenSSL, so a good way is to install OpenSSL via pods.
There's a good C implementation of srp by hoccer called csrp.
I have written an iOS wrapper for this implementation, which you can find here. But I must mention that csrp is already well implemented and self-explained from its documentation.
Related
The LLVM infrastructure now supports compiling from LLVM IR to WebAssembly (at least experimentally). Swift uses the LLVM compiler infrastructure and can easily be compiled to LLVM IR. So I thought it would be straightforward to compile some Swift code to LLVM IR and then to WebAssembly.
It turned out not to be that easy, however. It looks like LLVM IR is not entirely platform independent? Whatever the reason behind the scenes, when compiling Swift to LLVM IR, a target architecture must be specified and WebAssembly is not available.
I have two questions then:
1) Am I correct that there is currently (as of October 2017) no way to compile Swift to WebAssembly?
2) What would it take to make WebAssembly a supported target for Swift to LLVM IR compilation?
1) To the best of my knowledge as of early Nov, 2017 you are correct: there is no commonly available way to compile Swift to WebAssembly. Maybe some enterprising hacker somewhere has made it happen but if so she hasn't shared her code with us yet.
2) In order to enable Wasm support you will probably need to hack on a few different parts. I think you could do it without knowing much of anything about the internals of the compiler (e.g. the parser & optimizers), but you'd need to learn about how the toolchain works and how it integrates with the platform at runtime.
You can learn a ton about what you'd need to do by studying how Swift was ported to Android. Luckily, Brian Gesiak posted a really detailed blog post about exactly how that port worked (warning: small Patreon donation required):
https://modocache.io/how-to-port-the-swift-runtime-to-android
Seriously, you would be nuts to embark on this project without reading that article.
Though I'm NOT an expert, based on that port and my (basic) understanding of Swift, I think the rough overview of where you'd need to hack would be:
The Swift compiler
You'll need to teach it about the Wasm "triple" used by LLVM, so it knows how to integrate with the rest of its toolchain
You'll need to set up a WebAssembly platform so that people can write #if os(WebAssembly) in places that require conditional compilation
You'll also need to set up similar build-time macros. The Android article explains this sort of thing really well.
The Swift runtime
This is written in C++ and it needs to run on Wasm
Since Wasm is an unusual platform there will probably be some work here. You might need to provide compatibility shims for various system calls and the like.
Projects like Emscripten have demonstrated lots of success compiling C++ to Wasm.
The Swift standard library
In theory you can write & run Swift code that doesn't use the standard library, but who would want to?
Also in theory this should "just work" if the runtime works, but you will likely need to use your #if os(WebAssembly) feature here to work around platform irregularities
Bonus: The Foundation and Dispatch libraries
If you want to use existing Swift code these two libraries will be essential.
Links:
Brian Gesiak's awesome blog post: https://modocache.io/how-to-port-the-swift-runtime-to-android
Link to the Android port's pull request: https://github.com/apple/swift/pull/1442
Interesting article about the challenges and rewards of cross-platform Swift: https://medium.com/#ephemer/how-we-put-an-app-in-the-android-play-store-using-swift-67bd99573e3c
It looks like there is a commercial offering that supports compilation of Swift to WebAssembly. RemObjects, the developer tooling company, has just announced support for WebAssembly with their Elements compiler, which can compile Java, Swift, C# and Oxygene.
As of May 2019 there's an open-source project available called SwiftWasm that allows you to compile Swift code to WebAssembly targeting WASI SDK. This means that binaries produced by SwiftWasm can be executed either in browsers with WASI polyfill or standalone WebAssembly runtimes supporting WASI such as wasmtime, lucet or wasmer.
I was looking for a way to convert Swift code to web assembly, and I found this.
https://swiftwasm.org/
I do not know how mature this platform is (October 2022) and if it can flourish, but having the capability is exciting.
Also, it provides means for writing JavaScript in Swift directly.
WebAssembly target would be like a generic unix target for llvm, so I think someone needs develop that port.
Please note that Swift -> Wasm in browser would be pretty much useless because Wasm has no DOM or DOM API access so you still need JavaScript to do anything meaningful, thus the question: why would anyone bother to make the port? It looks like JavaScript remains the only web language. If you don't like JavaScript you better forget the web development.
Chances are that Swift will run on Android before it runs on the web so stick with Swift/iOS and then make the port to Android whenever that becomes possible. People don't use the web/browser that much anyway.
Is it possible to compile a swift binary from an OS X computer so that it runs on a server running Linux as a single binary without no extra libraries that need to be dynamically linked?
I'm thinking something like passing a -target to the swift command and passing another parameter to let it statically link all dependencies, but I'm not sure what the exact commands are.
The exact value for -target seems to be rather elusive.
Do I need to know the exact target distribution to be able to pass the correct string to the -target parameter?
From reading the sources on github
target would be Linux
machine would be x86_64
This gets called by the primary build script
This how ever answers a part of the question
The exact value for -target seems to be rather elusive.
Install a GCC toolchain for Mac OSX that can retarget Linux, one repo that I can see is OSXCross, for example.
Supply the values to the environment variables to GCC prior to running the script, that references that toolchain.
Unfortunately, that does not guarantee it will work, but give it a try and see what happens.
Is it possible to compile a swift binary from an OS X computer so that it runs on a server running Linux as a single binary without no extra libraries that need to be dynamically linked?
The short answer? Of course it is! Anything is possible when you put your heart to it!
Is it efficient? Inherently, no.
While I'm sure everyone here is familiar with what a compiler does, for the sake of this question and its newest of users, a compiler is an application that converts human readable code and maps it to a binary format that a computer can understand. However it should be worth mentioning that not all computers are the same. Each computer operating system has a different binary mapping than the other so a simple operation like copying values could be expressed as 1010 on one machine, and 0101 on another. As stated before in many questions prior, and for example this one, many programming languages are buildable across a variety of machines, but very few of them are portable across them because each computer has a different binary mapping.
~~~~~~~
So how do we fix this?
~~~~~~~
Well there are a number of solutions to fix this. The most obvious
method is to simply make your environment the target environment and
build your program to your hearts content. You obviously already did
this through a virtual machine and this typically what many
developers will do. This is by far the easiest solution but it
defeats the purpose of the question where you want to simply build
from your OSX machine.
Earlier you said you heard people talking about compiling windows programs on linux machines. Cygwin is a a development platform aimed at obtaining the windows framework that is not normally present on linux machines and allows many programs to be built with the windows framework in mind. However all its doing is adding binaries so that the compiler has some proper places to map to when windows only commands are found within a configuration. All its doing is introducing the binary configurations necessary for a program to successfully be ported over. This ties into the second option.
Secondly comes a compiler that supports cross platform compilation.
While I am currently uninformed and/or unfamiliar with such
compilers, this is technically a valid solution but would I call it
reliable? Probably not. If anything you're just adding more work to
your compiler as not only does it have to correctly map the syntax of
one computer program for one computer, it has to waste time linking
it to the new binaries. Additionally you would need to have the
compiler remember these linking's which could entail more wasted
memory space for having this one compiler.
Even then, systems like these are few and far between and whether its guaranteed to work depends upon how well the compilers maintainer knows their stuff, how frequently they update it etc. etc. And the chances that they even performed to correct mappings of binaries in the first place is not something I'd stake my life on.
The third and perhaps most ideal solution is to look into container technologies such as docker. Their containers are essentially ways for you to build your app and port it to new machines without having to change or modify anything about how you build and compile it. Simply build one, store it in a container, port it to your machine of choice and integrate it into your current project. Come to think of it, container systems like docker were built to prevent the very thing that you are currently experiencing, where you have a source code working on your one machine but no place else. Something like docker will be able to run your code on any machine without having to recompile it for each new machine.
Docker provides an interesting framework for container to container communication, application examples and has a fairly straightforward documentation that it would be worthwhile to look at to see if your project could have some of its parts ported to docker.
This being said, there are multiple ways to fix the issue you are currently facing, so as you being a software engineer, its up to you in what would be the most ideal way of handling your project.
// EDIT //
Will edit this to be a better response once im not drop-dead tired.
I am curious to know if there is any kind of programming library/framework for the C language for cross-platform programming of course. I mean there are already frameworks like Wxwidgets, Boost, Qt, U++ and etc for C++ available but I have not yet found any for C .
Updated Info:
We are trying to build an underlying Framework/library to be used in our project. We are going to eliminate the dotnet and instead provide a counterpart for those libraries which is fast and less demanding.
We will be working on a server/client based project, and thus the underlying services must be fast and also portable. GUI is not our priority now, but libraries providing threading capabilities is of importance to us.
And for the ANSI part, I think we are fine with that at the moment unless something changes that in the future.
if you write plain ANSI C, it should work on every POSIX system.
The most successful example of cross platform C library is standard C library itself (IMHO).
If you're looking for GUI toolkit GTK is the answer,
if you're looking for terminal UI, ncurses is pretty portable.
If you're looking for general use libraries, as long as they're written in ANSI C, should work almost everywhere, as long as it doesn't use system level APIs.
Can you just tell us, what kind of library/framework you are looking for ?
GTK+ is long established and actively maintained cross-platform C-only (or primarily) toolkit. You'll find not only on-line documentation but also books written about it. It is the framework backing up the GNOME project.
GTK+ is meant to build applications with UI, first of all. However, even if you don't need UI you'll find that some GTK+ components, namely GLib, provide general multiplatform support comparable with Qt. Actually, I needed a framework without UI at first and chose GLib over APR because I was able to find documentation and tutorials easier.
GTK+ was initially developed on UN*X an X-Windows which remains the platform where you can get it running the most easily. I wouldn't say that it is more difficult on Windows; it is just that you have more compiling environment options. I started with prepared GTK+ packages and MinGW but ended up integrating GTK+ with MSVC.
GTK+ exists for a long time and some people may find it old-school. On the other hand, it shows that it has proven to be stable and useful. There are also bindings for C++ and C#.
As with every big framework, the more you need from it the longer you will have to learn. But the other way round it works too; the more you learn the more you'll be able to do with it. Consistent coding style helps getting used to it.
--- Ferda
is it possible to use rsync lib inside of an iPhone or iPad app? Or maybe there are any alternatives suitable for remote file sync over sftp?
Acrosync library is a good choice, and I have made a demo for it.
It is licensed under the RPL license, and commercial license are provided.
Repository:
https://github.com/gilbertchen/acrosync-library
My demo (fixed some bugs):
https://github.com/Lessica/Acrosync-Demo
acrosync seems to be worth checking out as it implements a rsync client library rewritten from scratch and is available on multiple platforms, including iOS.
https://acrosync.com/library.html
I have to close this question because at the moment there are only few possible solutions and neither of them runs 'out of the box'.
I have found several programs on the AppSote which somehow mimics rsync functionality so after all using rsync is possible, however not so simple as it seems.
Modifiying rsync to turn it into a library is feasible, but this is not how author of one of these programs did it. Doing so would subject app to GPL, which not permitted by Apple.
There are other approaches, such as http://search.cpan.org/~leakin/File-Rsync-0.42/Rsync.pm (a perl module), and https://github.com/kolosy/rsync.net (c#).
I doubt someone would really need rsync lib for iphone since iOS 5.0 was released. However one may need it to support some legacy code, but even then rewriting rsync lib from scratch is questionable, because it is complex tool and this task certainly will take more than two or three month.
I've worked on a number of products that make use of code generation. It seems to be the only way to achieve both a high degree of user-customizability and high execution speed.
The downside is that we are requiring users to install a compiler (primarily on MS Windows).
This has been an on-going headache, because vendors like MS keep obsoleting compilers, and some users tend to have more than one compiler installed.
We're considering using GNU C, and possibly C++, but even there, there are continual version issues.
I've considered possibly generating assembly language, in an effort to get off the compiler-version-treadmill, but assembly languages are all machine-specific.
Ideally there would be some way to produce generated code that would be flexible, run fast, and not expose us to the whims of third-party providers.
Maybe I'm overlooking something simple, like Java. Any ideas would be appreciated. Thanks.
If you're considering C and even assembler, take a look at LLVM first: http://llvm.org
I might be missing some context here, but could you just pin yourself to a specific version? E.g., .NET 2.0 can be installed side by side with .NET 1.1 and .NET 3.5, as well as other versions that will come out in the future. So as long as your code makes use of a specific version of a compiler, what's the problem?
I've considered possibly generating assembly language, in an effort to get off the compiler-version-treadmill, but assembly languages are all machine-specific.
That would be called a compiler :)
Why don't you stick to C90?
I haven't heard much of severe violations of standards from gcc's side, if you don't use extensions.
And you can always distribute a certain version of gcc along with your product, say, 4.3.2, giving an option to users to use their own compiler at their own risk.
As long as all code is generated by you (i. e. you don't embed your instructions into other's code), there shouldn't be any problems in testing against this version and using it to compile your libraries.
If you want to generate assembly language code, you may take a look at asmjit.
One option would be to use a language/environment that provides access to the compiler in code; For example, here is a C# example.
Why not ship a GNU C compiler with your code generator? That way you have no version issues, and the client can constantly generate code that is usable.
It sounds like you're looking for LLVM.
Start here: The Code Generation conference
In the spirit of "might not be to late to add my 2 cents" as in #Alvin's answer's case, here is something I'd think about: if your application is meant to last for some years, it is going to face several changes in how applications and systems work.
For instance, let's say you were thinking about this 10 years ago. I was watching Dexter back then, but I guess you actually have memories of how things were at that time. From what I can tell, multithreading was not much of an issue to developers of 2000, and now it is. So Moore's law broke for them. Before that people didn't even care about what will happen in "Y2K".
Speaking of Moore's law, processors are indeed getting quite fast, so maybe certain optimizations won't be even that necessary. And possibly the array of optimizations will be much bigger, some processors are getting optimizations for several server-centric stuff (XML, cryptography, compression and regex! I am surprised such things can get done on a chip) and also spend less energy (which is probably very important for warfare hardware...).
My point being that focusing on what exist today as a platform for tomorrow is not a good idea. Make it work today, and surely it will work tomorrow (backward-compatibility is especially valued by Microsoft, Apple is not bad it seems and Linux is very liberal about making it work as you want).
There is, yes, one thing that you can do. Attach your technology to something that just won't (likely) die, such as Javascript. I'm serious, Javascript VMs are getting terribly efficient nowdays and are just going to get better, plus everyone loves it so it's not going to dissappear suddenly. If needing more efficiency/features, maybe target the CRL or JVM?
Also I believe multithreading will become more and more of an issue. I have a gut feeling the number of processor cores will have a Moore's law of their own. And architectures are more than likely to change, from the looks of the cloud buzz.
PS: In any case, I belive C optimizations of the past are still quite valid under modern compilers!
I would stick to that language that you use for generating that language. You can generate and compile Java code in Java, Python code in Python, C# in C#, and even Lisp in Lisp, etc.
But it is not clear whether such languages are sufficiently fast for you. For top speed I would choose to generate C++ and use GCC for compilation.
Why not use something like SpiderMonkey or Rhino (JavaScript support in Java or C++). You can export your objects to JavaScript namespaces, and your users don't have to compile anything.
Embed an interpreter for a language like Lua/Scheme into your program, and generate code in that language.