Even after communicating the fact to them several times, and one country or another asking the prison of some high executive. Those things are just too hard to keep track of.
I think it’s hard to think of the problem that way.
These days* of course you have to worry about security on almost anything you work on. And when you do, the folks who think of security all the time are going to tell you to simplify your interfaces so they are easier to think about, then then armor them. What a pain!
But we do those things because of all the bad actors. The security recommendations are a consequence, not the cause.
* I grew up — literally — in a non-security environment: networked computers with no passwords or any other security. The only “protection” what would be called today kernel space memory barrier just to protect against bugs, and most machines didn’t have that. It was the late 70s and security was considered a barrier to hacking. I knew people working on security and frankly it seemed weird.
To quote James Mickens "most of the security reasearch community seems to be obssesed with avant-garde horrors such as the ability to induce a heart attack in those wearing pacemakers during a solar eclipse with a pringles can."
At this point it seems that most of it really is just security theater and most really security actually comes from proper training.
And of course there are the theatrical password rotation and such that cause passwords to be written down in the first place.
But even in this comment stream someone asked who cares if the remote side learns the version number of the code you’re running, and somebody else wrote that security would not be a problem if users didn’t do what they considered foolish things. These pragmatic problems are where the risks lie.
Defense at depth is the only way to go, unfortunately.
I say this as someone who snuck an easter egg into our product at my last job. Yes, it was fun, but if I had gotten in trouble for it, I would have deserved it.
That's often how things works. With friends we joke around a lot because we know each other well and know there aren't bad actors. At work, I'm way more careful. If there were no cases of harassement, exploitation or things like that at work I may joke around more. But since they exist, I'm more careful. I don't want to harass people, be seen as an harasser, or create an atmosphere were harassers feel welcomed.
When bad actors exist, the way to show good will is to not act like them, so they can be quickly identified and removed.
> Update 12-04-2017: This feature was removed in PHP 5.5.
Because if you know the version, it gives you a shortcut, and you can immediately switch to a smaller arsenal designed for that specific version.
Hiding version numbers etc is an example of "Security through obscurity" and is a weak defence strategy:
And your second point is debatable. See defense in depth.
Is there a generation thing that made this happen? It seems now that no matter what you do, if it deviates from what a paying user would expect, even if the thing is free, that as a developer you can get called up in front of these ad-hoc tribunals of the common man to answer and atone for your sins.
It's so dumb the way the internet is going, I thought when we invented it that things would be so much better. I have nothing but spite for the last 20 years of the way we have treated this golden resource.
* Ages ago, when the millennials were still in grade school and CMS was still a multi-million dollar proposition, I wrote a nifty little copyediting tool for a Very Large Telephone Customer. Someone made a benign jokey edit in during a demo of the tool, which made it to production. The next day there was an emergency meeting with over 150 people across several offices about "what happened" that led to a page deep in the site showing people in New Jersey that calls from your basement were free.
I know we stand tall because we stand on the shoulders of giants (and, in our industry: many giants!) but I don't think you can expect any form of guarantee that curl continues to work exactly like you expect unless you're paying for it.
It's a different story if you have some kind of enterprise contract, but somehow I have the impression that we're all using cURL for free and paying nothing for support-- thus, there is no support and you shouldn't really expect any.
If you want to make cURL-Enterprise then that's fine..
but it's a bit unfair to co-opt someone else's project just because you and I chose to use it professionally.
(this applies to me also: I am guilty of this, I'm not pointing fingers at you specifically; just my, and our, collective attitude)
On the contrary, Daniel’s job is commercial curl support. See any of:
A lot of my joke errors boiled down to "you've hit an edge case I didn't handle, here's an easily searchable string to find the location". They were jokey because the subtext was another late night and you might as well soften the blow.
I started online in the early 90s. The Internet was not important back then. Not much depended on it, there weren’t many people on it, so the folks who were there could fuck around and not worry about it. Jokes are easy and safe when they are low-stakes.
Now, the Internet is extremely high stakes. A huge part of society depends on it. People are just naturally less willing to tolerate jokes in things they depend on. Powerful emotions involving fear and safety and security and power can get invoked, maybe accidentally.
Let’s say you’re driving with some friends and one falls asleep. So as a joke, the driver gives the car a swerve and everyone yells. The friend wakes up in a panic and everyone laughs, hopefully including them, eventually.
Now let’s say you’re flying across the Pacific. You fall asleep, but then wake up as the plane starts to drop and the pilot is yelling over the intercom. But then he straightens out and says, “just kidding folks! Ha ha ha, you should see the looks on your faces.” To many people, that’s not so funny.
Basically the Internet started as a car full of friends and now is a giant airliner with everyone in it. So the “pilots” are held to a higher standard.
Seems to me that there are still communities of jokers on the Internet to be found. They just tend to operate at “joke scale,” which is now a lot smaller than “entire Internet” scale.
To put it another way, an easter egg in a TV show or movie is interesting and fun. An Easter egg in a critical system in a plane or car is not amusing.
The person who decides that their steakhouse is going to make my free cake the centerpoint of their dessert cart and then expresses dismay that I like cream cheese icing on my free cake can fuck right off and bake their own cake.
In this case the author is saying that they don't do easter eggs because it would cause an erosion of trust, and that's fine, that's their prerogative and I get it. HOWEVER, let us not be fooled that there isn't an outrage contingent waiting to pounce every time someone dares to make free software the way it is most useful/accurate/fulfilling for themselves. This causes a chilling effect for a portion of us who write free software.
I have a tea jar in the kitchen and it’s full of Earl Grey instead of builders tea (eg Darjeeling). If anyone makes their own tea I warn them that the tea jar is Earl Grey and I have builders tea in one of the cupboards above the kettle.
I don’t do this because the Earl Grey is an Easter egg. I do this because I’m not a dick and actually want people to enjoy their cup of tea.
Your expectations of someone's free cake are too high, or you didn't understand the analogy. I don't think we will find a resolution between us, but I'll leave you with a bit of wisdom my father once gave me as I made a similar complaint about a free donut: "You can pick your friends, you can pick your nose, but you can't pick your friend's nose."
Also calling your cake story an “analogy” is giving it far too much credit given it had nothing to do with Easter eggs; let alone my original rebuttal regarding critical systems.
> I'll leave you with a bit of wisdom my father once gave me as I made a similar complaint about a free donut: "You can pick your friends, you can pick your nose, but you can't pick your friend's nose."
That’s both crass and irrelevant.
Original comment  made me aware that I've inspired some emotions in you about this particular topic, which was not my intent, bless your heart. Take care, have a great day, and hopefully we can both enjoy our own cake respectively.
 - laumars 1 minute ago | unvote | parent | context | flag | favorite | on: No Easter Eggs in Curl
> Your expectations of someone's free cake are too high, or you didn't understand the analogy
You’re conflating disagreement with misunderstanding.
Also calling your bullshit cake story an “analogy” is giving it far too much credit.
I’ve only replied to my thread and one other post. Hardly everywhere. And you’ve not hit a nerve nor am I being unduly negative. This is a discourse and in conversations it’s not unusual for people to take opposing stances.
What I do dislike is people taking conversations to a meta level and arguing about the argument rather than discussing the topic directly. I’m obviously happy to agree to disagree if an impasse has been reached but please don’t deflect the discussion with assumptions about one’s emotional well being
>curl is installed in some ten billion installations to date and we are doing everything we can to be responsible and professional to make sure curl can and will be installed in many more places going forward.
If you want to sell ten billion cakes and beyond, you better do your market research and listen to customer feedback
curl isn't sold.
Sure, it’s free and the author can manage it however they want. But the reason they choose not to is because it’s still falls into the enterprise software envelope even if it doesn’t command an enterprise level price tag.
Just because something is released for free it doesn’t mean the developers don’t take their own software seriously. And there’s absolutely nothing wrong with them doing so either (even if you personally would like your software to have all sorts of unexpected behaviours and side effects).
Everything is an attention game, if people stopped using curl, then it would stop getting donations, and the author(s) would probably have to stop working on it as much. They aren't being "greedy" or anything, but they do have some level of incentive just to have a reasonable living working on curl.
To use the example here. What if a plumber is wealthy enough to retire but continues to work because they enjoy it. And what if they then offer a job for free, eg for a community centre or church. Are they then allowed to put an Easter egg in where the pipes explode on Christmas Day?
Comparing adding a fun flag to a system with making a physical bomb is a huge strawman.
The rational behind the exaggeration was to illustrate how even seemingly innocuous software Easter eggs, like an additional flag, have often actually turned out to be security vulnerabilities.
Maybe there is a better way of illustrating that using the plumbing metaphor. Nothing immediately came to my mind but I do apologise if my choice of analogy was more of a distraction than an explanation.
This is a bad example because in what you describe the plumber is making a malicious "easter egg".
In secure software any kind of Easter egg can end up being a vulnerability (and all to often has become one).
Now? It's been serious since computers were originally built for business. It became a little more lax in the 90's and the 00's with the rise of the web. This has also coincided with a sharp increase in code size and decline in quality. Maybe we need to be more serious.
Lol this is one hell of a claim to just slip in.
I think we've largely just decoupled the fun and goofy projects from the mainline projects; I think businesses have less of a sense of humor than engineers.
Actually, if you read the article the author explain why this only applies to curl, and explicitly says they understand if other software wants to continue including easter eggs
I personally like adding easter eggs to my own code, but I wouldn't do it in software used by billions. At most a funny comment in the code, but nothing executable.
In this specific example, it's friggin' curl, whose whole existence is to go to talk to other machines over a hostile network. I'd rather it stick to its one, really, really hard job and not get cute.
At the same time, I could see someone launching an attack with a module “this.py” that outputs the Zen of Python and also installs a back door.
Come to think of it, one of the nastiest problems in Python programming is keeping track of which modules are in the PYTHONPATH (“hmm why is ‘pytest tests/test_my_module.py’ throwing an import error?”)
Maybe Easter eggs are a bad idea?
Really, I'd call that a prank, which is bad taste in software, not an Easter egg.
Some comments on the SO thread seem to imply that it shouldn't have been removed but I don't think this was a "good" easter egg. The joke is good, but it should have been harder to trigger (in my opinion).
1) This one yells "get off my lawn!".
2) This one yells "get off my lawn!" and proceeds to explain why he doesn't like kids walking through his grass, and gives the complete history of him yelling at kids and then goes into detail why staying off his lawn is best for everybody.
The author of curl is the latter. It would take much less time and effort to just write something fun into it, AND document it. Good grief, life is short, software development should be fun, even while remaining professional.
That last bit is key - to the same quality standards. curl is a really well-done, carefully-built-and-tested project. If we were talking about most other pieces of software - yes, a small easter egg wouldn't have taken much effort. Not in this case.
If someone else had volunteered to take on all of the effort of maintaining the easter egg, Daniel might let it in - but that would still be more work on his part to rope them in to test their thing after every change to code adjacent to the feature.
Conversely, nobody prevents you from forking curl and adding the easter egg in yourself. Why don't you?
This scenario is fictional, but possible. cf. the works of Charlie Miller and Chris Valasek.
That's the actual problem in your scenario. You can try to blame the kids for having fun all you like -- you might even be able to make it stick -- but it doesn't make you right.
> My X broke while doing Y.
> Well, you shouldn't be doing Y with X. That's the real problem.
What does it matter? If people are doing Y with X, and you as the author of X can improve that path, then you should do that. Normative ideas about what people should be doing don't make a difference.
(You can see this a lot with the Go community. "Go doesn't support [language feature in common use for longer than Keith Richards has been alive]" "Well, you shouldn't be using [language feature in common use for longer than Keith Richards has been alive]" etc etc.)
> X wasn't really designed/is not very suitable to do Y. Why did you resort to do Y with X?
It opens a lot more possibilities and doesn't sound too hostile. Maybe you get to learn that Z which is made to do Y is broken. Maybe a part of that person's workflow requires X specifically. One can learn a lot of things this way.
Consider a person asking about using some surgical equipment on themselves (though they likely wouldn't ask it on StackExchange). Normally, you shouldn't perform surgeries on yourself, but what if you're stranded in Antarctica during the winter night and your life depends on it?
If you don't pick your battles, you'll be doomed to fight for bad causes. Like this one.
But it's still a problem that exists, and one you have to acknowledge!
Easter eggs are a sin like throwing a candy wrapper into a landfill is a sin.
Isolation failure is a sin like drunk driving is a sin.
Easter eggs can get invoked in unintuitive ways and as a result can cause serious issues. Sure you can make easter eggs that are "safe" but the mental overhead to doing so just is absolutely not worth it for anything that could potentially end up in a security critical or automated path.
It's easier to just take a hard line stance and say "I don't want my projects to ever run the risk of losing someone millions of dollars or worse get somebody injured/killed because we decided to add an unnecessary joke".
See, I think security and reliability are good arguments for minimalism and that minimalism is a reason to get rid of easter eggs -- I just think that in most applications nobody gives one genuine whit about minimalism, except as a universal argument of last resort to kill an otherwise completely unobjectionable feature that they don't like.
The typical product has a very long tail of dead code and useless features that nobody will ever derive utility or joy from. Easter eggs typically bring a bit of joy, and this actually places them rather far up on the tail. In a land of zeros, a small number stands tall. I fully agree that the overall size of the tail is a problem, but actual attempts to make the tail smaller generally start with lower hanging fruit and still are widely considered a waste of time. Cleanup work is universally valued at close to nothing. Ditto dependency analysis. Nobody thinks twice about roping in heavy dependencies, even in applications that like to think of themselves as important. From the perspective of minimalism, these are all much heavier sins than easter eggs, yet these titanic-sized ships sail silently through the night while one tiny little unobtrusive easter egg that has not in fact caused any trouble will call forth a roiling army of soulless corporate drones, pouring over desks and cubicle walls to wring their wrists, clutch their pearls, and wag their fingers about the possibility that the easter egg may contain a bug.
I personally like the idea of easter eggs but I just think they are too difficult to do safely in command line tools. Graphical tools are generally fine provided the code running is isolated from anything dealing with a hostile network or safety critical environment.
I agree that tech/sec debt are just as bad if not worse but I can see how they slip past the radar. I personally am in the same ideological boat that these tails should be regularly and expediently dealt with but I think the distinction is that most technical debt seems like it was a good tradeoff at the time while there's never a good justification for easter eggs past "fun".
I guess I fall into the category of crotchety SW dev but I find it's easier to defend against that future technical debt by just drawing a hard line in the sand and not giving any ammunition towards the unnecessary additions crowd.
My point was to demonstrate through a nonsensical example that different environments have different ambient expectations for reliability. If a problem in a low-reliability environment propagates to a high-reliability environment, the root cause is the failure of isolation, not the bug or exploit in the low-reliability environment.
Now, I would never actually ship an easter egg, but that's because I have no faith in the corporate blame game to correctly assign blame, not because I place the slightest stock in the idea that safety and security are a genuine reason why it shouldn't be done.
This is why we can't have nice things.
And it's a very nice thing, and we have it.
That opinion scares me. Genuinely. Have you seen its protocol list grow in recent years? It has taken on a hundred thousand easter eggs worth of overhead to add 26 protocols, of which you probably use 2, but you consider it safety critical?
Random people on the internet can use your code fine, but big corporations run into issues because they need boring software. I think that's neat.
e.g. curl hxxps://haxx.se/something-cute-here
Obviously one day someone might see that page in the browser, thinks they need to get an offline copy of it, does a curl and gets something different. But I guess that's a surprising behavior of the server and not the client. Lots of servers already do this to do a first-level filter against people who can't figure out how to set curl's user-agent...
I don't care that much about the presence or the absence of easter eggs in curl or in most tools. It's still cool that some have easter eggs if they are inoffensive. Documented easter eggs are fine too.
Curl is a great tool and I'm perfectly fine (if not thankful) with this decision.
It's much easier for a developer that's new to a project to make `--moo` do something different than it is to perform all the ceremony to get a `--feature` going in the first place.
I think this is the right decision by curl and I support it.
Curl is just perched at a position where an easter egg introducing a vulnerability would be disastrous. I feel the same about OpenSSL or the kernel. Software that is highly security sensitive shouldn't have easter eggs.
On the flip side, I'm fine with grep or yes having an easter egg or two. It's hard to imagine using them in such a fashion where that'd create a security risk.
fortune | cowsay | git commit -F -
For me, my first ever experience of fortune was on DEC VMS systems.
Many, many, moons ago Windows NT had support for an 'autoexec.nt' batch file which did the same, so it's not a new feature just horribly undocumented.
I use it to have a different prompt for administrator windows.
To anyone using it: Be careful. Any side effects in your autorun script can have entertaining effects on batch files when you least expect it.
TLDR is that for /f loops do spawn a child cmd.exe process and you won't like the result (recursiveness).
The common one I've seen surprisingly often is the autorun script doing "cd" and causing for /f loops to break in some way.
Maybe it was this: https://docs.microsoft.com/en-us/archive/blogs/larryosterman...
Which was discussed on HN in 2005 here: https://news.ycombinator.com/item?id=17517085
Not to directly defend easter eggs but if we allow people to insert easter eggs, sure it creates slightly more work and potentially create an attack surface (albeit very unlikely), but in return you get something hard to measure directly. People love and embrace what they work with, they care about the project, spend extra time on it because it creates belonging and sympathy. It makes a little happier developers and a community, which eventually results in a better-cared project.
Even knowing any potential downsides of adding an easter egg to a program, I think upsides are a little higher. It's just hard to quantitatively measure.
No product (where no = a statistically insignificant percentage) ever lost trust because of an easter egg.
There are tons of other reasons for losing trust...
An analogous place to hide easter eggs in a CLI program like Curl might be in the --help dialog. Nobody is parsing the output of `curl --help`, so it's safe.
A random quote on a login page, some skeuomorphic theming, a config option to put particle effects on your custom dashboards.
I wouldn't really trust software less because of eggs though, unless it could be triggered by in band data. --egg is fine, triggering on nano activateEgg.txt is a problem.
Those eggs did require fixes from YARD and code linters, in order to support emoji code, so in a sense they helped make the ecosystem better.
"If we put an easter egg in, it would be impossible to sneak in" - It isn't about being completely undetected for the people looking at source code, it's for the people who want to see a funny print output.
"If we put an easter egg in, more people will want to put more in, or make the original more elaborate" - complete speculation, handled if true by the word "no".
"I bet you all think me writing this means I'm hiding something" - projecting much?
"If we would allow some features to get added like that, where would we draw the line? What other functionality and code do we merge into curl without properly disclosing and documenting it?" - Uh, the line is the definition you put in the top of the article: "An unexpected or undocumented feature in a piece of computer software, included as a joke or a bonus." This excludes malicious or harmful software.
"We frequently ship bugs and features that go wrong." Yeah, it seems you have more important work to do if that statement is accepted as a given. And when the heck does a bug look like an easter egg?
1. Including undocumented code is a breach of trust.
2. Adding a “fun” piece of code that’s not useful (and “secret”!) adds to the burden of maintainership.
3. People will inevitably want to add to the Easter egg code. Maintainers by and large are overworked, especially for software used on the scale of curl. They have better things to do.
If you want curl with Easter eggs, fork it and see if others will use it.
The only point I acknowledge is part two of point #3: They have better things to do, especially if, as the author says, they constantly ship buggy code.
Of all the data breaches, of all the zero days, of all the massive bugs found in open source software, how many have been caused by Easter eggs?