Create an initial Security.md document.

[crankyoldgit]

Respond to request in #1616

[JamieSlome]

LGTM! 🍰

[NiKiZe]

For small projects I think it is much better to not mention any specific user contact.
My logic is, Check https://github.com/crankyoldgit/IRremoteESP8266/graphs/contributors and then check if the major commiter is the same as the repo owner github.com/crankyoldgit/IRremoteESP8266 if so use their emailaddress used in most commits.

Is the noreply email addresses really usable? get bounces when testing.
Another aproach if it needs to stay secret, is for the reporters to create a private repo, invite us to it, create an issue and mention us. - There should be better ways to "getting in touch with maintainers" for github rather than having a separate file - which might I see is likely to be forgotten and unmaintained. (and out of date in old releases, can specific files be excluded from releases?)

[crankyoldgit]

For small projects I think it is much better to not mention any specific user contact.
My logic is, Check https://github.com/crankyoldgit/IRremoteESP8266/graphs/contributors and then check if the major commiter is the same as the repo owner github.com/crankyoldgit/IRremoteESP8266 if so use their emailaddress used in most commits.

I understand where you're coming from, and I agree to a point. I think we should make it easier than that for a report.

Is the noreply email addresses really usable? get bounces when testing.

Ditto. Seems the documentation (https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository & https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-email-preferences/setting-your-commit-email-address) is wrong or I read it wrong.

Another aproach if it needs to stay secret, is for the reporters to create a private repo, invite us to it, create an issue and mention us. - There should be better ways to "getting in touch with maintainers" for github rather than having a separate file - which might I see is likely to be forgotten and unmaintained. (and out of date in old releases, can specific files be excluded from releases?)

Fair point(s). Though requiring someone to create a private repo seems excessive (Are private repos free now?, they used to be a paid feature)

Perhaps we should create a link in the document to get the current correct details from the master branch etc or gh-pages branch/site.

I'll look into some better way of doing contacting that auto-tracks etc.

[crankyoldgit]

@NiKiZe I've updated the doc, please re-read etc.
Gist of the update is it drops the github email addresses, adds my personal one, and asks them to also create an issue without the sensitive details, as a backup comms method. i.e. In case I'm away/incapacitated etc etc.

It's not optimal, but it will do for now.

[NiKiZe]

I still have my doubts about this but ok.
I would like this file to not be included in releases before merging, is that doable?

[crankyoldgit]

Sounds reasonable to me. Lets remove it after we have the issue dealt with, and add this as a TODO for later.

[crankyoldgit]

I still have my doubts about this but ok. I would like this file to not be included in releases before merging, is that doable?

Oh, I think you mean in some automated process before each release. I'll see if there is some way to exclude a file from a release in GitHub

[crankyoldgit]

I still have my doubts about this but ok. I would like this file to not be included in releases before merging, is that doable?

Oh, I think you mean in some automated process before each release. I'll see if there is some way to exclude a file from a release in GitHub

A quick google shows it can be automatically excluded from the "ZIP" file, but not from the "release" tag, as the tag is pretty much just a pointer to a view of the entire repo tree as of a given "commit". Thus we can't hide/exclude it as such.

I think we need to go to a pointer/URL approach, and point to a page that has the info. e.g. We could point to a "security-contacts" branch, that is outside of the release branch/tag, and have that file/page have the current info.

[NiKiZe]

Exclude from zip (doable with gitattributes) was my thinking, having it in the zip is what I want to avoid, tag etc is git so that is not as big issue.