This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-24
Channels
- # announcements (4)
- # asami (5)
- # babashka (20)
- # beginners (94)
- # bristol-clojurians (1)
- # calva (23)
- # cider (2)
- # clj-commons (3)
- # clj-kondo (43)
- # cljfx (2)
- # cljs-dev (13)
- # clojure (112)
- # clojure-dev (44)
- # clojure-europe (17)
- # clojure-nl (5)
- # clojure-poland (12)
- # clojure-spec (2)
- # clojure-uk (3)
- # clojurebridge (1)
- # clojurescript (92)
- # cursive (17)
- # data-science (8)
- # datahike (1)
- # datalevin (1)
- # datomic (3)
- # deps-new (7)
- # events (2)
- # fulcro (40)
- # graalvm (110)
- # holy-lambda (16)
- # introduce-yourself (1)
- # lsp (13)
- # malli (8)
- # missionary (12)
- # off-topic (10)
- # pathom (13)
- # polylith (10)
- # portal (28)
- # re-frame (37)
- # reitit (1)
- # releases (1)
- # shadow-cljs (30)
- # spacemacs (1)
- # tools-deps (9)
- # xtdb (10)
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.
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.
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'
The problem is that envs in general contain sensitive fields that should not be logged.
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.
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?
Not only I think. One can put unmasked DB creds, some tokens, api keys etc.
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.
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
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.