Are you able to write parts of SRFIs while serving as the SRFI editor? I
can try to put these together but I wouldn't rely on myself to get it right.
Thanks for asking. I'd be happy to help by editing, but I'm not willing to commit to writing or implementing anything. This is for two reasons: first, I'm supposed to maintain my editorial independence, and second, and selfishly, I'm trying hard to find time for my long-term projects, so I don't want to commit to new projects. Thank you for your understanding.
> Despite the general recommendation against implementing one's own crypto,
> there are some examples of what appear to be excellent new implementations
> in other languages, e.g. Ocaml-TLS <https://github.com/mirleft/ocaml-tls>.
> Perhaps someone will make an attempt at an implementation in Scheme. I'd
> certainly be willing to entertain the possibility that it would be better
> than one written in C.
<https://akkuscm.org/packages/TerribleTLS/> -- TLS 1.0 and 1.1 in pure R6RS
Excellent!
I agree that it's good that crypto implementations start popping up in
non-C languages. However, one problem is that it's hard to wipe secret
data from memory in a GC'ed language. I've never seen a good solution;
languages that hit that problem tend to simply ignore it :-/ Go is the
most recent example I came across.
Yes, that's definitely an issue. It would certainly require non-portable (or currently non-portable) facilities. For example, key material might be kept in non-moving memory that is wiped upon release. I'm not sure what even C programs do about secret strings, for example, that are manipulated in the program. Are they careful to wipe them every time they're released? It would be nice to have some general mechanism for solving this problem once and for all.
Incidentally, this discussion should probably move to Schemeweb. Srfi-discuss is more for discussion of the SRFI process than for the specifics of particular proposals. I want to make sure that participants aren't overwhelmed by the level of traffic.