HN user

zwp

601 karma
Posts1
Comments198
View on HN
Learn Makefiles 1 year ago

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.

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

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 '(?<=").*(?=")'

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

Slightly silly sketch (bash):

    sqlite-utils create-table ~/commands.db commands id integer text text --pk id
    PROMPT_COMMAND="( fc -n -l -1 | perl -p -e 's/^\s+//; chomp if eof' | sqlite-utils insert --text ~/commands.db commands - & )"
It's slow, has perl & python external deps, needs a timestamp column, call subshell to avoid job control messages, ...

A nicer single "prompt command" wrapper is certainly possible though.

I wasn't aware of the figurative connotation, I will remember this next time I'm retreating from a climb.

"HMS carabiner" is also common amongst anglophone climbers (for the "Halbmastwurfsicherung" knot you might use as an alternative to your sticht plate).

Larry Wall, inventor of Perl:

"We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris.", "Programming Perl", 1ed

2ed says:

"Laziness

The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer. Also hence, this book."

Some discussion at https://wiki.c2.com/?LazinessImpatienceHubris

A long time ago I similarly tested a (non-heat-reflective) orange plastic survival bag, sleeping overnight behind some rocks on exposed moorland (something like https://www.military1st.eu/cs037-highlander-emergency-surviv...).

The poor thermal insulation and condensation were predictable. I hadn't predicted the shifting wind which chose to balloon my orange cocoon with cold air every 20 mins no matter which orientation I chose to lie in. I finished the night with a bungie cord around the sack, under my armpits. That of course left my head, shoulders and arms exposed but kept the wind out. Not recommended.

After this experience I upgraded to reflective mylar survival bags. NB "bag". These are a little harder to find than survival blankets but if a bag can be so badly affected by moderate wind, a blanket would be so much worse.

Nice find.

I'm hopefully preaching to the choir here but please beware that high-visibility flaws often attract fake PoCs. Malicious in the sense "might [also] attack the user" (you!).

Often these will surf on work done by valid PoCs to look credible. GitHub was stuffed with them for the Hafnium Exchange bug, before Microsoft brought down the ban hammer. (At the time there was lots of mewing about "Microsoft protecting their own" and "Microsoft killing free speech" but I wonder if they weren't also interested in stopping the pwnage from these fake exploits, too).

I'm not saying this repo is malicious. This github user looks legitimate and doesn't look like the obviously-created-by-a-bot profiles I've previously seen. Even so I wouldn't necessarily trust ~5000 vendored class files. Play carefully.

I disagree: for defenders trying to establish veracity of flaws and prioritizing defense this is useful information. "Active exploits seen in wild" is a strong signal.

Picking two potentially high impact announcements from the last month or so:

1. There is a severe flaw in the RSA cryptosystem. 2. There is a remote code exec vulnerability in Microsoft Exchange.

One of these was a sketch of an incremental improvement to an attack that remains mostly of theoretical interest. The other was being actively exploited, was tragically simple for 3rd parties to replicate post-announcement and resulted in widespread pain.

There is some (non-linear) scale here (theoretical flaw/poc/weaponized poc/public poc/public weaponized poc/exploited, but limited actors or targets/widely exploited/HAVOC). MS for example uses just "less likely to be exploited", "more likely to be exploited" "being exploited". It's coarse and somewhat subjective but there is value even so.

"This flaw is being actively exploited in the wild" is the best line I can take upstairs. I don't want that to go away just because some parties might misuse it.