Remove ineffectual parameter wiping

[contificate]

There is code in xapi_session.ml that appears to attempt to wipe memory by explicitly zeroing it. However, strings have been immutable in OCaml for a long time now and so the code creates a copy of the strings' contents as bytes (using Bytes.of_string) and then zeroes that. I suggest we remove this code as it has never been effective at doing what it set out to do.

As per a commit message, you can see that the first commit is effectively undoing the changes introduced by 6e24ca4.

I have done this in 2 commits: (1) removes the code. (2) applies formatting. This should hopefully make the changes easier to review. These should be squashed if PR is accepted and merged.

[lindig]

• I am surprised about the size of the diff
• The intention is the overwrite an existing string in memory - which in itself could be useful. Could this be still achieved using Obj.magic or a small C function?

[last-genius]

"This all makes Bigarrays ideal for storing secrets. We can be sure, that they are not moved by the GC, we can overwrite them to prevent the information leakage once they are freed." from a related StackOverflow question: https://stackoverflow.com/questions/47707142/overwriting-data-in-memory

And from Edwin, some time ago:

A bigarray might work, and might be the preferable approach (it doesn’t rely on any GC or libc implementation details and gives you full control over scrubbing), but comes with the drawback that none of the string processing routines would work with it, and you might have to create temporary bytes that need scrubbing (although that can be avoided if everything using the secret is converted to use bigarrays, or the API of this SecureString module).
https://discuss.ocaml.org/t/support-for-clearing-gced-memory/11071/9

[contificate]

• I am surprised about the size of the diff

@psafont informed me about the following feature which drastically reduces the visual size of the diff (the "hide whitespace" option):

• The intention is the overwrite an existing string in memory - which in itself could be useful. Could this be still achieved using Obj.magic or a small C function?

Even if we did achieve it, there's likely many more buffers on the way down that contain fragments of sensitive information. The problem just gets pushed up the way if we start using bytes for all of this (or something similarly in-place rewriteable), a string containing the same content is probably in-memory elsewhere. A C stub probably could destructively write zeroes to the string object in-memory, but I don't think we want to go that route.

[lindig]

I would agree overwriting memory is solving the problem at the wrong end. Once something is a string in OCaml you need to be very careful to not create copies and so it becomes difficult to overwrite it. And even before it reaches OCaml, it can be in memory.

[edwintorok]

I thought we fixed this long ago, I remember mentioning this at the time.
But perhaps that was just in person, not on the PR.

Thanks for removing these, it gives the wrong impression to someone reading the code.
We have many copies of the password:

• in the XML/JSON buffers
• in the password strings (the bytes was just a copy, strings are immutable now)

Although some of these are short lived, the garbage collector will eventually return it to the OS, or replace it with some other allocation.

Even before having immutable strings we still had a copy in the JSON/XML buffers, so the wiping was ineffective anyway.

[edwintorok]

• The intention is the overwrite an existing string in memory - which in itself could be useful. Could this be still achieved using Obj.magic or a small C function?

Strings are immutable in OCaml, so we can't overwrite them (if we want to keep them overwritable then we'd need to keep them as bytes), but yes as I mentioned elsewhere even with bytes the GC could've moved it (at least on OCaml 4), so bigarray is the only way to ensure it doesn't get moved and can be overwritten.
But that needs the entire stack, HTTP server, XML/JSON parser all changed to use bigarrays.

[psafont]

Lots of churn due to the indentation change. Other than that, I'm happy the misleading code got removed

[edwintorok]

For future reference I found the internal ticket referencing this: CP-28410, which was refered to in the linked PR