On 2/12/07, James Hawkins truiken@gmail.com wrote:
On 2/12/07, richardvoigt@gmail.com richardvoigt@gmail.com wrote:
You advocated that wine aim for working exactly like Windows, no less and no more, rather than deviating in user-configurable ways to enhance the user's control over his own system.
Right. That's the purpose of Wine. You'd know that if you were a developer on this project.
You'll get there a lot faster by contributing to colinux (www.colinux.org) instead.
Maybe while we're at it, wine should have the bug which allows certain software to prevent screen grabs.
I don't know of any apps that depend on this behavior, so that's not likely to happen.
Any DRM-enabled media player... which you would have understood if you looked at my next comment!
No, I think defeating DRM to enable fair use is perfectly reasonable, and there are some bugs which should be fixed. Should wine try to patch remote exploits at the exact same rate as windowsupdate.com?
Since we have completely different code bases, I don't see how we can fix their code in our tree.
You misunderstood me completely, I'm beginning to wonder if you're doing so intentionally.
To maintain "bug for bug compatibility", then when an exploit is discovered, wine won't be able to release a patch until after Microsoft has done so, because to do so earlier would be to implement functionality that doesn't match WIndows, breaking compatibility.
That would be also be required for true bug-for-bug compatibility. After all, someone properly authorized might be using that backdoor to reboot their webfarm remotely -- not!
There are things that are wrong in a theoretical sense (i.e. the Pentium floating-point bug), or misclassification of Unicode characters, which some programs might reasonably depend on. And then there are things that are wrong from a practical engineering perspective, like software taking away the user's choice to not run it, which the mere fact that a program depends on it makes it malware.
Are you a software engineer? From a practical engineering perspective, adding this option adds unnecessary complication to the code base and increases the chances for bugs. This is exactly what
I consider this sort of thing quite necessary, I would implement that function on Windows if it was possible without totally replacing all the security code (processing of Start menu/Programs/Startup and HKLM/Software/.../Run can be turned off, but group policy start items can't be disabled in any way that I'm aware of).
UAC does, and no competent engineer thinks UAC is a good thing, or that it adds any amount of security. This "malware" that you're so
UAC does add security, but the interface is horrid. It's really the same idea as Linux's don't-login-as-root, except that with linux you don't necessarily have to use sudo and type a password for every process you want to run elevated, there's suid, sudo remembers your credentials for a short while, you can open an elevated shell, etc. I think UAC has some of the same capability between signed manifests in place of suid and you can probably run an elevated shell there as well.
afraid of can just write over that registry entry.
I don't run Vista, but my understanding is that you can't permanently approve a particular program to run elevated, the question reappears every single time. Giving the user a per-program "Remember my answer" option improves the user experience so much it's not even comparable.
And I have never advocated for putting this in the registry, my suggestion has always been to store these settings in a file outside the .wine/drive_c jail area that is accessbile via wine's Win32 API.
If this entry defaults to "Always" or "Never", then the users won't even know that the option exists, and that's one more piece of information that we'll have to broadcast and answer questions about.
So the best thing would be to set "Ask" as the installation default, and in addition to the "Yes/No/Always/Never" buttons on the prompt, provide a link to the winecfg page where the default is configured.
Reduced privileges do little or nothing to prevent network abuse (open spam relay and the like).
If you're running executables that are going to add themselves to AutoStart, the fact that they might run again is the least of your concerns.
While I agree 100%, stopping the malware from running itself after a reboot is still a very good thing.
How useful would chroot be if the chrooted programs could set up autostart items or cron jobs without the admin's approval? Not nearly as much as it is now.