• 0 Posts
  • 38 Comments
Joined 2 years ago
cake
Cake day: June 17th, 2023

help-circle

  • Slotos@feddit.nltoLinux@lemmy.mlssh reverse tunnel
    link
    fedilink
    arrow-up
    6
    arrow-down
    1
    ·
    1 month ago
    • ssh to remote, forwarding some remote port to your local ssh port (-R)
    • ssh from remote through the exposed port, starting socks proxy in the process (-D)
    • use socks proxy explicitly or find some tool that can route the traffic into it

    Similar approach can be used to establish VPN tunnel with no encryption (ssh already provides that), routing everything but your ssh connection through it.

    • ssh to remote, reverse forwarding your VPN-over-tcp server’s listening port
    • establish vpn connection on remote, route everything but your ssh connection through the newly established interface

    It will be wasteful, but it will work.








  • Please correct me if I’m wrong, but doesn’t this allow one to represent virtually any resource as a mail inbox/outbox with access through a generic mail app?

    I’m working with a specialized healthcare company right now, and this looks like a way to represent patient treatments data as an intuitive timeline of messages. With a local offline cache in case of outages. Security of local workstations is a weak point of course, but when is it not…



  • Sorry, but you don’t get to claim groupthink while ignoring state of Apache when Nginx got released.

    Apache was a mess of modules with confusing documentation, an arsenal of foot guns, and generally a PITA to deal with. Nginx was simpler, more performant, and didn’t have the extra complexity that Apache was failing to manage.

    My personal first encounter was about hosting PHP applications in a multiuser environment, and god damn was nginx a better tool.

    Apache caught up in a few years, but by then people were already solving different problems. Would nginx arrive merely a year later, it would get lost to history, but it arrived exactly when everyone was fed up with Apache just the right amount.

    Nowadays, when people choose a web server, they choose one they are comfortable with. With both httpds being mature, that’s the strongest objective factor to influence the choice. It’s not groupthink, it’s a consequence of concrete events.


  • Atheist is a non-believer. Prefix “a-“ means absence. Every human is an atheist unless they believe in every god. The word was first used in relation to Christians.

    Anti-theist is someone opposed to religion or belief in supernatural. “Anti” means “opposed / opposite to”.

    Agnostic is a bullshit cop-out term that at some point in a Christian discourse briefly meant “someone who considers supernatural to not be knowable”, but doesn’t have a proper meaning nowadays. It has a transactional role in conversation - it most often relays unwillingness to continue the conversation on religion.

    A “definite belief that there is no god” would be “gnostic atheist” in proper terms. I.e. “god is knowable and he’s absent”. But those proper terms were barely ever alive. Instead, people dance around topic of religion as if it didn’t enjoy enough fucking dances for millennia past.





  • Seems to me, you’re dealing with a micromanager.

    Personal recommendation - put things into writing. When you get your assignment verbally, write it down with assumptions you have to make to fill the gaps, and send it to the person who gave you the assignment, with the person responsible for your teams’ results in CC. Basically an “I heard you, and I’m starting the work as described below”.

    Communication is one of the most important skills in software engineering, and this way you get to practise it while probing the social waters of dealing with management.

    Try it, see how it goes, adjust accordingly.


  • I described a route to spoof DNS root authority that Russia and China can use already. Single root is not an advantage, it’s merely a different kind of implementation with different attack vectors.

    When it comes to security, it is better to have multiple different implementations coalesce at a point of service delivery, than have a single source of truth. If everything is delivered via DNS, there’s your tasty target for a capable adversary. If there are multiple verification mechanisms, it’s easier to tailor an attack for a specific target.

    I want cryptographic infrastructure I rely on to be the last resort for anyone capable of dealing with it.