1. 1

    A programming language that: a) Allows me to express side effects b) Compiles with a static syscall sandbox based on those side effects c) Is actor-oriented, with first class support for spawning actors in separate, isolated processes d) Doesn’t have a traditional main, but instead has first class, static dependency injection e) Has move semantics

    Pony and Rust get super close to this in some capacity. For me this would just be a dream. It would give me what I love from Java (yes, I love things from Java), Rust, Pony, Erlang, etc, in one place.

    If I had endless time I would build it.

    1. 3

      pytype developer documentation - we’re hoping to make it easier for new people to come in and contribute.

      1. 2

        pytype is awesome! I hope to see it gain more traction, it feels more pythonic than mypy to me.

        1. 2

          thanks :) we’ve also been tagging issues “good first issue” if you ever would like to poke at the code!

      1. 1

        I’ve been rewriting our query builder/ data exploration library for Grapl[0].

        It’s a really fun project, pretty tough. One feature I’m adding allows you to express multiple constrains on a single edge. For example,

        ProcessQuery().with_children(
            ProcessQuery().with_process_name(eq="foo"),
            ProcessQuery().with_process_name(eq="bar"),
        )
        

        This was actually quite challenging to write. I have to create a sort of ‘graph zipper’ that would take a graph that has multiple edges and constraints and create a graph with only singular edges and the combined constraints.

        We do client side query optimization as well and that’s a really fun one, which involves creating N queries (N = number of nodes in the signature), each one with a different root of the graph, and then running those in parallel. There’s also some type based optimizations as well.

        [0] https://github.com/grapl-security/grapl

        1. 5

          Making it contactless defeats a whole layer of security and I don’t understand why you’d want that.

          1. 5

            I’m not sure that it does. If you are sitting at the laptop and have the device already, what is the purpose of requiring a touch? In case an attacker has the laptop, the yubikey, but no hands?

            That said, it means anyone with the laptop has access, and this is only for logged in sessions, so I wonder why you would want a lockscreen at all. But as the author notes, they pull the key out when they leave their laptop unattended.

            1. 10

              My primary use of the Yubikey right now is for SSH (and a few sites that support the old Yubi, not U2F).

              So I have ssh-agent. If I didn’t require touch for each event, someone who has compromised my workstation or any server that I am using SSH agent forwarding with could use my key without my knowledge. Even if they get root and steal my agent socket, they can’t use it to move laterally through the network unless they come to my home and touch the key.

              By requiring touch for every action I can guarantee that even though my key is available it simply cannot be used without my consent.

              1. 5

                I agree that for an SSH it makes perfect sense to require the touch for exactly the reason you stated. I’m saying for locking a user’s laptop the touch doesn’t make much different - a lockscreen is intended to stop attackers who have short lived physical access.

                1. 3

                  Yes, but as far as I know the “touch” option on a Yubikey is set in the firmware and is global. So if he turns off touch for this purpose, any other use of the key doesn’t require touch either. That’s concerning.

                  edit: it looks like this might be available on a per-key/action basis inside the Yubikey? That must be new… but I’d still be concerned if you ever use the challenge response for anything else.

                  1. 1

                    Ah, sure if it’s a global option and this key is reused for other actions where touch is important, I’m in agreement that this would be a dangerous setting.

              2. 4

                You’d also want to use a password: something you know + something you have. I use a yubkey in static password mode, so that when I touch the button, it spits out the static text. I append that static text to the password I’ve memorized. That way, I gain 2FA in a way that doesn’t require the system to explicitly support the yubikey (for example, no need for the yubikey PAM module).

                1. 2

                  I used that same method for a while :)

              3. 3

                It really just turns it into 1-factor authentication again, but with a device that is fairly easy to steal.

                I’m not sure if I’d want to have that as the only factor, but it’s not really “insecure”. More like having the password on a sticky note under the keyboard level of security.

              1. 3

                It’s interesting that Rust is simultaneously safer because it handles deallocation, a very scary thing, for you, while also be less safe in cases like this by hiding that very scary thing. And I agree that the Go code is clearly unsafe when compared to the Rust code.

                There’s clearly work left for improving these potential footgun situations.