On Thu, Aug 08, 2013 at 12:51:06PM +0300, Daniel Shahaf wrote: > Ben Reser wrote on Thu, Aug 08, 2013 at 00:58:50 -0700: > > On Wed, Aug 7, 2013 at 3:49 AM, Justin Erenkrantz <jus...@erenkrantz.com> > > wrote: > > > I'm okay with choice 3 - however, the "release a signed .diff" should also > > > include a full release - including whatever normal things we include with > > > a > > > standard release process. If 1.8.(x+1) is *only* available as a diff > > > against 1.8.x, that makes it hard for downstream users (or packagers) > > > until > > > 1.8.(x+2) is released. -- justin > > > > Not having tarballs is a huge problem since our most reliable > > packagers just release the latest version and don't put out patches. > > > > I'm not opposed to this. I didn't suggest it since I remembered there > were objections to "secret tarballs" last time we discussed that option. > > Naturally, if there are packagers in the audience who would not have > a problem with releasing, say, 1.8.3 as "1.8.2 + signed unidiff", please > raise your hand. (Note that 'svn patch' is available on windows to apply > the unidiff.)
I'd expect packagers would just call that "1.8.2 + patch". The assertion that packagers only use unmodified tarball is strange to me. Packagers routinely patch upstream software to make it work on their system or to backport security fixes. But usually the version number of the upstream release which the package is based on is used in the package name. E.g. as an OpenBSD user you'd probably jump from subversion-1.8.2 to subversion-1.8.2p0 which adds just the patch. Or from some 1.8.2pX to some 1.8.2pY (there are packaging changes that might need to be made even if no upstream changes are available). If you're running OpenBSD-current then you might jump from 1.8.2 to 1.8.3 instead. Suse Linux uses similar versioning schemes. So I prefer your suggestion number 2. We always send out patches in pre-notifications, and all trusted packagers can receive those upon request. They can decide to commit just the fix and keep the former upstream version in the package name, or upgrade to the newer fixed release once it is available. Sometimes the former is more appropriate, sometimes the latter (depends on packaging and release policy used by downstream projects such as Linux distros). We should provide both. Note that we already rely on packagers not to commit the patches to their public package source repositories before we announce the vulnerability. I don't think we can devise a process to avoid that issue. We have to trust these folks to do the right thing.
