Aight, I'll Post It Then!

[borgqueenx]

how many preasure did you put your thumb on while pressing the screen?
in the video it seemed like its really easy to press.

You barely need to touch it actually.
[/quote]
good news!
someone campared the touch screen with a nintendo DS, but sometimes i have the feeling im pressing a button instead of touching the screen on my DS.

 

[kagato]

There's a lot of griping about perceived security issues over on Pandorapress.

Wouldn't most potential security concerns be covered by only allowing a .pnd to write to (and even read from) its /pandora/appdata/<appid> directory? (not sure if this is already the case)

In that case, an app can only mess with its own files and can't affect other apps or data.

The worst a malicious .pnd could do would be to spoof the ID of another app to try and break that one app's data, but even that might not be totally successful as there are probably other problems caused by an ID collision (such as the archive's loopback mapping). Maybe pndnotifyd can issue an alert if duplicate IDs are detected.

If an app needs access to external files (such as a ROM collection), you can symlink the external directory under its appdata directory. This would sensibly be done after you've tested the app, so in effect you're manually granting permission to a specific file location. I'd argue that's more secure than blanket password or executable-bit access.

 

[gruso]

It certainly got a little OTT over there (or was that ADD?)

 

[juniorm33]

I've not read the comments on Pandorapress, but how are PND's inherently less secure than other Linux packages?
I would have thought at worse it's no better, and considering the product and users, anything bad would be picked up pretty quickly. Then the PND will be removed or repackaged.
If really need the security blankee, then could have a centralised list of black listed PND profiles that can be used like a virus checker.
And if even that's not enough for these people, they don't need to use PND's at all.
I know it's been brought up a couple times, so I'll not be reading the comments. As on a personal level I'm not to worried....

 

[WizardStan]

The argument is basically that "automatically setting something to be executable is bad" with the suggestion that the PND should ask for a password, at least the first time, before it executes. The reason it is bad is that someone could get a malicious PND file onto your card somehow. The argument is that adding this password feature will somehow make it more secure, but the proponents of this suggestion can seem to explain *how* it makes it more secure. The examples given are all easily thwarted by simply saying "if you are going to run something and have no idea what it is, a password will only delay the inevitable"
Rest assured, from what I've seen, PNDs are about as secure as they need to be, which is to say no less secure than any other binary you download off the internet. So long as you get them from a reputable source, of course. If you download some random PND from a questionable website, you're taking a risk, and should be aware of the steps needed to minimize that risk.

 

[juniorm33]

So you download a PMD, with the sole purpose of executing it, place it on an SD card, put it in your Pandora.
At any step especially the downloading one the user has the opportunity to decide no, lot better than a password.
Given the fact auto or not, you intend to run it anyway.
Anyway thanks for pointing out the discussion is no further along than the other times.

 

[skeezix]

About the "executable directories" (a directory containing a pxml)... I'd just like a little clarification. Say I'm developing something for the pandora and have an svn repository to host my code. If I have a pxml file in the svn trunk, it gets recognized as an executable directory? So basically to use the svn version I'd just need to checkout the repository to an sd card? It shows up in the menu just like any pnd? Of course the makefile would have something like "make pnd", but this sounds great for development. Yes I know cross-compiling is the way to go most of the time. Think something like python development.

I'm really liking this.

(sorry for the incoherent post, I'm a bit tired )

Oops, didn't see this one.. catching up on thread again

pndnotifyd has a configurable search-path; if those paths (or their children) have PXML.xml-dir-apps in them, they will be recognized and can generate .desktop apps (or be run from other libpnd using launchers.)

For dev, you'd just build it locally and run it on your desktop/whatever, and then build an ARM version with a cross-compiler, pack itg up into a PND (or drop the PXML-dir) onto SD and good to go. On the pandora itself, you can just run pnd-run.sh directly to invoke the pnd or PXML-dir, or use a pnd-run binary tool like this: pnd-run /path/to/my/app/foo.pnd -> and bam, runs.

Its all cake

jeff

 

[skeezix]

how deeply is it integrated in xfce? will pnd'd apps also show up in the proper xfce-menu (or a replacement plugin) categories?

Would be cool to have something like a "desktop"-tag that specifies if an app should be displayed on the desktop or just in the menu.

As far as I know the libraries are set up to create standard .desktop files, so I think it would be pretty easy to write something to integrate them into the system menu too.

PXML.xml names a category; libpnd looks up the category in a config file that maps it to a .desktop standard category, and notes that in the .desktop file. Thus apps can show up in the appropriate category and the desktop managers can do what they like with them - show them on desktop, in windows, in menus whatever. In practice, I think most desktops watch one set of dirs for menus, and another set of dirs for windows/desktop, but it varies by desktop manager and I'm not sweating it (One can also override the categor in the PXML, and one could browse over to a dir with PND apps and run them thataway..)

jeff

 

[dflemstr]

About the "executable directories" (a directory containing a pxml)... I'd just like a little clarification. Say I'm developing something for the pandora and have an svn repository to host my code. If I have a pxml file in the svn trunk, it gets recognized as an executable directory? So basically to use the svn version I'd just need to checkout the repository to an sd card? It shows up in the menu just like any pnd? Of course the makefile would have something like "make pnd", but this sounds great for development. Yes I know cross-compiling is the way to go most of the time. Think something like python development.

I'm really liking this.

(sorry for the incoherent post, I'm a bit tired )

Oops, didn't see this one.. catching up on thread again

pndnotifyd has a configurable search-path; if those paths (or their children) have PXML.xml-dir-apps in them, they will be recognized and can generate .desktop apps (or be run from other libpnd using launchers.)

For dev, you'd just build it locally and run it on your desktop/whatever, and then build an ARM version with a cross-compiler, pack itg up into a PND (or drop the PXML-dir) onto SD and good to go. On the pandora itself, you can just run pnd-run.sh directly to invoke the pnd or PXML-dir, or use a pnd-run binary tool like this: pnd-run /path/to/my/app/foo.pnd -> and bam, runs.

Its all cake

jeff

If enough people are interested, I guess that a kernel .pnd binfmt would be cool, so that .pnds could be executed directly like normal applications.

 

[skeezix]

There's a lot of griping about perceived security issues over on Pandorapress.

Wouldn't most potential security concerns be covered by only allowing a .pnd to write to (and even read from) its /pandora/appdata/<appid> directory? (not sure if this is already the case)

In that case, an app can only mess with its own files and can't affect other apps or data.

The worst a malicious .pnd could do would be to spoof the ID of another app to try and break that one app's data, but even that might not be totally successful as there are probably other problems caused by an ID collision (such as the archive's loopback mapping). Maybe pndnotifyd can issue an alert if duplicate IDs are detected.

If an app needs access to external files (such as a ROM collection), you can symlink the external directory under its appdata directory. This would sensibly be done after you've tested the app, so in effect you're manually granting permission to a specific file location. I'd argue that's more secure than blanket password or executable-bit access.

Not really feasible .. ie: consider an emu.

You probably do something like..

Keep SNES roms on the other SD card, or perhaps in a /rom dir on both or one card.

Put the pnd app in /pandora/apps on one of the cards; quite likely could have 2 or 3 different SNES emus, if current handhelds are an indicator.

So each emu would be its own app, and probabyl reads/writes to its whole conf files and such (which would be in their appdata folder.) But you'd instruct them to look in you /roms folder (say), to actually find the roms. This way 3 emus coudl share the same ROMs, but have their own private appdata folders.

That said, the security gab over there is mostly a farce; but check all my comments over there.

jeff

 

[skeezix]

So you download a PMD, with the sole purpose of executing it, place it on an SD card, put it in your Pandora.
At any step especially the downloading one the user has the opportunity to decide no, lot better than a password.
Given the fact auto or not, you intend to run it anyway.
Anyway thanks for pointing out the discussion is no further along than the other times.

Also note that the pnd file is never auto-run, not ever (dunno where that idea came from.) They are 'auto discovered', which is to say, they are found and possibly show up on your desktop or in menus magicly, with no work from the user. This is not the pnd being run, as there is no installation whatsoever. So there is auto-find, but no auto-run.

You still have to run it yourself, and like anything you download .. you download it from an unrepiutable location, on any OS, you should take your caution That said, its pretty easy to snapshot your pandora, restore it from an image, etc.. its not like you need a 4 hour Win 7 reinstall plus installing all your apps

jeff

 

[juniorm33]

So you download a PMD, with the sole purpose of executing it, place it on an SD card, put it in your Pandora.
At any step especially the downloading one the user has the opportunity to decide no, lot better than a password.
Given the fact auto or not, you intend to run it anyway.
Anyway thanks for pointing out the discussion is no further along than the other times.

Also note that the pnd file is never auto-run, not ever (dunno where that idea came from.) They are 'auto discovered', which is to say, they are found and possibly show up on your desktop or in menus magicly, with no work from the user. This is not the pnd being run, as there is no installation whatsoever. So there is auto-find, but no auto-run.

You still have to run it yourself, and like anything you download .. you download it from an unrepiutable location, on any OS, you should take your caution That said, its pretty easy to snapshot your pandora, restore it from an image, etc.. its not like you need a 4 hour Win 7 reinstall plus installing all your apps

jeff

Sorry I knew all that and still worded it badly
But yea, you download something with the intention of running it, passwords, click here to confirm makes no difference. Person isn't going to think at that time, oh I'm glad it asked I've now changed my mind. lol

Edit : I'm glad you clarified it, my wording was misleading at best, even if the message itself wasn't

 

[skeezix]

Didn't direct that at you, no worries; just put that out there to be clear for anyone else whose reading

jeff