Re: HEADSUP maintainers: Packages install scripts without execute permissions
On 6/22/2009 10:04 AM, Corinna Vinschen wrote: If the affected packages are replaced before we install a new Cygwin DLL, which correctly checks for execute permissions, the preremove scripts would be replaced with the ones with correct permissions before the problem actually starts to become visible. Ah, that's the part I was missing. Sorry for the noise. Ken
Re: HEADSUP maintainers: Packages install scripts without execute ?permissions
On Jun 22 16:09, Corinna Vinschen wrote: > On Jun 22 13:58, Eric Blake wrote: > > For that matter, are there any postinstall scripts currently relying on a > > different interpreter? If not, then I'm in favor of the idea of changing > > setup.exe to be immune to the execute bit on postinstall scripts, at the > > expense of making postinstall scripts locked into bash (at least, as the > > initial interpreter). > > There can be only *.bat and *.sh files in /etc/postinstall and > /etc/preremove. *.bat files are started via `cmd /c file' and *.sh > files are started via `bash --norc --noprofile -c file'. So we sort of > require a script to be a sh/bash script anyway right now. Admittedly, I > did not actually *look* into all postinstall/preremove scripts in the > distro. I just checked the entire 1.7 distro and here's the result: We have not a single package left which uses a .bat file in postinstall or in preremove. That's great, IMHO. And, AFAICS, all of the *.sh fiels are actually some variation of sh/ash/bash script. So I assume it's safe to remove the -c from setup's script starter method. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: HEADSUP maintainers: Packages install scripts without execute permissions
On Mon, Jun 22, 2009 at 09:45:12AM -0400, Ken Brown wrote: >On 6/22/2009 9:12 AM, Corinna Vinschen wrote: >> Here's the problem: If you exec shell scripts, they should only be run >> if the user trying to run the script has execute permissions on the >> script. This requires to check for executability in Cygwin, but as of >> today, such a check isn't performed in Cygwin. >> >> I have the patch for this ready, but I found that it would potentially >> break a couple of packages which have not set execute permissions on >> some of their script files. >> >> As you should know by now, setup for Cygwin 1.7 will set POSIX file >> permissions for the files extracted from the tar archives. That means, >> all scripts which don't have execute permissions set, will also not have >> execute permissions set after the user installed them. That's bad. >> >> So I created a list of packages which install scripts into >> /etc/preremove, /etc/postinstall, and /usr/bin without setting execute >> permissions on them. Please guys, fix the permissions ASAP. > >Users who have existing preremove scripts without execute permissions >will still have problems if you change setup.exe to check for this, >won't they? Doesn't setup.exe invoke preremove/postinstall shell scripts via "bash foo.sh"? You don't need exec permissions for that. cgf
Re: HEADSUP maintainers: Packages install scripts without execute permissions
On Jun 22 09:45, Ken Brown wrote: > On 6/22/2009 9:12 AM, Corinna Vinschen wrote: >> Here's the problem: If you exec shell scripts, they should only be run >> if the user trying to run the script has execute permissions on the >> script. This requires to check for executability in Cygwin, but as of >> today, such a check isn't performed in Cygwin. >> >> I have the patch for this ready, but I found that it would potentially >> break a couple of packages which have not set execute permissions on >> some of their script files. >> >> As you should know by now, setup for Cygwin 1.7 will set POSIX file >> permissions for the files extracted from the tar archives. That means, >> all scripts which don't have execute permissions set, will also not have >> execute permissions set after the user installed them. That's bad. >> >> So I created a list of packages which install scripts into >> /etc/preremove, /etc/postinstall, and /usr/bin without setting execute >> permissions on them. Please guys, fix the permissions ASAP. > > Users who have existing preremove scripts without execute permissions > will still have problems if you change setup.exe to check for this, > won't they? If the affected packages are replaced before we install a new Cygwin DLL, which correctly checks for execute permissions, the preremove scripts would be replaced with the ones with correct permissions before the problem actually starts to become visible. I don't understand how you suggest to change setup.exe. In theory, it could change permissions of scripts in /etc/preremove and /etc/postinstall on the fly while installing them, as it already does for *.exe files. It could do the same also for .dll files, btw. Is that what you mean? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: HEADSUP maintainers: Packages install scripts without execute permissions
On 6/22/2009 9:12 AM, Corinna Vinschen wrote: Here's the problem: If you exec shell scripts, they should only be run if the user trying to run the script has execute permissions on the script. This requires to check for executability in Cygwin, but as of today, such a check isn't performed in Cygwin. I have the patch for this ready, but I found that it would potentially break a couple of packages which have not set execute permissions on some of their script files. As you should know by now, setup for Cygwin 1.7 will set POSIX file permissions for the files extracted from the tar archives. That means, all scripts which don't have execute permissions set, will also not have execute permissions set after the user installed them. That's bad. So I created a list of packages which install scripts into /etc/preremove, /etc/postinstall, and /usr/bin without setting execute permissions on them. Please guys, fix the permissions ASAP. Users who have existing preremove scripts without execute permissions will still have problems if you change setup.exe to check for this, won't they? Ken
HEADSUP maintainers: Packages install scripts without execute permissions
[Wrong list. Resent to cygwin-apps] Hi, Here's the problem: If you exec shell scripts, they should only be run if the user trying to run the script has execute permissions on the script. This requires to check for executability in Cygwin, but as of today, such a check isn't performed in Cygwin. I have the patch for this ready, but I found that it would potentially break a couple of packages which have not set execute permissions on some of their script files. As you should know by now, setup for Cygwin 1.7 will set POSIX file permissions for the files extracted from the tar archives. That means, all scripts which don't have execute permissions set, will also not have execute permissions set after the user installed them. That's bad. So I created a list of packages which install scripts into /etc/preremove, /etc/postinstall, and /usr/bin without setting execute permissions on them. Please guys, fix the permissions ASAP. Corinna Vinschen: robots: etc/postinstall/robots.sh Reini Urban: perl: usr/bin/cpan5.10.0 usr/bin/shasum5.10.0 Christian Franke: ddrescue: etc/postinstall/ddrescue.sh Jari Aalto: colorgcc: etc/postinstall/colorgcc.sh joe: etc/postinstall/joe-manifest.lst Frank Seelisch: singular-icons: etc/postinstall/singular-icons.sh Dave Korn: gcc-core: etc/postinstall/gcc.sh etc/preremove/gcc.sh gcc-gnat: etc/postinstall/gcc-gnat.sh etc/preremove/gcc-gnat.sh gcc-gdc: etc/postinstall/gcc-gdc.sh etc/preremove/gcc-gdc.sh gcc-gpc: etc/postinstall/gcc-gpc.sh etc/preremove/gcc-gpc.sh gcc-g++: etc/postinstall/gcc-g++.sh etc/preremove/gcc-g++.sh gcc-g77: etc/postinstall/gcc-g77.sh etc/preremove/gcc-g77.sh gcc-java: etc/postinstall/gcc-java.sh etc/preremove/gcc-java.sh Yaakov S: perl-extutils-pkgconfig: etc/postinstall/perl-ExtUtils-Pk libgnome2:etc/preremove/libgnome2.sh gnome-vfs:etc/preremove/gnome-vfs2.sh ilibIDL: etc/postinstall/libIDL.sh libIDL2: etc/postinstall/libIDL2.sh Btw., DLLs should also be executable, otherwise applications will fail to start. I found one of them: glib: usr/bin/cyggmodule-1-2-0.dll Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] task-1.7.1-1 (pinging for awaiting review)
Hi Dave (and Yaakov) THX for the feedback regarding the packaging of task. And sorry for me "pinging" (we had a couple of user who have been asking for task in cygwin though...) I have now fixed the 2 remarks you had: 1) setup.hint removed dependency to cygwin in requires (but http://cygwin.com/setup.html should be update regarding this as it still advises to require cygwin) 2) task-1.7.1-1.src.tar.bz2 OK. Now I understand. I miss-understood the instructions. Thought that only the ready build binary package should install and contain the README file. And not the manual user build. I have now switched to cyport as you recommended (THX for the patches). I have included 2 small changes in the patch file: above mentioned requirement for cygwin disappers and I have also changed the build instructions to use cygport (using ideas and templates for the text from other packages using cygport). I have now re-uploaded the packages (without bumping the version number as the package is not yet in cygwin). So I would appreciate if you could take a new look at the new files at http://taskwarrior.org/download/cygwin/setup.hint http://taskwarrior.org/download/cygwin/task-1.7.1-1-src.tar.bz2 http://taskwarrior.org/download/cygwin/task-1.7.1-1.tar.bz2 Let me know if there are any problems. And thx for your time. /Federico
Re: [RFU 1.7] nasm-2.05-1
On Jun 22 10:15, Dean Scarff wrote: > Upstream release (actually I've missed a couple of minor upstream > releases since the last cygwin package). > > Built for cygwin 1.7. > > wget \ > 'http://scarff.id.au/file/cygwin/nasm/nasm-2.05-1-src.tar.bz2' \ > 'http://scarff.id.au/file/cygwin/nasm/nasm-2.05-1.tar.bz2' > rm -f nasm-2.01-1-src.tar.bz2 nasm-2.01-1.tar.bz2 > > Please upload :) Done. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP 1.7] dbus
On Jun 21 19:23, Yaakov S wrote: > D-Bus is the fd.o IPC framework, which just about all desktop software > is using nowadays. This, and its bindings (ITPs to follow), will be > required for GNOME 2.26, KDE4, and Xfce4 libraries. > > D-Bus defines two separate buses, a system bus and a session bus. The > system bus is installable as a Windows service via csih (thanks Chuck!), > although most software that uses the system bus (e.g. HAL, DeviceKit, > PolicyKit, etc.) is mostly Linux-specific. The session bus is started > with dbus-launch, or it will be launched automatically by apps/xsessions > which need it. > > ftp://ftp.cygwinports.org/pub/cygwinports/release-2/dbus/dbus-1.2.14-1-src.tar.bz2 > ftp://ftp.cygwinports.org/pub/cygwinports/release-2/dbus/dbus-1.2.14-1.tar.bz2 > ftp://ftp.cygwinports.org/pub/cygwinports/release-2/dbus/setup.hint > ftp://ftp.cygwinports.org/pub/cygwinports/release-2/dbus/libdbus1-devel/libdbus1-devel-1.2.14-1.tar.bz2 > ftp://ftp.cygwinports.org/pub/cygwinports/release-2/dbus/libdbus1-devel/setup.hint > ftp://ftp.cygwinports.org/pub/cygwinports/release-2/dbus/libdbus1_3/libdbus1_3-1.2.14-1.tar.bz2 > ftp://ftp.cygwinports.org/pub/cygwinports/release-2/dbus/libdbus1_3/setup.hint This looks good as well. Please upload. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP 1.7] lua
On Jun 21 19:12, Yaakov S wrote: > Per popular request: > > ftp://ftp.cygwinports.org/pub/cygwinports/release-2/Lua/lua/lua-5.1.4-11-src.tar.bz2 > ftp://ftp.cygwinports.org/pub/cygwinports/release-2/Lua/lua/lua-5.1.4-11.tar.bz2 > ftp://ftp.cygwinports.org/pub/cygwinports/release-2/Lua/lua/setup.hint > > category: Interpreters > requires: libgcc1 libreadline6 > sdesc: "Lua programming language interpreter" > ldesc: "Lua is a powerful, light-weight programming language designed > for extending applications. Lua is also frequently used as a > general-purpose, stand-alone language." Looks good. Please upload. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] mintty-0.4.1-1
On Jun 20 22:24, Andy Koppe wrote: > For both 1.5 and 1.7: > > wget http://mintty.googlecode.com/files/mintty-0.4.1-1.tar.bz2 > wget http://mintty.googlecode.com/files/mintty-0.4.1-1-src.tar.bz2 Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
