Apache OpenOffice (AOO) Bugzilla – Issue 73301
support application/octet-stream mime type in package manager
Last modified: 2008-02-04 15:14:28 UTC
Add support for the "application/octet-stream" mime type such sthat binary chunks can be given a mime type without the package manager complaining. Also added the attribute executable="true" which sets the exec flag to a file. Sample: <manifest:file-entry manifest:media-type="application/octet-stream;executable=true" manifest:full-path="OdfConverter"/>
Created attachment 42031 [details] patch
added patch
Who is supposed to integrate the patch? Please assign it to a suitable developer or nothing will happen. :-)
Mathias - does that mean you're happy with the patch ? if so great we can commit to a CWS etc. any suggestions for QA ? and/or can we share an existing writer CWS with someone else (to save overhead) ?
No, I didn't have a look on it. But I wanted to tell Florian that nothing will happen to this patch until it is assigned to a developer that can review it. The only thing that will happen is that our "initial response time" statistics gets worse because it ridiculously considers patches still assigned to the submitter also. I think the best owner for this patch issue would be "jl". I wonder whether this patch can cause security problems but I leave this up to the specialists.
This patch is still not assigned correctly so it isn't probable that something will happen here. Does that mean that we can close this issue?
flr->mba: Feel free to reassign this to the correct person.
I assume that the requirement is that the package manager should allow that arbitrary binary content can be added that is just unpacked but not processed further. For this purpose the type of the binary file is completely irrelevant so that using "application/octet-stream" looks appropriate. Of course the package manager shouldn't complain or warn about such unknown types.
kso->flr: One question re. the executable attribute: Why do you need this at all? If you assemble your oxt file on Linux/Un*x, all file attributes are preserved in the archive and should be restored *automatically* when the oxt file gets unzipped by the Extension Manager. If Extension Manager does not restore file attributes correctly, I consider this a bug in the unzip code it is using.
added myself to cc.
wrong component
KSO->FLR: Please provide the missing bits of information.
flr->kso: To the best of my knowledge .ZIPs can't store UNIX flags. Have you ever been able to store the UNIX flags inside .ZIPs as you suggested above or is this just a "try this first" comment?
KSO->FLR: I used zip 2.31 / unzip 5.52 on openSuSE 10.2 and it seems to handle UN*X filesystem flags correctly: temp/ziptest> ll total 24 -rwxr-xr-x 1 kso entwick 6521 2007-04-24 10:35 executable.sh -r--r--r-- 1 kso entwick 6521 2007-04-24 10:35 readonly.txt -rw-rw-rw- 1 kso entwick 6521 2007-04-24 10:34 readwrite.txt temp/ziptest> temp/ziptest> zip ziptest.zip ./* adding: executable.sh (deflated 19%) adding: readonly.txt (deflated 19%) adding: readwrite.txt (deflated 19%) temp/ziptest> temp/ziptest> rm -f executable.sh readonly.txt readwrite.txt temp/ziptest> temp/ziptest> ll total 16 -rw-r--r-- 1 kso entwick 16190 2007-04-24 10:47 ziptest.zip temp/ziptest> temp/ziptest> unzip ziptest.zip Archive: ziptest.zip inflating: executable.sh inflating: readonly.txt inflating: readwrite.txt temp/ziptest> temp/ziptest> ll total 40 -rwxr-xr-x 1 kso entwick 6521 2007-04-24 10:35 executable.sh -r--r--r-- 1 kso entwick 6521 2007-04-24 10:35 readonly.txt -rw-rw-rw- 1 kso entwick 6521 2007-04-24 10:34 readwrite.txt -rw-r--r-- 1 kso entwick 16190 2007-04-24 10:47 ziptest.zip temp/ziptest>
JL->FLR: It seems that KSO's solution, that is using zip on unix, solves the problem. Therefore back to you.
maybe. But its yet unclear whether OOo houours the system bits according to kso's idea? I give it to kso so that he can validate whether his idea would work.
kso->flr: exec flag gets lost. A problem with the zlib we're using? Will check that.
kso->flr: Thus, we do agree that in case OOo would preserve the flags your patch is not needed?
Kind of: a) we still need to get rid of the warning message in case of unknown items. This is where I introduced the "application/octet-stream" mime type b) "executable=true" only sets the user exec flag (never others or all). So allowing the full unix flags in the zlib might be a security problem. Maybe you can have a discussion with mba about this 'cause he raised the issue.
> "executable=true" only sets the user exec flag (never others or all) which leaves this feature broken in general (think deployment to shared layer)
kso->flr: If there is no manifest entry for a file contained in the package, Extension Manager simply unpacks it -- without complaining about unknown mime type. This problem is a direct result of your solution for setting the exec flag, because it requires a manifest entry. Thus, if we decide to fix zlib (or whatever is needed to automatically restore the flags stored in the zip file), nothing needs to be changed in the Extension Manager code.
Regarding security: I'm not an expert here, but my proposed solution does not have those problems, because it only manipulates permission flags for files contained in the package.
Florian, I thought about the topic again. There is one aspect that speaks for the solution you suggested. One would like to be able to provide oxt files containing stuff for multiple platforms and to be able to build this oxt on every platform. With my solution, one can only build the oxt on Linux/Un*x if the oxt shall contain files which require the executable flag. Thus, I would be happy to get a patch from you that extends the original patch the way that a) not only the user executable flag can be changed. As Stephan already pointed out, this is needed in order to be able install the oxt for all users. b) only only changing of attributes of files that are contained in the oxt. (security)
To prevent frustration among patch writers, all issues of type PATCH are monitored for extended inactivity periods, see <http://eis.services.openoffice.org/patchreport/irt_index.html> and <http://eis.services.openoffice.org/patchreport/iit_index.html>. Please proceed with this issue in an appropriate way, to satisfy the statistics and avoid frustration. Thanks. [http://wiki.services.openoffice.org/wiki/Uno/Misc/InactivePatchIssueReminder]
Will we do something for 2.3 or no? If so, please proceed - today is code freeze. If not, please change target accordingly.
/me has not done any work on this. kso: did you started implementing you suggestions?
flr: As I wrote on May 21, there is nothing to do for me. If you extend your original patch like suggested, we all should be happy. :-)
flr->kso: Hmmm --- got it wrong then. Thought we would work together on this...
I now need a fix for this, as well. The pdf import in its current state also needs an external executable (which for obvious reasons need the executable flag on *nix)
I fixed this for issue 84019.
*LOL*. So where is this solutions different from mine except that it allows you to set executions bits for any file?
flr: re "LOL": The difference is not a different concept, but that JL implemented a complete solution (which indeed conceptionally very similar to what you've suggested). We all agreed months ago that your concept is okay, but that your implementation needs to be completed. I kindly requested a complete patch from you (wrt. to fixed support for shared extensions and the security problem), months ago. You never came back with a completed patch. Now, we needed this functionality by ourself and the consequence is that we implemented it.
And suddenly there are a) no security concerns? b) no "use zip exec flags" etc? Why that? If you needed a solution why ask me to implement the "zip" stuff and post concerns regarding security and then when you need it do not listen to your own advice at all? Makes no sense to me!
flr: I really suggest you to (again) read the things that were said in this issue before writing further comments. >------- Additional comments from kso Mon May 21 08:05:56 +0000 2007 ------- > [...] > > I thought about the topic again. There is one aspect that speaks for the >solution you suggested. One would like to be able to provide oxt files >containing stuff for multiple platforms and to be able to build this oxt on >every platform. With my solution, one can only build the oxt on Linux/Un*x if >the oxt shall contain files which require the executable flag. > > Thus, I would be happy to get a patch from you that extends the original patch >the way that > That said, my suggestion to use the "right" zip to preserve file attributes was obsolete (I thought). >a) not only the user executable flag can be changed. As Stephan already pointed >out, this is needed in order to be able install the oxt for all users. JL implemented this. >b) only only changing of attributes of files that are contained in the oxt. >(security) JL implemented this as well. =============================== >------ Additional comments from flr Thu Aug 2 15:22:41 +0000 2007 ------- > >/me has not done any work on this. >kso: did you started implementing you suggestions? > >------- Additional comments from kso Tue Aug 14 15:04:53 +0000 2007 ------- > >flr: As I wrote on May 21, there is nothing to do for me. If you extend your >original patch like suggested, we all should be happy. :-) >------- Additional comments from flr Tue Aug 14 15:38:11 +0000 2007 ------- > >flr->kso: Hmmm --- got it wrong then. Thought we would work together on this... After reading this, I considered the confusions about what to do as solved.
Correct me if I'm wrong but I think this issue now is obsolete as the problem was fixed in another issue already?! In that case it should be closed before it can confuse the poor release status meeting attendees. :-)
Florian?! Please either close this issue or change the target. It would help keeping track of 2.4 development.
set to OOoLater as Fridrich suggested in release status meeting.
duplicate. *** This issue has been marked as a duplicate of 84019 ***
.