> suc does all that by leveraging SSH, UNIX’s access control API, and UNIX’s text-based modularity. On any fair metric, this should inflate the volume of code metric for any project (whether leveraging those APIs directly or not). It would still favor this implementation on that front, and there are still other merits to the approach besides code volume. But something does irk me about touting supposed minimalism whi…
Simple Unix Chat
51–60 of 175 posts
Re: Simple Unix Chat
#52Earlier quoted context omitted.
It’s pretty valid disingenuity. It’s just also pretty valid to identify as such.
Did the title contain the disclaimer? I only found it after visiting the page.
Re: Simple Unix Chat
#53> suc does all that by leveraging SSH, UNIX’s access control API, and UNIX’s text-based modularity. On any fair metric, this should inflate the volume of code metric for any project (whether leveraging those APIs directly or not). It would still favor this implementation on that front, and there are still other merits to the approach besides code volume. But something does irk me about touting supposed minimalism whi…
Re: Simple Unix Chat
#54Earlier quoted context omitted.
I once was in a meeting about which web authentication framework to use for a site that ran so long because of bikeshedding that I implemented during the meeting and demoed at the end a solution based on the fact that HTTP already provides an authentication facility.
HTTP auth is vastly insufficient for most use cases. You are missing passwords resetting, 2FA, bot/abuse detection, and probably a whole collection of other stuff. I’m also not sure if passwords manager extensions can prefill them. As well as the fact that the login form is only 1% of what an auth library does.
I think the principal here is not reinventing wheels.
Re: Simple Unix Chat
#55Re: Simple Unix Chat
#56In case you're passing over this because it sounds like click bait (it KIND OF is), this was actually a good read to me. It goes over a utility called "suc" (Simple Unix Chat) that implements server functionalities from Slack, Discord, etc. using a very small codebase. The novel part is it leverages existing unix tools and methodology instead of re-inventing them. - Auth is handled by SSH. - Channels are just a file…
Wait, KISS is a novelty? :-)
Re: Simple Unix Chat
#57what do i do after i sign up to the-dam.org ? i did not get any email after the payment and ssh-ing doesn't work either. (i just get a `Permission denied (publickey)`)
Re: Simple Unix Chat
#58what do i do after i sign up to the-dam.org ? i did not get any email after the payment and ssh-ing doesn't work either. (i just get a `Permission denied (publickey)`)
Same for me. I suspect maybe they add the public keys manually and haven't gotten around to it yet.
Re: Simple Unix Chat
#59Most current distros prevent you from making setuid bash scripts, on security grounds. But you can get most of the same effect with a specific sudoers entry.
_any_ shebang script really... except perl scripts, because perl has taint mode turned on automatically when uid != euid
https://perldoc.perl.org/perlsec#Taint-mode
Note that there may be a fundamental race condition on some systems:
https://perldoc.perl.org/perlsec#Shebang-Race-Condition
Also see the noted use of `sudo -T`:
https://perldoc.perl.org/perlsec#Using-Sudo
I lament the recent removal of taint mode from Ruby :( as tainting is a powerful mechanism that could go way beyond scripts: imagine Rack / Rails #html_safe but via tainting so it could have worked more thoroughly (e.g concatenate/interpolate/format a tainted user string into a SQL snippet would blow up, preventing a whole class of SQL injections by design)
Some folks used to use taint for CGI/mod_perl to such great effect. It's not a magic bullet by any means (security is hard!) but it's a really effective tool still.
Re: Simple Unix Chat
#60For some, IRC is the example why slack/discord won.