Of bugs and bees (especially annoying bees)
Oftentimes a simple operation fails and screws a much complex operation;
Well mostly though it's the complex operation that often fails and makes life miserable.
"echo PASSPHRASE | gpg --yes --quiet --passphrase-fd 0 --simple-sk-checksum -c --no-use-agent SOURCE_FILE"
This was the monkey wrench that I managed to throw in the wheel of the tractor!
It all happened like this: I was tasked to design an encryption utility which will use gpg in the background and encrypt files with keys from a pool. So I wrote a small C program that would access the pool securely and encrypt the file. Later this file would be transferred across the network and at the receiving end there was a similar utility which would decrypt the file.
Now the problem was I didn't have enough time to go through gpg's api's and integrate it in the utility. So instead I used system function to execute the gpg command as shown above. For testing I would call this utility from terminal and it would work fine.
The thing was when I tested this utility from the main program, I found it working. So here are the two cases I tested against:
1. Call the utility from terminal and check for all OK.
2. Start the main program from terminal and test the functionality using this encryption utility.
Both tests came positive. So I okay-ed the utility and it got shipped with the main program. Now the thing was it wasn't used right away since the encryption routines remained unused for 2-3 months. Just last week though, when the field teams started using the encryption routines it started failing with consistency. Of course the buck got back to me. I was genuinely perplexed since it was all working fine. So I fire up the main program and test it and behold! The encryption part is working fine. I call up the field people and ask them what is the problem and they explain - blah blah blah.
So after a lot of head scratching and hair pulling I understood the scenario. I would always use terminal to start the main program since I would be looking out for debugging output. But we had provided a shortcut on the desktop as well as start menu which was the recommended way for starting the program.
At this insight, I started up the main program using the desktop shortcut; tested the encryption routine and it was failing. I tested the encryption routine separately on terminal and it's working. I modified the utility to throw up as much debug code; variable values etc and retested. Still nothing! In the main program it fails; and in terminal it works!
Well, after much more testing - I keep records for testing sessions; and it was 20th attempt - I figured out the problem with the command. Later it was simple, I modified the command as shown below. And after 5 more rounds of testing I confirmed the bug to be dead!
"gpg --yes --quiet --passphrase PASSPHRASE --simple-sk-checksum -c --no-use-agent SOURCE_FILE"
Lesson learned: Don't pick up code from shell script and put it in c program; always consider pipes and environment variables. And even after that when testing for functionality, test it like a user and not a developer. Developers test for bugs; users test for proper working of solution!
Well mostly though it's the complex operation that often fails and makes life miserable.
"echo PASSPHRASE | gpg --yes --quiet --passphrase-fd 0 --simple-sk-checksum -c --no-use-agent SOURCE_FILE"
This was the monkey wrench that I managed to throw in the wheel of the tractor!
It all happened like this: I was tasked to design an encryption utility which will use gpg in the background and encrypt files with keys from a pool. So I wrote a small C program that would access the pool securely and encrypt the file. Later this file would be transferred across the network and at the receiving end there was a similar utility which would decrypt the file.
Now the problem was I didn't have enough time to go through gpg's api's and integrate it in the utility. So instead I used system function to execute the gpg command as shown above. For testing I would call this utility from terminal and it would work fine.
The thing was when I tested this utility from the main program, I found it working. So here are the two cases I tested against:
1. Call the utility from terminal and check for all OK.
2. Start the main program from terminal and test the functionality using this encryption utility.
Both tests came positive. So I okay-ed the utility and it got shipped with the main program. Now the thing was it wasn't used right away since the encryption routines remained unused for 2-3 months. Just last week though, when the field teams started using the encryption routines it started failing with consistency. Of course the buck got back to me. I was genuinely perplexed since it was all working fine. So I fire up the main program and test it and behold! The encryption part is working fine. I call up the field people and ask them what is the problem and they explain - blah blah blah.
So after a lot of head scratching and hair pulling I understood the scenario. I would always use terminal to start the main program since I would be looking out for debugging output. But we had provided a shortcut on the desktop as well as start menu which was the recommended way for starting the program.
At this insight, I started up the main program using the desktop shortcut; tested the encryption routine and it was failing. I tested the encryption routine separately on terminal and it's working. I modified the utility to throw up as much debug code; variable values etc and retested. Still nothing! In the main program it fails; and in terminal it works!
Well, after much more testing - I keep records for testing sessions; and it was 20th attempt - I figured out the problem with the command. Later it was simple, I modified the command as shown below. And after 5 more rounds of testing I confirmed the bug to be dead!
"gpg --yes --quiet --passphrase PASSPHRASE --simple-sk-checksum -c --no-use-agent SOURCE_FILE"
Lesson learned: Don't pick up code from shell script and put it in c program; always consider pipes and environment variables. And even after that when testing for functionality, test it like a user and not a developer. Developers test for bugs; users test for proper working of solution!
Comments
Post a Comment