agardnerIT
commented
9 months ago Since there has been no pushback from the user community, here is how it will work:
v0.8.0
No flags available
v0.9.0
Will add -ins [true|false] / --insecure [true|false] flag (defaults to false).
If --insecure flag is omitted, a soft WARN will be logged.
No breaking changes
v1.0.0
Will introduce the breaking change and --insecure false (either by default or as explicitly set by the user) will PREVENT outbound calls to http:// endpoints.
TLDR
In v1.0 and above, if you need to send to an insecure http:// endpoint, you MUST set --insecure true
This is a BREAKING CHANGE for >= v1.0
Currently, tracepusher will happily send data to either an insecure
httpendpoint or a securehttpsendpoint.Tracepusher should encourage "secure by default" practices and the first step of this would be to (by default) block (and warn) whenever an
httpendpoint is used unless an additional flag is passed.For example:
./tracepusher --endpoint https://example.com ...would complete as normal with no issues. But./tracepusher --endpoint http://example.comwould fail with a warning like: `Attempting to send data insecurely. Please add the --insecure true flag. Your data has NOT been sent.⚠️ This would introduce a potentially breaking change
For anyone currently pushing data to an insecure endpoint, this would introduce a potentially breaking change.
Maybe we introduce this feature as "warning only" first with a clear timeline towards it being "by default". In this model,
./tracepusher --endpoint http://example.com ...would still work (but print a warning + text about this behaviour being enabled by default in version X.X.This would give users plenty of warning and time to adapt their commands.
Your Input Required!
Please add your thoughts, questions, concerns below!