8 ms·

Raspberry Pi Pico: What is this code doing in its boot ROM, line 442?

217 points by nynyny7 5y ago

kzrdude 5y ago
It kind of looks like zphd is the label of the end of those bytes, right? I mean, that they are referred to somewhere else by using that as an end pointer.
- bri3d 5y ago
  I agree with this assessment, especially because `zphd` was added at the same time as those bytes.
  - nynyny7 5y ago
    The 'zphd' label seems to appear nowhere else in the boot ROM code, though: https://github.com/raspberrypi/pico-bootrom/search?q=zphd https://github.com/raspberrypi/pico-bootrom/search?q=zphd
    - deleted 5y ago
      [deleted]
    - napsterbr 5y ago
      That might be the case, but I wouldn't use Github search results to confirm this. I have no idea why, as this is super important, but code search in Github is surprisingly terrible. Not sure if this is just me or others have had similar experiences.
      - ejona86 5y ago
        Not just you. It can give no results and partial results, which is sometimes fixed on a re-query. But it also is just poor for code. I think it wants to find full words, so searching for substrings generally results in too few matches. That's made worse by its special character handling in word splitting and query parsing which makes some text impossible to find.
nynyny7 5y ago
Lines 442-445, but apparently line numbers are stripped from GitHub URLs posted to HN: https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5bc007f81d7f2416b48db90f313434/bootrom/bootrom_rt0.S#L441-L445 https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5...
- Retr0id 5y ago
  Interestingly, it was not present in the initial release. It was added here: https://github.com/raspberrypi/pico-bootrom/commit/ad55537bf35e332503b950d6951c41bcb8a7954f#diff-1bcdd4109020ba4c51666828150569e2bf550f4c3265b476175ba7375c8bf214R395-R398 https://github.com/raspberrypi/pico-bootrom/commit/ad55537bf...
- chillingeffect 5y ago
  first 2 bytes 0x11, 0x38... perhaps another scifi reference?
  - Retr0id 5y ago
    I think you're right. This instruction is essentially redundant, since the following instruction also adds an offset - so I think it's very deliberate.
  - deleted 5y ago
    [deleted]
  - chillingeffect 5y ago
    Next two bytes: 0xc0, 0x7a = "cola" ?
    - jhart99 5y ago
      It is little endian so that will be '7AC0' or taco
Retr0id 5y ago
ARM thumb disassembly: 00: 11 38 subs r0, #0x11 02: C0 7A ldrb r0, [r0, #0xb] 04: 00 BD pop {pc} 06: 00 B5 push {lr} 08: 42 40 eors r2, r0 0a: 00 2A cmp r2, #0 0c: 00 F0 02 F8 bl #0x14 10: F6 D2 bhs #0 12: 8E 46 mov lr, r1 14: 70 46 mov r0, lr 16: 00 47 bx r0 Edit: I agree with the other commenters that this doesn't really look like a valid disassembly, it is perhaps data rather than code. Edit2: I take that back - it's just very "creatively" written.
- mmastrac 5y ago
  This reads a bit like a spurious decompilation. It's sorta valid but doing very weird things. Random bytes will often decompile to valid Thumb that looks sort of right like this all the time. 04 pop {pc} -> this is an odd way to return from a function on ARM, and likely means that these first bytes would be a very odd function. 06 push {lr} -> OK, maybe a valid prologue, but this function ignores the result of the cmp and calls 0x14.
  - TuxSH 5y ago
    pop {..., pc} is THE standard way to return from a function that calls other functions itself, on Armv5 and above. Non tail functions usually do this: push {..., lr} ... pop {..., pc}
    - mmastrac 5y ago
      Only if there's a corresponding push { ..., lr }, but in this case there isn't. I'd expect bx lr here.
      - TuxSH 5y ago
        As other people are saying, code seems to be jumped at at #6. > I'd expect bx lr here LR is being clobbered by the bl (EDIT: bl, not blx)
mmastrac 5y ago
[deleted, thought it was possibly some pre-compiled code related to the trampoline but I don't think so] EDIT: I spoke too quickly, looking at the disassembly in the sibling comment. EDIT 2: That disassembly looks like data, TBH.
- jagger27 5y ago
  What does trampoline mean in this context?
  - mmastrac 5y ago
    Usually just a piece of code to jump to another piece of code with certain necessary register modifications, ie: https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html
  - diogenesjunior 5y ago
    if u go up it looks like there is a `debug_trampoline` function. so they are saying the `debug_trampoline_end` is a precompiled version of the `debug_trampoline` one. not sure if this is true or not
    - TuxSH 5y ago
      It is not. debug_trampoline_end is just a label in this context.
  - bri3d 5y ago
    A trampoline in code is something you jump off of - essentially, a redirection snippet. You jump into it and it bounces you somewhere else. In this case, the use is documented where it's implemented: https://github.com/raspberrypi/pico-bootrom/blob/master/bootrom/bootrom_rt0.S#L425 https://github.com/raspberrypi/pico-bootrom/blob/master/boot... . It's a custom wrapper to call ROM functions. When the ROM function returns, the trampoline executes a debugger breakpoint. This is done so that the debugger can call into ROM easily without needing to set a hardware breakpoint.
  - 5y ago
mannanj 5y ago
NSA hidden code?
- Epiphany21 5y ago
  If I put myself in the shoes of someone truly malicious, I would request a backdoor in the chip implementation itself. Hardware is hard. Once you put it in the customer's hands they can't change much. Hidden opcodes or combinations/uses of legitimate opcodes that trigger undefined behaviors on the platform as a whole are the way to go. Firmware on the other hand can be patched or replaced. It's probably an Easter egg or an undocumented workaround for something.
  - SuchAnonMuchWow 5y ago
    note that this boot loader is in ROM, so it can't be patched or replaced
    - Epiphany21 5y ago
      Is it true ROM or some kind of EEPROM? A lot of the time what people call ROM is actually writable if you jump through enough hoops.
      - ebenupton 5y ago
        It is true ROM.
nynyny7 5y ago
Okay. I have an idea. Let’s see what happens if we treat… 06: 00 B5 push {lr} … as the start of this weird code(?) sequence. It pushes the link register (i.e., the return address to the caller). 08: 42 40 eors r2, r0 0a: 00 2A cmp r2, #0 This XORs R2 and R0 and compares the result against zero. But that’s just a decoy, as we’ll see. 0c: 00 F0 02 F8 bl #0x14 This calls into… 14: 70 46 mov r0, lr 16: 00 47 bx r0 … which moves the return address to R0, and then returns. Using the addresses in this disassembly (not in the actual boot ROM), the return address is 0x10; but LR and, therefore, R0 will actually contain 0x11 because the LSB signifies Thumb mode. None of the previous three instructions modifies the flags. (I checked in the ARM reference manual.) Thus, “BHS” (branch unsigned higher or same) uses the flags from the “CMP R2,#0” above. _Every_ value of R2 is higher (in the unsigned sense) or same as 0. Hence, the following branch is always taken: 10: F6 D2 bhs #0 … to… 00: 11 38 subs r0, #0x11 R0 contained 0x11 relative to the start of this code sequence. (The absolute address in boot ROM is of course different.) Now, R0 points to the start of the code sequence. 02: C0 7A ldrb r0, [r0, #0xb] This loads the byte at offset 0xB in this code sequence. Look above, it is 0x2A. 04: 00 BD pop {pc} This returns to the caller, using the LR pushed at the beginning. The return value in R0 is 0x2A. 0x2A is 42 (decimal)! Could this be an Easter egg; a very obfuscated way of returning 42, the Answer to the Ultimate Question of Life, the Universe, and Everything? (Remember that the Raspberry design team is from Britain, same as Douglas Adams.)
- onetimertwo 5y ago
  That reference would fit the zphd label. But it's _very unlikely_ that Zaphod Beeblebrox himself shows his head(s) here.
  - qzw 5y ago
    Would you go so far as to say the improbability is infinite?
    - justinjlynn 5y ago
throwaway81523 5y ago
Even if it's not obfuscated, what is this decompilation doing in the pico source repo? Are they claiming that is the real source code that someone wrote?
- Retr0id 5y ago
  There is no decompilation here.
  - throwaway81523 5y ago
    (edited) Hmm, maybe you are right, it is not that easy to tell. Those bytes at #441 are still mysterious.
    - bad_alloc 5y ago
      Looks like hand written assembly code to me. Also the legible function and label names indicate it was manually written. In diassemblies you usually have no such information.
      - throwaway81523 5y ago
        I'm thinking more like a manually annotated disassembly of something.
        oneplane 5y ago
        Writing machine instructions isn't that unusual in microcontrollers where you write very closely against the bare metal.
        Retr0id 5y ago
        Why? It would take longer to annotate and idiomatize a disassembly to this extent, than it would to just write it from scratch.
peter_retief 5y ago
What happens if you remove it?
- nynyny7 5y ago
  As it is in ROM (inside the RP2040), removing it might involve a Focused Ion Beam machine ;-)...
  - peter_retief 5y ago
    Of course, is there no way to flash the firmware?
    - nynyny7 5y ago
      It is in the boot ROM; not in flash memory.
      - peter_retief 5y ago
        https://www.linuxjournal.com/content/flash-roms-raspberry-pi https://www.linuxjournal.com/content/flash-roms-raspberry-pi
        nynyny7 5y ago
        What are you trying to say here? Please have a look into the RP2040 data sheet to understand what "boot ROM" means. It is not programmable! https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p... "A 16kB read-only memory (ROM) is at address 0x00000000. The ROM contents are fixed at the time the silicon is manufactured."
        peter_retief 5y ago
        I am just interested not trying to argue, found this link. https://wiki.segger.com/Raspberry_Pi_RP2040 https://wiki.segger.com/Raspberry_Pi_RP2040 The RP2040 includes a boot ROM which needs to be executed after reset in order to guarantee proper functionality. In case of a valid application has been detected in the external QSPI flash, the boot ROM copies the first 256 bytes from QSPI to SRAM5. In the RP2040 user manual, this code is called "flash second stage" (2nd stage bootloader) which is not part of the boot ROM but is part of the application image thus can be adapted by the user. The J-Link performs a device specific reset which halts on the first instruction at address 0x20041F00 of this so called "flash second stage" (bootloader).
rahimiali 5y ago
Direct link to the line in question: https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5bc007f81d7f2416b48db90f313434/bootrom/bootrom_rt0.S#L442 https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5... (@dang, worth updating the link?)
josuah 5y ago
Crosslinking the two posts: https://github.com/raspberrypi/pico-bootrom/issues/17 https://github.com/raspberrypi/pico-bootrom/issues/17
0x456 5y ago
Worthwhile reading on Easter Eggs "Why No Easter Eggs" https://docs.microsoft.com/en-us/archive/blogs/larryosterman/why-no-easter-eggs https://docs.microsoft.com/en-us/archive/blogs/larryosterman... https://hn.algolia.com/?query=Why%20no%20Easter%20Eggs https://hn.algolia.com/?query=Why%20no%20Easter%20Eggs ... and https://unix.stackexchange.com/a/405874 https://unix.stackexchange.com/a/405874 https://news.ycombinator.com/item?id=27994194 https://news.ycombinator.com/item?id=27994194
- bmitc 5y ago
  I tend to agree with that sentiment. If most software "just worked", I would be okay with it from time to time. But it doesn't, so I am not. I feel the same with cutesy error messages. They're usually a bit condescending or infuriating when something is going wrong. I personally tend to be a bit clinical in my software development, despite the urge to be playful. I am also not a big fan of cutesy commit or issue descriptions either.
  - EvanAnderson 5y ago
    When I'm having problems with software I'm typically not in a whimsical mood. Most software I use are tools meant to help me do my job. A cutesy / playful error message coming from a misbehaving tool generates nothing but rage for me. Cute, condescending error messages are unprofessional and unhelpful. If fewer programs were steaming piles of garbage I might feel differently about it.
- sneak 5y ago
  Easter eggs are fine, just probably not in security code like bootloaders.
- socialdemocrat 5y ago
  God what a humorless crowd. We got a bug report from a customer on an Easter Egg once. There was nothing wrong with the software. It just annoyed them that there was an Easter egg. The idea that Easter Eggs are security risks comes across as the most pedantic paranoid position. Statistically speaking software is not failing because of Easter eggs. This does not seem to be about security but about typical American style “cover your ass” legalize thinking. Sure if you create a space rocket control system I would not put in an Easter egg. But if it is a code editor, word processor, email reading client etc then who cares? Nobody will die and million dollar equipment is not going to blow up. Disclaimer: I have never made an Easter Egg and I get that companies don’t do it if it causes problems with customers. I just think customers who complain about this should get a life.
drpixie 5y ago
Hmmm. Looks like 441 would be a great place for a helpful comment block.

217 points by nynyny7 5y ago

It kind of looks like zphd is the label of the end of those bytes, right? I mean, that they are referred to somewhere else by using that as an end pointer.

bri3d 5y ago
I agree with this assessment, especially because `zphd` was added at the same time as those bytes.
- nynyny7 5y ago
  The 'zphd' label seems to appear nowhere else in the boot ROM code, though: https://github.com/raspberrypi/pico-bootrom/search?q=zphd https://github.com/raspberrypi/pico-bootrom/search?q=zphd
  - deleted 5y ago
    [deleted]
  - napsterbr 5y ago
    That might be the case, but I wouldn't use Github search results to confirm this. I have no idea why, as this is super important, but code search in Github is surprisingly terrible. Not sure if this is just me or others have had similar experiences.
    - ejona86 5y ago
      Not just you. It can give no results and partial results, which is sometimes fixed on a re-query. But it also is just poor for code. I think it wants to find full words, so searching for substrings generally results in too few matches. That's made worse by its special character handling in word splitting and query parsing which makes some text impossible to find.

nynyny7 5y ago

Lines 442-445, but apparently line numbers are stripped from GitHub URLs posted to HN: https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5bc007f81d7f2416b48db90f313434/bootrom/bootrom_rt0.S#L441-L445 https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5...

Retr0id 5y ago
Interestingly, it was not present in the initial release. It was added here: https://github.com/raspberrypi/pico-bootrom/commit/ad55537bf35e332503b950d6951c41bcb8a7954f#diff-1bcdd4109020ba4c51666828150569e2bf550f4c3265b476175ba7375c8bf214R395-R398 https://github.com/raspberrypi/pico-bootrom/commit/ad55537bf...
chillingeffect 5y ago
first 2 bytes 0x11, 0x38... perhaps another scifi reference?
- Retr0id 5y ago
  I think you're right. This instruction is essentially redundant, since the following instruction also adds an offset - so I think it's very deliberate.
- deleted 5y ago
  [deleted]
- chillingeffect 5y ago
  Next two bytes: 0xc0, 0x7a = "cola" ?
  - jhart99 5y ago
    It is little endian so that will be '7AC0' or taco

Retr0id 5y ago

ARM thumb disassembly: 00: 11 38 subs r0, #0x11 02: C0 7A ldrb r0, [r0, #0xb] 04: 00 BD pop {pc} 06: 00 B5 push {lr} 08: 42 40 eors r2, r0 0a: 00 2A cmp r2, #0 0c: 00 F0 02 F8 bl #0x14 10: F6 D2 bhs #0 12: 8E 46 mov lr, r1 14: 70 46 mov r0, lr 16: 00 47 bx r0 Edit: I agree with the other commenters that this doesn't really look like a valid disassembly, it is perhaps data rather than code. Edit2: I take that back - it's just very "creatively" written.

mmastrac 5y ago
This reads a bit like a spurious decompilation. It's sorta valid but doing very weird things. Random bytes will often decompile to valid Thumb that looks sort of right like this all the time. 04 pop {pc} -> this is an odd way to return from a function on ARM, and likely means that these first bytes would be a very odd function. 06 push {lr} -> OK, maybe a valid prologue, but this function ignores the result of the cmp and calls 0x14.
- TuxSH 5y ago
  pop {..., pc} is THE standard way to return from a function that calls other functions itself, on Armv5 and above. Non tail functions usually do this: push {..., lr} ... pop {..., pc}
  - mmastrac 5y ago
    Only if there's a corresponding push { ..., lr }, but in this case there isn't. I'd expect bx lr here.
    - TuxSH 5y ago
      As other people are saying, code seems to be jumped at at #6. > I'd expect bx lr here LR is being clobbered by the bl (EDIT: bl, not blx)

mmastrac 5y ago

[deleted, thought it was possibly some pre-compiled code related to the trampoline but I don't think so] EDIT: I spoke too quickly, looking at the disassembly in the sibling comment. EDIT 2: That disassembly looks like data, TBH.

jagger27 5y ago
What does trampoline mean in this context?
- mmastrac 5y ago
  Usually just a piece of code to jump to another piece of code with certain necessary register modifications, ie: https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html
- diogenesjunior 5y ago
  if u go up it looks like there is a `debug_trampoline` function. so they are saying the `debug_trampoline_end` is a precompiled version of the `debug_trampoline` one. not sure if this is true or not
  - TuxSH 5y ago
    It is not. debug_trampoline_end is just a label in this context.
- bri3d 5y ago
  A trampoline in code is something you jump off of - essentially, a redirection snippet. You jump into it and it bounces you somewhere else. In this case, the use is documented where it's implemented: https://github.com/raspberrypi/pico-bootrom/blob/master/bootrom/bootrom_rt0.S#L425 https://github.com/raspberrypi/pico-bootrom/blob/master/boot... . It's a custom wrapper to call ROM functions. When the ROM function returns, the trampoline executes a debugger breakpoint. This is done so that the debugger can call into ROM easily without needing to set a hardware breakpoint.
- 5y ago

mannanj 5y ago

NSA hidden code?

Epiphany21 5y ago
If I put myself in the shoes of someone truly malicious, I would request a backdoor in the chip implementation itself. Hardware is hard. Once you put it in the customer's hands they can't change much. Hidden opcodes or combinations/uses of legitimate opcodes that trigger undefined behaviors on the platform as a whole are the way to go. Firmware on the other hand can be patched or replaced. It's probably an Easter egg or an undocumented workaround for something.
- SuchAnonMuchWow 5y ago
  note that this boot loader is in ROM, so it can't be patched or replaced
  - Epiphany21 5y ago
    Is it true ROM or some kind of EEPROM? A lot of the time what people call ROM is actually writable if you jump through enough hoops.
    - ebenupton 5y ago
      It is true ROM.

nynyny7 5y ago

Okay. I have an idea. Let’s see what happens if we treat… 06: 00 B5 push {lr} … as the start of this weird code(?) sequence. It pushes the link register (i.e., the return address to the caller). 08: 42 40 eors r2, r0 0a: 00 2A cmp r2, #0 This XORs R2 and R0 and compares the result against zero. But that’s just a decoy, as we’ll see. 0c: 00 F0 02 F8 bl #0x14 This calls into… 14: 70 46 mov r0, lr 16: 00 47 bx r0 … which moves the return address to R0, and then returns. Using the addresses in this disassembly (not in the actual boot ROM), the return address is 0x10; but LR and, therefore, R0 will actually contain 0x11 because the LSB signifies Thumb mode. None of the previous three instructions modifies the flags. (I checked in the ARM reference manual.) Thus, “BHS” (branch unsigned higher or same) uses the flags from the “CMP R2,#0” above. _Every_ value of R2 is higher (in the unsigned sense) or same as 0. Hence, the following branch is always taken: 10: F6 D2 bhs #0 … to… 00: 11 38 subs r0, #0x11 R0 contained 0x11 relative to the start of this code sequence. (The absolute address in boot ROM is of course different.) Now, R0 points to the start of the code sequence. 02: C0 7A ldrb r0, [r0, #0xb] This loads the byte at offset 0xB in this code sequence. Look above, it is 0x2A. 04: 00 BD pop {pc} This returns to the caller, using the LR pushed at the beginning. The return value in R0 is 0x2A. 0x2A is 42 (decimal)! Could this be an Easter egg; a very obfuscated way of returning 42, the Answer to the Ultimate Question of Life, the Universe, and Everything? (Remember that the Raspberry design team is from Britain, same as Douglas Adams.)

onetimertwo 5y ago
That reference would fit the zphd label. But it's _very unlikely_ that Zaphod Beeblebrox himself shows his head(s) here.
- qzw 5y ago
  Would you go so far as to say the improbability is infinite?
  - justinjlynn 5y ago

throwaway81523 5y ago

Even if it's not obfuscated, what is this decompilation doing in the pico source repo? Are they claiming that is the real source code that someone wrote?

Retr0id 5y ago
There is no decompilation here.
- throwaway81523 5y ago
  (edited) Hmm, maybe you are right, it is not that easy to tell. Those bytes at #441 are still mysterious.
  - bad_alloc 5y ago
    Looks like hand written assembly code to me. Also the legible function and label names indicate it was manually written. In diassemblies you usually have no such information.
    - throwaway81523 5y ago
      I'm thinking more like a manually annotated disassembly of something.
      - oneplane 5y ago
        Writing machine instructions isn't that unusual in microcontrollers where you write very closely against the bare metal.
      - Retr0id 5y ago
        Why? It would take longer to annotate and idiomatize a disassembly to this extent, than it would to just write it from scratch.

peter_retief 5y ago

What happens if you remove it?

nynyny7 5y ago
As it is in ROM (inside the RP2040), removing it might involve a Focused Ion Beam machine ;-)...
- peter_retief 5y ago
  Of course, is there no way to flash the firmware?
  - nynyny7 5y ago
    It is in the boot ROM; not in flash memory.
    - peter_retief 5y ago
      https://www.linuxjournal.com/content/flash-roms-raspberry-pi https://www.linuxjournal.com/content/flash-roms-raspberry-pi
      - nynyny7 5y ago
        What are you trying to say here? Please have a look into the RP2040 data sheet to understand what "boot ROM" means. It is not programmable! https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p... "A 16kB read-only memory (ROM) is at address 0x00000000. The ROM contents are fixed at the time the silicon is manufactured."
        peter_retief 5y ago
        I am just interested not trying to argue, found this link. https://wiki.segger.com/Raspberry_Pi_RP2040 https://wiki.segger.com/Raspberry_Pi_RP2040 The RP2040 includes a boot ROM which needs to be executed after reset in order to guarantee proper functionality. In case of a valid application has been detected in the external QSPI flash, the boot ROM copies the first 256 bytes from QSPI to SRAM5. In the RP2040 user manual, this code is called "flash second stage" (2nd stage bootloader) which is not part of the boot ROM but is part of the application image thus can be adapted by the user. The J-Link performs a device specific reset which halts on the first instruction at address 0x20041F00 of this so called "flash second stage" (bootloader).

rahimiali 5y ago

Direct link to the line in question: https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5bc007f81d7f2416b48db90f313434/bootrom/bootrom_rt0.S#L442 https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5... (@dang, worth updating the link?)

josuah 5y ago

Crosslinking the two posts: https://github.com/raspberrypi/pico-bootrom/issues/17 https://github.com/raspberrypi/pico-bootrom/issues/17

0x456 5y ago

Worthwhile reading on Easter Eggs "Why No Easter Eggs" https://docs.microsoft.com/en-us/archive/blogs/larryosterman/why-no-easter-eggs https://docs.microsoft.com/en-us/archive/blogs/larryosterman... https://hn.algolia.com/?query=Why%20no%20Easter%20Eggs https://hn.algolia.com/?query=Why%20no%20Easter%20Eggs ... and https://unix.stackexchange.com/a/405874 https://unix.stackexchange.com/a/405874 https://news.ycombinator.com/item?id=27994194 https://news.ycombinator.com/item?id=27994194

bmitc 5y ago
I tend to agree with that sentiment. If most software "just worked", I would be okay with it from time to time. But it doesn't, so I am not. I feel the same with cutesy error messages. They're usually a bit condescending or infuriating when something is going wrong. I personally tend to be a bit clinical in my software development, despite the urge to be playful. I am also not a big fan of cutesy commit or issue descriptions either.
- EvanAnderson 5y ago
  When I'm having problems with software I'm typically not in a whimsical mood. Most software I use are tools meant to help me do my job. A cutesy / playful error message coming from a misbehaving tool generates nothing but rage for me. Cute, condescending error messages are unprofessional and unhelpful. If fewer programs were steaming piles of garbage I might feel differently about it.
sneak 5y ago
Easter eggs are fine, just probably not in security code like bootloaders.
socialdemocrat 5y ago
God what a humorless crowd. We got a bug report from a customer on an Easter Egg once. There was nothing wrong with the software. It just annoyed them that there was an Easter egg. The idea that Easter Eggs are security risks comes across as the most pedantic paranoid position. Statistically speaking software is not failing because of Easter eggs. This does not seem to be about security but about typical American style “cover your ass” legalize thinking. Sure if you create a space rocket control system I would not put in an Easter egg. But if it is a code editor, word processor, email reading client etc then who cares? Nobody will die and million dollar equipment is not going to blow up. Disclaimer: I have never made an Easter Egg and I get that companies don’t do it if it causes problems with customers. I just think customers who complain about this should get a life.

drpixie 5y ago

Hmmm. Looks like 441 would be a great place for a helpful comment block.