karmarepellent

Regarding SSH bastion hosts, apart from open-source and enterprise solutions that may add some valuable features, you can always get away with a properly configured SSH jump host using TcpForwarding to relay connections to the target host.

Regarding SSH, the MitM would generate a new host key for the actual host you try to connect to. meaning when the MitM existed in the first place and you trusted the host key then (adding it to your Known_hosts), you will not get any additional security warning.

This can of course be avoided by the organization by distributing host keys to the client beforehand as they (maybe) would if the host keys were the actual keys from the host stored in /etc/ssh.

In cases where I trust both the communication endpoints, e.g. an employee trying to SSH into an internal host, "trust" being established by other parameters that are not relevant to the firewall, why would I MitM such a connection?

At work I use a VPN to access the internal network, I then have to traverse multiple firewalls and a MitM breaking up my SSH connection in order to connect to a host running a webserver.

I have yet to understand how the MitM would increase security. Extra (well minus) points if the appliance in question auto-updates from the vendor's repository, offering no insight into the inner workings.

I agree with you in general, but to quote another point made in the article:

> Engineers are not turned off by jargon—in fact, they like it.

If a video or marketing-focused website tries to be clever, but without "fluff", and maybe alluding to some technical quirks or general behaviour of the product, I think I would like it. Extra points for being capable of not taking things too seriously, e.g. when some aspect of your product seems to be a weird design choice that is sure to get some flak from the engineering crowd.

Sorry for drifting a little off-topic, but I think this is also true for recruitment. When I get messaged from recruiters, most try to get into a call or video conference right of the bat to discuss an open position that would "fit my resume". Then I have to ask what the actual position is about and if there's a job ad with more (technical) detail. I'm perfectly capable of evaluating if a position is likely to appeal to me when I see a document describing it.

There is also the added benefit of saving a lot of time on both sides, because I do not even want to get into a lengthy conversation about a position I have zero interest in.

Again, sorry for hijacking your reply to talk about something entirely different!

I think we have to make a distinction between "concepts" being out of date and tools being out of date. I would not consider the concept (or architectural decision) to run a system on a fleet of VMs as outdated. However tools (e.g. compilers) absolutely go out of date once they are being deprecated and need timely migrations.

In the latter case I would consider it a red flag if some long-deprecated tool turned up in the tech stack of a company, but there might be perfectly good reasons to stick to the former, a bunch of VMs, instead of operating a Kubernetes cluster.

I ran a small Kubernetes cluster once and it turned out to be the wrong decision _at that time_. I think I would be delighted to see a job ad from a company that mentioned both (common hypervisors/VMs, containers/Kubernetes) in their tech stack. Without more information I would think that company took their time to evaluate their needs irrespective of current tech trends.

I would be hesitant to claim "the world is moving to" anything, really. Deployments that would now be called "traditional", so anything that does not run in a container but in a VM, will continue to exist for quite some time.

And not only because of legacy systems that are hard to migrate to a modern platform. At my place of work there are workloads that can easily run on Kubernetes and it would be wise to do so. On the other hand there are systems that are not designed to run in a container and there is frankly no need to, because not everything needs to scale up and down or be available 100% of the time at all costs.

I think configuration management systems like mgmt (or Ansible and Puppet) are here to stay.

It is hard to make assumptions about what parent means by that statement, given that there are degrees in which a system can be "connected to the internet". For example, every request coming in or going out, as well as SSH access, could go through a proxy. I would still call that being "connected to the internet", but it's different from giving your server a public IP address.

I think parent refers to the infrastructure that is required to (automatically?) sign certificates by an internal CA and managing the distribution of those certificates. I don't think verification is the issue.

I don't think it's always the software that is to blame. Sure there is software that wants to self-update and only accepts one upstream update source run by the vendor, instead of allowing users to run their own mirror and control update distribution to some extent.

But there are also cases where the software could be perfectly run in air-gapped systems but people are unwilling to put in the work (for some reason or another). For example everyone could run their own Docker image mirror that only contains images that are actually needed and pulls them from upstream with some delay. Docker allows you to pull images from your own registry. But not veryone is willing to operate their own registry.

Just to add to this: Apart from the security aspect of hosting your software dependencies internally, it also gives you the added benefit of better availability and performance.

As you mentioned in your other comment however, this presumes a certain mindset in people where they are willing to plan upfront and are mindful of the dependencies their software needs. As you say, just pulling whatever from Docker hub is certainly easier.

Internally hosted repositories also allow you to pull and install updates at your own pace, possibly days after they have been released upstream. So if a patch is borked you won't be affected.

I agree with you. Unfortunately my place of work has a habit of buying snake-oil security appliances as well which seems to magically absolve everyone from actually thinking about security deeply themselves.

Rather ironically said appliance (that basically acts as a man-in-the-middle in remote access) prevents me from going the last mile in securely configuring my systems. I would not be surprised if the appliance self-updates, but I'm not sure.

Regardless you could make the case that practices like these do not improve overall security, but instead just cost a large amount of money that you could hire three security-minded engineers from.

> I understand the author is saying "it's not that easy" and I agree completely with that, but I don't agree that it means you're doing your job well.

Could you elaborate what you mean by this? It seems to me that your comment just highlights another set of problems that should (in theory) motivate people to think more clearly about the ways their system communicates with the internet.

I don't see where you disagree with the blog author. Or are you saying that it's fundamentally impossible to improve security in internet-connected systems because people are not equipped to do so?

I don't think it is for people who refuse to learn another entire ecosystem for a project. Although smaller in size, HTMX needs to be learned as well. And although it is advertised as being simple, I certainly had a few struggles with it where I needed to spent some time figuring things out.

I would also oppose the frequently made proposition that HTMX is for people who hate Javascript. I certainly do not love Javascript, but I do not go out of my way to avoid it. My apps always have some vanilla Javascript sprinkled in where it fits.

To refer to the article: people really need to stop searching for that "silver bullet" and just use the tooling they are comfortable with.

I really have to say I'm annoyed by parties on both sides of the isle who either refuse anything but SPAs and React or others who see HTMX as the holy grail. The tooling on both sides (e.g. either React or HTMX) is being overhyped a lot. Once your app grows to a certain size or complexity you will struggle with either for some time until you "figure stuff out". No tool will ever alleviate the struggle in its entirety.

Fair enough, I did not think about the IaC space when I wrote the comment. And I can absolutely see how a blame could take you to commits from a few years back.

I was only thinking about the application code space where elaborate code comments are definitely more common.

Well written GitHub issues and PRs that you can reference in your git commit also don't save you from commenting code. I mean please do not reference an issue in a code comments, but describing to other people what a function in general does goes a long way to build understanding.

For new contributors it's probably also more useful to see the latest snapshot of the code base and code comments than having to check a git log in order to find out why a function would be written in the way it is.

I don't know about the "git log should stand on its own". Chances are that when you finally migrate to another ticketing system and the ticket numbers in your commits "break" or become meaningless, you do not care much about that old history anyway.

And even if someone is interested in an old commit that contains a ticket number for a ticketing system that does not exist anymore, the commit itself (the code changes, not the message) tell the story as well, just not in prose.

Yes, it happens a lot to me as well. However it baffles me why I would ever want to download and install a tool when I could just read a man page and create an alias for curl and some args. It's a perfectly capable tool that comes with every conceivable distribution.

The point of having man pages is that you don't have to remember "arcane spells of args". For huge manpages or manpages in general there is certainly a learning curve on how to read and apply them effectively. But it's also an underrated way of learning about the system you use and deploy your applications on.

I highly doubt that people employing this scheme are thinking it through though. Lets say you indeed engage with this email, not knowing its AI. Then when things are getting serious a human approaches you after all and you find out you were talking to AI all the time. Would you not be completely outraged by being fooled like this?

I think marketers underestimate that they may turn people off their brand in the long run by these tactics, because people do not like being fooled. And the more sophisticated the scheme the more outraged people are when they find out.

At my place of work there is an internal project ongoing whose goal is to determine which tasks could immediately be improved by leveraging AI. Its a desperate try to get into AI in general even though the company does not employ any people that would actually be able to dive deeper and have subject matter expertise.

Knowing the people (mostly marketers) leading the project I can 100% guarantee that they would call these Emails shenanigans a great idea and would immediately start (to tell someone) to implement it without taking a step back and thinking it through.

When I look into the website source of the book I just see static HTML and CSS as well as a few media queries. Why would you want to use htmx to serve a completely static website?

Yes, I don't get why people always tend to drift into thinking in extremes when it comes to new tech. Like when using htmx or similar tech you would absolutely need to implement every piece of logic in the backend.

Well, you don't. I have been very successful using htmx by using it only in interactions that make changes to my data, that is state. Other user interactions (e.g. strictly visual interactions) remain on the client.

You don't need to mix logic with templates. I just produce a context (result from database queries and some such) and pass it to a function that produces HTML from the data in the context. The data must not be changed in the templating function. This is something I try to avoid as well in order to maintain separation of concerns in the backend code.

Edit for clarification: The context holds the data that is rendered as-is by the templating function. So any transformations from the "raw" database data and the context data happens beforehand and the templating function just turns it into HTML.

If you have multiple applications on different servers communicating with the same database, then yes you would need to run a database such as PostgreSQL.

If you run a single application on a server that needs a database you might want to consider SQLite, regardless of your needs for concurrency/concurrent writes.

Yes PostgreSQL (and others) are a better choice in these scenarios. I think the point is that a lot of applications/systems might not even need this separation since a single server would be able to handle the load. In this case a local SQLite database could be a serious performance enhancement.

A lot of factors play into this and it certainly does not work in every case. But I recently got to re-write an application at work in that way and was baffled how simple the application could be if I did not outright overengineer it from the start.

That is just anecdata. But my guess is that this applies to a lot of applications out there. The choice is not between PostgreSQL/MySQL and SQLite, but between choosing a single node to host your application or splitting them between multiple servers for load balancing or other reasons. So the choice is architectural in nature.

Actually I first thought this person was joking in their blog post. As you already mentioned almost every piece of advice in there is related to how to look good in others eyes.

I would not dare interpreting too much into it but I do not think this is how you achieve satisfaction in your job. In fact I get anxious just thinking about me sitting there and being "oh my, I have not committed in an hour, people must be thinking I'm slacking".

On another note I also think much more goes into what makes a good commit than frequency. It's a topic that has already been widely discussed a lot and will continue to be discussed in the future.

Edit: I suppose this sentiment may also be one of the reasons why I'm increasingly reluctant to work with Gitlab. Their UI changes multiple times per year and I have yet to encounter a UI change that I would actually call an improvement. I value some level of stability in software that is being used by all our developers throughout the day. But someone seems to think their customers need to "see things changing" or they will stop paying for licences.

I am no familiar with SSH certificates either. But if there is no revocation system in place, how can I be sure access from a person can be revoked?

At our org we simply distribute SSH public keys via Puppet. So if some leaves, switches teams (without access to our servers) or their key must be renewed, we simply update a line in a config file and call it a day.

That way we also have full control over what types of keys are supported and older, broken kex and signature algorithms are disabled.

Just for info: there are alternative SSH server implementations out there that disable features that are discouraged (e.g. password authentication)[0]

Tinyssh is just one I already knew, I suppose you would find more via a proper search.

[0] https://tinyssh.org/

If feel like this is the moment where these discussions about old filesystem layouts start to go in circles.

Yes, system users tend to not have a home directory. But you are fully able to create one for a new system user if this is what you want to do.

You are also able to create all kinds of temporary directories and read-only filesystems for a process (e.g. using systemd) if this is what you want do to.

Yes there is a lot of fragmentation and no real standard, which is a little disappointing, but you sure have options to work with. And these options do not have to involve any legacy-ish filesystem components like /var/tmp that nobody knows the purpose of.