|
Post by rustleg on Oct 26, 2011 13:12:51 GMT -5
(I'm not sure I want an affirmative answer to this question ) Is it possible to run Internet Explorer using Wine or similar? The reason for asking is that I have been trying to convince a friend to use a live CD for his internet banking but he insists that he wants to run an application supplied by one of the banks. This aggregates his balances from all his other bank accounts - not just at this bank - which shows the balances of all these accounts. It presumably uses some form of scripting within IE which doesn't work in Firefox. I'd rather him face up to a bit of inconvenience for the benefit of security, but it's hard to persuade him. I hope he won't be sorry.
|
|
|
Post by Kevin McAleavey on Oct 28, 2011 2:04:23 GMT -5
(I'm not sure I want an affirmative answer to this question ) Is it possible to run Internet Explorer using Wine or similar? The reason for asking is that I have been trying to convince a friend to use a live CD for his internet banking but he insists that he wants to run an application supplied by one of the banks. This aggregates his balances from all his other bank accounts - not just at this bank - which shows the balances of all these accounts. It presumably uses some form of scripting within IE which doesn't work in Firefox. I'd rather him face up to a bit of inconvenience for the benefit of security, but it's hard to persuade him. I hope he won't be sorry. It's been a while since I've done much with WINE because although it doesn't have all of the security holes of Windows, it has more than enough of them intact to very likely force you to do a reboot and a do-over when something weird happens. We DO include WINE inside KNOS but it's shipped "empty" ... that means that when you run it, you have to allow a fresh install of its "needed stuff" each time you boot KNOS. I'm running from memory here, but I do believe that it installs an ersatz IE along with what else it brings down when it starts, but don't remember exactly what it does for the scripting without having to also install other stuff. We only support WINE primarily as a "yes we can" if a custom build absolutely requires that we support Windows crap. We also provide DOSBOX for those who insist on running MSDOS 3'ish stuff (and it's fabulous!) but you have to load that from a terminal in our public release version. For us, it's all about "yes it can!" But I wouldn't. It's kind of scary though with all the nasties floating around these days that ANY bank would still be forcing the use of "active anything" but then again I guess that's why FDIC is still in business I guess. So I'm not sure of the answer here for your friend, but I'll offer this. If you can send me a copy of whatever that program is (make sure that no banking information is sent along with it) I'll be glad to take a look at it and see if we can get it to run here (chances are it might already be there) and that way I can give you a real answer. Drop me an email at support@knosproject.com along with an attach and I'll be happy to look into it since I'm sure others in the future will require this of us. But if I were your friend, I'd sure be looking for another bank if I *had* to use aiyee (shivers).
|
|
|
Post by pharrisire on Oct 29, 2011 8:45:37 GMT -5
Before KeePassX solved the problem, wine would just automagically kick in to allow KeePass to be used.
|
|
|
Post by Kevin McAleavey on Oct 29, 2011 18:14:49 GMT -5
Before KeePassX solved the problem, wine would just automagically kick in to allow KeePass to be used. Yep ... we rigged KNOS to offer that if you want to open a Windows app. Even more fun is opening the EXE inside the archiver so you can have a look at what's inside the EXE before running it on a Winders box.
|
|
|
Post by Kevin McAleavey on Oct 31, 2011 2:09:27 GMT -5
Before KeePassX solved the problem, wine would just automagically kick in to allow KeePass to be used. Since I'm doing new code on this end now, you raised a "what if?" question for me there with that. As I'm building our KNOS9 64 build machine now, I'm noticing how "expensive" KeePassX is for resources since they've gone from "Mono" (a dotNET clone) to QT4 environment for it as far as all its needed libraries go. Excellent security decision on their part since dotNet (and of course Mono too) is a security nightmare, and I'm glad to be able to remove Mono entirely from KNOS for the "public build" since it gave me the willies even though we sandboxed all hell out of it in a "jail." But I'm noticing that the complete QT4 for that one proggie ONLY is adding an additional 300 megs of code (QT4 is all or nothing, and can't have portions of its libraries "cherry-picked" like we did with Mono for KeePassX) that I'd rather not be eating if the Windows version of it worked well or better than the KNOS-native build. So I'm wondering since KeePassX is an older version of what they're doing in Windows, how did the Windows version work out for you running under WINE in KNOS before we did that? Do you think it would be acceptable given the limited interest in KeePassX among everyone else to throw it back to using WINE with the Windows version instead? Not planning to pull it, but your comment there has me wondering ... did the Windows version work more satisfactorily? Just wondering out loud here as I contemplate how to maximize the efficiency of our next "public build" ... Nokia's QT4 stuff seems to be the "upcoming thing", so we might end up needing to keep it anyway for other stuff when we roll out KNOS9 around the end of the year. Thus the question about KeyPassX without any decision being made on this end about it one way or the other. Just curious since I highly value your opinion and contributions over the years in helping to guide us as to what KNOS offers ... and THANKS for doing that!
|
|
|
Post by pharrisire on Nov 2, 2011 15:15:37 GMT -5
""Since I'm doing new code on this end now, you raised a "what if?" question for me there with that. As I'm building our KNOS9 64 build machine now, I'm noticing how "expensive" KeePassX is for resources since they've gone from "Mono" (a dotNET clone) to QT4 environment for it as far as all its needed libraries go. Excellent security decision on their part since dotNet (and of course Mono too) is a security nightmare, and I'm glad to be able to remove Mono entirely from KNOS for the "public build" since it gave me the willies even though we sandboxed all hell out of it in a "jail."
But I'm noticing that the complete QT4 for that one proggie ONLY is adding an additional 300 megs of code (QT4 is all or nothing, and can't have portions of its libraries "cherry-picked" like we did with Mono for KeePassX) that I'd rather not be eating if the Windows version of it worked well or better than the KNOS-native build. So I'm wondering since KeePassX is an older version of what they're doing in Windows, how did the Windows version work out for you running under WINE in KNOS before we did that?
Do you think it would be acceptable given the limited interest in KeePassX among everyone else to throw it back to using WINE with the Windows version instead? ""
Sure, its OK by me. There is a short delay while it has to download what it needs, but not a problem. KeePassX didn't handle the .kdbx (ver. 2.12) and neither does the Wine, but both KeePassX and Wine handle the .kdb(ver, 1.18) just fine. And if you consider the extra steps of copying the .kdb from 'BigDrive' to the desktop before KeePassX can find it, there isn't all that much difference from waiting for Wine to download what it needs.
Is Anjuta able to 're-make' KeePass so KNOS won't need either KeePassX or Wine?
|
|
|
Post by Kevin McAleavey on Nov 3, 2011 1:22:23 GMT -5
Sure, its OK by me. There is a short delay while it has to download what it needs, but not a problem. KeePassX didn't handle the .kdbx (ver. 2.12) and neither does the Wine, but both KeePassX and Wine handle the .kdb(ver, 1.18) just fine. And if you consider the extra steps of copying the .kdb from 'BigDrive' to the desktop before KeePassX can find it, there isn't all that much difference from waiting for Wine to download what it needs.
Is Anjuta able to 're-make' KeePass so KNOS won't need either KeePassX or Wine?
We've had a confab on our end over this today, and we've decided to keep QT4 despite its "hungry" primarily as a result of Anjuta. QT4 is becoming more popular with time as a coding language and we're hoping once we can get some funding to provide a phone/pad OS in the future and with QT4 gaining popularity, we'll need to keep it for Anjuta as a coding option. Like I said, my question was largely a "what if" and my wonder was whether or not the newer version of KeePass worked under WINE. If not, then we might as well stick with what works. THANKS for the answer there, it helped us decide. As to Anjuta, it's merely a development environment (IDE and tools) which will permit making new code for KNOS. It isn't a "cross development" tool, so it's not able to convert existing code, it can only make NEW code. Somehow I don't suspect that the maintainers of KeePass want to bother with yet another operating system to maintain unless folks can be convinced to buy a LOT of copies of KNOS and make it worth their while.
|
|