What you describe is not allowed in Mac App Store apps as displaying a dialog that sends you to a non-Mac App Store site that sells a product (i.e. our downloads) is forbidden by Apple.
I think my original help wording for items that we removed may also run afoul of Apple's restrictions so I think we will likely limit the help wording to the following:
Quote:
This feature is not available in NeoOffice App Store Edition due to Apple's Mac App Store security requirements.
Joined: Oct 24, 2005 Posts: 561 Location: Edinburgh, Scotland
Posted: Tue Feb 26, 2013 9:52 am Post subject:
Thanks for clarifying those points, Patrick. As I'm not a developer I hadn't been aware just how restrictive Apple is with regard to the App Store.
I still think it's not a great solution, but I appreciate that it is pretty much the only one available to you.
I'll keep using the full version of NeoOffice as I need the report functions of Base, though I am looking at moving my databases away from Java and JDBC, just in case…
Is it allowed (probably not) to have an add-on in the app store version that will break out of the sandbox and activate Java support for what NeoOffice needs? It should come with all the warning signs about what that means... _________________ "What do you think of Western Civilization?"
"I think it would be a good idea!"
- Mohandas Karamchand Gandhi
Is it allowed (probably not) to have an add-on in the app store version that will break out of the sandbox and activate Java support for what NeoOffice needs? It should come with all the warning signs about what that means...
In other words, can an application break out of the sandbox it is running in?
I hope not. This is exactly the means that malware developers use to infect machines: find a security hole to escape the sandbox imposed by your web browser, Flash player, PDF renderer, etc.
With the proper authentication, is that not possible? Or is a process in such a sandbox barred from even acquiring such privileges? _________________ "What do you think of Western Civilization?"
"I think it would be a good idea!"
- Mohandas Karamchand Gandhi
Joined: Jun 11, 2006 Posts: 481 Location: Great Britain
Posted: Wed Feb 27, 2013 3:40 am Post subject:
ovvldc wrote:
With the proper authentication, is that not possible? Or is a process in such a sandbox barred from even acquiring such privileges?
It's not about authentication, it's about Apple's App Store rules. Using "deprecated technologies" will get NeoOffice rejected, and Apple's Java implementation is considered deprecated. Think of it like the ban on pornography in App Store apps: there is no anti-porn technology in the App Store, the reviewers simply have a check list and reject any apps that do something not permitted.
Incidentally, there is some evidence that you can bundle OpenJDK in an App Store app without falling foul of Apple's rules: here.
With the proper authentication, is that not possible? Or is a process in such a sandbox barred from even acquiring such privileges?
Now I am getting annoyed with this line of discussion. I have already explained both the sandboxing issues and the Mac App Store rules regarding Java in this thread and not going to keep repeating them after each time I post an update on our status.
Have you even looked at the list of entitlements for sandbox applications? I have linked to Apple's App Sandbox and the list of entitlements is in its own section.
djpimley wrote:
Incidentally, there is some evidence that you can bundle OpenJDK in an App Store app without falling foul of Apple's rules: here.
Great, someone sneaked OpenJDK into the Mac App Store. How again does that fix the problem of requesting access to files and folders sandbox imposes? And no, the answer is not use the temporary sandbox exception and grant access of the entire file system. Our contacts at Apple have assured us that that would not be approved.
The answer to my question for you is we would have to modified the OpenJDK to intercept all file and folder calls and display the Mac OS X "powerbox" open dialog.
We aren't going to do that. We have enough work to do ensuring that NeoOffice runs on the latest version of Mac OS X without having to expand our work to enhance Java and Python to run in the sandbox.
We aren't doing this for some big expectation of gain. We are doing this because we believe Apple is going to keep tightening down Mac security and so now is the time to figure out what can run within those security constraints.
At this point, I will only respond to questions as to how NeoOffice Mac App Store will work differently from regular NeoOffice. I don't have the time to respond to the engineering "suggestions" from those who have no direct experience with this subject matter or the "but it is broken without Java" worries.
While we are talking about OpenJDK, I should mention that Ed and I are working under the assumption that Apple will stop making their own Java available in future releases of Mac OS X.
If and when that happens, we will see if there are any versions of OpenJDK that are digitally signed and are loadable by NeoOffice. If so, we will add such a OpenJDK versions to the list of Java implementations to look for.
However, we will not bundle someone else's Java. If you want Java and Apple does not provide it, the user will have to download and install it themselves. Also, if we can we will check that the OpenJDK is digitally signed before loading. Application signing is now the standard for Mac OS X applications and if a product as big as OpenJDK doesn't sign their code, that is a big security flag and we would not load it.
Joined: Oct 24, 2005 Posts: 561 Location: Edinburgh, Scotland
Posted: Wed Feb 27, 2013 10:10 am Post subject:
pluby wrote:
If and when that happens, we will see if there are any versions of OpenJDK that are digitally signed and are loadable by NeoOffice. If so, we will add such a OpenJDK versions to the list of Java implementations to look for.
That would be most helpful and greatly appreciated, here at least.
In my experience, problems of compatibility only arise with new 10.x releases of Mac OS, which can be avoided by not upgrading the OS and are only a real sticking point when new hardware is bought that cannot run the older OS. However from what you've said, Patrick, and what Apple has done to date, it seems not unlikely that Apple will remove Java from 10.8.x during the course of a more general bug fix/security update at some point in the future, which is harder to avoid.
If and when that happens, we will see if there are any versions of OpenJDK that are digitally signed and are loadable by NeoOffice. If so, we will add such a OpenJDK versions to the list of Java implementations to look for.
That would be most helpful and greatly appreciated, here at least.
Don't hold out too much hope. Oracle's Java download is not digitally signed so that is out and the I just found this which seems to indicate that the OpenJDK project on Mac OS X is dead.
Joined: Jun 11, 2006 Posts: 481 Location: Great Britain
Posted: Wed Feb 27, 2013 5:02 pm Post subject:
pluby wrote:
Great, someone sneaked OpenJDK into the Mac App Store. How again does that fix the problem of requesting access to files and folders sandbox imposes?
I did not claim it did solve any problems. I merely mentioned it as an incidental detail that I discovered whilst doing a search for Apple's wording of the rules. I apologise if I've caused some kind of offence by mentioning this detail. Personally I don't use Base and therefore I care not a jot for the loss of Java.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Wed Feb 27, 2013 9:28 pm Post subject:
I've seen more security notices on Java recently than Flash, and that's not a good sign. It is way too risky to bundle as those security holes open us up to liability, not to mention having to push our own updates for a custom VM every other week, etc.
With all of the Oracle bugs, I really think they're shooting themselves in the foot and Java on the client side is dead.
Also, when using Apple's App Sandbox, the version browser only displays a small thumbnail image of old versions....
FYI. I have fixed this sandbox problem for .od* files by overriding what each version's preview window draws. It took a few days of experimentation, but I found a way to override the default version window drawing in these windows and so if there is any PDF content embedded an old version (i.e. if NeoOffice saved the past version), our code now extracts that PDF just like our QuickLook plugin does and then renders the PDF using Mac OS X's PDFKit functions.
As you can see in the following screen snapshot while running in Apple's App Sandbox, the version window on the left now looks the same as in NeoOffice 3.3.
Note: since non-.od* files (e.g. .doc, .docx, .xls, .xlsx) do not contain any embedded PDF content, we must still relying on Mac OS X's default version window drawing. This means that only a thumbnail image will appear for old versions on non-.od* files until Apple fixes the bug (see end of this post for a description) that causes thumbnails to be drawn instead of full previews:
During the last week, I implemented the following changes in our "App Store Edition" code that uses Apple's App Sandbox:
1. NeoOffice help entries that reference Java or Python will display "feature not available" like the following screen snapshot:
2. Trying to open an .odb file that uses a Java-based HSQLDB or JDBC database will display a "database drive not available" dialog like the following screen snapshot. Also, trying to install an extension that contains Java or Python code will display a similar "extension cannot be loaded" dialog:
I still need to find and replace the text for several help entries that reference Java or Python, but other than that work I think that later this month we should be able to post a test build for our moderators and volunteer testers.
BTW, below is the most common message that our code uses for the above screen snapshots as well as my likely very poor German, French, Italian, and Dutch translations. If anyone sees any errors in my translations, please let me know and I will update the code:
English: This feature is not available because it requires external software that has been identified as a security risk.
German: Diese Funktion ist nicht verfügbar, da externe Software, die als Sicherheitsrisiko identifiziert wurde benötigt werden.
Dutch is fine, good work . _________________ "What do you think of Western Civilization?"
"I think it would be a good idea!"
- Mohandas Karamchand Gandhi
All times are GMT - 7 Hours Goto page Previous1, 2, 3Next
Page 2 of 3
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
.