zwp's comments

On: The Future of Programming (2013) [video]

[zwp]

You might like https://cs.brown.edu/~spr/codebubbles/

On: Learn Makefiles

[zwp]

I used to like having a "depend" target to make the dependencies explicit and so minimize build time, although that fiddles with the contents of the Makefile (some discussion at https://wiki.c2.com/?MakeDepend).

The standalone makedepend(1) that does the work is available in package xutils-dev on Ubuntu.

On: Setting up a trusted, self-signed SSL/TLS certificate authority in Linux

[zwp]

Is it coming? I notice that OpenSSL now has support for raw public keys.

The spec (RFC 7250, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)") suggests DANE/DNSSEC as a mechanism to bind identities to public keys (section 6).

https://datatracker.ietf.org/doc/html/rfc7250

Will this really be simpler?

[tptacek → zwp]

It is not coming. Browsers are unlikely to support DANE (Chrome briefly did, and then pulled support, IIRC).

[vlovich123 → zwp]

Simpler and faster I hope.

[tptacek → vlovich123]

In fact, the slowness and complexity of DANE is a big part of why it got pulled.

On: Handling cookies is a minefield

[zwp]

We already have Macaroons

https://en.wikipedia.org/wiki/Macaroons_(computer_science)

https://en.wikipedia.org/wiki/Macaroon

On: Title drops in movies

[zwp]

And Layer Cake

On: Vulnerabilities show why STARTTLS should be avoided if possible (2021)

[zwp]

There was a sense of "wasting a port". A modern Linux /etc/services has only 200 or so reserved TCP ports (out of a possible ~50k) so that fear might have been overblown.

I suspect the bureaucratic overhead of needing to go to IANA to reserve a new port might have had a chilling effect. See:

  https://www.iana.org/protocols/apply

  https://www.iana.org/form/ports-services

On: Vulnerabilities show why STARTTLS should be avoided if possible (2021)

[zwp]

> you are supposed to still continue if you strictly follow the standard

Which standard? RFC 3207 (for STARTTLS over SMTP), 2002, says: "If the client receives the 454 response [TLS not available], the client must decide whether or not to continue the SMTP session".

On: Anonymous Block Forwarding in Ruby

[zwp]

    def execute(f)
      f.call "test response"
    end

    perform = TOPLEVEL_BINDING.method(:execute)

    perform.call Kernel.method(:puts)

On: Why use strace in 2023? [video]

[zwp]

You can use "-e trace=open" to trace only open(2) calls

Alternatively "-e trace=%file" to get all file-related system calls (will catch eg failing pre-emptive checks using access(3) -> stat(2)).

[c0l0 → zwp]

FTR, on modern-ish glibc-powered systems (in code that actually does use libc, and does not do its very own syscall-related thing instead), you will not find a single call to open(2) issued, in my experience. That's because the library functions shadowing these syscalls were rewired to use openat(2) under the hood.

    $ strace -e trace=open cat /dev/null 
    +++ exited with 0 +++


    $ strace -e trace=openat cat /dev/null 
    openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
    openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
    openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
    openat(AT_FDCWD, "/dev/null", O_RDONLY) = 3
    +++ exited with 0 +++

[lelanthran → c0l0]

If you want to catch both `open` and `openat`, the opensnoop BPF[1] program is pretty nifty, especially if you are trying to figure out file stuff across several different programs ("which #$%^-ing program keeps modifying this file", for example).

[1] I've been dipping my toes into BPF recently, and while complicated (best to simply clone the bpftools repo and work off of that) there's a lot that can be done that tools like strace won't be able to match.

[amelius → zwp]

Ok, but then you will still need to parse the output to get the filenames. That's ok, but since it is something that is used a lot, you'd expect a flag.

[tanelpoder → amelius]

Check out strace -y and strace -yy (--decode-fds)

[zwp → tanelpoder]

You still need to pull out the paths?

A sprinkling of grep/perl (awk/sed/ruby/...) is mostly good enough eg:

strace -e trace=%file cat /etc/passwd 2>&1 >/dev/null | grep ^open | grep -Po '(?<=").*(?=")'

[eesmith → amelius]

Is your example situation really all that common?

If so, what format do you expect for the output?

If it's one filename-per-line then how do you encode filenames with embedded newlines?

How do you encode non-UTF8 characters, or is the file meant to be parsed only in binary mode?

I don't know of any generally agreed upon spec for this, so no matter what you think is right, most people are going to have to write a special-purpose parser.

In which case you might as well parse the native strace output since one is about as complex as the other.

[amelius → eesmith]

It can use the same format as the Unix find utility. This utility has a -print0 flag to separate filenames by NUL characters instead of newlines if desired.

[eesmith → amelius]

That is a good point.

I still don't see it as common use case.

On: Passive SSH Key Compromise via Lattices [pdf]

[zwp]

> whatever "SSH-2.0-SSHD" is (the authors don't know either)

I think this is from the j2ssh/maverick SSH server, used in a bunch of enterprisey Java products.

https://jadaptive.com/en/products/java-ssh-server

https://github.com/sshtools/j2ssh-maverick/blob/ce11ceaf0aa0...