Bug 963835

is this protected mode enable by default?

(In reply to comment #1)
> is this protected mode enable by default?

It is when IE10 runs on Win8 with Metro UI. In other cases, it is not, but then it runs in 32b mode only (see also https://bugzilla.redhat.com/show_bug.cgi?id=918656#c15 ).

Attached dump & associated files of m-r-v crash.

Created attachment 749348 [details]
deps.txt

the dump is from mingw-virt-viewer-0.5.3-25, deps.txt file is attached

I can't reproduce, using win7 x64, IE10.0.9200.16576 against RHEVM3.1 spice.lab.eng.brq and mingw-viewer -0.5.3-25, after enabled EPM and rebooting (2 times, first time didn't save the setting!)

Is this only a win8-IE-metro bug? metro isn't meant to work with plugins/activex.


So another reason to stop using activex (and deploying):

"The new Windows UI browsing experience doesn't support Microsoft ActiveX or any other binary extensibility."

http://msdn.microsoft.com/en-us/library/ie/hh920753%28v=vs.85%29.aspx

(In reply to Marc-Andre Lureau from comment #8)
> I can't reproduce, using win7 x64, IE10.0.9200.16576 against RHEVM3.1
> spice.lab.eng.brq and mingw-viewer -0.5.3-25, after enabled EPM and
> rebooting (2 times, first time didn't save the setting!)

I can't reproduce either against 3.1 but it's 100% reproducible against 3.2, the mingw-virt-viewer version does not matter. That suggests that the issue is in spice-x or in User portal

> 
> Is this only a win8-IE-metro bug? metro isn't meant to work with
> plugins/activex.
> 

It's the same win/ie versions, just UP is different. We could bisect it further by installing newer cabs on 3.1 portal.

> 
> So another reason to stop using activex (and deploying):
> 
> "The new Windows UI browsing experience doesn't support Microsoft ActiveX or
> any other binary extensibility."
> 
> http://msdn.microsoft.com/en-us/library/ie/hh920753%28v=vs.85%29.aspx

Well, there's one big elegant thing on cab/activex that I don't see on it's alternatives without further work: automatic updates of the bits to latest software version with minimal work for corporate systems (allow spicex UUIDs to install automatically without Administrator permission) and with no work needed to upgrade things on user's computers (allowed by PowerUser privileges on XP or UAC prompts from Vista on). The only prerequisite is to keep RHEV-M itself up-to-date.

Mainaining the software up-to-date would mean either developing of yet another updater for spice bits or increase of windows administrator burden for corporate system together with total lack of automatic upgrades on user's personal computers...

(I'm wondering why various free software projects with considerable windows user base didn't join forces on a common updating service - where newly installed package could register it's repository and signing keys and the service could perform updates on it's own...)

(In reply to David Jaša from comment #9)
> Well, there's one big elegant thing on cab/activex that I don't see on it's
> alternatives without further work: automatic updates of the bits to latest
> software version with minimal work for corporate systems (allow spicex UUIDs
> to install automatically without Administrator permission) and with no work
> needed to upgrade things on user's computers (allowed by PowerUser
> privileges on XP or UAC prompts from Vista on). The only prerequisite is to
> keep RHEV-M itself up-to-date.
> 
> Mainaining the software up-to-date would mean either developing of yet
> another updater for spice bits or increase of windows administrator burden
> for corporate system together with total lack of automatic upgrades on
> user's personal computers...
> 
> (I'm wondering why various free software projects with considerable windows
> user base didn't join forces on a common updating service - where newly
> installed package could register it's repository and signing keys and the
> service could perform updates on it's own...)

I suspect Windows admins of big deployment prefers a solution like http://support.microsoft.com/kb/816102 where they can control what gets installed and when. No clue if this comes for free with the msi installer work Marc-André has been doing or if this will need more work.

Automatic updates is just a terribly bad idea.

(In reply to David Jaša from comment #9)
> (In reply to Marc-Andre Lureau from comment #8)
> > I can't reproduce, using win7 x64, IE10.0.9200.16576 against RHEVM3.1
> > spice.lab.eng.brq and mingw-viewer -0.5.3-25, after enabled EPM and
> > rebooting (2 times, first time didn't save the setting!)
> 
> I can't reproduce either against 3.1 but it's 100% reproducible against 3.2,
> the mingw-virt-viewer version does not matter. That suggests that the issue
> is in spice-x or in User portal

I have no access to 3.2 atm, I will try again.

The mingw-virt-viewer-0.5.3-25 install the same activex version as 3.2. So it seems to be an issue with the portal itself... (the spice-x test html page seems to work too)

> > 
> > Is this only a win8-IE-metro bug? metro isn't meant to work with
> > plugins/activex.
> > 
> 
> It's the same win/ie versions, just UP is different. We could bisect it
> further by installing newer cabs on 3.1 portal.

Sorry to ask again, are you using metro UI?

Just tried successfully again rhevm 3.2 instance too.

David, please try to narrow it down, so I can reproduce.

(In reply to Christophe Fergeau from comment #10)
> I suspect Windows admins of big deployment prefers a solution like
> http://support.microsoft.com/kb/816102 where they can control what gets
> installed and when. No clue if this comes for free with the msi installer
> work Marc-André has been doing or if this will need more work.

Last I recall, according to WiX documentation it should. Would be nice if someone upstream could test that :)

(In reply to Christophe Fergeau from comment #10)
...
> I suspect Windows admins of big deployment prefers a solution like
> http://support.microsoft.com/kb/816102 where they can control what gets
> installed and when. No clue if this comes for free with the msi installer
> work Marc-André has been doing or if this will need more work.

.msi package is a prerequisite for it if I understand the docs correctly. The manual work connected with it is there and that's what I meant by extra burden, to perform any upgrade, they have to check for new versions of the software and perform the steps described on the page you linked. What a difference from just running 'rhevm-upgrade' (or even plain 'yum update') on rhev-m machine...

(In reply to Marc-Andre Lureau from comment #11)
> Automatic updates is just a terribly bad idea.

Maybe in an AD-controlled corporate environment, but certainly not universally. Think about clients outside of AD. How would you deliver a security update to clients outside of AD?

(In reply to Marc-Andre Lureau from comment #12)
...
> Sorry to ask again, are you using metro UI?

I'm using Windows 7, so no metro UI.

(In reply to Marc-Andre Lureau from comment #13)
> Just tried successfully again rhevm 3.2 instance too.
> 
> David, please try to narrow it down, so I can reproduce.

Windows 7 x64 client, fully upgraded. Flip EPM on, go to rhevm32 setup, connect to a console. Confirm activex installation, wait for m-r-v window to come up, observe it crash within 5 seconds...

Created attachment 751728 [details]
screenshot

The crash I could reproduce on David machine, seems to be related to smartcard.

the bug is a missing NULL at the end of g_build_filename(), in one of the mingw-libcacard patch. It's an early version, and it doesn't exist upstream. moving to post, ack

crash fix is the good candidate for z -stream

This bug is currently attached to errata RHEA-2013:15512. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to 
minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.

Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:

* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')

Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.

For further details on the Cause, Consequence, Fix, Result format please refer to:

https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes 

Thanks in advance.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-0034.html