Index: site/publish/docs/community-guide/issues.part.html =================================================================== diff -u -N -r1816938 -r1866117 --- site/publish/docs/community-guide/issues.part.html (.../issues.part.html) (revision 1816938) +++ site/publish/docs/community-guide/issues.part.html (.../issues.part.html) (revision 1866117) @@ -410,6 +410,8 @@ +

Security approach in Subversion's Design and Implementation

+

Subversion's first job is keeping your data safe. To do that, the Subversion development community takes security very seriously. One way we demonstrate this is by not pretending to be cryptography or security experts. @@ -422,6 +424,8 @@ degree that we can leverage the knowledge of security experts by using the third-party libraries and APIs they provide, we will continue to do so.

+

Handling reported security vulnerabilities

+

This document describes the steps we take when receiving or finding an issue which may be classified as having security implications, and is meant to suppliment the @@ -436,7 +440,36 @@ Other stuff? --> +

Mailing Lists

+

Security problems should be discussed on private@subversion.apache.org + +security@apache.org. security@subversion.apache.org is a convenience alias +that targets these two lists. (Note that unlike, say, security@httpd.a.o, +it is not a mailing list, so you can't subscribe/unsubscribe to it +separately.)

+ +

Tracking Issues

+ +

We publish the list of previous security advisories at: +http://subversion.apache.org/security/

+ +

We track in-progress issues in the PMC's private repository: +https://svn.apache.org/repos/private/pmc/subversion/security

+ +

Procedures We Follow

+ +

We aim to follow a published procedure.

+ +

We usually follow the ASF's recommended +procedure. +We usually also do pre-notification to pre-selected parties; details of this +are managed in the PMC's private repository.

+ +

We also have a different procedure which we may use, documented in +How to Roll Releases in Private. +At present we do not usually use this procedure.

+ + Index: site/publish/docs/community-guide/how-to-roll-releases-in-private.txt =================================================================== diff -u -N --- site/publish/docs/community-guide/how-to-roll-releases-in-private.txt (revision 0) +++ site/publish/docs/community-guide/how-to-roll-releases-in-private.txt (revision 1866117) @@ -0,0 +1,134 @@ +HOW TO ROLL RELEASES IN PRIVATE +=============================== + +To roll the release: +-------------------- + +- For each CVE, there should be a CVE patch for each supported release line + that is vulnerable. These are the patches that will be distributed with + the advisory. They are indexed in /metadata ['patches']. + +- Write patches for CHANGES for each supported release line. These + will be part of the tarball but will not be distributed with the + advisory. + + The CHANGES patch for each minor line should include the CHANGES patches for + each older minor line, e.g., if releasing 1.8.19 and 1.9.7, the CHANGES patch + for 1.9 would add not only 1.9.7 but also 1.8.19. + [TODO: And how are the patches to be committed to trunk, then?] + +- You'll be rolling a 1.a.b release with b>0, so for the magic + revision argument pass the magic revision of 1.a.c where c=b-1. You + can find the magic revision by running 'svn log -v' on the 1.a.c + tag. Run 'release.py roll' and pass '--patch DIR' where DIR + contains the CVE and CHANGES patches. The names of the patch files + should include '1.a' and end 'patch'. Example rolls: + + release.py roll --patch .../security/CVE-2017-9800 1.8.19 1800620 + release.py roll --patch .../security/CVE-2017-9800 1.9.7 1800392 + +- Compare the contents of the candidate tarballs with the previous + release tarballs, and verify that the differences correspond to the + patches. + +- Run 'release.py sign-candidates' as usual. + +- Upload the artifacts to /repos/private/pmc/subversion/security/staging-dist. + DO NOT USE 'release.py post-candidates', that would PUBLISH them, days + before the end of the embargo. + +- Post a "up for testing/signing" mail to private@. + DO NOT SEND it to dev@... + +- Prepare a website update announcing the release. Remember to update + /site/publish/security/ as well. Note that the advisory files therein + contain patches (see tools/dist/README.advisory) and are signed with PGP + detached signatures. + +- Prepare a log message for committing the patch to trunk. + +(send pre-notifications) + +(wait for sufficient votes) + +To post the release: +-------------------- + +- Check that your machine's clock is synced. A good way to do this is to run + 'ssh known-good-host env TZ=UTC date; TZ=UTC date' (in one line) in the shell + and ensure the results are no more than a second apart. This ensures you + will not announce before the end of the embargo. + +- Join IRC so the other committers can easily report any problems to you. + +- At the designated end of the embargo, upload and announce the release as usual. + + + Upload: + + svn import \ + .../security/staging-dist/dev/subversion/ \ + https://dist.apache.org/repos/dist/release/subversion \ + -m "Release Apache Subversion 1.9.7 and 1.8.19 with a fix for CVE-2017-9800." + + + Commit the website patch which you had prepared above. + + If you need to announce the release less than 24 hours after uploading it + to the public /dist/release tree, use the ?update= argument: + + https://svn.apache.org/viewvc/infrastructure/site/trunk/content/dyn/mirrors/mirrors.cgi?revision=1771297&view=markup#l180 + https://www.apache.org/dev/release-download-pages#less-than-24hr + + Use that in the news entries (index.html and news.html, output of + 'release.py write-news'), and in the sidebar (site-nav.html). + + * TODO: Is there a way to edit download.html so that ?update=YYYYMMDD... + also applies to people who have bookmarked download.html and are opening + it from their bookmark. + + + Send the email announcement. Remember to pass --security to 'release.py + write-announcement', and use the ?update=YYYYMMDD... link. + +- Commit the patch to trunk. Use the log message prepared earlier. + +- Commit any additional patches, e.g., hook scripts to tools/hook-scripts/. + +- [TODO details] Commit the CHANGES patches to trunk. + +- Backport the patch to HEAD of the 1.a.x branch. Copy the shadow-status entry to the + log message (or just add it directly to the "Approved changes:" section of + the public STATUS file and let the bot merge it overnight). + + This ensures the next 1.a.x release, 1.a.(c+2), will have the patch applied. + +- Bump SVN_VER_PATCH on the 1.a.x branch, as explained in the public release + rolling documentation. + + The order of the last two steps ensures that any interim revision of the + 1.a.x branch that has SVN_VER_PATCH == 1.a.(c+2) has the patch applied. + +- Tag the release: + + + Checkout a working copy of the 1.a.x branch. Revert all local + changes, and update (back in time) to the the magic revision of + 1.a.c (the same 1.a.c from earlier). + + + Cherry-pick any patches from 1.a branch, these are patches from + the "future" i.e. revisions later than the magic revision. Do not + commit (you can't, since your wc is backdated). + + + When release.py rolled the tarball it left a working copy with all + the tarball changes applied, this includes the patches above but + also other changes, in particular svn_version.h. Either use this + original working copy or reroll to create a another instance of + this working copy. Be aware that the release.py working copy + is sparse. + + + Run 'svn diff' in the release.py working copy to create a total + tarball patch. Use 'svn patch' to apply this to the magic revision + working copy. This will patch svn_version.h to match the tarball + and should report "already applied" for all the other hunks as they + should match the merges from the "future". + + + Tag your magic revision working copy: + + svn cp ./ ^/subversion/tags/1.a.b -m "..."