Bugzilla Bug 118101

It's not April the first, so I take this for real: 
http://blogs.zdnet.com/Ou/index.php?p=146

Created an attachment (id=76431) [edit]
upstream patch for wmf exploit

Patch already checked into WineHQ's cvs.

http://cvs.winehq.org/cvsweb/wine/dlls/gdi/metafile.c

Created an attachment (id=76432) [edit]
wine-0.9.5 ebuild bumped to -r1 applying upstream fix

Updated wine-0.9.5 ebuild to include the upstream fix.  Applied cleanly,
building now and I'm not expecting any problems so submiting ebuild.

ok, waiting for an ebuild that is ready to be marked stable (ie. approved by
the wine herd and if possible, commited to portage)

The version numbering issue blocks this, since users won't get the fixed Wine
version. There's also the question, if WineX/Cedega/Transgaming stuff is
affected, too.

mhh, maybe backport the fixes and makes a revbump of the 2005XXXX ebuilds as
workaround for the version number issue? I can't check cedega/transgaming and
so on, because i don't own a copy, so i guess wine herd has to find that out.

we dont maintain cedega, that is all handled upstream

ive added the patch to all ebuilds and moved wine-20050930 to stable

as for unstable, i dont really see the big deal with waiting for a 0.9.6
release to pushout the version bump

(In reply to comment #6)
> we dont maintain cedega, that is all handled upstream

We do care for it by hard masking the vulnerable ebuilds, when upstream doesn't
provide an update in an acceptable amount of time.

ready for glsa

*** Bug 118373 has been marked as a duplicate of this bug. ***

the patch is applied to ebuilds without a rev.bump, this results in glsa-check
not being able to detect if a system is vulnerable, by all means don't be
offended, but there is a lot of noise on the dev.list about enterprise gentoo,
first must be  sure that users can rely on glsa's and related tools for no less
then 100%, if it isn't standard procedure that security fixes are rev.bumped
then enterprise gentoo will never be a reality, changing glsa-check to be able
to detect if a system is vulnerable without depending on ebuild-versions is off
course also a posibility.

All the stable versions were rev-bumped, unstables are fixed but as you can see
in comment #7, we're waiting for a new upstream release. SpanKY (or somebody
else) could you commit a simple rev-bump of the latest unstable so everybody is
happy? (Btw, i'm not payed for this, so i dont care too much about enterprise
gentoo)

i'll revbump if a new wine release isnt made along their normal timeframe

GLSA 200601-09 is out.

I just checked my system with glsa-check and GLSA-200601-09 is wrong.

a) all versions of wine-0.9* have the wmf-patch included, but are marked as
vulnerable in the GLSA
b) the wine-20050930 is marked as not vulnerable, but does NOT contain the
patch
(The commit
http://www.gentoo.org/cgi-bin/viewcvs.cgi/app-emulation/wine/wine-20050930.ebuild?r1=1.7&r2=1.8
has the comment 'Add upstream patch for WMF exploit #118101', but only marks
this ebuild stable without adding the epatch line!)

Thx for the report Torsten.

Back to ebuild, vapier please apply patch.

@ a) If patches are are applied to older ebuilds without rev-bumping them,
installs from before the update are still vulnerable. 

hmm, must have changed all of the 200x on the remote test box and forgot to
commit local versions

200* are all now -*
0.9.x are all now stable

stable users will be upgraded to 0.9.5 now

ready for errata

>> I just checked my system with glsa-check and GLSA-200601-09 is wrong.

>>a) all versions of wine-0.9* have the wmf-patch included, but are marked as
vulnerable in the GLSA
>>b) the wine-20050930 is marked as not vulnerable, but does NOT contain the
patch

OK, that is pretty slack work for Gentoo security team just banging out the
usual comment "please update to most recent version" without even checking what
verson they were advising people to use.

But now this is a security issue HOW ABOUT someone actually dealing with the
version nonsense in wine. This 20050930>0.9.x thing has been a bug in portage
for six wine versions now. 

I posted it in October. Reposted to it twice since then. 

The reason it was not dealt with correctly was probably that it was marked
FIXED when the fix was not to fix it. :?

Maybe now would be a good time to get half of gentooland past 20050930.

regards.

> But now this is a security issue HOW ABOUT someone actually dealing with the
> version nonsense in wine. This 20050930>0.9.x thing has been a bug in portage
> for six wine versions now. 

hey jackass why dont you read what has changed

> Maybe now would be a good time to get half of gentooland past 20050930.

already done, why dont you sync up your tree and check the facts before
complaining

(In reply to comment #20)
> > But now this is a security issue HOW ABOUT someone actually dealing with the
> > version nonsense in wine. This 20050930>0.9.x thing has been a bug in portage
> > for six wine versions now. 
> 
> hey jackass why dont you read what has changed
> 
> > Maybe now would be a good time to get half of gentooland past 20050930.
> 
> already done, why dont you sync up your tree and check the facts before
> complaining
> 

yeah right dickhead, if you want to get really grown up about this, you made a
change to gentoo cvs six hours ago. [Sat Jan 14 18:39:32 2006 UTC] So how about
giving it time to get to the mirrors before throwing insults.

According to my system my last sycn was 18:50:01 CET , so I should not even be
thinking of loading the mirrors again so soon.

If my system did not pick up the changes it's probably because you forgot to
commit them.


It took you four friggin months to move on this and now you're getting smart
because I dont sync 4 times a day. 



kind regards, jackass.


Let's drop the insults now ,eh?

the reason for my pissyness was how you so offhandly refer to the security team

this isnt their fault, it was mine

and really i could care less about the time frame of the wine stuff, i sat on
it because any solution to the issue sucked

(In reply to comment #22)
> the reason for my pissyness was how you so offhandly refer to the security team
> 
> this isnt their fault, it was mine
> 
> and really i could care less about the time frame of the wine stuff, i sat on
> it because any solution to the issue sucked
> 
Thanks, I think the calmer approach is better.

I'm not sure this is the most suitable place to go into the details of the
security post but I think they could have been more rigourous in serveral
respects, putting aside your mistake.

However I dont believe that the earlier outburst was on their behalf , people
usually react like that when they feel themselves critisised not others.

It seems in keeping with your ingenuous attitude I have seen before, you slip a
mod through then start sounding off at people hoping no-one will notice the
timing. I recall a very similar instance with the reiser4progs ebuild.

That aside, I give you credit for fairly accepting your mistake on this one and
for coming back with a more reasonable tone. I admit I was expecting another
flame, beg your pardon.

I accept that in view of the glsa issue you had to do the quickest thing that
did not require too much checking but I think a better solution could/can be
found for wine. Wine can be very fickle and the older versions are quite often
needed.

Best regards.

0.9.5-r1 in portage to push out the patch changes

crossover-office-*-5.0.0 is also effected, a fix was issued with 5.0.1.

http://crossover.codeweavers.com/pipermail/announce/2006-January/000031.html

BTW, regarding cedega, since portage doesn't carry the cedegea "engine", only
the wrapper (the -small package), the upgrade is up to the users to update
their engine.

crossover office cannot be upgraded unless someone gives me the file
name/size/md5 information as i have no access to said files

just mailed codeweavers for the info, but also got the md5sum/size from
#crossover on freenode:

MD5 96bea3142fd096db88186f7233c5d43c install-crossover-standard-5.0.1.sh
16160351

MD5 847d4a3d7cb23d4931fc5e04ea243f53 install-crossover-pro-5.0.1.sh 16177282

Crossover office will be handled in bug #119107

thanks, added 5.0.1 to portage

ERRATA issued. Thx for the notification.