Fork me on GitHub
Karol Wójcik08:11:50

Hi guys. I would like to ask you whats your opinion on removing the :envs property from the ctx map. The reason I found it a necessary change is that I see to many people logging the whole event and exposing their AWS_SECRET_KEY. By removing the :envs property the runtime should also perform slightly better.


What was the purpose of envs? Just a shorthand for (System/getProperty)?

Michael W16:11:27

Couldn't you strip out the secrets instead of dropping all the environment variables? I'm currently using it for some other vars, though I guess I could swap to using java interop to get them.

Karol Wójcik19:11:43

Idea behind adding envs to ctx was to support calling native-agent-payloads for generating GraalVM native-configurations.. Basically HL gots a mechanism that can gather edn files with payloads and in for loop call specified Lambda with corresponding payload. This forces GraalVM native agent to gather all possible reflections, resources, JNI usage etc. The way to go should be to use System/getenv. For generating native-configuration one can still put envs in ctx:envs and then use (or (System/getenv “XX”) (get-in ctx [:envs “XX”])) There is also another reason why I want to remove envs in ctx. To many times I’m being asked how to get envs out of handler context. Envs in ctx are just too misleading.


I use it in every lambda so this is a breaking change for me. I'd prefer you redact the sensitive fields in .toString or something like that. I can patch but accretion is 'the way'

Karol Wójcik21:11:27

The problem is that envs in general contain sensitive fields that should not be logged.

Karol Wójcik06:11:00

Sooner or later this is something I should address. @U0510KXTU I’m not planning any new changes beside analitics and envs in the core runtime, so I think you can stay with the current version of HL. The next few months I will spend on tasks, ring/pedestal adapter, live environment improvements.


yeah, I’ve accidentally logged it myself in the past also

Karol Wójcik06:11:26

I also hope that after few months I would be able to promote the new version to 1.0.0 and mark core as a complete/stable.


in cloudwatch logs for lambdas they redact the payload unless you specifically print the nested data


I wonder if you could provide some kind of masking like that? it’s mostly just the aws creds right?

Karol Wójcik06:11:17

Not only I think. One can put unmasked DB creds, some tokens, api keys etc.

Karol Wójcik06:11:34

There is no way I can „quess” what should be hidden. Also even I would start masking those values it's already a breaking change to someone.


makes sense


I don’t really mind this breaking change. I can adapt easily. it’s just not the clojure way but then again you are not v1.0 yet either

Karol Wójcik07:11:58

Right. There was a lot more breaking changes before, but the more we're close to v1.0 the more runtime is stable, and less breaking changes are introduced.