Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Snitch – A friendlier ss/netstat

github.com

Post reply on HN
Print view View original

71–80 of 109 posts

Re: Snitch – A friendlier ss/netstat

#71

Post by Melonai »

pdimitar wrote: post #53

When attempting to install through go: go install github.com/karol-broda/snitch@latest I get this error message: go: github.com/karol-broda/snitch@latest: version constraints conflict: github.com/karol-broda/snitch@v0.1.8: parsing go.mod: module declares its path as: snitch but was required as: github.com/karol-broda/snitch

They declared their module with just their package name without a URL, it got fixed a few hours ago.

I find it a bit interesting that Go even allows you to declare `module barename` in go.mod even though it loves breaking so many things if you do so. I sometimes try doing it for completely private projects but I always just declare some URL in the end, it's a weird anti-pattern in my opinion.

Re: Snitch – A friendlier ss/netstat

#73

Post by PhilippGille »

pdimitar wrote: post #53

When attempting to install through go: go install github.com/karol-broda/snitch@latest I get this error message: go: github.com/karol-broda/snitch@latest: version constraints conflict: github.com/karol-broda/snitch@v0.1.8: parsing go.mod: module declares its path as: snitch but was required as: github.com/karol-broda/snitch

They fixed it 6 hours ago, but it's not in a release yet: https://github.com/karol-broda/snitch/commit/7fdb1ed477894f1...

Re: Snitch – A friendlier ss/netstat

#74

Post by ycombiredd »

jcgl wrote: post #57
PunchyHamster wrote: post #29

it's weird that both lsof and ss defaults are so awful Like, ss without any options shows such arcane, rarely needed details as send/receive queue size but not the application socket belongs to . And omits listening sockets which is main use for such tools. I know picking the right defaults is hard ask but they managed to pick all the wrong defaults.

Completely agreed. Not sure what the historical reasons for lsof and ss are, but unix tools are structurally in a hard place when it comes to having sensible defaults over the long term. Generally speaking, you can only have sensible defaults over time if you're able to change the defaults over time . New users and new use-cases come with time, and so what constitutes a "sensible default" changes. However (and this i…

Hah yes, I've come to unashamedly - by muscle memory since the 1990's - find myself always typing 'ps auxw[w...]', where [w...] is some arbitrary number of w's depending on how heavy my index finger feels at the moment of typing.

Re: Snitch – A friendlier ss/netstat

#75

Post by TZubiri »

TZubiri wrote: post #48

One aspect of sysadminship that I find cute (but suboptimal) is how we memorize this strings of commands that were clearly not quite designed to be used in that manner. A slightly related example is how our intents in our mind end up having commands that don't resemble at all what we actually want, creating a map between intent and command that is almost exclusively arbitrary except for some obsucre etymological orig…

I've just connected this to some other thought on Android app marketplaces.

Even in operating systems as distant as Android, we still have the phenomenon of using proper_names instead of natural names.

If you want a taxi or a cab, you don't ask your OS to get you a taxi or cab, you ask it to use the Uber binary.

In the 2000s it wasn't clear that this was going to be the case, the famous example of the pets.com domain was a wrong bet that natural names would somehow be important.

Instead natural names are only important when used through an obscure privately controlled algorithm like Google or StackoverFlow or ChatGPT, if you want to say "flights to Greece" instead of "Oobloo greece", you need a magical black box in the middle.

Re: Snitch – A friendlier ss/netstat

#76

Post by gus_ »

jcgl wrote: post #61
gus_ wrote: post #42

Earlier quoted context omitted.

At the very least, these tools should not parse /proc to obtain information of processes or connections. It should be the last option. Many LD_PRELOAD rootkits hide their activity from the system by manipulating the output of libc functions like readdir(), open(), stat(), etc. kernel rootkits can hide whatever they need, but the common functionality is also to hide data from /proc. That's why netstat, ps, *top or lso…

What makes ss different? In any case, interesting to think of shared libraries (specifically shared libc) as a risk here. Makes sense, but I hadn't thought about it before. That said, I'm having a hard time doing a threat model where you worry about an attacker only setting LD_PRELOAD but not modifying PATH. The latter is more general and can screw you with all programs (doesn't cover shell builtins, but it's not lik…

ss obtains the connections information via netlink directly from the kernel (besides parsing /proc):

https://manpages.debian.org/bookworm/manpages/sock_diag.7.en...

https://github.com/vishvananda/netlink/blob/main/inet_diag.g...

Not many rootkits tamper the netlink channel, so in most cases it's a bit more reliable.

Re: Snitch – A friendlier ss/netstat

#77

Post by jcgl »

gus_ wrote: post #76
jcgl wrote: post #61

Earlier quoted context omitted.

What makes ss different? In any case, interesting to think of shared libraries (specifically shared libc) as a risk here. Makes sense, but I hadn't thought about it before. That said, I'm having a hard time doing a threat model where you worry about an attacker only setting LD_PRELOAD but not modifying PATH. The latter is more general and can screw you with all programs (doesn't cover shell builtins, but it's not lik…

ss obtains the connections information via netlink directly from the kernel (besides parsing /proc): https://manpages.debian.org/bookworm/manpages/sock_diag.7.en... https://github.com/vishvananda/netlink/blob/main/inet_diag.g... Not many rootkits tamper the netlink channel, so in most cases it's a bit more reliable.

Okay yeah, sure. So it's not intrinsically more reliable or anything, it's just not specifically vulnerable to LD_PRELOAD. And it's not clear to me why LD_PRELOAD would be a particularly interesting attack vector, but maybe that's just my ignorance.

Re: Snitch – A friendlier ss/netstat

#79

Post by [deleted] »

WhyNotHugo wrote: post #44
mabedan wrote: post #25

Earlier quoted context omitted.

Are they as accessible as GUI though (genuine question) UI libraries have a lot of features for allowing people with disabilities to “read” and interact with the screen in efficient ways

TUI tools are generally as accessible as the terminal on which they run. GUI apps are much trickier. They require that the developer implement integration with accessibility frameworks (which vary depending on X11/Wayland) or use a toolkit which does this.

[deleted]

Re: Snitch – A friendlier ss/netstat

#80

Post by karol-broda »

pdimitar wrote: post #53

When attempting to install through go: go install github.com/karol-broda/snitch@latest I get this error message: go: github.com/karol-broda/snitch@latest: version constraints conflict: github.com/karol-broda/snitch@v0.1.8: parsing go.mod: module declares its path as: snitch but was required as: github.com/karol-broda/snitch

i fixed it and created a release so building from @latest should work now
Post reply on HN