Expanding App::Link to Cloud storage

[vejmarie]

Hi,

I do have plan to extend App::Link to Cloud storage, allowing the capacity to link to an element which is not stored locally but remotely. My intend is to create a github like approach with the https://github/com/CADCloud project. You can see a live rendering of the "service" here https://justyour.parts. This is just a work in progress, but I am closed to be able to support fork operation from project, and the server side is using extensively object storage, which is pretty well suitable with FreeCAD, and allow server side data processing.
Everything is open, public and under a very relaxed licensed (MIT). I discussed about this project with @sliptonic and @yorik at Fosdem, and I really believe we shall continue to move forward.

The App::Link is a great enhancement to build potential assembly / design in a collaborative way. My challenge now is to adapt the App::Link if everybody agrees (I know sliptonic is waiting for that !). I have identified a couple of modifications required. Right now App::Link is relying on the fact that linked objects are seating into a locally stored Document, which is not the case if using a Cloud storage (it is remote, but still open as an active Document into the running freecad instance). I have 2 options either adapt the filename of the document to a potential uri format, or if not possible add to the Document object, a status which allow me to keep track of the fact if it is local or remote Document and based on this status route open request to the Cloud module, as well as write request.

I am wondering also if we had a read-only mode to a document ? I mean could we lock a document which has been open to prohibit potential modification ? As a first step it could help me.

CADCloud is going to be extend with a fork capability (same impact than on github). The Pull Request is going to be super tricky, but I am not there yet. My initial goal is to have a free, open database of native freeCAD designs, which could be reused, easily and directly from FreeCAD. Hope you will enjoy that appraoch. Let me know your thoughts and guidance !

vejmarie

[apeltauer]

[M4x]

Sounds exciting! Reminds me a litte bit of KiCAD.

[vocx]

... Right now App::Link is relying on the fact that linked objects are seating into a locally stored Document, which is not the case if using a Cloud storage (it is remote, but still open as an active Document into the running freecad instance). I have 2 options either adapt the filename of the document to a potential uri format, or if not possible add to the Document object, a status which allow me to keep track of the fact if it is local or remote Document and based on this status route open request to the Cloud module, as well as write request.
...

ping

[Zolko]

Right now App::Link is relying on the fact that linked objects are seating into a locally stored Document, which is not the case if using a Cloud storage

We're using OwnCloud at work and it's actually a local sync to a remote repository, therefore everything is local.

Running a CAD system directly from remote files is something that we had tried before, and stopped right away. It doesn't work (network down, access rights, corrupted files, temporary files...). It's a nightmare, think twice before wasting your time. And if anything, there is Samba or NFS, not sure why you would want a "cloud".

I am wondering also if we had a read-only mode to a document ?

that would be great, yes. Absolutely, yes. Today, when I set a file to read-only in the file-manager, FreeCAD still opens-it read-write.

[apeltauer]

Running a CAD system directly from remote files is something that we had tried before, and stopped right away. It doesn't work (network down, access rights, corrupted files, temporary files...). It's a nightmare, think twice before wasting your time. And if anything, there is Samba or NFS, not sure why you would want a "cloud".

I think this is not correct
Having CAD files handled by something like git is tricky, but the "cloud" jean-marie had developed is the right approach to collaborate with CAD files, i think.
Give it a try https://justyour.parts/

[yorik]

Great prospects @vejmarie!

My own inner feeling would be more like @Zolko, I'd tend to copy everything locally before using it, but it's probably much more a question of how things are designed, to carefully prevent and work around network failures... And yeah, it interested me a lot too that app::links are designed to work with urls. I'd be really interested in seeing that at work in real life...

[vejmarie]

Great prospects @vejmarie!

My own inner feeling would be more like @Zolko, I'd tend to copy everything locally before using it, but it's probably much more a question of how things are designed, to carefully prevent and work around network failures... And yeah, it interested me a lot too that app::links are designed to work with urls. I'd be really interested in seeing that at work in real life...

Hey, I got a prototype which works. It does requires some slight modification into the App::Links backend, but this is just amazing to see it live on my machine. I didn't thought I could make work that proto in 3 days.
I still have a few patches to do, but it will definitely works before end of summer, probably even before end of july !

[aapo]

Hey, I got a prototype which works. It does requires some slight modification into the App::Links backend, but this is just amazing to see it live on my machine. I didn't thought I could make work that proto in 3 days.
I still have a few patches to do, but it will definitely works before end of summer, probably even before end of july !

That is a great technological achievement, and I think it opens up a realm of new possibilities, congrats!

However, I'm a bit worried that if this is going to be added to the FreeCAD master, it opens up one particular can of worms: Using this technology, it will be really easy to craft malicious .FCStd files, that will download payload from the internet. FreeCAD would become, in essence, a web browser; and I'm pretty sure that at least the current FreeCAD codebase is not meticuously hardened against intentional buffer overruns. It would be a bummer to open a (local) .FCStd file, and find out that some malware hidden inside an App::Links target has overrun your machine.

Maybe keep a list of user-allowed internet link targets, and ask the user everytime a new domain is introduced?

[vejmarie]

Hey, I got a prototype which works. It does requires some slight modification into the App::Links backend, but this is just amazing to see it live on my machine. I didn't thought I could make work that proto in 3 days.
I still have a few patches to do, but it will definitely works before end of summer, probably even before end of july !

That is a great technological achievement, and I think it opens up a realm of new possibilities, congrats!

However, I'm a bit worried that if this is going to be added to the FreeCAD master, it opens up one particular can of worms: Using this technology, it will be really easy to craft malicious .FCStd files, that will download payload from the internet. FreeCAD would become, in essence, a web browser; and I'm pretty sure that at least the current FreeCAD codebase is not meticuously hardened against intentional buffer overruns. It would be a bummer to open a (local) .FCStd file, and find out that some malware hidden inside an App::Links target has overrun your machine.

Maybe keep a list of user-allowed internet link targets, and ask the user everytime a new domain is introduced?

Hi Aapo,

That is an interesting abstract. I have to admit that I didn't really took care about that issue for now (still a lot of work to build the stack), but it might be fun to understand how to hack a machine through FreeCAD. I do work on other open source projects where security features are at the heart of them (linuxboot, which is an open "BIOS" implementations for example). I will have a look to the potential exposure we might have. I do think it is low for the moment, as FreeCAD is able to load/store document through the s3 protocol, which is a signed protocol (user needs an account with credential and every requests are signed, so man in the middle attack will be tough, especially since I switched on SHA256 signature (was using SHA1 as default)). I don't think that you can execute code from an FCstd file or that this file contains code(bunch of xml and brep). There is still the macro which is python executed code, but I do not support import/export of them on the s3 infrastructure (yet perhaps).
So roughly your current exposure with the web storage, is about the same than downloading a FreeCAD model from another user and opening it up on your machine. What is true is that if the feature is used at scale, more potential mallicious people might be interested to have a look at it. I am not convinced that today a lot of FreeCAD users share back and forward their models. But that is also my goal, creating an active community of model contributors to avoid redrawing an existing part.

So my security strategy is based on the fact, that the communication channel is secured and signed. Then I rely on FreeCAD capability to properly interpret its own files.

As of now to activate the feature you need to turn on a compiler switch (-DBUILD_CLOUD=1). If your build doesn't have it, you won't get it. As I am touching the core of FreeCAD it is tough to make it as a module, some stuff really needs to be into the core.

SNAP build, and my MacOS build have it turned on. SNAP has the benefit to be sandboxed into a container like approach. About the same thing on Mac, so this is reducing potential threat.

vejmarie