Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Strawberry Perl MSI installer
50 views
Skip to first unread message
kmx
May 15, 2014, 11:35:15 AM5/15/14
to win32-...@perl.org
Hi,
We have many reports related to problems with installing strawberry perl via MSI installer. Like troubles with installing on non-C: drive, troubles with installing on a machine completely without C: drive, some permission related issues etc.
I have prepared redesigned version of MSI (it is 5.19.11.4) and made it available at http://strawberryperl.com/beta/ - visually it looks exactly as the old installer but guts changed a lot.
If you have experienced in past any troubles with MSI installer or if you can test it on a unusual machine (like one with system drive D: without drive C:) or if you can test it on a box with some unusual UAC settings - please get the latest beta from URL above and check if the MSI installer works for you.
In case of troubles run:
c:\anydir> msiexec /l*vx install.log /i strawberry-perl-5.19.11.4-64bit.msi
and send me install.log (off-list)
The second issue is related to our highly respected sponsor <ad> https://auditsquare.com </ad> as their security checker (even FREE version) reports a security warning related to strawberry perl installation. In short it says that PATH contains directories (c:\strawberry\c\bin c:\strawberry\perl\site\bin c:\strawberry\perl\bin) which are writable by too wide group of users (built-in Users or even Authenticated Users).
We currently do not explicitly set any filesystem ACL therefore C:\strawberry directory gets some ACL inherited from C:\ which is probably mostly fine but might be a trouble if you choose another directory (or another drive) which parent dir has some strange and/or unexpected ACL. I feel that our MSI should probably set some filesystem ACL on C:\strawberry (which is supported by WiX Toolset we use for MSI creation) but I am not sure what it should be (e.g. Administrators+SYSTEM/FullControl, Users/Read+Execute ?). Any ideas or preferably experiences with building MSI are welcome.
--
kmx
We have many reports related to problems with installing strawberry perl via MSI installer. Like troubles with installing on non-C: drive, troubles with installing on a machine completely without C: drive, some permission related issues etc.
I have prepared redesigned version of MSI (it is 5.19.11.4) and made it available at http://strawberryperl.com/beta/ - visually it looks exactly as the old installer but guts changed a lot.
If you have experienced in past any troubles with MSI installer or if you can test it on a unusual machine (like one with system drive D: without drive C:) or if you can test it on a box with some unusual UAC settings - please get the latest beta from URL above and check if the MSI installer works for you.
In case of troubles run:
c:\anydir> msiexec /l*vx install.log /i strawberry-perl-5.19.11.4-64bit.msi
and send me install.log (off-list)
The second issue is related to our highly respected sponsor <ad> https://auditsquare.com </ad> as their security checker (even FREE version) reports a security warning related to strawberry perl installation. In short it says that PATH contains directories (c:\strawberry\c\bin c:\strawberry\perl\site\bin c:\strawberry\perl\bin) which are writable by too wide group of users (built-in Users or even Authenticated Users).
We currently do not explicitly set any filesystem ACL therefore C:\strawberry directory gets some ACL inherited from C:\ which is probably mostly fine but might be a trouble if you choose another directory (or another drive) which parent dir has some strange and/or unexpected ACL. I feel that our MSI should probably set some filesystem ACL on C:\strawberry (which is supported by WiX Toolset we use for MSI creation) but I am not sure what it should be (e.g. Administrators+SYSTEM/FullControl, Users/Read+Execute ?). Any ideas or preferably experiences with building MSI are welcome.
--
kmx
Jan Dubois
May 15, 2014, 1:25:44 PM5/15/14
to kmx, Win32 Perl mailing list
On Thu, May 15, 2014 at 8:35 AM, kmx <k...@atlas.cz> wrote:
> it says that PATH contains directories (c:\strawberry\c\bin
> c:\strawberry\perl\site\bin c:\strawberry\perl\bin) which are writable by
> too wide group of users (built-in Users or even Authenticated Users).
[...]
> it says that PATH contains directories (c:\strawberry\c\bin
> c:\strawberry\perl\site\bin c:\strawberry\perl\bin) which are writable by
> too wide group of users (built-in Users or even Authenticated Users).
> I feel that our MSI should probably set some filesystem ACL on C:\strawberry
> (which is supported by WiX Toolset we use for MSI creation) but I am not
> sure what it should be (e.g. Administrators+SYSTEM/FullControl,
> Users/Read+Execute ?). Any ideas or preferably experiences with building MSI
> are welcome.
The problem is that if you set a more restrictive ACL, then you will
> (which is supported by WiX Toolset we use for MSI creation) but I am not
> sure what it should be (e.g. Administrators+SYSTEM/FullControl,
> Users/Read+Execute ?). Any ideas or preferably experiences with building MSI
> are welcome.
always need to run from an elevated shell to install additional
modules from CPAN. So you have to make a choice between convenience
and security. My personal opinion: setting a restrictive ACL makes
sense on a server, but not on a user's desktop.
Cheers,
-Jan
Chris Marshall
May 15, 2014, 2:10:26 PM5/15/14
to Jan Dubois, kmx, Win32 Perl mailing list
Not familiar with MSI details but I hope any changes
won't be a problem for SPP which is useful because
it *doesn't* require special permissions---just enough
to create the folder...won't be a problem for SPP which is useful because
it *doesn't* require special permissions---just enough
Jan Dubois
May 15, 2014, 2:27:31 PM5/15/14
to Chris Marshall, kmx, Win32 Perl mailing list
On Thu, May 15, 2014 at 11:10 AM, Chris Marshall <devel....@gmail.com> wrote:
> Not familiar with MSI details but I hope any changes
> won't be a problem for SPP which is useful because
> it *doesn't* require special permissions---just enough
> to create the folder...
This has nothing to do with MSI, but with putting a directory on the
> Not familiar with MSI details but I hope any changes
> won't be a problem for SPP which is useful because
> it *doesn't* require special permissions---just enough
> to create the folder...
PATH to which the user has write access. Essentially all scripting
languages do this to allow the user to install additional modules
easily, but security companies like to put out alerts about this...
It is not a new issue; here is the ActiveState position about the same
issue with ActivePerl:
https://community.activestate.com/node/9199
TL;DR: The default is more convenient for most users; it is trivial
for users to apply more restrictive ACLs if they are bothered about
it.
Cheers,
-Jan
kmx
May 15, 2014, 4:25:45 PM5/15/14
to win32-...@perl.org
On 15.5.2014 20:27, Jan Dubois wrote:
> On Thu, May 15, 2014 at 11:10 AM, Chris Marshall<devel....@gmail.com> wrote:
>> Not familiar with MSI details but I hope any changes
>> won't be a problem for SPP which is useful because
>> it *doesn't* require special permissions---just enough
>> to create the folder...
> This has nothing to do with MSI, but with putting a directory on the
> PATH to which the user has write access. Essentially all scripting
> languages do this to allow the user to install additional modules
> easily, but security companies like to put out alerts about this...
With ZIP and Portable it completely in user's hand how he|she created
> On Thu, May 15, 2014 at 11:10 AM, Chris Marshall<devel....@gmail.com> wrote:
>> Not familiar with MSI details but I hope any changes
>> won't be a problem for SPP which is useful because
>> it *doesn't* require special permissions---just enough
>> to create the folder...
> This has nothing to do with MSI, but with putting a directory on the
> PATH to which the user has write access. Essentially all scripting
> languages do this to allow the user to install additional modules
> easily, but security companies like to put out alerts about this...
destination directory and with what filesystem permissions. This will not
change.
> It is not a new issue; here is the ActiveState position about the same
> issue with ActivePerl:
>
> https://community.activestate.com/node/9199
>
> TL;DR: The default is more convenient for most users; it is trivial
> for users to apply more restrictive ACLs if they are bothered about
> it.
Thanks.
--
kmx
0 new messages