Auto-Mounted Pnd Files?


Yeah, but there was only ever one bricking program and it quickly became blocked by all of the DLDI-patchers.
For those not in the DS-Scene:
DLDI is a very clever standard that, when followed, allows a developer to produce a single binary which can then be patched or re-patched with a byte or two of data in a block reserved for DLDI, which takes only a quarter of a second and needs to be done just once, to run on any flashcart. It has been universally adopted, is done by all flashcarts themselves now and a patched binary can be re-patched to run on another cart without issues.

DLDI is brilliant. It's like PND files for the DS- universal and community-driven!

Now, where was I...
Oh yeah! Any bricking program will quickly be shunned by the community.
Plus the Pandora has actually been designed to be unbrick-able (multiple boot-loaders), unlike the DS, which was never designed to run un-authorized code.
 
More practicfal would be an automount program that crashes, eats up all the CPU, overlays libc with libpng or somethign and kills your boot :) Not a big deal if you didn't bugger up your NAND and can just pop out the SD and reboot, but still.

Theres also the question of.. if you flag a pnd as automount.. does it moutn when the SD inserts, or only when you boot fresh? And any rules ofr how to un-mount the automounts? ie: normal pnd mounts and unmounts around the invocation, but if you want a shared-libn pack of DB or somethign, you want it to persist across other applications, but you may want a way to stop it without sending a SIGKILL..

I shoudl probably write up my thoughts and approach so people could debate it a bit, but I rather figured to do that after 1.0 ships; I mean, we're busy enough right now :)

jeff
 
If you set problems like this loose on the community now, some clever programmer might grab the libPND git and hack up a solution for you.

A rather simple solution to the autorun problem would be flag the PND as containing an autorun script, ask for permission to run the script when the PND is detected the first time and add the MD5 checksum of the PND to a whitelist if the user says go for it. The MD5 is handy because if the PND changes it will ask the user again, that way someone couldn't sneak something nasty into the autorun of an already whitelisted PND without the user being alerted to the change.

Obviously, what's should be a simple game shouldn't ever need to autorun and should throw up a red flag to the average user. Of course a security concious user should be able to disable autorun completely.

A program that is designed to thrash your Pandora's OS does not need autorun to do anything, all it needs is for the user to run the program. This is a poor argument against autorun.
 
I HATE ask-for-permission-thingys. They only work if you actually check what it wants to do. Anyone here actually ever doing that?

Better way would be to (cryptographically) sign those PND's. Only those PND's which have been checked by someone you trust (Pandora-devs by default?) would be allowed to autorun. Of course, you can always sign the PND's yourself, and add new keys to the trusted-list...
 
mindlord said:
A rather simple solution to the autorun problem would be flag the PND as containing an autorun script, ask for permission to run the script when the PND is detected the first time and add the MD5 checksum of the PND to a whitelist if the user says go for it. The MD5 is handy because if the PND changes it will ask the user again, that way someone couldn't sneak something nasty into the autorun of an already whitelisted PND without the user being alerted to the change.

Just a idea but why not have signed PND ? It doesn't have to be mandatory but it could be a plus in my opinion. It could be a better way to maintain a list of trusted PND. Obvisouly the individual creating the PND would have to sign them (and this isn't implemented yet of course) or there could be some PND signed by the official Pandora team as well.

That would requiere some kind of PND manager which would have to manage all of this. (List of trused key...)
Maybe a bit complicated...
 
Last edited by a moderator:
Mindlord .. THe problem is in defining specs, which first need nailing down :) as you can see, it'll take some doing (but as in all things opensource, some coder (prolly me :) will just code it up to kick things off .. Anyway, all of libpnd has been open source since day one so it's not like we're not opening things up.. Have at! As I've always said.. We built stuff in free time and while things were moving targets, so we built stuff to work well.. And to be fixed up or replaced as time goes on as in any healthy project :)

jeffphone
 
skeezix said:
Also don't want it to ask on boot "do you wish to allow these pnd files ot run that request it".

What is it that people find so intrusive about pop-ups that can be turned off after first execution:

Code:
/*
 The following applications are requesting auto-mounting, do you wish to allow this:
 {Yes,No,Always,Never}
 
 [x]  Never automount PND files
 (this option can be changed in settings/SD
*/

You could then add a context menu items to all PNDs which have requested automount which say 'Allow auto-mount'

If you don't like the pop-up you have to deal with it once, and you still have a way of allowing automounts on a per-app basis through the OS
 
Last edited by a moderator:
rabidpoobear said:
torpor said:
Rabidpoobear: why not use sqlite? Then you won't need all the Postgres luggage ..

Shh, don't tell anyone, but I'm making a GPS navigation application, and PostgreSQL is a requirement because it has the PostGIS extensions and all the tools to import OpenStreetMap data and a lot of the libs I'm using for routing, etc. require your data to be in a Postgre database. So unfortunately I have no other choice. Otherwise I'd use sqlite, I like it.
Oow! Sounds good. This is very high on my intended uses of the Pandora. I really want it for fell-walking so I think the opensource maps may struggle here. Anyway, don't want to hi-jack this post, just keep up the good work. Community! Help this man so I can enjoy his fecundity.
 
Last edited by a moderator:
Pleng said:
skeezix said:
Also don't want it to ask on boot "do you wish to allow these pnd files ot run that request it".
What is it that people find so intrusive about pop-ups that can be turned off after first execution:
The problem is when it keeps happening. The first couple of times, you pay attention to the window. By the 10th time you're all "I already gave you permission to do that!". Around about popup 20 you've just stopped reading them and hit "Allow" out of habit. The {Yes,No,Always,Never} would certainly go a long way to solving the problem.
 
Last edited by a moderator:
The way I described it, it would only pop up for applications containing autorun information, and even then only once per PND. A different, more ominous message would appear if the PND's checksum had changed. Either the user updated it and consciously knows that the PND will need whitelisted again. Or something nasty tried to change the PND without the user's knowledge and the system is alerting the user to the unexpected change. It's certainly not every time the SD card is inserted, and not often enough to develop the click-thru behavior.
 
mindlord said:
A rather simple solution to the autorun problem would be flag the PND as containing an autorun script, ask for permission to run the script when the PND is detected the first time and add the MD5 checksum of the PND to a whitelist if the user says go for it. The MD5 is handy because if the PND changes it will ask the user again, that way someone couldn't sneak something nasty into the autorun of an already whitelisted PND without the user being alerted to the change.
Oh yeah, MD5 is really safe, and it's not like someone who wants to sabotage people's systems is going to be smart enough to run an app that tacks data onto the end of their exe to make it have the same MD5 or something... :rolleyes:
 
Last edited by a moderator:
From what I understand a number of people consider MD5 "good enough"... seems like collision attack are becoming relatively easy those day.
Anyway it's not like it's yet implemented of anything... it was just an idea.

If it is ever implemented I believe it would be worth looking into using SHA-256 or a similarly strong hash algorithm.
 
skeezix said:
Theres also the question of.. if you flag a pnd as automount.. does it moutn when the SD inserts, or only when you boot fresh? And any rules ofr how to un-mount the automounts? ie: normal pnd mounts and unmounts around the invocation, but if you want a shared-libn pack of DB or somethign, you want it to persist across other applications, but you may want a way to stop it without sending a SIGKILL..

I shoudl probably write up my thoughts and approach so people could debate it a bit, but I rather figured to do that after 1.0 ships; I mean, we're busy enough right now :)
I would guess it should mount on SD insert. This way it can be included on the same SD as any applications/games which depend on it. If it's a general OS enhancement then I suppose you would have to include it on every SD.

The beauty of two SD slots is that I will probably keep one permanemtly inserted anyway with any OS enhancements, common applications etc.

My personal interest in this is that I would like to package Mono, since I want to develop games with C# and SDL.NET. It's not like I can get started before I have a Pandora anyway so 'after 1.0' is fine by me. It's nice to have an opportunity to discuss it first, and we all know you have enough to do right now :)
 
Last edited by a moderator:
Yeah, 'terps and libpacks are one of my worries. Ie: we got python in there but not every lib under the sun. Wegot SDL but no lib sdl sound since that's one of 800 non core sdl extensions. We don't have ruby and perl and scheme in there (or emacs :( .. So system extensions are hmm

strikes me we should treat it like USB .. Allow automount or manual mount, and a dialog to safely unmount .. But hard to detect dependancies maybe.. Or laid may do it...

Jeff

lsof*. I *hate* phone auto-uncorrection on phones
 
skeezix said:
Wegot SDL but no lib sdl sound since that's one of 800 non core sdl extensions.
Wait, what? Run that by me again? Before I go into a weird kind of panic, are you telling me you do not have sound for SDL apps? Or am I misunderstanding?
 
Last edited by a moderator:
WizardStan said:
skeezix said:
Wegot SDL but no lib sdl sound since that's one of 800 non core sdl extensions.
Wait, what? Run that by me again? Before I go into a weird kind of panic, are you telling me you do not have sound for SDL apps? Or am I misunderstanding?
He's saying in the libs. Not in the compiled apps. So basically you'd have to add libsdlsound to your library if you wanted to compile apps on the Pandora. No need for panic.
 
Last edited by a moderator:
I have a quick question about the pnd system.

If I use another OS, would I be able to install a simple package to gain pnd abilities back?
 
shadow.8 said:
I have a quick question about the pnd system.

If I use another OS, would I be able to install a simple package to gain pnd abilities back?
Well I guess that depends if your new OS's package manager can use Angstrom Packages / if the devs bundle it as one. The answer is probably No it won't be as easy as clicking an installer at first, but will probably be close, and you're free to create a package for whichever distro you use. But that's speculation, I'm not involved with pnd at all.
 
Last edited by a moderator:
Well the other OS would also need a package that actually understands the PND format. So it depends on the OS that you install.
 
Adding pnd support to other distro is -easy- - just build libpnd and poach pndnotifyd.

sdl has sound :) . Lib sdl sound is not part of sdl, it is someones random extension with mp3/etc decoding. It was an example of... We have tonnes of common libs in panda distro, but no distro has all possible libs.

Jeffphone
 
Back
Top