If you’re always using a VPN, that’s not necessarily a privacy threat on your VPN’d device, but any other device on the network that doesn’t have a VPN could be exposing itself to the ISP.

Also, you’re at the mercy of whatever firmware updates your ISP issues for the router. Hopefully they remember to support your box when the next CVE is discovered…

We are forced to keep an ISP router/gateway combo in our home because it has certificates necessary to authenticate our subscription. However, behind that router we have the “real” router with settings and firmware updates that we control. The ISP router is just a hop between our router and the outside world. Everything on our network only connects to the router we control.

I left a company after 5 years because (in retrospect) I was starting to feel burned out about product engineering. I left for another product engineering job, thinking that my problem was with the product culture at my old place. Nope! Hated product work at the new place too.

Eventually a role opened up at the old place, working on a more dev-ops-y side, and I gave it a shot. It worked out well for 2 years, but after a re-organization cut back the scope of my work, I left for somewhere else.

http://www.thecodelesscode.com/case/6

I wouldn’t trust anything like that to the open internet. It would be better to access the system over a VPN when you’re outside the network.

The man is a monster. I don’t know how many of my build jobs have been murdered by this fiend.

As others have said, a reverse proxy is what you need.

However I will also mention that another tool called macvlan exists, if you’re using containers like podman or docker. Setting up a macvlan network for your containers will trick your server into thinking that the ports exposed by your services belong to a different machine, thus letting them use the same ports at the same time. As far as your LAN is concerned, a container on a macvlan network has its own IP, independent of the host’s IP.

Macvlan is worth setting up if you plan to expose some of your services outside your local network, or if you want to run a service on a port that your host is already using (eg: you want a container to act as DNS on port 53, but systemd-resolved is already using it on the host).

You can set up port forwarding at your router to the containers that you want to publicly expose, and any other containers will be inaccessible. Meanwhile with just a reverse proxy, someone could try to send requests to any domain behind it, even if you don’t want to expose it.

My network is set up such that:

• Physical host has one IP address that’s only accessible over lan.
• Containerized web services that I don’t want to expose publicly are behind a reverse proxy container that has its own IP on the macvlan.
• Containerized web services that I do want to expose publicly have a separate reverse proxy container, which gets a different IP on the macvlan.
• Router has ports 80 and 443 forwarding only to the IP address for my public proxy

“Still stands” means that there is no known way to achieve it. Not that it’s known to be impossible.

Until the discovery of the virtual console glitch for BitFS a few years ago, the A button challenge “still stood” for all cases.

For anyone wondering, this was done on the virtual console version, so the floating point glitch that lets you skip the climbing pole from Bowser in the fire Sea is available.

The A Button Challenge still stands for the console versions.

I know this is a joke, but I couldn’t be a programmer without some pedantry. LUnix is actually a real OS! I booted it on my Commodore 64 once.

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

I’m ok if this requires better EM shielding of electric vehicles. RF bands are a natural resource, and we should prevent short term profit-seeking from shitting them up.

They would not even need to open source the servers. Just making the server available for users to run (even under a proprietary license) would be enough.

Ahh, sorry. Our prior emails accidentally got sent to a family of 4 on their way to a birthday party. We promise our next job offer won’t miss!

Everyone’s gotta start somewhere. I do know that it’s not easy for trans men to get a well-fitting suit. I’m familiar with one case where the tailor sent the suit back without any alterations, because they thought the body proportions given by the shop were a mistake. That was rather infuriating to see, but it worked out in the end. I guess what I’m saying is that you should give yourself plenty of time in advance to get your next suit. It may not be the “come back in a week for pickup” that most men are used to.

Hell, I know a cis guy who had to visit 8 different places to find a suit that fit him. He’s a normal looking guy, but the proportions between his hips and waist was somehow an outlier for 99% of the pants he tried on.

He’d rather have a GNU contributor take a diarrhea dump on his pull request.

Consider SW Michigan. 2h drive/train to Chicago, proximity to large bodies of water for summer enjoyment, and if you live in a reasonably-sized town they’re probably good at clearing roads when it snows.

Besides, our winters get milder each year. There’s a couple of big snow/ice events, but the trick is to not be on the road while the heavy stuff is coming down. Wait a few hours for it to ease up and for the snow plows to do their thing.

These days, it’s not actually a blanket ban on anyone who used cannabis. To join the FBI, you need to be cannabis-free for 1 year before applying for a job.

https://fbijobs.gov/sites/default/files/2023-04/guide_eligibility.pdf

Reverts work because users have equal write access to all the data. You can mess things up in the codebase, and even if you die of a heart attack 10m later, my revert is just as valid as your commit.

It’s not really the same when every user has “sovereignty” over their address in the ledger. A bad actor has to consent to pushing a revert transaction onto the chain, or they have to consent to using a blockchain system where 3rd-party reversion is possible (which exists on some systems, but also defeats the concept of true sovereignty over your address).

Sounds rough. My fiancé does security, and from what I’ve gathered from him, the best time for security to get involved is at the design stage. They look over the proposal, give their input, and then nobody’s surprised at release time, and teams can follow agile practices. Obviously there’s still a review of the final product, but that can be done asynchronously after the fact to confirm that best-practices were followed.

Easy to say, hard to put into practice. Certainly depends on the kind of service your business provides.

I don’t think the security people would like that idea very much

Why not? How do your feature flags work?

Small releases, on a regular cadence.

How do you ensure that you’re not releasing features before they’re ready? Kinda depends on the application, but you might use feature flags. A system for turning features on and off without deploying the application. It could be a Boolean in a redis cache that your app looks for, or a DB entry, or another API. The point is for you to be able to flick a switch to turn it on instantly, and then if if breaks things in prod you can just as easily turn it off again.

And just a word of advice: Consider the performance impact of your feature flag’s implementation. We had a team tank their service’s performance because it was checking hundreds of feature flags in different DBs on every API call. Some kind of in-app caching layer with a short refresh period might help.