Announcement

Collapse
No announcement yet.

A New Wireless Daemon Is In Development To Potentially Replace wpa_supplicant

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Ardje
    replied
    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.
    And then we read this:

    https://access.redhat.com/security/cve/cve-2018-1111

    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...

    Leave a comment:


  • Ardje
    replied
    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.)
    Exactly! Finally someone outside of #Lua that agrees :-). And yes, python might be able to do something like that, but with Lua it is the base of the language... _ENV={}, let's start with that. Namespace restriction is natural in Lua. I haven't seen it in any other language.
    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.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by Hi-Angel View Post
    Why not Python then? Or even better — Haskell
    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.)

    Leave a comment:


  • Hi-Angel
    replied
    Originally posted by Ardje View Post
    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.
    Why not Python then? Or even better — Haskell

    Leave a comment:


  • Ardje
    replied
    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.

    Leave a comment:


  • DeepDayze
    replied
    Originally posted by starshipeleven View Post
    The 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.
    OK that is also acceptable as well. Good point there.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Sonadow View Post
    It'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.
    Hmm, are you saying what I think you are saying? (= that OSX uses wpa_supplicant too)

    I thought wpa supplicant was compilable/usable on OSX but wasn't there by default.

    Leave a comment:


  • starshipeleven
    replied
    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.
    The 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.

    Leave a comment:


  • Sonadow
    replied
    Originally posted by starshipeleven View Post
    wpa_supplicant is network-manager's backend when it operates wifi.

    So yeah, the beast is caged and under watch, but still there.
    It'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.

    Leave a comment:


  • c117152
    replied
    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.
    Depends on the API. They could have very wifi specific syscalls and nothing general purpose which will make using it from the user land difficult or even impossible.

    Leave a comment:

Working...
X