Hey folks, I got access to exec method for test! But, it's not working... :( the function returns 127 and don't create the zip file, I've tested on Linux command tool and works! Do you have any idea why didn't work?
Thanks again and sorry for the inconvenience, Petrus Bastos. On Feb 18, 2008 2:37 PM, Nick Stinemates <[EMAIL PROTECTED]> wrote: > Petrus Bastos wrote: > > Richard, > > > > Unfortunately, I can't get out of the zip password rut because the > > destination system read only this file format. I can't change the > > destination system. > > > > Thanks, > > Petrus. > > > > On Feb 18, 2008 2:11 PM, Richard Lynch <[EMAIL PROTECTED]> wrote: > > > > > >> On Mon, February 18, 2008 5:59 am, Petrus Bastos wrote: > >> > >>> Thanks again for your worry. So, let's go, here goes my situation. > >>> I'm > >>> exporting data to another system. That system have an option to be > >>> feed by a > >>> password protected zip file. The export activity will be occur in this > >>> way: > >>> the user will generate the file on my application and will put this > >>> file > >>> into that another system. So, I need generate that file. Maybe one > >>> solution > >>> is to generate the file unzipped and determine that user should zip > >>> the file > >>> with password on his Windows or Linux operating system. But, I can't > >>> let > >>> that responsibility on user hands. So, because that I need to generate > >>> the > >>> file already protected. > >>> > >> Perhaps you could use SCP (or SSH tunneling) to transfer the file from > >> system to system, so that it need not ever be visible to the outside > >> world, and thus not need the rather lame zip password. > >> > >> Another option would be to take the whole file and 2-way encrypt it > >> with a public/private key pair, and install the private key on the > >> receiving server. > >> > >> In other words, get out of the zip password rut, and protect the file > >> some other way. > >> > >> -- > >> Some people have a "gift" link here. > >> Know what I want? > >> I want you to buy a CD from some indie artist. > >> http://cdbaby.com/from/lynch > >> Yeah, I get a buck. So? > >> > >> > >> > > > > > Sounds like a creative challenge... this is what makes programmers > problem solvers. You can write the code, you have the knowledge.. and > then you get requirements like this one. How annoying! > > I found out some interesting information researching your issue. It > seems that encryption by password is actually not built in to ZIP > itself, but was an implementation detail apps like WinZip added to the > mix. Because of that, the original ZIP libs don't have any notions of > password protection. > > It seems like this isn't a language specific issue, either. > > I think it's time to get creative, Petros. You're in a bind, and I > assume you need to get this done, so you have the following options (in > the order I would do it in..) > -> Turn on exec() > -> You can use/modify an app I wrote (in python) which accepts UDP > packets and executed commands based off of it. You can strip out the > really insecure things and just accept 'zip' commands. The lib/app is > really small and lightweight. There are no dependencies outside of I > think 3 python modules. If I couldn't turn on exec(), this is the route > I would go. > -> Use some form of file/directory montoring + zip. > -> Pass the request on to an environment that has zip() > > -- > ================== > Nick Stinemates ([EMAIL PROTECTED]) > http://nick.stinemates.org > > AIM: Nick Stinemates > MSN: [EMAIL PROTECTED] > Yahoo: [EMAIL PROTECTED] > ================== > > >