All the CISCO networking solutions contain Easter eggs, that allow you to see everything because you get full root. Haters insist on calling them backdoors of course.
You can't expect a software distributor to be aware of all of the Easter eggs developers added to its software.
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 this is really why we can't "have fun" anymore. Because bad actors exist and can exploit things being done "just for fun". I do wonder, however, how much of the "serious" nature comes from actual bad actors or from the security research community.
> I do wonder, however, how much of the "serious" nature comes from actual bad actors or from the security research community.
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.
Counterpoint. In our org we'd eliminate pretty much every security incident if users would not download attachments on suspicious emails, give out their password and try and click on the monkey to win the iPad.
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.
In my household back around Y2K era (95 - 05), I eliminated a large number of virus infections by having the computer that the kids used set up so them clicking on the AIM icon actually did an X connection over ssh to my Linux server to run GAIM (using Cygwin/X on the Windows side).
That quotation simply reflects what’s exciting enough to get attention.
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.
Physical access to computers in the late 70s was decently secured. Most computers were at large businesses (typically with access through a lobby with a receptionist watching) or universities with access limited to students & faculty. So there was some security, not usually great, but few bad actors could get access, even across networks. As computers became more common physical-security-only stopped working well.
It's more of a risk/reward thing. Any code on a networked computer has non-zero risk. And what's the reward... an engineer had fun at work today? That's not a very compelling argument in a business context.
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.
> I think this is really why we can't "have fun" anymore. Because bad actors exist and can exploit things being done "just for fun".
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.
The post says that Easter egg only works if 'expose_php' is set in php.ini, which will also report the PHP version in the X-Powered-By header of every response. So it doesn't seem to leak any information that wouldn't already be available.
Question is what you gain by knowing the version. Better just fire your arsenal of attacks than waste time trying to figure this out as many sites will hide these things anyways.
On an individual basis it's sometimes hard to see the harm in this. But more specifically the problem with version identifiers is that attackers can scan across many servers, iterating which ones have a certain vulnerable version.
While a bit of an extreme scenario, I can imagine it being useful for high-level actors with their own private vulns which they'd like to keep on the down low unless absolutely necessary.
Exploiting a memory corruption vulnerability depends on the exact details of the software version and platform. Attempting the wrong exploit risks crashing the process, which might be noticed and investigated.
Not sure why you're being downvoted. Your question is reasonable and any attacker worth their salt will fire a full arsenal of all the CVE's at your environment regardless of version.
Hiding version numbers etc is an example of "Security through obscurity" and is a weak defence strategy:
It feels like gradually things are getting 'less fun'. We can't have nice things, people can't do jokes, everything is like "your service must be completely professional even if it is just this thing you needed and built and offered to others for free". Everything is SO SERIOUS now, when one thing isnt how a small group feels it should be, suddenly everyone mobs up and more fun disappears.
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.
It's not a generation thing, it's a paycheck thing. curl is run many many billions of times per day in lots of critical workloads. There's nothing to stop anyone from developing a similar library with some jokes in it. I'd probably use it for ad hoc or personal stuff, but I don't want this in the thing I'm getting paid to built, and going to get paged* for when the joke shows up in the wrong place.
* 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 understand your argument; but it sounds to me like you expect hobby projects to be paying your wage.
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)
Looking at it another way, you didn't need to set up any tooling to shepherd data into production because everyone involved understood the point of the joke. It was a very clear example of GIGO for your entire company and the cost was one meeting.
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.
Actually, the opposite. The result of this, besides damaged reputations and hundreds of person-hours of time wasted, was more access controls and more reviews/oversight, which slowed things down and generally made things far less "fun" than the original joke could offset.
I’ve noticed the same thing, and I think it comes down to this: the Internet is important now.
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.
I'd also argue that jokes in the business world aren't that funny; they feel like advertising in another form, an attempt to ingratiate a brand through emotional means.
I think you are correct in your observations, but I'd attribute the real cause to something other than "fun:" our low-trust society. Things can be fun when one doesn't have to worry about attacks from every angle, in the case of software. There are so many malicious actors out there that one is no longer allowed to "have fun" with hidden software functionality. It might increase the attack surface of your application.
Easter Eggs have lead to do many security concerns over the years that software authors have had to get serious.
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.
Hang on, this exact situation is like if I make a cake, and as people walk by and see it, they want a slice too. So I say "sure have a slice, its free cake, I made it for myself but it's also free for you".
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.
That’s not an Easter egg. But also I would expect the baker to warn me that it had cream cheese if just to set my expectations.
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."
You’re conflating disagreement with misunderstanding. I understood your point fine, I gave a counterpoint on why I disagreed.
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."
I'm only now noticing you've replied to almost everything I've said, and quite negatively, so I think some apology is in order as it seems I've maybe touched a nerve I was not aware of. I want to be the bigger person and wholeheartedly apologize to my esteemed colleague.
I'm sorry.
Original comment [1] 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.
[1] - 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'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."
> I'm only now noticing you've replied to almost everything I've said, and quite negatively, so I think some apology is in order as it seems I've maybe touched a nerve I was not aware of.
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
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).
Open-source projects still have to sell themselves to get users (marketing/"devrel"). curl's author definitely makes money from curl: https://curl.se/support.html
I'm not 100% sure why you're being downvoted. While the choice of the word "sell" kind of feels at odds with FOSS, it's honestly not an inaccurate verb.
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.
Imagine making this complaint with regards to electrical, or plumbing work. How would you feel if your electrician put an easter egg in your home's electrical system?
Motives are irrelevant. It’s the application that matters.
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?
Tearing down a building,, you could probably find many easter eggs. Things written on the inside of walls. A signature in concrete later being covered by materials. Etc.
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.
It's a strawman in the sense that some here argue for the fun of adding a few bytes of output to some program, while your retorts argue against them wanting to blow up innocent people.
> 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?
This is a bad example because in what you describe the plumber is making a malicious "easter egg".
For goodness sake I’m trying to having a grown up conversation with someone else and you’re making out like I have a personal vendetta against yourself.
Neither do the curl authors. This library is used basically everywhere, from your device over IoT applications to critical servers. Sure, people might have fun while writing this software, just like your plumber might enjoy his craft, but the end product is professional groundwork.
No one is stopping you from having "fun" with your free tool, it's just that if you do many/most people will not want to use your tool no matter how free it is.
I like to feed the birds with my less-awesome bread loaves sometimes, as I learn to bake. I am not at all disappointed that someone doesn't create stuffing or croutons with it.
I think this is more like some other baker saying "I don't put raisins in my bread because the people I am baking for don't like raisins" and you shouting "argh when did people become such prudes??"
I wouldn’t read the article as a polemic against all Easter eggs, just not in critical lower level infra where reliability and security are paramount. So Easter eggs in my music player - sure. In my pacemaker - not so much.
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.
I mean, I don't think it's generational at all, there are plenty of libraries on Github that are meant to be fun and silly [1] [2] [3] [4].
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 totally understand this stance. Not every game had cheat codes, not every movie/TV show has hidden details, and so not every piece of software has to have easter eggs. That kind of defeats the fun of it anyway, knowing that everything has a joke.
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.
I sort of remembered this and was going to comment once I found it, but you beat me to it - and saved me some work. Thanks! It's a very relevant and important story.
An Easter egg doesn't need to be an undocumented secret thing. Put something silly behind a flag and document the flag in the manual, and it's still a goofy Easter egg.
Is that egg accounted for in the threat model? Did we just unnecessarily add to the attack surface? Does it get regular reviews? Does it have tests? Are we willing to continue to donate the cost of maintaining this "component" that serves no purpose but entertainment?
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.
You bring up a valid point, though I don't know that even that much is necessary. The internet will find it soon enough and document it for us. But, hey, takes ten minutes to write down the flag and what it does, right? Are we still talking about an Easter egg at that point, though? :-)
I mean Python has all the functionality of curl (potentially, at least) and it has an Easter egg.
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?”)
It goes to show that even stuff that I would consider rock solid (such as man pages) can be surprisingly brittle if one person can make a change over a tweet.
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).
To me the real reason to not do them is outlined in the "useless work" section. They add surface area, support and maintenance to a project for essentially no gain. For a project as popular and visible as curl, I'd imagine avoiding having to talk about it, and dealing with feature requests and PRs on it alone makes not having an easter egg well worth it.
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.
The linked article is only a few hundred words long. It probably took Daniel half an hour to write. It would take far longer to write, integrate, test, document, and maintain even a simple easter egg to the same quality standards as the rest of the curl project.
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?
Yeah, next time I'm on the highway and go into my foot-brake's "About" menu and click on the word "2020" twenty times I might be in serious danger of crashing my car!
Yes because it'll load an image from a domain that expired and is now
controlled by a nefarious third-party. The image is now a payload targeting the
out of date image loading lib used by the onboard entertainment system that has
seen no updates for 5 years.
This entertainment system is connected to the actual driving electronics of the
car that will now brake at full force the next time it reaches 130 km/h.
This scenario is fictional, but possible. cf. the works of Charlie Miller and Chris Valasek.
> This entertainment system is connected to the actual driving electronics
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.
> 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?
It's worth adding that I agree with the main point that software should be fun, and Easter eggs should be allowed. I'd just prefer to argue for it on the grounds that (a) it's possible to make software fun without making it dangerous, rather than (b) software is fun, dammit, and if that crashes your plane then your plane was built wrong.
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".
That's the best example you can come up with? A bug in an easter egg broke a test related to manuals?
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.
That was just the first link I had on hand and I do agree it was fairly innocuous but at least in my line of work, if something like that was to be discovered in a tool, it'd cause all kinds of problems and we'd have to do a full security audit.
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.
When the API that enables the effect has a buffer overflow that no one noticed because the feature was snuck in and attackers exploit it to take over your brakes (and from there the CAN bus because how could the brakes possibly have any vulnerabilities?), you'll care.
My brakes don't have an about menu, they don't have a monitor, and they don't have a mouse. Everyone agrees they are safety critical.
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.
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?
This argument works the other way too: if you don't want people to rely on and demand support for your code add in a bunch of easter eggs. The more random the triggers, the better.
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.
He could put the easter egg externally, e.g. create a page on his site that would react differently if fetched with the curl user-agent compared to all other user agents. So all the code would be server side and it'd still be an easter egg, because you get it by entering a certain input.
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...
It reminded me of apt-get moo and aptitude moo, which do not seem risky or to trigger unexpected things (since they just print text when using specific, useless flags), nor cause maintenance troubles, and yet those programs are on many computers.
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.
I've viewed that flag as an admission or convenient hookup point for new features under development, and have taken to adding a `--moo` or `--wip` flag which is a convenient starting point for adding something new to a utility.
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 too feel an innocence has been lost in software and the internet. It's a shame that things can't be so whimsical, but it is also good that serious software is taken more and more serious.
I think this is the right decision by curl and I support it.
I'd say I think it depends on the software, but agree with your assessment.
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.
I added "fortune | cowsay -f tux| lolcat" to my ~/.bashrc. It is always nice to see some often inspirational or thought-provoking quote if I open a terminal window.
I've ported fortune to Win32, and now have it show me a nice quote whenever I open a Command Prompt. It was feature I always wanted to have, and gave up waiting for MS to provide it.
For me, my first ever experience of fortune was on DEC VMS systems.
Thanks for that! I added -a to fortune, so every once in a while (but not always) I get an offensive aphorism -- yes, I am willing to be offended! NOTE: this may require installing the offensive fortunes package.
I once wrote a script to pipe fortune -os into cowsay with random parameters. Unless things have changed in the past six years, cowsay inexplicably has no options to specify to use a random cowfile and randomly choose whether to say or think the aphorism.
Never had the pleasure. I skipped the whole configuration management era and went straight from Windows "click around the UI following this manual procedure" to cloud-config and IaC.
Weird, I could have sworn I've read this before, not necessarily about curl, but the exact same words and sentiment. Searching for "no easter egg in" yielded nothing. Yet the post is dated as of today. Maybe I lived briefly in an alternate universe?
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.
Top has a few easter eggs that have persisted. Check out top(1) section 7: STUPID TRICKS Sampler. Several issues have been filed like https://bugs.launchpad.net/ubuntu/+source/procps/+bug/446002 but I am happy to see relics like how to enter "the super bounce zone" remaining in nearly every distro containing top.
Easter eggs are fine, as long as you hide them in a "non-work area" and not a "work area". In the 80s and 90s, on Macintosh, it was customary to hide easter eggs in the "About" dialog box. Since nobody was relying on the about dialog to do real work, it's safe.
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.
I don't think I've ever put a true easter egg in software. I do decorations instead.
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.
I guess it depends on your definition of easter eggs. Some of our "easter eggs" are loading icons showing at specific events. So right now they are christmas themed.
I can see how the facts/opinions presented would be true if the Easter egg was a closed-source binary blob, but that would be farcical to do in an open-source project like curl.
This is such a stereotype of a kind of over-analytical type that it's hilarious. There are so many poor assumptions and overcaution.
"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.
My entire premise is that you are wrong on all counts. Your ideological point is balanced by the fact that no one cares in reality. `apt-get` and other tools are used in critical systems all day long, and Krebs isn't blogging about it. Easter eggs aren't causing outages and data breaches. The fact we're discussing it all is a form of bait; the entire discussion is useless and distracting a-la Twitter culture wars, but we're addicted to the debate of minutiae.
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.
I don't feel strongly about including easter eggs in the codebase. I feel strongly that someone I suppose is very intelligent feels so strongly about it for such foolish reasons. But, it is their code, and curl is a wonderful tool. Their blog about easter eggs is laughable in how seriously it takes itself when it comes off like a joke.
At this point the lack of any Easter Eggs almost IS the hidden feature. I would not have expected this much discussion and controversy, it causes more surprise than an actual egg in the app would!
