anyone had any luck with plugin stuf yet? :)

[CardBoardBoxProcessor]

well anyone? I think the plugin loader needs it\'s own tutorials and forum thread. lets go

also, Kosmos parts pack could sue a few things. if anyone who is able to make DLL custom parts wants to help make the pack have some better quality let me know i will tell you what i could use it would be most great of you.

and better yet I will be more than happy to make models for stuff you want made a nice trade off.

[skyline131313]

Nothing on that end has been released yet as far as I know.

[r4m0n]

Working on an autopilot, but until the distribution guidelines get official I can\'t post anything.

[N3X15]

I\'m waiting on Squad to approve some preliminary distribution guidelines I threw together as a stopgap so we don\'t have people handing out DLLs that can damage stuff or steal private info. They\'re busy as hell with bugfixes and store problems, and there\'s probably going to be some back-and-forth as the posting rules get hammered into something safe and agreeable to all parties, so it may be a while. Everyone\'s working as best they can to get this stuff to you as soon as they can.

Once it\'s done, we\'ll let you know.

[CardBoardBoxProcessor]

ah I see.

Well Kosmos parts pack could sue a few things. if anyone who is able to make DLL custom parts wants to help make the pack have some better quality let me know i will tell you what i could use it would be most great of you.

and better yet I will be more than happy to make models for stuff you want made a nice trade off.

[Ydoow]

Working on an autopilot, but until the distribution guidelines get official I can\'t post anything.

Don\'t make it too easy D:

[CardBoardBoxProcessor]

I agree auto piloet is sort of... eh...

[clone95]

Hey, even the earliest spaceflights had guidance computers. Apollo had a full-on program based guidance computer.

Don\'t knock the autopilot.

[trbinsc]

Only autopilot I would use would be for orbital maneuvering to orbiting targets and a Munar landing assist.

Edit: And maybe a precision deorbiter.

[Ydoow]

I would want autopilot for when I\'m running two missions at once.

Say I want this ship A to go to the Mun and rendezvous with ship B.

However ship B is still on the Munar surface.

I would setup ship A on a trans-Munar injection path and then tell the auto pilot 'Bro, burn this ship into a stable Munar Orbit once it transfer\'s SOIs'

Then I\'d leave and go play on Ship B and get that into the desired Orbit.

That\'s the only time I can see me using auto-pilot.

It would be amazing.

I\'d also really like an ASAS/SAS module that will hold me to apo/periapsis. I managed to 'dock' today and discovered how incredibly hard it was to multitask between judging relative speeds between crafts, checking the orbital path, and maintaining an apo/peri orientation for effective RCS burns.

My mind was spinning for the first few minutes ???

[thorfinn]

I\'m waiting on Squad to approve some preliminary distribution guidelines I threw together as a stopgap so we don\'t have people handing out DLLs that can damage stuff or steal private info.

Is there a safe way to identify (and simply forbid) any file I/O or network operation in the CIL bytecode?

With these out of the way, you\'d need something like a buffer overflow to damage the user\'s machine: doing privilege escalation attacks from within an interpreter should be hard... (but hey, maybe I\'m all wrong, that\'s why I\'m asking.)

[N3X15]

Is there a safe way to identify (and simply forbid) any file I/O or network operation in the CIL bytecode?

With these out of the way, you\'d need something like a buffer overflow to damage the user\'s machine: doing privilege escalation attacks from within an interpreter should be hard... (but hey, maybe I\'m all wrong, that\'s why I\'m asking.)

The best option would probably be to make a wrapper around System.IO and forbid System.IO, System.Process, and similar from even being loaded (by examining the bytecode for example), but I\'m not sure how easy that would be. In Java it\'s a matter of just tossing together a classloader and using reflection to examine the code before it\'s loaded, but IL requires CECIL for proper analysis, and I\'d rather not add in more dependencies. I could probably use a string search for references to forbidden classes, too.

Even then, any automated security measure can be defeated. Hell, even with a completely custom language with locked down commands, there\'s always ways to introduce denial of service vectors and ways to introduce shellcode to the environment. Right now, with available resources and the current state of things, this is the best course of action. I\'ll do some research into sandboxing Mono/.NET code, but even then we\'d still need the rules I submitted for approval and people with sharp eyes.

[r4m0n]

The best option would probably be to make a wrapper around System.IO and forbid System.IO, System.Process, and similar from even being loaded (by examining the bytecode for example), but I\'m not sure how easy that would be. In Java it\'s a matter of just tossing together a classloader and using reflection to examine the code before it\'s loaded, but IL requires CECIL for proper analysis, and I\'d rather not add in more dependencies. I could probably use a string search for references to forbidden classes, too.

Even then, any automated security measure can be defeated. Hell, even with a completely custom language with locked down commands, there\'s always ways to introduce denial of service vectors and ways to introduce shellcode to the environment. Right now, with available resources and the current state of things, this is the best course of action. I\'ll do some research into sandboxing Mono/.NET code, but even then we\'d still need the rules I submitted for approval and people with sharp eyes.

I guess it must come down to peer review, and maybe get the DLLs compiled by some trusted party or automatically.

People will still be able to get mods directly, but at their own risk... You could use code signing to allow only some mods to run, but I think that would restrict things too much.

[swamismurf]

I support peer-review and signing, and having a central location to find trusted modules.

[meeper]

Unrelated to the issue of trusted distribution: has anyone had any luck spawning new parts from within an inherited class yet? I was half expecting some sort of a factory pattern, but it appears we\'ll have to do it manually.

[drewmacrae]

I\'m not sure blocking IO is the best idea. I\'d like to see flight data recorders so we could do 'science,' and those would require the right to do output to some sort of file. That said, I think autopilots and flight data recorders give a novel opportunity to make custom parts that maintain the balance of the game. (In my mind, orbits, stock mun landings etc are just hard enough) of course auto pilots begin to throw that balance a bit as well but tuning them is a challenge itself.

Could someone who\'s worked with the factory post some sort of tutorial, I\'d love to build my own DLLs and I\'m fairly certian that a tutorial wouldn\'t create a risk or require the sharing of licensed information.

In terms of developing an ecosystem, I think swamismurf is right, but the installation of custom parts has been difficult, and sharing source with a community that is comfortable with the syntax and the compiler seems like a good basis for the community.

[N3X15]

I was saying I\'d put a wrapper around System.IO (so we can ensure IO is limited to the KSP folder), and then forbid access to System.IO itself.

Again, I haven\'t heard back from Squad, but we need their go-ahead signal before we can post plugins.

[aphazael]

I guess it must come down to peer review, and maybe get the DLLs compiled by some trusted party or automatically.

The most attractive solution to me would be some sort of compile-at-loadtime thing, that way we all get to look at the source for the code we\'re running on our machines. I\'m not at all comfortable linking .dlls that come from some dude on the internet.

I\'m not sure blocking IO is the best idea.

I agree. I think that a) it won\'t be 100% effective, and it would limit the legitimate ways that people could use the system. I myself would like to be able to pipe the camera data out to allow for dual-screen awesomeness

[thorfinn]

I was saying I\'d put a wrapper around System.IO (so we can ensure IO is limited to the KSP folder), and then forbid access to System.IO itself.

Right: locking down the general-purpose I/O, and giving a KSP-mediated interface to some kind of data store (be it files in a single folder, or some database).

The same for network I/O: Harv says he wants to add OSC connectivity to KSP, mod parts could use OSC through the main program and so communicate with the external world without the risks of allowing direct net access. (Also, if Harv wirtes the net code once and for all, it\'s less work for the modmakers )