Originally posted by starshipeleven
View Post
Announcement
Collapse
No announcement yet.
A New Wireless Daemon Is In Development To Potentially Replace wpa_supplicant
Collapse
X
-
Originally posted by DeepDayze View Post
As SSL/TLS support is a MUST for wifi, there should be hooks for the existing SSL/TLS libs that may be installed on the system or at even include a basic SSL/TLS library in the package as a fallback where system SSL/TLS libraries aren't installed.
Oh the host system might not have X, how about we make a shit implementation of it so the idiots using this program can assume that everything is ok and safe even when it is totally fake?
Best course of action is to have hooks for system's libraries and disable SSL/TLS support if no libraries are detected in host system. Period.
Comment
-
Originally posted by Sonadow View PostIt's also the backend used by Android to establish wifi connections over WPA. Basically, as long as an OS with Unix roots is used, the backend providing wpa authentication is almost always wpa_supplicant.
I thought wpa supplicant was compilable/usable on OSX but wasn't there by default.
Comment
-
Originally posted by starshipeleven View PostThe bolded part is turd decision commonly found in OpenSSL.
Oh the host system might not have X, how about we make a shit implementation of it so the idiots using this program can assume that everything is ok and safe even when it is totally fake?
Best course of action is to have hooks for system's libraries and disable SSL/TLS support if no libraries are detected in host system. Period.
- Likes 1
Comment
-
Please, please, please, let it have a lua based hook framework, so we don't get weird big daemons that have to think of everything while only network X wants to advertise those vendor specifics. So many network utilities already use lua as the scripting engine to configure or even control everything.
Comment
-
Originally posted by Ardje View PostPlease, please, please, let it have a lua based hook framework, so we don't get weird big daemons that have to think of everything while only network X wants to advertise those vendor specifics. So many network utilities already use lua as the scripting engine to configure or even control everything.
Comment
-
Originally posted by Hi-Angel View PostWhy not Python then? Or even better — Haskell
I haven't tried embedding Haskell, but Python developers are very clear that, unless you're OK with Python scripting being able to make arbitrary system calls, you shouldn't use it for embedding. (Though I think PyPy can be compiled in a sandbox mode, which uses a process-separation-plus-IPC model similar to the separation between chrome and content processes in browsers.)
- Likes 1
Comment
-
Originally posted by ssokolow View Post
Lua is designed for embedding, so it's easy to integrate and easy to expose a restricted API to.
I haven't tried embedding Haskell, but Python developers are very clear that, unless you're OK with Python scripting being able to make arbitrary system calls, you shouldn't use it for embedding. (Though I think PyPy can be compiled in a sandbox mode, which uses a process-separation-plus-IPC model similar to the separation between chrome and content processes in browsers.)
And don't forget it is small, the total Lua compiler/interpreter is smaller than the perl regex library, while being able to do much more.
And it is so fast that there is even a kmod-lua as packet filter on openwrt.
It's the basis of nmap. It even has been requested as an add on for routers to filter bgp.
Comment
-
Originally posted by ssokolow View PostLua is designed for embedding, so it's easy to integrate and easy to expose a restricted API to.
I really really really really can't understand... It's so easy.
At this moment I am even writing my own network discovery daemon using lua-pcap (patched for lua5.3).
The worst part of it all, is that rpm itself (redhat), has full Lua scripting support. So it's not that redhat packagers do not know the full advantages of Lua...
Comment
Comment