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 <justin_at_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.
Received on 2013-08-08 12:14:06 CEST