Julian Foad wrote:
I handled two security fixes in the recent set of patch releases. It was
the first time I had done it and the procedures were rather less than
push-of-a-button simple to follow.
1. We should move as much as possible of the scripts and documentation
that exists in a private
== Pre-notification ==
For the last set of patch releases (1.12.2, etc.), I started off not
intending to do any pre-notification, then later in the process it was
suggested I do so, and so I tried to fit it in, although the policy [1]
doesn't mention it and Subversion's own docs only include i
Daniel Shahaf wrote:
Julian Foad wrote on Wed, 28 Aug 2019 11:41 +00:00:
* Drop the CVE? (steps 8, 15, 16)
For cases that are not looking like a very high severity, we could
omit the CVE process and much of the formal description associated with
it. CVEs are a Good Thing, but they do requir
Daniel Shahaf wrote on Thu, 29 Aug 2019 00:44 +00:00:
> I do concede that if we had just a single release format, tarballs,
> that'd be easier on downstreams, but I do not accept that releasing
> patches would place an unreasonable burden on downstreams.
Forgot one thing: the releases have generat
Stefan Sperling wrote on Wed, 28 Aug 2019 12:07 +00:00:
> Also, users would have a much harder time trying to verify what they
> are actually running.
Did you see the part where I specifically proposed to release a patch
that fixes the issue _and_ bumps SVN_VER_PATCH? (The patch can also add
a ne
Julian Foad wrote on Wed, 28 Aug 2019 11:41 +00:00:
> * Drop the CVE? (steps 8, 15, 16)
>
>For cases that are not looking like a very high severity, we could
> omit the CVE process and much of the formal description associated with
> it. CVEs are a Good Thing, but they do require extra effor
Stefan Sperling wrote:
Julian Foad wrote:
* Drop the CVE? (steps 8, 15, 16)
For cases that are not looking like a very high severity, [...]
Yes. I would be in favour of this.
* Drop the requirement to roll a release? (steps 12, 13, 14)
I believe this approach would make things harder
On Wed, Aug 28, 2019 at 12:41:45PM +0100, Julian Foad wrote:
> This is not just theoretical. The next security issue has already landed in
> the queue and is currently waiting to be fixed and we have not enough hands
> on deck to deal with it.
>
> https://www.apache.org/security/committers
>
>
This is not just theoretical. The next security issue has already landed
in the queue and is currently waiting to be fixed and we have not enough
hands on deck to deal with it.
https://www.apache.org/security/committers
After dealing with the last pair of security fixes, I feel following
th
I'd like to reference and summarize some relevant mails from private@:
[[[
Date: Fri, 29 Mar 2013 07:07:12 +0300
From: Daniel Shahaf
To: priv...@subversion.apache.org
Subject: PGP encrypting pre-notification recipients
Message-ID: <20130329040712.GA2958@lp-shahaf.local>
]]]
tl;dr Should we PGP-en
I handled two security fixes in the recent set of patch releases. It was
the first time I had done it and the procedures were rather less than
push-of-a-button simple to follow.
1. We should move as much as possible of the scripts and documentation
that exists in a private repo, into a public
11 matches
Mail list logo
