Outdated Wine packages in repository that could make Trisquel vulnerable

Well, the wine1.2 and wine1.3 are just transitional packages that install wine1.4, so the only version of wine in Trisquel is 1.4 (and this is the same as in Ubuntu 12.04). Second, when you're running applications in Wine, you're doing so at your own risk, and Trisquel doesn't support these applications (and definitely not proprietary MS applications).

You can take some steps to prevent malware running in Wine from doing any damage by removing the symbolic links to places outside of the .wine directory and never running as superuser (as you already said). Also if you only run .exe's that you trust, I think you should be fine.

It sounds strange that Trisquel does't support applications running on wine, but yet Synaptic Package Manager has wine packages listed.

Even Add/Remove Application has a Q4Wine listed.

Can somebody tell me why these packages, which has often issues of crash of M$ proprietary programs are still maintained? (Please don't feel offended, I am asking this out of curiosity)

I meant that Trisquel doesn't support the software that you run in wine. Of course it supports wine.

There are free programs in Windows, and people also use Wine to test Windows ports of their applications, so it's not just for proprietary programs.

True there's controversy about Wine in the wider GNU/Linux communities, but that primarily stems from uses of it Trisquel won't support and assumes its domestic users are not interested in.

It is deceiving that Wine is used in other distros by domestic users often in an act of sacrificing their software freedom by using proprietary software (as implied by your M$ Update comment). Trisquel assumes all its users want the complete software freedom the distro provides and will not do such things.

Of course, like its upstream distros, Trisquel is not divided into 'editions' for home, small business. 'enterprise' or whatever. The practice is incompatible with the intent of Freedom 0, the right to use software for any purpose. So there's lots of software which domestic users will have little if any use for in the repos. Similarly Wine is something which domestic free software only users will have little use for. For most of them Wine is unnecessary as nearly all free software runs natively under GNU/Linux anyway. The forum has repeatedly given this advice.

There are all sorts of interesting ways to damage or make your Trisquel system vulnerable by using software in the repos ill advisedly. Running Wine is no worse than running telnetd, leaving sshd up after choosing a daft password is just as bad. So there are lots of 'could make Trisquel vulnerable[s].'

Wine is a lot less of a worry in terms of computer pathogens for Trisquel users in particular because free software is not a common vector of such M$ Whinedoze maladies if the widely accepted practice of getting it direct from the developers' website is followed.

As with game machine and retro computer emulators in the repos Wine is there for use with niche or legacy _free_ software. Particularly for Trisquel's business users who often have need for support for their legacy custom software (a type of free software) originally written for M$ Whinedoze.

Something like 70% of all software effort in the world is on businesses' 'in house' aka custom software. Many businesses are in the position that they simply cannot afford to rewrite all their custom software. Given this Wine is a critical component in the migration path for them moving away from proprietary software, Mono is another. The net position after migration, even with Wine's inherited limitations, will be that their systems are more secure.

Also business users will be grateful that the Trisquel LTS release formula guarantees them ~4 years of Wine 1.4 as they won't have to retest their own custom software for compatibility and perhaps modify it as a consequence for the duration of Toutatis. Similarly with Trisquel being an LTS release distro, new business users today will test against the Wine 1.6.2 in Belenos (the current beta) to maximise time between these upgrade costs.

In conclusion, yes, Wine has inherent limitations which introduce additional vulnerabilities. However, those are an acceptable risk to some users when taken in balance with a range of other factors. And for the bulk of Trisquel's other users Wine is not needed and advised against.

So this issue is properly 'by design' but I'm leaving it 'needs more info' for a while in case you need further explanation.

leny,

I have seen some small commercial enterprises in our locality have a multi boot option in their work machine; To run M$ and any other OSs.(Open source or 'Free as in freedom' GNU/Linux)

In case you have not heard this concept before; Multi-booting is an alternate solution to investigate or test a new operating system without switching completely. To add more cream to it, multi-boot allows a new operating system to configure all applications needed, and migrate data before removing the old operating system, if desired.

So commercial users have three options, all having their own risk;

1. Use wine to test or run their legacy software.

2. Use a multi-boot which can have the propritary OS(The Free boot-loader related issues are still a concern, but for the time being lets leave it out)

3.Use a virtual machine which can emulate a computer OS.

After all, its all matter for The big Players(Read the Corporates) to choose which of the above solution is better evil to others, till Free distributions mature to satisfy all their software needs.

You have missed the point that Trisquel's objective is always a complete fully free as in freedom software solution, as in *zero* non-free/proprietary code anywhere. Therefore to us Wine is the only acceptable option among those you list.

Similarly to rephrase the original, using Wine with proprietary/non-free programs is something which we give no consideration. So the issues you raise are not appropriate to Trisquel's specific situation. Non-FSF approved distros are a different matter, but that is for them.

Well, this is our fate; Give the freedom to commercial user to use wine so that he can develop and test some *free* software that can run in *the* proprietary OS as well, so other non-FSF endorsed software players gets it.

Considering the fact that Trisquel serves home Users,educational/research organisations and small enterprises who respect the complete software freedom the distro provides to them and will not sacrifice it by using proprietary software, as leny pointed out, changing the priority for this to be minor, so that the project can focus on other normal and critical issues for the time being.

Why should we care about the possibility of the user running malware? The user can always run malware without Wine.
There's no reason to worry about the security of the programs run in Wine. The only thing that we should care about is the security of Wine itself (which should be ensured by upstream)

Firstly, the presumed security issue is *not*applicable* to running free software under Wine because the additional 'defense in depth' provided by the suggested measures is not necessary for free software use under Wine, ordinary system protections are enough.

Secondly, even if this were a defect, the support for non-Trisquel or non-Trisquelized packages not on the install CD/DVD such as wine is currently referred upstream as legmit rightly points out.

In short I am saying you have not raised any valid, supported problem here.