SQLite, inspiring.

Just take a look at this website: http://www.sqlite.org/testing.html

They test everything. One particular term caught my eye, because I didn’t understand it.

100% modified condition / decision coverage

What does this mean?

First, what is 100% decision coverage? For each conditional, both the true and false branch must have test coverage.

Consider A & B, the following two cases provide 100% decision coverage:

A = true, B = true

A = true, B = false

But these cases don’t provide 100% condition coverage, which states that both A and B take on all possible values. These cases provide 100% condition coverage, but not 100% decision coverage:

A = true, B = false

B = false, A = true

What about 100% condition / decision coverage? Each decision and each conditional must take on all possible values at least once.

A = true, B = true

A = false, B = false

These test cases provide condition / decision coverage.

Finally, what is modified condition / decision coverage? Like, condition / decision coverage, each conditional and decision must take on all possible values. The additional restriction is that each condition must affect the decision independently.

The above cases don’t provide 100% MC / DC coverage, because of this case:

A = false, B = false

If we hold one fixed, the decision of A & B is not affected by the value of the other.

We would need 3 cases:

A = true, B = true

A = true, B = false

A = false, B = true

To satisfy 100% MC / DC coverage. Pretty strong requirement huh?

Oh and every entry / exit point of the program must be exercised, but that’s a minor detail.

 

Advertisement

ecryptsfs and ssh don’t play nice together

I encountered the most aggravating issue today. My zeal for security combined with my lack of understanding was my downfall.

Recently I bootstrapped a server with a fresh Ubuntu installation. When asked if I wanted to encrypt my home directory, I didn’t hesitate for a second. No baddie was pulling my files off my disk, no hell no.

When ungodly winds struck LA last weekend, the power went out. Nine times out of ten, any wind over 15mph and LA’s grid is struggling.

So I turn this machine on again, and go to SSH in. It prompts me for my password.

Strange, I absolutely had my public key installed on the server.

I ran ssh-copy-id again for good measure.

Same problem.

I scoured Google with vague terms “SSH public key still prompts for password send help”

And then it worked! I ran ssh and it logged me in smoothly, no-hassle, as God intended.

Did I fix it? Take Note: When something works without any change to the system, no you did not fix it. I’m looking my fellow programmers dead in the eyes right now.

I carried on, logged out and tried again. Once again prompted for the password.

OH I logged out of all my sessions! I could only SSH with public key authentication when I was already logged in with a separate session.

What the devil is this bullshit … ecryptfs … my home directory was only decrypted and mounted when I had an active login session.

Where do SSH keys live by default? /home/user/.ssh/authorized_keys.

 

Chroot Jail Part 3

Recently I decided my dev DigitalOcean instance needed a boost. Normally 512mb is sufficient for production but I want to develop remotely.

I opted for a temporary resize to 1gb of RAM.

I also learned that my attempts to bind /dev/urandom and /dev/tty in /etc/fstab were failing miserably. I had to use DigitalOcean’s VNC connection and manually try to figure things out.

Remember how often I hit Ctrl-W and closed the tab still raises my blood pressure.

I ended up using /etc/rc.local to run

 

$ sudo mount --bind /dev/urandom /jailthing/urandom
$ sudo mount --bind /dev/tty /jailthing/tty

And it worked like a charm!

No more VNC to setup my convoluted login scheme anymore!