| That would mean having to encode "sensitive" into each and every value, integers, floats, strings etc. and that could have drastic impact on performance. The trait of being "sensitive" would then need to be handled by all operations on all those types as we need to automatically propagate the sensitive bit to the results of operations. Thus being lots of code that needs to be touched in many places, and would probably result in instabilities and subtle bugs until we manage to sort it out. So no, don't think this is a viable option. I did consider using the "tainted" bit available in Ruby since it handles such propagation, but it is for almost the opposite of what we want and it turned out to be a very bad idea to use it for some other purpose than what it is intended for. I think the best we can do is to have a different function for EPP templates that produces a sensitive result if it interpolates sensitive. For regular string interpolation it is tricky since calling a function would not work since you would like to pass the string with interpolations to it for evaluation and that would mean evaluating it, which would mean getting "redacted" text into the string. It works for EPP since the argument to the epp functions isn't evaluated. For interpolation into a string we would need a special interpolation instruction, or some new keyword / operator in the language that would tell the evaluator that the interpolation should unwrap and wrap the final result in a sensitive if it interpolates a sensitive. |
