How can I report security issues?

[leprechaun]

@engswee , I have security concerns about the implementation of analytics.

How would you prefer I relay them? I tried finding your email in commits, and the web-form on equaliseit.com doesn't work for me.

[engswee]

Hi @leprechaun

Thank you for getting in touch. The plugin for the web form needed updating! I've updated it now, can you please try again? You should see the screen below once the message is successfully sent. Let me know your concerns and leave me your contact details, and we can take it from there.

[leprechaun]

Sent.

[engswee]

Hi @leprechaun

Thanks for sending in your message. As it does not involve zero day vulnerabilities, it is okay to discuss them here.

Here is my public response on LinkedIn to your concerns 👉🏻 https://www.linkedin.com/posts/engsweeyeoh_flashpipe-activity-7333072342132129792-i_de?utm_source=share&utm_medium=member_desktop&rcm=ACoAAADdbz4BTbVvlTnNNYh2HddEaBarMSE_RzQ

TLDR - analytics will stay and will not be optional. But let’s continue talking anyway.

I understand you have very strong opinions about analytics. That is fine and you are entitled to having them. Let’s have a constructive discussion and see if we can figure a way forward.

I must say I am pleased to hear about your efforts to look under the hood of FlashPipe (debugging and changing its code), and bothered to reach out to me to discuss your concerns. I do not see any of your efforts as a mistake or time wasted.

FlashPipe is not without its flaws, and feedback like yours do not come often and therefore is valuable, more so as it comes from a different perspective and forces me to consider a different viewpoint.

I am keen to continue this conversation and see if there are areas that we can agree on, and if you are up for contributing.

Let me know if you are still keen to discuss and we can take this further.

[leprechaun]

Thank you fro promptly addressing the issue of transparency. I wasn't expecting or hoping you to go that far our of you way to dispell things. Good on you.

I'm afraid my message may have landed poorly. I think the haste, and trying to cram all thoughts and recommendations into one limited length message made the focus less clear, less collaborative, and I may have come across like a mad man. I apologize.

That said, I reached out because I care, because Flashpipe scratches an incredible itch! I'm grateful you've spent the time and effort on it, it can change the way people work.

---

I'm still keen, of course.

While I might have gone on about opting in or out and such, perhaps the reason for the urgency was the contents dimension5.

I think that as a rule of thumb, anything logged at "Fatal" would be included as part of dimension5, Those errors printed on the command line are definitely useful to end-users to understand something they might have done wrong. I can also see why getting access to those through analytics would be useful to support the development of Flashpipe.

However, despite taking the care to strip out TMN host, I still feel there's problematic content making it into analytics through errors -- content I don't think all users would be comfortable sharing -- and at the same time, I wonder how useful those extra details really are for supporting development and analytics.

I have 3 examples of user caused errors resulting in user input/content metadata making it into the analytics payload. I'm worried there may be more I haven't encountered yet. Does this sound like something worth looking into?

[engswee]

Hey @leprechaun, great to hear that you are still keen. I'm really pleased that you reached out because you care and want to make a difference ❤️

Let's focus on dimension5. I can't recall every instance of how analytics and in this particular discussion, error messages, have helped with FlashPipe development, but I do remember the most recent one. At the end of last year, SAP made some changes to the behaviour of an API which caused the deploy command to stop working. Because I could see the widespread errors happening, I could quickly churn out Release 3.4.1 even before any user raised an issue.

Now error messages are a really tricky topic, because due to the wide range of functionality FlashPipe provides, the messages could come from anywhere and contain anything. It's possible that not all of them would be useful, but not having any at all would not work.

So my suggestion would be to improve the sanitisation of the error messages. We start with what we have/know (the 3 use cases you have in mind), and progressively improve it where needed in the future. I work on the principle "I deal with what I do know, because I don't know what I don't know".

If this suggestion sounds acceptable, maybe you could work on it an submit a PR of the changes? I also suggest that you have a look at the contribution guideline page, taking note about making changes in a non main branch. Also I think it may be worth having all the sanitisation in a separate function as I anticipate it could grow with more use cases in the future.

[leprechaun]

Hey, sorry for the delay,

Yes. Happy to send some fixes in.

Would you also be open to logging a more precise error that is shown to the user, before a more generic error is raised (and potentially sent to analytics)? Something like this

I think it might be easier over the long term to maintain these error and log pairs in the same codeblock, than it would be in two different files. Looks like github.com/rs/zerolog/log gets pulled in and use in a lot of places in the codebase already, so it might not significantly change inter-dependencies.

Thoughts?

[engswee]

Hi

I like the idea of having the specific and generic error pairs, this would remove the need of having a sanitisation method at the end that has to deal with all sorts of errors.

Using zerolog is fine, but I think you can't use the Fatal() method because that immediately terminates the processing.

[leprechaun]

Ok, awesome.

Let me whip something up and see if I still like it. I suspect the repetition will get tiresome, I'll have a think.