Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security vulnerability #892

Open
CiscoTalos opened this issue Sep 3, 2024 · 4 comments
Open

Security vulnerability #892

CiscoTalos opened this issue Sep 3, 2024 · 4 comments

Comments

@CiscoTalos
Copy link

Dear David

We are trying to reach you to submit a vulnerability report for MiniAudio. So far we have sent emails to the listed @gmail address. Please get back to us.

Best,

Martin
Cisco Talos

@mackron
Copy link
Owner

mackron commented Sep 3, 2024

I deal with all bug reports publicly and transparently. Please post the report here like any other bug report.

@orcmid
Copy link

orcmid commented Sep 4, 2024

David, please go to miniaudio Security Policy and provide the necessary information. Then be prepared to handle vulnerability reports.
 
Details

Exploitable security defects are not the same as bugs. Dealing with them in public leaves all users of products based on a vulnerable release exposed to exploits.

There are safe practices for not identifying such defects even when a commit is made that includes elimination of a vulnerability. Resolution and all discussions are in secret until a repair is made. Then people are warned to use the updated release along with minimal discussion of the nature of the vulnerability.

This should not be new news.

You might be aware that when GitHub recognizes a likely security flaw, typically from a dependency but also from their own scans, they always report privately and do not do anything in public.

@CiscoTalos
I am a little startled that anyone from Cisco Talos even made a public notification by creating this issue, no matter how difficult it is to get your private attention.

@orcmid
Copy link

orcmid commented Sep 4, 2024

I realize I need to follow my own advice, including providing a security policy that specifies there is no exploit handling/reporting on repositories where there are no public releases and any code is unsupported while being experimental/provisional and not for a stable release. Since I'm not accepting pushes, these are low-security situations.

@CiscoTalos
There is also GitHub advice on how to arrange a secure conversation when there is no security policy or vulnerability-reporting provision on a repository.

See Privately reporting a security vulnerability.

@orcmid
Copy link

orcmid commented Sep 4, 2024

===Practice What I Preach Department===

I started setting security policies for all of my repositories.
This one is typical. You might want something even simpler. I would setup the notification mechanism just in case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants