#2994 Issue closed: RFC: Should we activate security bug reports for ReaR?¶
Labels: won't fix / can't fix / obsolete, ReaR Project
jsmeix opened issue at 2023-05-25 09:39:¶
Should we activate security bug reports for ReaR?
Right now I noticed
which describes the reasoning behind and details
how to activate security bug reports at GitHub.
schlomo commented at 2023-05-29 09:55:¶
IMHO we should do this only if we can also offer or even guarantee some kind of SLA in dealing with it.
As long as nobody can commit resources to follow up on such reports I'd rather not offer this, as it would lead to false expectations.
Also, we could advise people who would like to report a security issue to write to one of the maintainers via email instead.
Finally, how many security bugs did we have over the last 10 years? Without discounting the possibility of security issues in ReaR, maybe we are not yet at the forefront of this problem.
jsmeix commented at 2023-05-30 10:31:¶
@schlomo
I fully agree with you.
I did this issue primarily as a request for comments.
But right now while I write this I have the idea that
the underlying GitHub functionality is actually
a generic method for non-public bug reporting
which could be something that could be actually useful
so that ReaR users could report issues where they do not
like to just publish all information out into the wild.
Of course GitHub's non-public bug reporting functionality
cannot and must not be used to submit real secrets
(like passwords or access keys) to GitHub
(and we at ReaR upstream never want to get
nor do we ever need any real user secret)
but perhaps some ReaR users may feel better
if not all and everything would be just public?
schlomo commented at 2023-05-30 11:02:¶
I understand your reasoning @jsmeix, however I'm wary of two things:
- If the GitHub flow suggests to the end-user that this way of submitting issues will get any sort of immediate response - we shouldn't offer it without a commitment by maintainers behind it
- How would we decide when to turn a secret/private issue to be a public issue? I'm a bit worried that we will start to pile up private issues which means that only maintainers can see them and work on them - again something I'd like to avoid without a strong commitment of maintainers.
Bottom line for me is that without a commitment of maintainers to take care of such issues I'd prefer to not offer it. There are enough existing options to contact maintainers privately so that there is no immediate need for a change.
If those of the maintainers who get paid for working on ReaR can commit to taking care of such issues, then please go ahead and configure private issues. Please also specify on the website and in the top-level README who are the maintainers serving in that role.
jsmeix commented at 2023-05-30 11:58:¶
@schlomo
again I fully agree with you.
Personally I am not interested to deal with
non-public GitHub issues at ReaR upstream
because this would be more (administrative) work
with less outcome (proper improvements for ReaR),
cf. "given enough eyeballs, all bugs are shallow"
https://en.wikipedia.org/wiki/Linus%27s_law
E.g. SUSE customers (who in the end pay my salary)
can report ReaR issues privately to SUSE
via their specific customer contacts and
same or at least similar for Red Hat customers.
Unfortunately Canonical is not (yet?) sufficiently
interested in actively supporting upstream ReaR.
jsmeix commented at 2023-05-31 11:58:¶
@rear/contributors
provided you do not object
I would like to close this issue as
"won't fix / can't fix / obsolete"
on Friday afternoon.
gdha commented at 2023-06-01 12:59:¶
FYI Codacy action was added last week and now a PR has been requested - https://github.com/rear/rear/pull/3001 - see also https://docs.codacy.com/getting-started/supported-languages-and-tools/ for more details (it does contain a short of shellcheck)
jsmeix commented at 2023-06-05 08:07:¶
FYI regarding Codacy
also see
https://github.com/rear/rear/pull/2991#issuecomment-1573522079
and the subsequent comments there
[Export of Github issue for rear/rear.]