object capability discipline audit (WIP, FYI)

[dckc]

Implicit access to stuff like files and the clock makes unit testing awkward and hinders security auditing.

The lint stuff goes beyond stable so it would have to go in the long term, once I/we refactor for explicit access.

But I got far enough tonight that I thought I'd share my work in progress.

[bluejekyll]

Thanks for the PR!

Do you think you could explain what your intending to do with these changes? I'm unfamiliar with some of this.

[dckc]

The first commit replaces "ambient" access to the command line args with explicit access. One benefit is that we can substitute the args with our own for testing. Likewise the clock: if some random bit of code deep in the call stack can just reach out and access the clock without explicitly being given access, we can't make unit tests that provide a simulated clock.

It also lets us enforce the principle of least power. I'll have to think about how to explain succinctly.

Meanwhile, perhaps one of the talks in https://github.com/dckc/awesome-ocap#presentations-talks-slides-and-videos is worth your time? Flipping through the "Bringing Object-orientation to Security Programming" slides takes just a few minutes.

[bluejekyll]

Ah, ok. In terms of unit tests, this will definitely be handy, and it sounds like for this type of verification you will probably need it. As an FYI, pretty much anywhere I use current time, I try to make sure that that code path is easily unit-testable. But this will be cool. I'm excited to see what you come up with!

Also, can I suggest putting the txt files into server/ocap/...

And add a README.md in there would be awesome too with just a simple amount of information, or even just a reference back to the material you posted here? I think that would keep the that path a little cleaner.

[bluejekyll]

I'm going to close this, as it's been open for a long time. I am still interested in it if you ever pick it back up @dckc