You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Sidney Markowitz <si...@apache.org> on 2021/03/17 21:53:07 UTC
Rewrite of SecurityPolicy page on SpamAssassin wiki
I've completely rewritten the wiki page describing our project's process for
handling reports and fixes of security vulnerabilities because it did not
match what we actually do.
https://cwiki.apache.org/confluence/display/SPAMASSASSIN/SecurityPolicy
I have a point I would like to bring up for discussion.
"Also, unlike non-security issues which are closed in Bugzilla once the fix is
committed, leave this issue in Open state until the SpamAssassin release
containing the fix is prepared. That prevents people without full access to
the issue from matching up the time of closing of the issue with time of svn
commit."
That is something we have done, but I don't see the need given that for anyone
without access to security bugs any search or notification of closed bugs will
not show the issue. Even if someone knows the issue number, attempting to look
at it will show that a closed-access issue with that number exists, but
nothing about its contents or status or dates the status changed.
Given that the security purpose for that policy is not actually helped by it,
and it is more convenient to close bugs when the fix has been tested and
committed, I propose that we drop that policy.
After getting some responses to get a sense of things, I'll call for a vote to
change the policy.
I also locked the page to allow it to be viewed by anyone, but edited only by
members of the PMC. We might want to consider identifying other wiki pages
that similarly describe PMC policies and lock write access to those too. While
it is helpful that a wiki page can be improved by anyone who notices a typo or
awkward phrasing, pages that purport to describe official policy should have a
bit more assurance that they remain accurate. If anyone thinks that was a
wrong decision, feel free to speak up and we can discuss and vote on it.
Sidney
Re: Rewrite of SecurityPolicy page on SpamAssassin wiki
Posted by "Kevin A. McGrail" <km...@apache.org>.
+1
On Wed, Mar 17, 2021, 17:53 Sidney Markowitz <si...@apache.org> wrote:
> I've completely rewritten the wiki page describing our project's process
> for
> handling reports and fixes of security vulnerabilities because it did not
> match what we actually do.
>
> https://cwiki.apache.org/confluence/display/SPAMASSASSIN/SecurityPolicy
>
> I have a point I would like to bring up for discussion.
>
> "Also, unlike non-security issues which are closed in Bugzilla once the
> fix is
> committed, leave this issue in Open state until the SpamAssassin release
> containing the fix is prepared. That prevents people without full access
> to
> the issue from matching up the time of closing of the issue with time of
> svn
> commit."
>
> That is something we have done, but I don't see the need given that for
> anyone
> without access to security bugs any search or notification of closed bugs
> will
> not show the issue. Even if someone knows the issue number, attempting to
> look
> at it will show that a closed-access issue with that number exists, but
> nothing about its contents or status or dates the status changed.
>
> Given that the security purpose for that policy is not actually helped by
> it,
> and it is more convenient to close bugs when the fix has been tested and
> committed, I propose that we drop that policy.
>
> After getting some responses to get a sense of things, I'll call for a
> vote to
> change the policy.
>
> I also locked the page to allow it to be viewed by anyone, but edited only
> by
> members of the PMC. We might want to consider identifying other wiki pages
> that similarly describe PMC policies and lock write access to those too.
> While
> it is helpful that a wiki page can be improved by anyone who notices a
> typo or
> awkward phrasing, pages that purport to describe official policy should
> have a
> bit more assurance that they remain accurate. If anyone thinks that was a
> wrong decision, feel free to speak up and we can discuss and vote on it.
>
> Sidney
>
Re: Rewrite of SecurityPolicy page on SpamAssassin wiki
Posted by John Hardin <jh...@impsec.org>.
On Fri, 19 Mar 2021, Sidney Markowitz wrote:
> Oh, are you saying to be more explicit in the part of the policy about how to
> write those commit messages and what to say in public about the commit? Yes,
> that would be a good idea.
Yes, that.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
292 days since the first private commercial manned orbital mission (SpaceX)
Re: Rewrite of SecurityPolicy page on SpamAssassin wiki
Posted by Sidney Markowitz <si...@sidney.com>.
John Hardin wrote on 18/03/21 1:48 pm:
> Are there guidelines for how to (not) comment on the commit that fixes a
> CVE? Blocking public access to a bug doesn't help obscure the fix if the
> public comment on the fix commit is referencing a locked security bug...
What kind of comment would that be? Discussion about the bug would be in the
comments of the Bugzilla issue and in the securty@ mailing list, both of which
have restricted access (the Bugzilla issue being security restricted in this
case). The only public comment is the commit log message, which is in public
view and is sent to commits@. The policy is to not mention the CVE id in that
commit message and to say something bland but true like "fixing rule parsing".
Oh, are you saying to be more explicit in the part of the policy about how to
write those commit messages and what to say in public about the commit? Yes,
that would be a good idea.
Re: Rewrite of SecurityPolicy page on SpamAssassin wiki
Posted by John Hardin <jh...@impsec.org>.
On Thu, 18 Mar 2021, Sidney Markowitz wrote:
> Given that the security purpose for that policy is not actually helped by it,
> and it is more convenient to close bugs when the fix has been tested and
> committed, I propose that we drop that policy.
I have no objections. Access to security issues in BZ is restricted so
that seems an exercise in security through obscurity.
Are there guidelines for how to (not) comment on the commit that fixes a
CVE? Blocking public access to a bug doesn't help obscure the fix if the
public comment on the fix commit is referencing a locked security bug...
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Then there's that look that your cat gives you when you make
six grammatical errors and two pronunciation errors in one sentence
when you meow back at him.
-----------------------------------------------------------------------
291 days since the first private commercial manned orbital mission (SpaceX)