[pkg-wine-party] Bug#591837: Wine 1.2 packages with wine-gecko

[Michael Gilbert]

On Fri, 20 Aug 2010 08:59:08 +0200, Ove Kaaven wrote:
> Den 20. aug. 2010 07:38, skrev Stephen Kitt:
> > On Fri, Aug 20, 2010 at 07:08:21AM +0200, Ove Kaaven wrote:
> >> Den 19. aug. 2010 23:45, skrev Stephen Kitt:
> >>>> 1. the dependency on wine-gecko really should be dropped for now (and
> >>>> when that package is ready, it should be at maximum a recommends since wine
> >>>> gets by just fine without wine-gecko).  this is especially important if you
> >>>> want to get this into squeeze since no more new packages are going be
> >>>> accepted due to the freeze.
> >>>
> >>> Indeed, I'll remove it for now.
> >>
> >> Wine 1.2 depends on wine-gecko, it's that simple. Packaging without
> >> would be asking for RC bugs, as the result would go against Debian
> >> standards - for example, things like the security implications of
> >> automatically downloading and running untrusted binaries from the
> >> Internet with no sandboxing and no cryptographic verification of
> >> either the binaries themselves or the web server hosting the
> >> binaries.
> >
> > Would it be acceptable in that case to add a hash of the CAB file (as
> > provided by upstream) to the download code, to verify it hasn't been
> > tampered with before installing it?
> 
> I suppose you'd have to ask the people who might otherwise be filing 
> those bugs - probably at least debian-devel. Remember that although you 
> may be able to prevent the most practical avenue of attack by verifying 
> that the downloaded .cab is identical to the known upstream one, for the 
> particularly security-minded there's still the issue that the upstream 
> .cab is, in principle, not trusted, because you can't prove what sources 
> it was built from.
> 
> Even if you get approval, someone'd have to write the verification code. 
> I know where the download happens, but it'll take more than an one-liner 
> to do it, and I don't have the time. And since it's a stopgap solution, 
> I doubt you'd receive much help from upstream.
> 
> > Personally I'm rather in favour of having wine simply depend on
> > wine-gecko, since that avoids the support problems related to Wine not
> > installing wine-gecko when creating a new prefix; but having this
> > dependency reduces the chances of getting Wine 1.2 into Squeeze to
> > zero.  Admittedly that may well be an argument in favour of not
> > getting Wine 1.2 into Squeeze right there - shipping a package with
> > known potential support issues...
> 
> I don't mind much leaving Wine 1.0 in squeeze. For those who want to run 
> Wine 1.2 on squeeze, there'll always be www.backports.org.

i agree.  at this point, the only reasonable solution is to stick with
the old known-to-be-stable wine release.  of course this is bound to
lead to a few complaints about out-of-dateness by distro reviewers.
perhaps the release notes (and/or release announcement) should mention
the decision and logic for doing sticking with 1.0 (and maybe mention
backports)?

i would be interested in helping with the backports package.  i sent a
request to join the pkg-wine alioth project a couple weeks ago.  could
you approve that so i can work in the team?

best wishes,
mike