CGAL header only

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

CGAL header only

kintel
Administrator
This is mostly a question related to Linux packaging:

Now that CGAL offers a header-only option, could we step away from using a CGAL versions shipping with Linux distros and lock OpenSCAD against a specific CGAL version?
This has the potential of fixing any issues arising from different CGAL version being used depending on what OS/distro people are using.

Technically, we’d need a way of acquiring/bundling the CGAL headers. At build-time, we could get CGAL from a git submodule, for the source tarball we could bundle it.

Thoughts?

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: CGAL header only

codifies
Given that Linux is such a nebulous target, this is defiantly a good idea.

Think about the difference of a LTS (long term support) distribution and
a rolling release, the versions of CGAL could be significant internally
(even if the API is still the same)

It might even help windows self builders who might mistakenly grab the
very latest version of CGAL or sometime later forget to update the CGAL
they're using.


On 07/12/17 14:22, Marius Kintel wrote:

> This is mostly a question related to Linux packaging:
>
> Now that CGAL offers a header-only option, could we step away from using a CGAL versions shipping with Linux distros and lock OpenSCAD against a specific CGAL version?
> This has the potential of fixing any issues arising from different CGAL version being used depending on what OS/distro people are using.
>
> Technically, we’d need a way of acquiring/bundling the CGAL headers. At build-time, we could get CGAL from a git submodule, for the source tarball we could bundle it.
>
> Thoughts?
>
>   -Marius
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: CGAL header only

thehans
Sounds like a great idea to me (from admittedly not the most
packaging-savvy guy).

Hans

On Thu, Dec 7, 2017 at 9:33 AM, Chris Camacho <[hidden email]> wrote:

> Given that Linux is such a nebulous target, this is defiantly a good idea.
>
> Think about the difference of a LTS (long term support) distribution and a
> rolling release, the versions of CGAL could be significant internally (even
> if the API is still the same)
>
> It might even help windows self builders who might mistakenly grab the very
> latest version of CGAL or sometime later forget to update the CGAL they're
> using.
>
>
>
> On 07/12/17 14:22, Marius Kintel wrote:
>>
>> This is mostly a question related to Linux packaging:
>>
>> Now that CGAL offers a header-only option, could we step away from using a
>> CGAL versions shipping with Linux distros and lock OpenSCAD against a
>> specific CGAL version?
>> This has the potential of fixing any issues arising from different CGAL
>> version being used depending on what OS/distro people are using.
>>
>> Technically, we’d need a way of acquiring/bundling the CGAL headers. At
>> build-time, we could get CGAL from a git submodule, for the source tarball
>> we could bundle it.
>>
>> Thoughts?
>>
>>   -Marius
>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: CGAL header only

RobWLakes
And should reduced tendency of developers to pull their hair out??
Cheers, RobW

On 8 December 2017 6:57:15 pm AEDT, Hans L <[hidden email]> wrote:
Sounds like a great idea to me (from admittedly not the most
packaging-savvy guy).

Hans

On Thu, Dec 7, 2017 at 9:33 AM, Chris Camacho <[hidden email]> wrote:
Given that Linux is such a nebulous target, this is defiantly a good idea.

Think about the difference of a LTS (long term support) distribution and a
rolling release, the versions of CGAL could be significant internally (even
if the API is still the same)

It might even help windows self builders who might mistakenly grab the very
latest version of CGAL or sometime later forget to update the CGAL they're
using.



On 07/12/17 14:22, Marius Kintel wrote:

This is mostly a question related to Linux packaging:

Now that CGAL offers a header-only option, could we step away from using a
CGAL versions shipping with Linux distros and lock OpenSCAD against a
specific CGAL version?
This has the potential of fixing any issues arising from different CGAL
version being used depending on what OS/distro people are using.

Technically, we’d need a way of acquiring/bundling the CGAL headers. At
build-time, we could get CGAL from a git submodule, for the source tarball
we could bundle it.

Thoughts?

-Marius




OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Rob W
Lake Tyers Beach,
Victoria, Australia
Reply | Threaded
Open this post in threaded view
|

Re: CGAL header only

Jamie Bainbridge
In reply to this post by kintel
On 8 December 2017 at 00:22, Marius Kintel <[hidden email]> wrote:
> This is mostly a question related to Linux packaging:
>
> Now that CGAL offers a header-only option, could we step away from using a CGAL versions shipping with Linux distros and lock OpenSCAD against a specific CGAL version?
> This has the potential of fixing any issues arising from different CGAL version being used depending on what OS/distro people are using.
>
> Technically, we’d need a way of acquiring/bundling the CGAL headers. At build-time, we could get CGAL from a git submodule, for the source tarball we could bundle it.
>
> Thoughts?

Forget the concept of distro packages altogether and make AppImage the
only supported distribution method on Linux. This way you can package
whatever dependencies you like, and end users have the fantastic
experience of downloading one file which "just works" regardless of
the user's distro.

You're already aware of the GitHub issue about AppImage and the OBS
AppImage work going on.

Jamie

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: CGAL header only

kintel
Administrator
> On Dec 8, 2017, at 7:58 AM, Jamie Bainbridge <[hidden email]> wrote:
>
>
> Forget the concept of distro packages altogether and make AppImage the
> only supported distribution method on Linux.

AppImage is a good idea.
This kind of pushed the problem into how to establish a dev environment, as that’s already a pain point for people building on Linux.
Small note: header-only CGAL would also be beneficial to the (ever changing) MXE build env for Windows, and for Mac builds, but these have much less variation in the wild compared to Linux.

..but yes, if we raise our gazes, header-only fixes won’t cut it for other challenging libs , e.g. OpenCSG.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: CGAL header only

JordanBrown
In reply to this post by Jamie Bainbridge
On 12/8/2017 4:58 AM, Jamie Bainbridge wrote:
Forget the concept of distro packages altogether and make AppImage the only supported distribution method on Linux.

Not that it really applies to OpenSCAD[*], but this style of distribution virtually guarantees that library security bugs will never be fixed in the wild, because it depends on each individual application packager packaging up and releasing updated versions of the libraries.

[*] In theory, it does apply:  users assume that they can download an OpenSCAD model and open and play with it without risk.  OpenSCAD could easily have a bug such that an OpenSCAD program could break out of OpenSCAD and attack the system - say, for instance, there could be a buffer overflow in the handling of the text( ) module.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: CGAL header only

JordanBrown
On 12/8/2017 2:40 PM, Jordan Brown wrote:
[*] In theory, it does apply:  users assume that they can download an OpenSCAD model and open and play with it without risk.  OpenSCAD could easily have a bug such that an OpenSCAD program could break out of OpenSCAD and attack the system - say, for instance, there could be a buffer overflow in the handling of the text( ) module.

It would be mildly surprising if import( ) *doesn't* have such a bug.  It's a pretty rare application that processes binary file formats without introducing at least one such bug, if it hasn't been specifically attacked.  And that is a good example of the problem:  if OpenSCAD uses a library to process, say, PNG files, what happens if that library is found to have a security bug?

Like, say, these 35 security bugs against libpng:  https://www.cvedetails.com/vulnerability-list/vendor_id-7294/Libpng.html


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: CGAL header only

MichaelAtOz
Administrator
In reply to this post by kintel
a. Alan, this got discarded, you need to subscribe to the list*, or use the email you previously
subscribed. (.cymru new??)

b. Copied below for everyone.

MichaelAtOz
Admin

* see
http://forum.openscad.org/Registration-amp-Subscription-Info-The-Forum-amp-the-Mailing-list-working
-hand-in-hand-td21660.html

p.s. You learn something new every day; cymru = Wales (ie in UK)

> -----Original Message-----
> From: Alan Cox [mailto:[hidden email]]
> Sent: Sun, 10 Dec 2017 00:13
> To: Marius Kintel
> Cc: OpenSCAD general discussion
> Subject: Re: [OpenSCAD] CGAL header only
>
> On Thu, 7 Dec 2017 09:22:49 -0500
> Marius Kintel <[hidden email]> wrote:
>
> > This is mostly a question related to Linux packaging:
> >
> > Now that CGAL offers a header-only option, could we step away from using a CGAL versions
> shipping with Linux distros and lock OpenSCAD against a specific CGAL version?
>
> If you want to lose a chunk of your user base.
>
> Most Linux users don't install random packages in funny formats from
> untrusted locations. In business cases it's often possible to install a
> distro package from an approved distro but requires corporate security
> approval for anything else.
>
> And one of the reasons this happens is because random docker and flatpack
> or similar images invariably come with old, insecure libraries and are
> often poorly maintained.
>
> Having something like flatpak or a docker layer as an option is
> definitely a good thing (especially with old distros), but it's never
> going to replace enavling people to create an actual distro shipped
> packages as the ideal case.
>
> Docker may be a better choice because once you've got a docker file you
> can manage the docker container really nicely, including just firing your
> large command line OpenSCAD render at the fastest CPU core you have access
> too wherever it may live.
>
> Alan



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Admin - PM me if you need anything,
or if I've done something stupid...

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: CGAL header only

Jamie Bainbridge
In reply to this post by JordanBrown
On 9 December 2017 at 08:40, Jordan Brown <[hidden email]> wrote:
> On 12/8/2017 4:58 AM, Jamie Bainbridge wrote:
>
>> Forget the concept of distro packages altogether and make AppImage the only
>> supported distribution method on Linux.
>
> Not that it really applies to OpenSCAD[*], but this style of distribution
> virtually guarantees that library security bugs will never be fixed in the
> wild, because it depends on each individual application packager packaging
> up and releasing updated versions of the libraries.

While you are not wrong, this depends on the individual developers
maintaining a specific software package.

If you're suggesting that all OpenSCAD packagers and contributors are
so uncaring as to what's happening in their upstream libraries that
they will never update those libraries, or aren't willing/able to
create an AppImage build system which does update libraries, then your
point is valid and OpenSCAD should always be beholden to distro
libraries. If the opposite is true, then this point does not apply to
OpenSCAD and AppImage is fine to use here.

As Alan said, this happens a lot in container land too. I also shudder
to think how many containers are out there still vulnerable to serious
vulnerabilities. Containers make this problem much more opaque than
AppImage too imo.

But we're not talking about other developers or container deployments,
we're talking about potential AppImage usage within OpenSCAD. One
cannot solve everyone else's problems, one can only be aware of the
problems and avoid them in ones own actions.

If OpenSCAD does AppImage right, there's no problem and the result is
better for everyone.

Jamie

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: CGAL header only

JordanBrown
On 12/10/2017 3:51 PM, Jamie Bainbridge wrote:
If OpenSCAD does AppImage right, there's no problem and the result is better for everyone.

Yes.  In any individual case that's the developers' intent, and in any individual case it might be the way that things work out.

Unfortunately, in some percentage of cases, it *isn't* how it works out.  The development team isn't aware of the upstream library's issue, or is too busy right now, or maybe even doesn't exist any more.  And, similarly unfortunately, there's no way to predict whether *your* project will fall into one of those situations.  I mean no disrespect to the OpenSCAD team, or to any other development team, but stuff happens.  People change jobs, get sick, have kids, or get hit by a bus.  Across a large set of projects, it's inevitable, so if you want to be secure you have to assume that it will happen to you.

Practically, OpenSCAD is probably safe from those issues... not because it won't be vulnerable, but because it simply won't be a big enough target for the bad guys to shoot at.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: CGAL header only

Alan Cox
In reply to this post by Jamie Bainbridge
> they will never update those libraries, or aren't willing/able to
> create an AppImage build system which does update libraries, then your
> point is valid and OpenSCAD should always be beholden to distro
> libraries. If the opposite is true, then this point does not apply to
> OpenSCAD and AppImage is fine to use here.

Yes you can do it right with something like Jenkins and cron jobs
auto-rebuilding and re-posting the image when a trusted source of a new
version of the various pieces appears.

> As Alan said, this happens a lot in container land too. I also shudder
> to think how many containers are out there still vulnerable to serious
> vulnerabilities. Containers make this problem much more opaque than
> AppImage too imo.

The better container folk have I think got a handle on it however.
Firstly they use lightweight virtual machines for security, secondly they
use docker layers so that the only pieces that would be in say an OpenSCAD
container would probably be OpenSCAD and CGAL (and maybe a couple of
other other more problematic C++ libraries). When you run it then it will
get unioned with an up to date ubuntu and run.

The risk for OpenSCAD is also lower than many things because a lot of the
formats it handles through libraries are output only which reduces the
attack surface. Realistically you've got to aim at inputs habitually used
from the internet, and for the most part that means the OpenSCAD parser
and maybe the importers.

> Practically, OpenSCAD is probably safe from those issues... not because
> it won't be vulnerable, but because it simply won't be a big enough
> target for the bad guys to shoot at.

That's unfortunately a rather 1990s viewpoint. OpenSCAD is an interesting
target because people habitually use it to process files directly from
the internet, a successful attack would be likely to obtain things like a
Shapeways account and lots of design files, and because it has folks
using it with addresses from 'interesting' companies whose stuff is worth
stealing.

The 'bad guys' work on economic models of risk not volume. One US power
company account is worth a lot more to the right people than 10,000
random facebook users.

Alan

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org