Hello everybody, I would like to point out that the issue presented by Oliver is quite common nowadays. I know of business environments where the security settings do not allow - in the entire company IT infrastructure - to launch any application from the temp directory, for example. In these cases, I simply could not use the executable generated by pp. I have the feeling that these restrictions are getting more and more common, so a more flexible solution for pp could be very useful.
Best Welle Am Mi., 8. Mai 2019 um 22:58 Uhr schrieb Oliver Betz <list...@gmx.net>: > Roderich Schupp wrote: > > [...] > > > The Windows standards suggest to make exectuables write protected. > > > > Bullshit advice. If the files are owned by the user, the malware can > > unprotect them. > > with the correct ACL, a restricted user cannot modify the files > unnoticed (needs at least to confirm in the UAC dialog). > > > Unpacking the runtime files in a dedicated step seems to be a natural > > solution to me. That's how most (portable) programs are "installed". > > > > If they can be installed by the user (i.e. without "admin" rights), this > > gains you nothing. > > The user needs to run the installer with elevated rights, which requires > confirming the UAC dialog or logging in as admin. On my machine, I can't > write to "C:\Program Files" from my working account. I need admin rights > to write there. Well, you can weaken the UAC settings. > > In business environments, it can be even enforced by a SRP that > executables can be executed only from protected locations. > > > A PAR archive seems to contain (nearly?) everything to run the > program > > (Perl interpreter, libraries, DLLs etc.) > > > > What do you consider a "PAR archive"? In PAR lingo this is a .par file, > > actually a zip file > > Sorry for using the wrong terms... > > > If you don't to use the standalone executables generated by "pp -o ..." > > ...I actually mean the content of the executable created by pp -o. > > As far as I see, this exe contains an archive with all dependencies > including the Perl interpreter, the unpacker and a small stub to call > the interpreter, correct? > > On the first run, the archive contents are unpacked somewhere. > Alternatively, I can use my preferred unpacker to extract the files > directly from the exe. > > What would be wrong with executing this unpacked stuff directly, without > the "auto unpacking to temp" magic? > > What do I need to run it? > > Oliver >
