For sending a mail message on port 25:
HELO
mail-from: [email protected]
mail-to: [email protected]
<other headers>
<blank line>
Body of the message yay.
<two blank lines to end>
POP3 was so long ago I forgot but you could list the mailboxes then get individual messages and so on.
This revelation was the beginning of "there is no magic" for me. The realization that every part of the computer was built by human beings and was at some level understandable if one undertook the effort.
Perhaps most people in the future won't bother. They'll just let agents do it all. I'm sure that will leave some interesting holes in various systems for people willing to actually learn how they work without the filter of a model (or its safety rails).
I sent many an email from [email protected], the veneer of the terminal helping, my friends were quite impressed by how good a hacker I was. Good olde days when many DKIM/SPF weren't a thing yet and SMTP servers weren't even authenticated.
Back in those days not only was there was no DKIM or SPF, most SMTP servers would accept email from anyone anywhere to anyone anywhere (i.e. 'open relay').
[ Note: Anyone who has been a geek since the 90s, there's nothing you don't already know here ]
> most SMTP servers would accept email from anyone anywhere to anyone anywhere (i.e. 'open relay').
to date that claim, I'd say that by the late 90s at least, true open relays ("from anyone to anyone") were still numerous but carried a huge assumption of being part of spam operations (willingly or through ineptitude), and the most basic spam filtering would reject mail that came out of one.
That said, (before things like SPF) it was easy enough to deliver email to anyone you wanted even if you didn't have your own real email account and SMTP server; you could just look up the destination's MX and connect to it with telnet like that. Since your own random IP probably wasn't blocklisted it would generally be accepted and delivered.
Back then it was still basically considered bad form to reject email simply because the server didn't know where it was from... sadly, if we were still playing by those rules today, I can only imagine how useless email would be. Now it's definitely guilty-till-proven-innocent.
You can actually do that today. In fact I did that for some time, because I didn't want to configure e-mail client. The only hard thing is HTML. Average HTML e-mail is almost impossible to read and friction to extract it to a file to open in a browser is too much.
It was also cool discovering the ATA commands to drive the modem. You could “war-dial” numbers, or manually initiate Internet connection, or connecting to a bbs
You can't do that with HTTP/2 (but thankfully every server still talks HTTP/1).
You also can't do that with TLS (and a lot of servers won't talk HTTP other than redirects). openssl s_client instead of telnet might allow you to tunnel text inside TLS, but that feels like a cheating.
And many other modern protocols, sadly, prefer binary encoding, which makes it impossible to tinker with it on wire level, not without specialized tools anyway.
I think people in the future will bother. I tried to make a fire with sticks once, I tried to burn a clay brick, these old things can be a lot of fun and sometimes of real use. If anything, AI actually makes tinkering a lot more easier. You don't need to dig into RFC to check your mail, you can just talk to LLM about it and it'll help you with most typical IMAP commands, for example.
I never figured out you could do it with HTTP, but for some reason I did for FTP and IRC. I don't know why I first tried using a telnet client but I couldn't believe it when the server responded to me!
When I was 12, I learned about open SMTP relays and how to spoof email this way. I once spoofed an email between two rivals on a community I was a part of and started a flame war.
When I was in high school in the mid 2010s, Verizon's email-to-SMS gateway didn't verify SPF/DKIM/DMARC, and I had a field day showing my classmates the Viagra ads that Hillary Clinton's "hacked" email server was sending me. In reality, it was an open relay, but Verizon didn't care; they always delivered it anyway.
What you are doing here is trying to speak HTTP yourself, which is fine for testing and debugging, and hella cool for fun to do by hand, but you will shoot yourself in the foot if you try to use this pseudo http client unattended in reality. This toy code does not parse HTTP properly and will break.
Need to be clear that "full http server in pure bash" is incorrect. Bash cannot listen on a TCP/UDP socket for incoming connections.
bash-web-server project builds a C language socket listener [0] that is dynamically loaded at run-time as a "built-in" module that makes the functionality available.
Very fair pushback -- I did get carried away and will update the article to be more precise. Thanks for raising it!
> For less insane, non-bash shells there is always nc which is usually probably the wiser choice.
For completeness, `nc` or any netcat equvialent I could think of was not available in the image I was trying this with. It would certainly be a better option though.
This worries me. Some AI writing styles became mainstream; at first it was the em-dashes, now it’s “A, not B” patterns and excessive acknowledging. There will be more.
Was grandparent comment written by an LLM?
Or is this a human who copies a style they saw in a blog post, unaware that they’re copying an AI?
Or is this a human who spent too much time talking to an AI and now they just talk like this?
Or is this an organic human response and we’re all paranoid by now?
When learning a language, I've heard it's good to find a reference speaker, such as a prolific actor, and mimic them in order to absorb several aspects of what makes them sound authentic as a speaker, such as vocabulary, intonation, diction, pacing.
For many in the next generation of language learners, this reference will be Claude.
I think that the fact that AI has a very recognizable singular style is a problem. And this problem will be solved, sooner or later. It probably isn't a very important problem, because I feel that it should be relatively easy to solve (but maybe I'm wrong?).
But certainly with smarter AI I do believe it'll become more fluent with choosing more diverse idioms and phrasing, rather than repeating one thing over and over, to a point of being a comically similar. So people who learn on AI-generated text, will not learn from just one recurring style.
Insightful, and scary! Imitating an imitation machine... even if no one is trying to intentionally do so, McLuhan's "we become what we behold" is inescapable.
It's pretty rough to learn I sound like Claude. Will need to do something about it then.
(For what it's worth I did write the message above manually but I understand why no one would believe that now. At least I did not call netcat "load-bearing" [https://mareksuppa.com/til/load-bearing/] or something...)
I did not think you sounded like claude. Then I looked again after the comment was made and then I saw some of the vibes. Like acknowledging a mistake you have done.
Before that would just made you top 5% (or maybe top 1%) of the nicest people to talk too.. know ppl think you are Claude.
FWIW, I didn't read this as AI-like. Even on a re-read, it's only the quasi-em-dash, and _maybe_ the polite acknowledgement of "Very fair pushback" (just good etiquette, IMO!) that would ring any alarm bells. You're fine.
Sometimes you want to do something that curl cannot express, e.g. timing, protocol oddities, etc. For example you may want to issue a CONNECT to an echo server through a proxy and observe the bytes flowing back and forth. You may want to see what happens when conflicting hop-by-hop headers are specified without worrying about the client's (curl's) interpretation of them. A simple nc -c (or openssl s_client -crlf) lets you do all of that.
Ah, I see what you mean. Aside from putting the proxy into debug logging one would have to use curl -vvv to get similar details but I suppose whatever works best with muscle memory is the right choice and one may not always have access to put the proxy into debug logging.
I need to try this with a Squid SSL Bump MitM proxy just dont have one up at the moment.
curl -vvv -A Mozilla -H "Accept-Language: en_us" -H "Sec-Fetch-Mode: navigate" --url 'https://nochan.net/.env'
Is it the reply to ‘HELO’ that enables things like tarpits?
Like if my server replied with ‘HI PLEASURE TO MEET YOU 127.0.0.1 THAT NAME SOUNDS FAMILIAR ARE YOU BY CHANCE FROM BOSTON MY MOTHER IS FROM BOSTON WELL QUINCY ACTUALLY BUT DO YOU KNOW 127.0.1.1 THEY ARE A REALLY GOOD FRIEND OF MINE YOU SHOULD MEET I HEAR THEIR DAUGHTER IS A DOCTOR DONTYAKNOW AND YOU COULD…”
For SMTP tarpits you can do all kinds of fun stuff. Not just in the reply to helo. Like: always be slow to respond. Respond to each command with a temporary error. Accept everything, then pause, then error. Send back large chunks of garbage.
the '90s version of finding the hiring manager or boss on linkedin to try and get a job was connecting to the company's public smtp server with telnet, using their name to probe different email address patterns with "rcpt to:" (those days the actual servers were often directly connected to the internet and would leak email address validity in how they would respond to rcpt to) and then sending them a nice email.
smtp grew up to be an antisocial curmudgeon. extended smtp starts with EHLO.
yeah, i think you're right. i originally read a bit of snarky blow-off, like "eh?" ... but you know, now that i think of it, it's actually does have more of a friendly canadian style vibe.
Note: Telnet is not completely plaintext and has control characters in the upper byte range (like 0xff or something, I forget).
Use nc or this TCP Bash technique if you really want to ensure decent compatibility when doing hacky solutions, otherwise a random 0xFF somewhere from a terminal console color change (or other control character) might really screw you over.
Sometimes I don't understand why people use those most tiny of images, at least for anything that they might ever ssh into.
When there is no corresponding level of restraint in the libraries that we add to most applications, does it really make a difference to leave out the likes of curl, nano, ping, etc compared to how frustrating it is to operate in just busybox (etc)?
I'm not just ranting, I'd actually like someone who swears by always shipping alpine images (etc) and never installing any basic utilities in them to share their reasoning.
>No, you can't write 10 lines of code, you have to import a 100k LOC dependency
Common misconception, if you want to replace a dependency on a swiss knife you don't need to implement a swiss knife, sometimes you can just implement the last helix of the corkscrew.
Nice parameter expansion examples in that bash-web-server. It uses the $_ parameter in ways I hadn’t thought to before, often preceded by a single : ${x} line for pre-processing of the variable.
I thought you had to use a program called netcat for that--if not then what is the point of that binary? And for that matter, can't you also use telnet to manually send HTTP?
It seems pretty cool, but I am wondering if there's any drawback on just using images that support curl? I can't think of any and to me it's kinda a must have, even on production images
I always recommend to not have any dependencies outside of the code.
So we start at compiling the codebase (Rust) against MUSL. That way we can run it with FROM scratch images.
If we need more tooling available at runtime, then we look at alpine, but still using MUSL.
If MUSL itself is proving problematic, or if some of the libraries we use need glibc then we can look at using some locked down image.
The cool part about FROM scratch images is that you'll never have to update your base image to address CVEs. Only your software and its (compiled) dependencies.
preface: I'm not asking things rhetorically, I genuinely want to learn here.
> to not have any dependencies outside of the code.
> ... FROM scratch images is that you'll never have to update your base image to address CVEs...
So a FROM scratch image, basically doesn't have things like a package manager to install things, and maybe also libraries that things like curl would depend on? Sorry for my ignorance, I've heard of FROM scratch but never tried them.
> The cool part about FROM scratch images is that you'll never have to update your base image to address CVEs. Only your software and its (compiled) dependencies.
What's the benefit really, though? If you still need to be able to rapidly deploy a new image in response to a dependency CVE, what have you gained?
You want to ship every debug utility you will need in every image? Just seems wasteful. What about 3rd party images, you will respin images just to add your preferred toolset?
Nope, not my position at all. I want to have a minimal OS environment with rudimentary tools available with zero extra friction. FROM alpine:latest adds less than 10MB and covers 95% of use cases. Typically depending on the container I will often throw in curl and some other QoL tools too.
For the rare cases where you find yourself needing to attach a debugger to your pods running in staging/prod, a debug container is absolutely the right tool to reach for.
> every debug utility you will need in every image? Just seems wasteful
How wasteful though? I have to admit, I envy the person whose codebase itself they have to support is so lean and space-conservative that the size of the gnu coreutils, curl, nano, etc., would show up as anything but a rounding error in the image size.
I see it like putting a thermometer in a turkey before I stick it in the oven. Sure, the thermometer adds thermal mass itself, making the turkey take a few seconds longer to cook, but the value of it being there is greater than the cost imposed.
Both. Many attacks take the form of an exploit to get a shell, then using available utilities to exploit the kernel to escape to the host. If your image has neither a shell nor utilities that won't get very far.
More than one ~500 employee company I've worked at has had security policies either encouraging or requiring the use of "distro-less" images - images with no OS components other than the absolute minimum required to run the application. For go binaries this meant literally nothing in the container apart from the executable.
In theory it has a couple of benefits. You don't have to re-deploy your image to patch CVE's in OS components if you don't have any OS components. And it provides some measure of defence-in-depth - one could certainly theory-craft a scenario where an attacker gains some limited control over your application and then uses some OS component to escalate.
These days if a security engineer is proposing my team adopt distro-less containers to receive these benefits, I would point out that we need to weigh them against the very real drawbacks of not having standard debugging tools available where and when we need them. And also to consider the relative impact of other defence-in-depth measures they could be pursuing instead - such as any sort of network policy to limit network traffic.
> not having standard debugging tools available where and when we need them
Keeping in mind that containers are merely a bunch of namespaces, there's nothing stopping you from entering the same PID namespace with a different mount namespace in order to debug.
For what its worth, this container used `python:3.12.2-slim-bookworm` and I really would not expect that sort of an image to bundle `curl` -- even if it is intended for production.
Ah I see so it was basically a minimal image that bundles just python? I can see why it wouldn't bundle curl! Thought it was a custom Image for some reason, hence my original comment
This of course only supports http, not https. It's great for health checks e.g. in a docker environment. To do https, you'd have to use something like socat, but of course that doesn't use bash only.
example.com is also great for that reason when something fails about a captive portal on a public WiFi.
I open my web browser and go to http://example.com and get redirected to the captive portal page again and retry completing what they need from me to get internet access.
Plus, it feels nice to depend on the reserved domain name example.com instead of relying on a domain that any one specific corporation has to maintain :D
What gives you confidence example.com won't start serving the HTTPS redirect though? There isn't any reason they wouldn't, and given that browsers are clearly tending towards showing big scary warnings to even accessing something over cleartext, I wouldn't be surprised if they flipped that switch just to avoid confusing noobs.
Note that this didn't work historically on Debian, and presumably Debian-derived distros, where the virtual file TCP access was disabled by default. The position was reversed (and the capability enabled) in 2009, AFAIU. There's discussion and links in Bug #146464:
As others have mentioned, there are numerous other ways to directly access network features using shell tools, including curl (noted in TFA's title), wget, the HEAD and GET commands (from Perl), netcat (nc), socat, telnet, and I'm quite sure others.
For a light-weight aliveness check or something like that this is perfectly fine approach.
Just like parsing HTML with regexes can be fine too - for instance if you know the sender.
Just like repeating code can be fine too, even though it violates DRY.
Mixing markup and code can be fine (call it Locality of Behavior).
But separating markup and code is fine too (Separation of Concerns).
goto’s can be a lifesaver for deeply nested error conditions in C.
The point is all these “you shouldn’t do this” comments are just generalities. Use your judgement, decide if the tradeoffs are right and make a deliberate choice.
Note that this is not what the article is about. Bash has a fake /dev/tcp path that opens sockets. What you have there is just perl opening a socket normally. Great solution, but the interesting bit is that fake path.
TIL: bash and other shells try to copy Plan 9's /net directory and the kernel ip(3) file server. Too bad it's not a real file system. And a missed opportunity to call the root of the path /net.
At a past job the security team wouldn't let us have netcat or curl on our systems. So I just used /dev/TCP to get around that. The ergonomics were not as nice as using netcat or curl, but it got the job done.
This is pretty neat if all you need is to ping a local server but please use curl (or something equivalent) for contacting remote services. HTTP1.1 seems like such a simple protocol but in the real world you need to deal with proxies, different encodings, and redirects. Curl takes care of that (and a host of other annoying stuff) for you.
I was really just trying to see if intra-container connectivity works, and this ended up being a very quick way of doing so. (The alternative being building and deploying a new image, which would likely take significantly longer.)
Fun story: A few years ago, I worked for a small company that customized off the shelf routers to enable businesses provide Wifi Hotspots.
The routers were very basic model with very limited flash memory (~4MB?). I was brought in to build firmware for those routers. I ended up customising openwrt - removed all kinds of packages to make their packages fit on those routers. At the end, I had less than 4KB space, And I needed to implement a "heart beat" service. A lot of routers were behind firewalls that only allowed http, https and a couple of other protocols. Libcurl was too heavy. So I ended up writing a shell script that used this feature of bash to send out heart beats.
It was fun exploring this to make a native-shell-only peer-to-peer file transfer utility at work for some automation scripts. At least, it was until trying to replicate it in Powershell was somehow triggering Crowdstrike and the corporate Cybersecurity team thought I was writing malware.
This is the kind of content we all deserved in 2026, and this is still why I ask during interviews to explain how cookies are represented in HTTP protocol.
> This is a bash feature, not POSIX. dash (Debian’s /bin/sh) and zsh don’t have it, so a #!/bin/sh script can’t use it. Call bash directly.
This is why we can’t have nice things. This feature is complex and obscure enough that you are unlikely to be able to use it manually without consulting a reference, and poorly supported that any script you write with it is unportable.
Bash is so powerful and so frustrating for this reason all the time :(
It's interesting that most of the comments here are about using this feature to bypass security restrictions (whether valid or not). It says a lot about the attack surface of GNU utilities caused by featuritis.
This was something I learned about 10 years ago when earning my OSCP, useful during penetration tests and CTFs when you get a low-priv shell that's running a minimal OS (No curl, nc, python, etc.) but running a web server listening on localhost.
Using /dev/tcp was also handy in getting that initial low-priv shell.
This is an old post-compromise trick used when an attacker needs to download a payload or make a network connection and curl, wget and nc are all not available.
Once had a coworker tell me to never to use this because "you never know when the customer doesn't have bash installed; use python instead" even though our contract required that the customer had bash. I'm still laughing at that.
FWIW, some distributions (I forget which ones, but I've seen it more than once) compile bash without the network features. Python is ubiquitous, and I've never seen it subsetted this way, so I'd have sided with the coworker.
Eh, looking around, I think you're thinking of Debian. They re-enabled it by-default back in 2009. So, sure, I guess. But if you're dealing with an OS that's from 2009 these days, whether /dev/tcp is enabled in bash or not isn't exactly relevant anymore. And I've seen enough broken python installs (even with stdlib) to put my faith in /dev/tcp working in bash :)
I discovered this bash trick by chance when I was once trying to healthCheck the Envoy's official OCI image container which didn't include curl or wget while forcing the envoy admin interface to listen on localhost which breaks the traditional k8s httpGet checks.
It's a fun trick, but I really don't like that bash does this. It's such an un-clean interface, and I'm not aware of any use cases beyond trying to exfiltrate data from a badly locked-down shell.
Yes, it used to be my goto few times when some devices tried to lockdown everything with bare minimum core utils and no network capable tools like curl etc.
I discovered it for myself some years ago, when I wanted to make simple network test scripts run without depending on curl or telnet, or other executables outside of bash.
Simple get: GET / HTTP/1.1 Content-Type: text/html User-Agent: l33t hax0rs lol X-Funny-Monkey: farts
For sending a mail message on port 25: HELO mail-from: [email protected] mail-to: [email protected] <other headers> <blank line> Body of the message yay. <two blank lines to end>
POP3 was so long ago I forgot but you could list the mailboxes then get individual messages and so on.
This revelation was the beginning of "there is no magic" for me. The realization that every part of the computer was built by human beings and was at some level understandable if one undertook the effort.
Perhaps most people in the future won't bother. They'll just let agents do it all. I'm sure that will leave some interesting holes in various systems for people willing to actually learn how they work without the filter of a model (or its safety rails).
> most SMTP servers would accept email from anyone anywhere to anyone anywhere (i.e. 'open relay').
to date that claim, I'd say that by the late 90s at least, true open relays ("from anyone to anyone") were still numerous but carried a huge assumption of being part of spam operations (willingly or through ineptitude), and the most basic spam filtering would reject mail that came out of one.
That said, (before things like SPF) it was easy enough to deliver email to anyone you wanted even if you didn't have your own real email account and SMTP server; you could just look up the destination's MX and connect to it with telnet like that. Since your own random IP probably wasn't blocklisted it would generally be accepted and delivered.
Back then it was still basically considered bad form to reject email simply because the server didn't know where it was from... sadly, if we were still playing by those rules today, I can only imagine how useless email would be. Now it's definitely guilty-till-proven-innocent.
One day I realized even databases were just text files and I had to sit down.
As the calendar rolled from 1999 to 2000, we entered a new millennium, century, decade, year, day, ...
Every Jan 2 I start saying "last year" and every Dec I say "see you next year"
no, that all happened when we rolled from 2000 to 2001.
smh, even paedants today aren't what they used to be.
You also can't do that with TLS (and a lot of servers won't talk HTTP other than redirects). openssl s_client instead of telnet might allow you to tunnel text inside TLS, but that feels like a cheating.
And many other modern protocols, sadly, prefer binary encoding, which makes it impossible to tinker with it on wire level, not without specialized tools anyway.
I think people in the future will bother. I tried to make a fire with sticks once, I tried to burn a clay brick, these old things can be a lot of fun and sometimes of real use. If anything, AI actually makes tinkering a lot more easier. You don't need to dig into RFC to check your mail, you can just talk to LLM about it and it'll help you with most typical IMAP commands, for example.
Good times.
But the joke's on him--it led directly to me meeting a lifelong friend & mentor.
But can you imagine the look on some young teen’s face when they train their own GPT on their local computer for the first time?
No, it can not. Bash lets you open TCP sockets.
What you are doing here is trying to speak HTTP yourself, which is fine for testing and debugging, and hella cool for fun to do by hand, but you will shoot yourself in the foot if you try to use this pseudo http client unattended in reality. This toy code does not parse HTTP properly and will break.
You could of course write a full http/1.1 client in bash, you can even do a full http server in pure bash: https://github.com/bahamas10/bash-web-server
For less insane, non-bash shells there is always nc which is usually probably the wiser choice.
bash-web-server project builds a C language socket listener [0] that is dynamically loaded at run-time as a "built-in" module that makes the functionality available.
[0] https://github.com/bahamas10/bash-web-server/tree/main/loada...
https://sdomi.pl/weblog/15-witchcraft-minecraft-server-in-ba...
Very fair pushback -- I did get carried away and will update the article to be more precise. Thanks for raising it!
> For less insane, non-bash shells there is always nc which is usually probably the wiser choice.
For completeness, `nc` or any netcat equvialent I could think of was not available in the image I was trying this with. It would certainly be a better option though.
Was grandparent comment written by an LLM?
Or is this a human who copies a style they saw in a blog post, unaware that they’re copying an AI?
Or is this a human who spent too much time talking to an AI and now they just talk like this?
Or is this an organic human response and we’re all paranoid by now?
I don’t know which would be worse.
For many in the next generation of language learners, this reference will be Claude.
But certainly with smarter AI I do believe it'll become more fluent with choosing more diverse idioms and phrasing, rather than repeating one thing over and over, to a point of being a comically similar. So people who learn on AI-generated text, will not learn from just one recurring style.
(For what it's worth I did write the message above manually but I understand why no one would believe that now. At least I did not call netcat "load-bearing" [https://mareksuppa.com/til/load-bearing/] or something...)
Before that would just made you top 5% (or maybe top 1%) of the nicest people to talk too.. know ppl think you are Claude.
We are all going crazy s a sibling comment said.
I notice myself getting afflicted with llm-isms after a full workday. And I didn't always notice, sometimes I only realize the day after...
Like it slowly siphoned out my soul, which then reconnected with me over night
I remember when the "hacker vs. cracker" distinction went away because Hollywood co-opted the former and it became de facto "hacker == bad guy"
it is insane to use it for anything serious (also the opposite, implementing webservers in bash), but for quick testing it's pretty great!
[2] - torsocks, tsocks, wireproxy, shadowsocks-rust, proxychains-ng, etc...
and a server behind it like
``` mkfifo /tmp/myfifo cat /tmp/myfifo | nc -l 12345 > /tmp/myfifo ```
so if you manually type out
you can see exactly what's happening. To be fair you can hack curl to support that via but that's not exactly what you want and requires curl to have been compiled with telnet support.I need to try this with a Squid SSL Bump MitM proxy just dont have one up at the moment.
telnet was always there though. it also worked for speaking all the other plaintext internet protocols. (imap, pop, smtp, etc)
Like if my server replied with ‘HI PLEASURE TO MEET YOU 127.0.0.1 THAT NAME SOUNDS FAMILIAR ARE YOU BY CHANCE FROM BOSTON MY MOTHER IS FROM BOSTON WELL QUINCY ACTUALLY BUT DO YOU KNOW 127.0.1.1 THEY ARE A REALLY GOOD FRIEND OF MINE YOU SHOULD MEET I HEAR THEIR DAUGHTER IS A DOCTOR DONTYAKNOW AND YOU COULD…”
etc, etc?
smtp grew up to be an antisocial curmudgeon. extended smtp starts with EHLO.
email will become so unusable, next one will have to be HELNO i guess
"EHLO" still sounds friendly. It just sounds like a different accent or something. Know someone that used to answer calls with a friendly "Jello?".
Use nc or this TCP Bash technique if you really want to ensure decent compatibility when doing hacky solutions, otherwise a random 0xFF somewhere from a terminal console color change (or other control character) might really screw you over.
EDIT or ya know, use the correct tool like Curl.
When there is no corresponding level of restraint in the libraries that we add to most applications, does it really make a difference to leave out the likes of curl, nano, ping, etc compared to how frustrating it is to operate in just busybox (etc)?
I'm not just ranting, I'd actually like someone who swears by always shipping alpine images (etc) and never installing any basic utilities in them to share their reasoning.
Common misconception, if you want to replace a dependency on a swiss knife you don't need to implement a swiss knife, sometimes you can just implement the last helix of the corkscrew.
api, GET url, content-type aplication/json, parse json
you can even invert it and make a server
I thought you had to use a program called netcat for that--if not then what is the point of that binary? And for that matter, can't you also use telnet to manually send HTTP?
https://linux.die.net/man/1/nc
The main surprise was that Bash has /dev/tcp which lets you do the equivalent of an HTTP request with a bit of shell magic, for instance:
Where `service` is just the hostname of whatever you’re talking to and 8642 is the port you are trying to talk HTTP to.Pretty cool!
So we start at compiling the codebase (Rust) against MUSL. That way we can run it with FROM scratch images.
If we need more tooling available at runtime, then we look at alpine, but still using MUSL.
If MUSL itself is proving problematic, or if some of the libraries we use need glibc then we can look at using some locked down image.
The cool part about FROM scratch images is that you'll never have to update your base image to address CVEs. Only your software and its (compiled) dependencies.
> to not have any dependencies outside of the code.
> ... FROM scratch images is that you'll never have to update your base image to address CVEs...
So a FROM scratch image, basically doesn't have things like a package manager to install things, and maybe also libraries that things like curl would depend on? Sorry for my ignorance, I've heard of FROM scratch but never tried them.
What's the benefit really, though? If you still need to be able to rapidly deploy a new image in response to a dependency CVE, what have you gained?
Add an ephemeral container to an already running pod, for example to add debugging utilities without restarting the pod.
https://kubernetes.io/docs/reference/kubectl/generated/kubec...
And even that's only true if you assume kubernetes is the only place your container runs where you might want to also debug it.
For the rare cases where you find yourself needing to attach a debugger to your pods running in staging/prod, a debug container is absolutely the right tool to reach for.
How wasteful though? I have to admit, I envy the person whose codebase itself they have to support is so lean and space-conservative that the size of the gnu coreutils, curl, nano, etc., would show up as anything but a rounding error in the image size.
I see it like putting a thermometer in a turkey before I stick it in the oven. Sure, the thermometer adds thermal mass itself, making the turkey take a few seconds longer to cook, but the value of it being there is greater than the cost imposed.
But when Docker scans my image and notices that there is a CVE in one of those binaries, my image is currently out of compliance.
FROM scratch just reduces the surface.
The actual attack surface of your application? Or the attack surface of you and your team's attention from a busybody security org.
It's important not to confuse the two.
In theory it has a couple of benefits. You don't have to re-deploy your image to patch CVE's in OS components if you don't have any OS components. And it provides some measure of defence-in-depth - one could certainly theory-craft a scenario where an attacker gains some limited control over your application and then uses some OS component to escalate.
These days if a security engineer is proposing my team adopt distro-less containers to receive these benefits, I would point out that we need to weigh them against the very real drawbacks of not having standard debugging tools available where and when we need them. And also to consider the relative impact of other defence-in-depth measures they could be pursuing instead - such as any sort of network policy to limit network traffic.
Keeping in mind that containers are merely a bunch of namespaces, there's nothing stopping you from entering the same PID namespace with a different mount namespace in order to debug.
Add an ephemeral container to an already running pod, for example to add debugging utilities without restarting the pod.
https://kubernetes.io/docs/reference/kubectl/generated/kubec...
For what its worth, this container used `python:3.12.2-slim-bookworm` and I really would not expect that sort of an image to bundle `curl` -- even if it is intended for production.
I open my web browser and go to http://example.com and get redirected to the captive portal page again and retry completing what they need from me to get internet access.
https://gist.github.com/skull-squadron/edb8c0122f902013304c0...
- http://captive.apple.com/
- http://connectivitycheck.gstatic.com/generate_204
- http://detectportal.brave-http-only.com/
Plus, it feels nice to depend on the reserved domain name example.com instead of relying on a domain that any one specific corporation has to maintain :D
My only concern would be that example.com doesn't promise to never do the 'required SSL' thing.
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=146464#37>
As others have mentioned, there are numerous other ways to directly access network features using shell tools, including curl (noted in TFA's title), wget, the HEAD and GET commands (from Perl), netcat (nc), socat, telnet, and I'm quite sure others.
Just like parsing HTML with regexes can be fine too - for instance if you know the sender.
Just like repeating code can be fine too, even though it violates DRY.
Mixing markup and code can be fine (call it Locality of Behavior).
But separating markup and code is fine too (Separation of Concerns).
goto’s can be a lifesaver for deeply nested error conditions in C.
The point is all these “you shouldn’t do this” comments are just generalities. Use your judgement, decide if the tradeoffs are right and make a deliberate choice.
FROM openjdk:11-jre-slim HEALTHCHECK --start-period=10s --timeout=3s --retries=5 \ CMD perl -e "use IO::Socket; $sock = IO::Socket::INET->new(Proto => 'tcp', PeerAddr => 'localhost', PeerPort => '8888') or die $@; $sock->autoflush(1); print $sock 'GET /actuator/health HTTP/1.1' . chr(0x0a) . chr(0x0d) . 'Host: localhost:8888' . chr(0x0a) . chr(0x0d) . 'Connection: close' . chr(0x0a) . chr(0x0d) . chr(0x0a) . chr(0x0d); while (my $line = $sock->getline ) { if ($line =~ /UP/) {exit;} }; close $sock; exit 1;"
https://youtu.be/hBcfrQ8y5Qg?is=Osjnhjrx7WgsHqVj
docker inspect -f '{{.State.Pid}}' container-name
# let's imagine that outputs 814538
nsenter -t 814538 -n curl example.com
https://github.com/ksh93/ast-open-archive/blame/master/src/c...
I was really just trying to see if intra-container connectivity works, and this ended up being a very quick way of doing so. (The alternative being building and deploying a new image, which would likely take significantly longer.)
You said the image was Python, though? Using that is way easier and faster. https://news.ycombinator.com/item?id=48558763
If all you need to know is that it can connect:
python3 -c 'import socket as s;s.create_connection(("8.8.8.8",53))'
or http:
python3 -c 'from urllib.request import*;print(urlopen("http://example.com").status)'
The routers were very basic model with very limited flash memory (~4MB?). I was brought in to build firmware for those routers. I ended up customising openwrt - removed all kinds of packages to make their packages fit on those routers. At the end, I had less than 4KB space, And I needed to implement a "heart beat" service. A lot of routers were behind firewalls that only allowed http, https and a couple of other protocols. Libcurl was too heavy. So I ended up writing a shell script that used this feature of bash to send out heart beats.
Fun times...
This is why we can’t have nice things. This feature is complex and obscure enough that you are unlikely to be able to use it manually without consulting a reference, and poorly supported that any script you write with it is unportable.
Bash is so powerful and so frustrating for this reason all the time :(
Using /dev/tcp was also handy in getting that initial low-priv shell.
I discovered it for myself some years ago, when I wanted to make simple network test scripts run without depending on curl or telnet, or other executables outside of bash.