== 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 it in a
different procedure ("how to roll releases in private", in 'README' in
our pmc/security repo).
What I did was to send a pre-notification, giving 7 days' notice before
disclosure, and at the same time publish the release which was not
announced as a security release. This seemed to be allowed by step 15
but perhaps isn't a good idea.
With hindsight, a disclosure date and whether to pre-notify should have
been decided in step 11, "The project team agrees the fix, the
announcement and the release schedule with the reporter" before
committing the fix and starting the release process. This could be
stated more explicitly.
A downstream consumer asked, "Why aren't these announced *at the same
time* as the release? The delayed post-notification makes it extremely
difficult for distributors - I can push [OS] updates for the new
Subversion releases right now but I can't tell users they are security
updates. Once the updates are pushed, I have no out-of-band way to
announce to users that they needed to update because of the security
issues which were silently already fixed."
If and when we pre-notify in future, should we always disclose the
security vulnerability at the same time as the release? And keep the
pre-notification "embargo" time short.
Mark Cox permits me to share his thoughts on the topic. I'm not sure but
I think Mark was under the impression when he wrote this that we were
just working out how to do pre-notification for the first time, unaware
we've been doing it for years, but nevertheless his comments are
interesting.
Mark Cox wrote on 2019-07-31:
We've not covered pre-notification in the security committers page because it's not something that has a general policy and projects can do things differently based on their users and release procedures.
It's great and fine that projects *can* operate independently, but my
position now is that we don't *want* to be discussing and maintaining
our own procedure independently of other projects. We want to be
following procedures that are shared with other projects, in order to
reduce the friction caused by differences and the maintenance and
discussion of the procedures.
For example, HTTP server has in the past had some selected group of folks know
about issues in advance, in order to test a fix or prepare updates to help
protect the community at large (for example a large proportion of users of
Apache HTTPD probably are using binaries supplied by some OS vendor). This is
troublesome because you end up having to deal with private communications and
with groups that are unhappy they were not included in the prenotification. So
it tends to only happen for things serious enough to be a real risk to users
(i.e. some usual default and some impact to all of CIA) and we've seen projects
leverage lists like the private distros list so decisions about who gets what
info are abstracted. I've seen this has very positive benefits when the
prenotified folks actually do some value add to the process (like find flaws in
the patches, advisory, etc).
At OpenSSL we combine some full private prenotification with giving public a heads up
that something is coming ("next Tuesday something severity Critical will be
released") which does help ensure anyone who has a dependency can be paying
attention that day (holiday coverage etc etc). We get a lot of positive feedback about
doing this, even if there is no useful actionable information.
It's tricky where you're releasing something public (for mirror purposes etc)
but at the same time giving the public pre-notification because as you say it
can make it fairly trivial for someone to dig and find the fix to the flaws and
figure out an exploit. If you want to do this it's just best to keep those
timescales as short as possible.
Given that we have been doing pre-notification for some of our security
fixes in the past, and we see the value in it, how should we incorporate
it in [1]?
Is anyone willing to make an amended version of [1], inserting
pre-notification, that we could publish and follow, and invite other
projects to share?
- Julian
[1] https://www.apache.org/security/committers
