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:

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 chris@bedroomcoders.co.uk wrote:

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

On 8 December 2017 6:57:15 pm AEDT, Hans L thehans@gmail.com wrote:

On 8 December 2017 at 00:22, Marius Kintel marius@kintel.net wrote:

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

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

On 12/8/2017 4:58 AM, Jamie Bainbridge wrote:

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.

On 12/8/2017 2:40 PM, Jordan Brown wrote:

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

On 9 December 2017 at 08:40, Jordan Brown openscad@jordan.maileater.net wrote:

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

On 12/10/2017 3:51 PM, Jamie Bainbridge wrote:

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.