Easter egg; noun:
An unexpected or undocumented feature in a piece of computer software, included as a joke or a bonus.
There are no Easter eggs in curl. For the good.
I’ve been asked about this many times. Among the enthusiast community, people seem to generally like the concept of Easter eggs and hidden treasures, features and jokes in software and devices. Having such an embedded surprise is considered fun and curl being a cool and interesting project should be fun too!
With the risk of completely ruining my chances of ever being considered a fun person, I’ll take you through my thought process on why curl does not feature any such Easter eggs and why it will not have any in the future either.
The primary and main reason is the question of trust.
We deliver products with known and documented functionality. Everything is known and documented. There’s nothing secret or hidden. The users see it all, can learn it all and it all is documented. We are always 100% transparent.
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.
Having an Easter egg in curl would violate several of the “commandments” we live by. If we could hide an Easter egg, what else is there that we haven’t shown or talked about?
Everything in curl needs to be scrutinized, poked at, “tortured” and reviewed for security. An Easter egg would as well, as otherwise it would be an insecure component and therefor a security risk. This makes it impossible to maintain an Easter egg even almost secret.
Adding code to perform an Easter egg would mean adding code that potentially could cause problems to users by the plain unexpected nature of an Easter egg. Unexpected behavior is not a good foundation for security and secure procedures.
Boring is good
curl is not meant to be “fun” (on that fun scale). curl is here to perform its job, exactly as documented and expected and it is not meant to be fun. Boring is good and completely predictable. Boring is to deliver nothing else than the expected.
Even more security
If we would add an Easter egg, which by definition would be a secret or surprise to many, it would need to be hidden or sneaked in somehow and remain undocumented. We cannot allow code or features to get “snuck in” or remain undocumented.
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?
If we would allow an Easter egg to get merged, we would soon start getting improvements to the egg code and people would like to add more eggs and to change the existing one. We would spend time and effort on the silly parts and we would need to spend testing and energy on these jokes instead of the real thing. We already have enough work without adding irrelevant work to the pile.
“Unintended Easter eggs”
We frequently ship bugs and features that go wrong. Due to fluke or random accidents, some of those mistakes can perhaps at times almost appear as Easter eggs, if you try hard. Still, when they are not done on purpose they are just bugs – not Easter eggs – and we will fix them as soon as we get them reported and have the chance.
Yes, some readers will take this denial as a sign that there actually exists an Easter egg in curl and I am just doing my best to hide it. My advice to you, if you are one of those thinking this, is to read the code. We all benefit if more people read and carefully investigate the code so we will just be happy if you do and then ask us about whatever you think is unclear or “suspicious”.
I am not judging
This is not a judgement on projects that ship Easter eggs. I respect and acknowledge that different projects and people resonate differently on these topics.
Image by anncapictures from Pixabay
8 thoughts on “No easter eggs in curl”
Embrace the egg!
Nicely reasoned and explained.
For someone want to read a story of a totally unexpected and undocumented feature in a widely used command:
`Why does man print “gimme gimme gimme” at 00:30?`
This is an absurd argument. I don’t include easter eggs in my libraries, unless one were to include comments and whatnot, but I’ve included some in finished programs.
While trust is a part of Free Software, this is only due to necessity from incompetence. If Curl weren’t so large, people wouldn’t need to trust its developers.
It’s laughable to use security as an argument in regards to a C language program. Curl could be much smaller and more secure written in a language such as Ada, but security isn’t the real concern here, or it would be.
Curl is a program that should be finished, not updated forever, so all of the work on it after a point should be considered useless. Further, testing is no replacement for proving software correct.
Anyway, it’s interesting to see a man hounded by customers of businesses with which he has naught to do and who almost had his project name stolen out from under him be so concerned about professionalism instead of fun; it gains him little or nothing.
> If Curl weren’t so large, people wouldn’t need to trust its developers.
> Curl is a program that should be finished, not updated forever
I haven’t read or heard more nonsense thing in a long time.
If someone wants a curl easter egg, they can make it themselves by hosting a webpage or service that behaves amusingly when it receives a curl user-agent string.
Then all the code and funny behavior is OUTSIDE the infrastructure that needs to be bullteproof for millions of users.
The “Useless work” is a classic example of the slippery slope fallacious argument. (see “if you give a mouse a cookie”). The probability of each successive case occurring gets smaller and smaller to the point that the entire chain of events is quite improbable. I see your other arguments with regard to transparency, but this particular one is fraught with doomsaying.
I think Easter Eggs are a fine concept, but some tools are serious. curl is one of those serious tools. Putting Easter Eggs in a GUI tool is fine. I’m even cool with “import antigravity” in Python. But at some point, you need to be serious.
Would an Easter Egg in OpenSSL be acceptable?
I was somewhat appalled to find, back in the 90s, that Microsoft had included an Easter Egg in Excel with the developers’ names implemented in a raycasting engine (a la Wolfenstein 3D), and all I could think of was how many gigabytes of disk space this took up in all the millions of instances of Excel for something no one needed and maybe 1 in a thousand people actually ever saw.
Disk space is cheaper than water these days, but bloat is a hundred times worse. But there are other considerations. curl isn’t just a tool. It’s part of the infrastructure.
I think keeping Easter Eggs out of curl is a good idea.
Comments are closed.