75 replies to this topic

[littlesat]

Can you help to offer a commit request on our git....?

Weird as soon we started a good discussion here... they make an upgrade there...

[SpaceRat]

It was requested some weeks ago and arn built OpenVPN 2.4.0 back then.
I have been running OpenVPN 2.4.0 on my Quadbox for about the same time ... it was just time to merge

BTW: I wouldn't suggest bumping OpenVPN on PLi 4.0 (Neither did I bump in oe-a 3.4), because it doesn't make much sense to build against an old, vulnerable OpenSSL.

[dolphs]

wow this is quite interesting , have been playing around with help of a member, configuring ovpn2.3 on two AES-NI boards ( in my case two Biostars N3150NH ).

However certainly want to give it a go on my Vu+Uno 4K and ET10000 running ovpn2.4 ( perhaps a static build including proper openssl libs is available for testing purposes ? ) as ideally that could save me additional wattage on both ends ;-)

root@et10000:~# opkg list |grep vpn
openvpn - 2.3.2-r0.0 - A full-featured SSL VPN solution via tun device  A full-featured SSL VPN
openvpn-dev - 2.3.2-r0.0 - A full-featured SSL VPN solution via tun device - Development files  A

currently 2.3.2 only - that seems to be rather outdated as 2.3.14 is the " latest " or preferably " 2.4.0 "

 

thanks

Edited by dolphs, 18 January 2017 - 14:01.

[Pippin]

Great progress, here is the request

https://github.com/o...core/issues/142

 

I still not came around to installing. If can manage I will next week.

[WanWizard]

currently 2.3.2 only - that seems to be rather outdated as 2.3.14 is the " latest " or preferably " 2.4.0 "

 

Same for the current OpenPLi-5 base, it is the standard version in the current OE.

[littlesat]

So this actually means this merge request should not be done on oe-a... our git... but on oe's github..... Then we better can do nothing.... So actually the oe-allance commit is done on the incorrect unstructured place....?

Edited by littlesat, 18 January 2017 - 15:27.

[A.A.]

So this actually means this merge request should not be done on oe-a... our git... but on oe's github..... Then we better can do nothing.... So actually the oe-allance commit is done on the incorrect unstructured place....?

 

Hello,

 

what does mean "then we can better do nothing"?

Instead, send patches to the openembedded mailing list!

 

There is a 2.3.9 recipe already [1].

Please send a patch to meta-networking as documented in the layer itself [2]. Thanks.

 

[1] https://layers.opene...ipes/?q=openvpn

[2] http://cgit.openembe...ing/MAINTAINERS

 

Cheers

 

A.A.

[SpaceRat]

The problem is not openembedded.
They will eventually catch up with OpenVPN 2.4.0 anyways.

The problem is that all E2 images are working with a more or less frozen status of openembedded.

In theory it would be nice if we could just use the current status of openembedded's "master" branch, but sadly an E2 box contains a lot of things that are done in closed source (binary only).
Linux is among the worst, if not the worst of all, OSes in such a scenario.

The only thing that a Linux dev hates more than ease-of-use or Windows is compatibility.
A Linux dev would have multiple sleepless nights if a single code change wouldn't also include 10 API changes, breaking at least 3 other parts of a Linux system.

One of the root causes for Linux' success in constantly staying below 1.5% market share is that $APPA requiring libgif.so.7 will also conflict with libshit.so.9, requiring an upgrade to libdumbshit.so.1, breaking the compatibility of libcrap with libshit, breaking $APPB in consequence and so on.

As an E2 box contains a lot of binary only and often rather legacy parts, certain parts must not be updated if you do not want to break everything.
So 90% of the time spent for development of an E2 image does not get used for E2 but for finding a status of openembedded where 60% of all stuff works and then patching the other 40%.
Once that is done, everybody fears to touch the current oe-core, that's why OpenPLi is using the same oe-core since YEARS.

At the moment, almost all OpenPLi ressources are eaten by finding a new status of oe-core plus zillions of patches, where shit compiles and even works in the end.

[WanWizard]

Once that is done, everybody fears to touch the current oe-core, that's why OpenPLi is using the same oe-core since YEARS

 

I don't know what type of mushrooms you have been eating this evening, but this is complete and uther rubbish. Yes, an OpenPLi version uses a specific version of OE, and we normally don't change OE versions within the same release. But that has nothing to do with the reason you're sucking out of your big thumb here...

 

And what binary-only parts does an OpenPLi image exactly contain? Apart from the manufacturer drivers and perhaps some optional 3rd-party rubbish?

[SpaceRat]

Yes, it is complete bullshit.

And what binary-only parts does an OpenPLi image exactly contain? Apart from the manufacturer drivers and perhaps some optional 3rd-party rubbish?

Enough said.

[WanWizard]

As I wrote: "Yes, an OpenPLi version uses a specific version of OE, and we normally don't change OE versions within the same release."

 

What part of that line isn't clear to you? The current OpenPLi-5 OE:
 Screenshot from 2017-01-18 22-33-58.png   49.06KB   7 downloads

 

And then you clarify that with

 

"As an E2 box contains a lot of binary only and often rather legacy parts, certain parts must not be updated if you do not want to break everything.
So 90% of the time spent for development of an E2 image does not get used for E2 but for finding a status of openembedded where 60% of all stuff works and then patching the other 40%."

 

you actually only mean

 

"the closed source drivers"

 

Which isn't a real bother at all, as long as there is a good relation with the manufacturer. We don't have a lot of issues to get kernel changes made, or kernel modules added.

[SpaceRat]

What part of that line isn't clear to you? The current OpenPLi-5 OE:
Screenshot from 2017-01-18 22-33-58.png

So what?
That's the oe-core you are building now, it would be strange if that was years old already.
But rest assured: Once done, it and its libs will last unchanged for years again.

 

And then you clarify that with
 
"As an E2 box contains a lot of binary only and often rather legacy parts, certain parts must not be updated if you do not want to break everything.
So 90% of the time spent for development of an E2 image does not get used for E2 but for finding a status of openembedded where 60% of all stuff works and then patching the other 40%."
 
you actually only mean
 
"the closed source drivers"
 
Which isn't a real bother at all, as long as there is a good relation with the manufacturer. We don't have a lot of issues to get kernel changes made, or kernel modules added.

... so good, that you just keep out some of the parts that won't work
I have to agree, "We don't support Kodi" is easier than fighting with the consequences of having a binary only Kodi with dependencies on gstreamer 0.10.

Don't get me wrong, this is nothing against OpenPLi. Any E2 image is confronted with the same problems.
You just can't deny the facts.

Everybody who has ever given Linux a try on a desktop system where some or even just one component was only supported through binary only drivers knows how much you are in deep shit then.

[WanWizard]

I am so happy that there is finally someone that knows it all! What would we all do without you?

 

Nobody is forcing you to spend any time on a platform you seems to hate very much.

 

If I were you, I would quit with the E2 platform immediately, and move on to making Visual Basic apps. On Windows, where everything is binary, and where the DLL hell is a complete nightmare, if only because the OS will not warn you for potential incompatibilities.

[A.A.]

Well, I dug a bit in the repository and there are indeed some relics: please, try to catch up with actual oe-core status for your dev work.

 

That said, OpenVPN has a dependency on openssl and the one carried here is very old (0.9.8x) while the version in oe-core master is 1.02j.

 

The soname of libcrypto changed in the meantime....

See here https://abi-laborato...meline/openssl/

 

So this change really needs to be tested properly.

 

Regards

A.A.

[littlesat]

Just my 2 cents...

highest release numbers != stability

[SpaceRat]

OpenPLi (As well as oe-a images) come with multiple versions of OpenSSL.
In oe-a 3.4 (For example OpenATV 5.3) we have OpenSSL 1.0.2g and in oe-a 4.0 (For example OpenATV 6.0) we have OpenSSL 1.0.2j.
In both cases there is also a fake OpenSSL 0.9.7/0.9.8 for backwards compatibility.

OpenPLi 4.0 should be similar, although it's an OpenSSL 1.0.1, afair.

Updating OpenSSL in openembedded is a real nightmare, I'm currently doing that in oe-a 3.4
There are zillions of other packages depending on OpenSSL and as - as I already said - Linux devs hate API compatibility, some exports have even changed in between OpenSSL 1.0.2g and 1.0.2j (That's just three sub-sub-subrevisions!).
Dependencies are almost circular, libcrypto, py-crypto, python-cryptography, and so on.
Once you bump OpenSSL, you have to patch some of the others, meaning you also have to bump them ...

[dolphs]

not sure if OpenPLi-5.0 carries 1.02 but to be honest dont have a bitbake master anymore so Im stuck to nightly builds, eg openATV-6.0 is available for ET10000.

Assume building static libs in the mipsel bin would be impossible for OpenPLI-4.0 to make things work? ( just a brain fart from an mid/low experienced end user )

[SpaceRat]

OpenATV 6.0 will not get updates to OpenSSL 1.0.2j either ... one day people will find security bugs in OpenSSL 1.0.2j as well and as nobody - besides me - has security in mind when it comes to E2 development, most likely nobody will care.
I guess OpenPLi 5.0 will also get OpenSSL 1.0.2j ... but it will most likely stay with that version for a long time as well.

About static:
One can build a lot of stuff statically, that means integrating the libs into the binary.
It's in fact a way out of lib hell, but a bad one.

While OpenVPN 2.4.0 statically linked against OpenSSL 1.0.2j would be secure from what we know now, it won't benefit if anyone upgraded OpenSSL to 1.0.2k, l, m ... whatever, if security bugs in j would be found.
It would stay with j forever.
Dynamically linked binaries benefit from upgraded libs, as long as they stay API compatible (and they break, as soon as any libs they are linked against get non-API-compatible upgrades, which is the rule and not the exception under Linux).

[blzr]

not sure if OpenPLi-5.0 carries 1.02

 

there's openssl 1.0.2j in openpli5

[A.A.]

It has been painful but the update has been done in OpenEmbedded: it took months and the older releases have been patched as well.

 

About latest 1.1 versions, the plans were to focus on the 1.0.2 LTS.

Maybe the next Yocto 2.3 will introduce 1.1.

 

A.A.

 

[1] http://lists.openemb...ber/127315.html