To what extend could linux binary emulation when enabled weaken OpenBSD security ?

There are two different parts to your question.

The first involves the Linux emulation layer itself. This is written by OpenBSD developers which goes through the same commit process as any other piece of code checked into CVS.

Because the Linux filesystem layout is different from OpenBSD's, the emulation layer will not be able to fully mimic the Linux environment. Study hier(7) on both platforms to see the differences.

The real question is how much is emulation tested. I cannot answer this question. I do not know its limitations.

In recent years, keeping the Linux emulation layer up to date hasn't been as important as it may have been 5+ years ago now that more applications are available natively in the packages/ports system, so support of newer Linux kernel calls in the emulation layer hasn't stayed in synch with more recent releases of the Linux kernel. However, I have seen a number of CVS check-in's into OpenBSD's src tree before 5.2 was tagged showing an effort to keep the emulation layer current.

Don't expect emulation layers to be perfect. They aren't. Bugs can & will exist for several different reasons. Some Linux binaries will run on OpenBSD fine. Others won't. To find out whether any particular Linux binary will run under emulation, try it yourself. Studying compat_linux(8) is a start.

In the end, if you want perfect Linux emulation, run your Linux application on Linux.

Secondly, how well the application has been vetted is a question which has to be answered on an individual basis. You will need to ascertain this yourself.

In comparison, third-party applications available officially in the OpenBSD ports tree are not as vetted as the base system itself, so you can equally question the trustworthiness of native applications as well.

In general when it comes to third-party applications, determine whether a native port is available in the ports tree. If one is, use it as the maintainer should have resolved all library & filesystem differences. If not, try the emulation layer if a Linux binary can be found. OpenBSD's emulation layer may or may not be sufficient for the application's needs.

Thank you very much !!
I hope this not again a thread hijacking recurrence :-)
* Opera as emulated on OpenBSD 5.2 bears the 5.1 bug too : Abort trap . So I always do a make reinstall before reusing it ater reboot.
* Opera as emulated on NetBSD 6.0_BETA2 (GENERIC) : a bit faster and bug-free ..
$ opera --version for NetBSD :

Code:

Opera 11.62 Build 1347 for Linux i386.

Does this occur because of a certain inherent OpenBSD security feature ?
Or is it because the OpenBSD Team are not putting effort to this particular port because it's a closed source and contradicts the followed policy ?
Or maybe some reason ??

Because the new information being presented which takes the tenor of discussion in a different direction, yes, daemonfowl, you have hijacked discussion yet again.

This would have been good information to include in your original message. Being upfront with the fundamental problem you wish to discuss helps you & helps anyone who might respond frame their response(s).

Sir ocicat , believe me , I'm developping a Thread-Hijacking Phobia !
Here is what I did :
* I asked about binary emulation under OpenBSD and whether/how it might be a security risk.
* I brought an example I have in front of me : Opera.
* I added info about it on both OpenBSD (security-aware) & NetBSD (portability-driven)
to conclude maybe that : security as tightened on OpenBSD may be a cause that emulated software don't run as expected while on NetBSD it just runs .. maybe not .. you help me discover it :-)

Opera is a closed-source application. It is available only as a port as its commercial license does not permit redistribution in other packages. The port does not "make" anything, it merely repackages the binary files.

Between 5.1 and 5.2, there was a revision bump of the OpenBSD port due to underlying changes for gtk-update-icon-cache. This changes the package signature, and therefore the underlying dependencies would be refreshed on reinstall ("make print-run-depends" will give you a list). The Opera binary remained unchanged; OpenBSD has nothing to do with that at all.