Please upload opengl-1.1.0-9
Please upload opengl-1.1.0-9, keeping 1.1.0-8 as previous. This update should solve the problems that have been reported after the release of new X server, such as: http://cygwin.com/ml/cygwin/2008-11/msg00022.html http://cygwin.com/ml/cygwin-xfree/2008-12/msg3.html The problems were due to some conflict with the last version of the libGL-devel, libGLU-devel, libglut-devel packages. See: http://cygwin.com/ml/cygwin-apps/2008-11/msg00037.html http://cygwin.com/ml/cygwin-apps/2008-11/msg00043.html Unfortunately, users of the opengl package might have to change the way they build their applications. See: http://cygwin.com/ml/cygwin/2008-11/msg00056.html There is a remaining conflict with the w32api package, with a workaround. This would be the subject of another thread. Exerbs from the updated README.txt: --- What has changed since opengl-1.1.0-8 - A new symbolic link, /usr/include/opengl/GL - /usr/include/w32api/GL was added to be able to compile native OpenGL, GLU, GLUT, GLUI, and GLUIX program when the libGL-devel, libGLU-devel, libglut-devel packages are also installed. In that case, compiling with -I/usr/include/opengl is REQUIRED, otherwise the headers from libGL-devel, libGLU-devel, libglut-devel will be used, leading to missing functions at link time. If the libglut-devel package is not installed, you can compile as usual. usr/lib/glut32.lib is now provided. It should used instead of libglut32.a. A bug introduced in opengl-1.1.0-6 was corrected in glut.h. The bug caused the program to continue to run in the background if its window was closed by using the close (X) icon in the title bar. If you prefer to keep that behavior, you must recompile with -DGLUT_DISABLE_ATEXIT_HACK . glut-examples was added to /usr/lib. The helloGLUT example program was improved. FAQ.txt was added. --- Please be aware that the following links are not wget-able. This is a caveat of skydrive. http://cid-83947d81d2c2bf73.skydrive.live.com/browse.aspx/Public/opengl-1.1.0-9.tar.bz2 http://cid-83947d81d2c2bf73.skydrive.live.com/browse.aspx/Public/opengl-1.1.0-9-src.tar.bz2 http://cid-83947d81d2c2bf73.skydrive.live.com/browse.aspx/Public/setup.hint Regards, - André Bleau, Cygwin's volunteer OpenGL package maintainer. Please direct any question or comment about the OpenGL package to cygwin at cygwin dot com _
Conflict betwen the opengl package and the w32api package over libglut32.lib
Hi there. For a very long time, the w32api package has provided /usr/lib/w32api/libglut32.a . I don't know why the w32api package provides libglut32.a ; it is the only glut-related file that it provides. The rest of glut, that is, the glut.h header and the glut32.dll, are provided by the opengl package. This was fine until glut32.dll was updated from 3.7.3 to 3.7.6, which happened at the release of opengl-1.1.0-6. From then, libglut32.a has been missing some hidden functions in the new glut32.dll: ___glutCreateMenuWithExit, ___glutCreateWindowWithExit, and ___glutInitWithExit. I hacked around it in glut.h, but this caused programs to continue to run in the background if their window was closed by using the close (X) icon in the title bar. For opengl-1.1.0-9, I reversed that hack to correct the problem, but now if you include glut.h, you can not link with libglut32.a, as it misses the 3 required functions. The opengl-1.1.0-9 package now includes glut32.lib, and linking with it works well. But: 1- It is ugly. A POSIX environement should not require to link with some .lib file. 2- It forces developers of glut programs to modify their build system. 3- It creates confusion, as there is now 2 files competing for the same goal: libglut32.a and glut32.lib, the first of which don't work anymore. So, I am asking the maintainers of the w32api package to remove libglut32.a. Then I would update the opengl package to include a version that is compatible with the rest of glut. Regards, - André Bleau, Cygwin's volunteer OpenGL package maintainer. Please direct any question or comment about the OpenGL package to cygwin at cygwin dot com _
Conflict betwen the opengl package and the w32api package over libglut32.a
Sorry, I made a typo in the subject of my last message. The rest of the message, http://cygwin.com/ml/cygwin-apps/2008-12/msg6.html is hopefully correct! - André Bleau, Cygwin's volunteer OpenGL package maintainer. Please direct any question or comment about the OpenGL package to cygwin at cygwin dot com _
Re: Conflict betwen the opengl package and the w32api package over libglut32.lib
Hey André, So, I am asking the maintainers of the w32api package to remove libglut32.a. Then I would update the opengl package to include a version that is compatible with the rest of glut. I'm comfortable with doing this, but I've taken it to the MinGW-dvlpr list just to make sure that it won't cause any issues. Chris -- Chris Sutcliffe http://emergedesktop.org
Re: Please upload opengl-1.1.0-9
On Dec 3 10:24, Andr? Bleau wrote: Please upload opengl-1.1.0-9, keeping 1.1.0-8 as previous. [...] Please be aware that the following links are not wget-able. This is a caveat of skydrive. :( Don't you have some other provider to upload files? Cygwin.com is a remote system only accessible by ssh and the only way to fetch these files would be to fetch them first to my local machine, and then upload them to cygwin.com. That's really inconvenient. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Please upload cron-4.1-7
On Wed, Dec 03, 2008 at 01:06:28PM -0500, Pierre A. Humblet wrote: Please upload cron-4.1-7 and delete the oldest version http://mysite.verizon.net/phumblet/cron-4.1-7/cron-4.1-7.tar.bz2 http://mysite.verizon.net/phumblet/cron-4.1-7/cron-4.1-7-src.tar.bz2 Uploaded. cgf
Invitation to submit your software at Sooftware.com
Dear Sir or Madam, we noticed you are in software development business and you also promote your software on the internet. We would like to invite you, to submit your software at http://www.sooftware.com. You can submit directly by PAD file, or open a free publishers account. Software submission form is located at http://www.sooftware.com/submit-software.html. Please contact us, if we can help in any way. Best wishes, Sooftware.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X, backingstore and opengl
Angelo Graziosi wrote: Jon TURNEY wrote: I'm sorry, your our previous mail hadn't really made it clear to me that there was problem with glxgears etc. Just for my comprehension, can you explain again what happens if you run glxinfo and glxgears on 1.5.3-4. Really, in my posts, I never cited 'glxgears', 'glxinfo' etc. Sincerely, I do not know what they are... Ah, I'm sorry. By OpenGL demos you mean the ones which come with ROOT. glxgears, glxinfo are GL demo programs which come with mesa (the OpenGL library) It would be useful if you could install the mesa package and check if glxinfo, glxgears work for you. I have written: 1. Adding +bs at command line which starts XWin (in startxwin.bat) and then trying to run some ROOT macro (hsimple.C etc.) both ROOT and XWin-1.5.3-4 (from [1]) segfault. Using YOUR XWin with debug info etc., ROOT, hsimple.C etc. work fine, i.e. NO segfault etc. 2. Adding +bs at command line which starts XWin (in startxwin.bat) and then trying to run some ROOT OPENGL macro (geom/shapes.C, for example see [2]) then the macro fails to be excuted (see [2]), but it works if I omit '+bs' OR if I use the workaround described here [3] OR if I use YOUR debug XWin.exe! MAY YOU try [1] with the steps described in [2] and confir/or not the segfaults? Yes, I have tried running the ROOT application, but I am afraid I cannot reproduce your problem. Irrespective of if I use +bs or not, with 1.5.3-4, simple.C runs ok, geom/shapes.C causes ROOT to segfault unless XLIB_SKIP_ARGB_VISUALS is used. You should raise the ROOT segfault as an issue with the ROOT developers. They will be far more qualified to diagnose the issue than me. If you wouldn't mind trying again, I've built a slightly different debug version, which you can get from: ftp://cygwin.com/pub/cygwinx/XWin.20081203132739.exe.bz2 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: fonts and xterm
JP de Vooght wrote: Hello all, I have recently updated to the newest XWin and have noticed the following on my Vista laptop: - whenever I open an xterm as indicated below, the scrollbar does not work and the window is not rendered at the bottom and on the right where small bands reveal the background; is this an xterm problem that will be fixed? Or some omission on my part? xterm -sb -rightbar -fg white -bg black -e /bin/bash --login -i This is a bit vague as to, for e.g. if the scrollbar is drawn and works correctly when it is on the left. - I can't seem to fix the problem with finding Times-Roman for applications such as graphviz which I had resolved previously - where is Times-Roman now? I had resolved previously: then why not do whatever you did last time to resolve it? I guess you might have obtained a times.ttf file from somewhere (perhaps C:\Windows\Fonts) In which case, being aware [1] that fonts have moved from /usr/X11R6/lib/X11/fonts to /usr/share/fonts, you'll probably want to obtain that file again and put it in /usr/share/fonts/TTF [1] http://cygwin.com/ml/cygwin-xfree-announce/2008-11/msg0.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X, backingstore and opengl
Jon TURNEY wrote: glxgears, glxinfo are GL demo programs which come with mesa (the OpenGL library) It would be useful if you could install the mesa package and check if glxinfo, glxgears work for you. You have ignored my cygchec.out here [1]. I have those packages installed and glxgears, glxinfo seem to work (see opengl.txt below). Irrespective of if I use +bs or not, with 1.5.3-4, simple.C runs ok, geom/shapes.C causes ROOT to segfault unless XLIB_SKIP_ARGB_VISUALS is used. You should raise the ROOT segfault as an issue with the ROOT developers. They will be far more qualified to diagnose the issue than me. The fact that also XWin segfaults, means it isn't a problem only for ROOT developers... If you wouldn't mind trying again, I've built a slightly different debug version, which you can get from: ftp://cygwin.com/pub/cygwinx/XWin.20081203132739.exe.bz2 Just for completeness, I have tried and IT WORKS JUST FINE and without XLIB_SKIP_ARGB_VISUALS! Respect to the previous testing-XWin you have proposed, with XWin.20081203132739 also the keyboard works just fine!!! So, I doubt we are referring to the same failing XWin which one finds on the mirrors... Cheers, Angelo. --- [1] http://cygwin.com/ml/cygwin-xfree/2008-11/msg00332.html opengl.txt.bz2 Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Recent X11 upgrade and getting _gl?? Undefined references compiling another package
Jon TURNEY wrote: OPENGL_INCLUDE_DIR /usr/include OPENGL_gl_LIBRARY/usr/lib/w32api/libopengl32.a OPENGL_glu_LIBRARY /usr/lib/w32api/libglu32.a I suspect you might have the problem discussed here: http://cygwin.com/ml/cygwin-apps/2008-11/msg00036.html That was it. thanks bk -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/doc ChangeLog ntsec.sgml
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2008-12-03 11:47:27 Modified files: winsup/doc : ChangeLog ntsec.sgml Log message: * ntsec.sgml: Revamp parts of the doc for clearness. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.162r2=1.163 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/ntsec.sgml.diff?cvsroot=srcr1=1.19r2=1.20
src/winsup/cygwin ChangeLog libc/minires.c
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2008-12-03 16:37:53 Modified files: winsup/cygwin : ChangeLog winsup/cygwin/libc: minires.c Log message: * libc/minires.c (open_sock): Set non blocking and close on exec. (res_ninit): Set id pseudo-randomly. (res_nsend): Do not set close on exec. Initialize server from id. Flush socket. Tighten rules for answer acceptance. (res_nmkquery): Update id using current data. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4310r2=1.4311 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/libc/minires.c.diff?cvsroot=srcr1=1.4r2=1.5
Re: [Patch] Minires update
On Dec 3 11:25, Pierre A. Humblet wrote: This patch syncs the built-in minires with the latest packaged version. Also attaching the files to guarantee format preservation. Pierre 2008-12-03 Pierre A. Humblet [EMAIL PROTECTED] * libc/minires.c (open_sock): Set non blocking and close on exec. (res_ninit): Set id pseudo-randomly. (res_nsend): Do not set close on exec. Initialize server from id. Flush socket. Tighten rules for answer acceptance. (res_nmkquery): Update id using current data. Applied with a very minor change: Index: minires.c === RCS file: /cvs/src/src/winsup/cygwin/libc/minires.c,v retrieving revision 1.4 diff -u -p -r1.4 minires.c --- minires.c 1 Apr 2008 10:22:33 - 1.4 +++ minires.c 3 Dec 2008 02:57:26 - @@ -1,6 +1,6 @@ /* minires.c. Stub synchronous resolver for Cygwin. - Copyright 2006 Red Hat, Inc. + Copyright 2008 Red Hat, Inc. The Copyright should keep the old dates, like this: Copyright 2006, 2008 Red Hat, Inc. Thanks! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Finally managed to create a jailed SFTP server, but how secure?
On Wed, Dec 3, 2008 at 2:43 AM, Albert van der Velde wrote: I followed this discussion, but does an ftp server exist with a possibility to lock a user in its home directory preventing him to get out of this jail. Are you sure you were understanding this conversation? It was about SFTP, not FTP - they're very different, though related in terms of the interface they expose... ~Matt -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Socket programming with Cygwin
Hi guys, For the past few weeks I've been struggling to compile a program that uses sockets. Actually, the program compiles and builds okay but the client can never connect to the server. This morning I found this simple example that implements client/server socket comms in just a few modules (probably no more than 200 lines of code, in total). http://tldp.org/LDP/LG/issue74/tougher.html I thought this would be a great way to test the process but even this simple sample won't work under Cygwin (although it builds and works fine under Linux). In every case, the programs fail when the client attempts to connect to the server. This would be a typical line:- status = ::connect ( m_sock, ( sockaddr * ) addr, sizeof ( addr ) ); 'status' receives -1 and if I check the error it's invariably something like Connection refused (assume for the sake of argument that the supplied parameters are valid because the same programs work fine under Linux). Do I need to enable something in Cygwin for sockets to work? e.g. should I have previously run a service using cygrunsrv? I'm running out of things to try and there seems to be very little that could go wrong. I'd be grateful for any suggestions. Thanks John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Finally managed to create a jailed SFTP server, but how secure?
Hi, all Cygwinners! I've been following this thread with most interest, because I've been thinking in setting up some kind of chroot'ed SFTP environment myself. The tone of the answers are, however, consistent with what I've already saw in similar threads in the last months. Yet, I still consider that this kind of answer is lacking the informative part as in It's not secure BECAUSE From the answers in this and many other threads, and a little gray-matter shaking(tm) I think I can try to put in words all the implications around this kind of setup. Please feel free to correct me, as this is also a confirmation-probe from myself to the list-gurus: 1) Chroot-like features are not supported natively in Windows. Not even close. Period; 2) Chroot, although configurable in the sshd-config, is not implemented in sshd (or sftp) but in the Cygwin DLL itself. You can, for example, do a chroot on demand with the chroot(1) command in a bash prompt - see man chroot. 3) From 1) and 2) you can easily guess that any native windows command couldn't care less about any chroot configuration or command because it just does not exist in their environment! 4) Only commands compiled for Cygwin, AND accessing the file system exclusively through the Cygwin POSIX interfaces can (and will) obey the chroot settings; 5) So, the bottom line is, for the particular SFTP scenario: As long as you don't give any executable possibilities to the remote users, you should stay safe. As far as I can tell, SFTP (and SSHD) fits the scenario in 4). Now for my own doubt: why is everyone walking (running) away from making a statement such as 5)? Is there an easy (or difficult, whatever) way for anyone execute commands in a SFTP command line? Thanks for your wisdom! ___ Julio Costa On Wed, Dec 3, 2008 at 7:29 AM, TheO [EMAIL PROTECTED] wrote: Hi again, I am afraid I have to ask for clarification again :(, I hope this is the last time before I am on my own with this: No, you cannot hide it. It is created by Cygwin itself as a convenience to access the virtual 'cygdrive' directory. This is one of a number of virtual directories ('/proc' and '/dev' come to mind) that Cygwin supports. See the description of Special filenames in the User's Guide for more details. I understand why all these virtual directories are necessary at the absolute '/' root level. But here I refer to /cygdrive which is created inside the jail directory, which means in absolute path, /jail/cygdrive (/jail being the root of my jail). Inside the jail, only /cygdrive is created, no other virtual directories (/proc or /dev/xxx) or files are created. In 1.7, there is a new authentication module that will solve these and other pubkey authentication problems. But 1.7 is not currently released and it's release date is not decided. Thanks for this input. I suppose that to be on safe side, I must restrict it to password based authentication only if I use the current Cygwin. And finally one more question. I am only aware of two subsystems supported by sshd more or less implicitely; sftp and shell (interactive logon). Is there any other subsystems which are handled by sshd implicitely (without me having to add anything to /etc/sshd_config)? Thanks again. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Socket programming with Cygwin
John Emmas wrote: In every case, the programs fail when the client attempts to connect to the server. This would be a typical line:- status = ::connect ( m_sock, ( sockaddr * ) addr, sizeof ( addr ) ); 'status' receives -1 and if I check the error it's invariably something like Connection refused (assume for the sake of argument that the supplied parameters are valid because the same programs work fine under Linux). The call fails because addr is junk, because the demo passed localhost to inet_pton. According to the docs, this function only takes IP addresses. If you change simple_client_main.cpp to use an IP address instead of localhost the example works for me. (It should really be modified to do a hostname lookup.) This example really isn't that great in that it's apparently relying on some non-standard behavior of glibc's inet_pton. Do I need to enable something in Cygwin for sockets to work? e.g. should I have previously run a service using cygrunsrv? I'm running out of things to try and there seems to be very little that could go wrong. I'd be grateful for any suggestions. Thanks No, you don't need to install any service to use regular sockets. The plethora of network tools in the distro (e.g. apache, curl, openssh, proftpd, lftp, wget, etc) that use sockets and that build without any special modifications should be an indication that this should just work. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Finally managed to create a jailed SFTP server, but how secure?
Julio Emanuel wrote: 4) Only commands compiled for Cygwin, AND accessing the file system exclusively through the Cygwin POSIX interfaces can (and will) obey the chroot settings; This is not valid reasoning, as Eric Blake already pointed out you can still access files outside of a chroot even if you're still going through the Cygwin DLL by using Win32 style pathnames since Cygwin passes those through untouched. Whether or not you can trick the sftp code into letting such a filename through remains to be seen, but the point here is that just because the access occurs via the Cygwin API doesn't mean the chroot is absolute. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Finally managed to create a jailed SFTP server, but how secure?
On Wed, Dec 3, 2008 at 11:01 AM, Brian Dessent [EMAIL PROTECTED] wrote: Julio Emanuel wrote: 4) Only commands compiled for Cygwin, AND accessing the file system exclusively through the Cygwin POSIX interfaces can (and will) obey the chroot settings; This is not valid reasoning, as Eric Blake already pointed out you can still access files outside of a chroot even if you're still going through the Cygwin DLL by using Win32 style pathnames since Cygwin passes those through untouched. Aha! So this is the tiny bit that was missing! What you are saying is that the Cygwin DLL does not honor the chroot if the path is in WIN32 format? But why is that? It shouldn't honor the chroot all the time? I mean, this sounds like the right thing to do(tm), if Cygwin is supposed to fully support chroot environments... Whether or not you can trick the sftp code into letting such a filename through remains to be seen, but the point here is that just because the access occurs via the Cygwin API doesn't mean the chroot is absolute. Right. Point taken. Although, this could be answered with a patch (a ugly-cygwin-only patch) to the sftp/sshd package to filter all the Windowish file paths that came across, right? I known that it is an ugly solution, but surely it would settle the worries for this specific (but more and more frequent) chrooted sftp scenario. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Socket programming with Cygwin
- Original Message - From: Brian Dessent Subject: Re: Socket programming with Cygwin The call fails because addr is junk, because the demo passed localhost to inet_pton. According to the docs, this function only takes IP addresses. If you change simple_client_main.cpp to use an IP address instead of localhost the example works for me. (It should really be modified to do a hostname lookup.) Brian - you were absolutely right and thanks very much for taking the time to build this project. Forgive me - but as someone who's very new to socket programming, I'm confused about why the program worked when I built it under Linux. Is it because something would have converted localhost to an IP address (is this the lookup stuff that you referred to?) and where can I find out a bit more about all this? Thanks, John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Finally managed to create a jailed SFTP server, but how secure?
On Dec 3 11:38, Julio Emanuel wrote: On Wed, Dec 3, 2008 at 11:01 AM, Brian Dessent [EMAIL PROTECTED] wrote: Julio Emanuel wrote: 4) Only commands compiled for Cygwin, AND accessing the file system exclusively through the Cygwin POSIX interfaces can (and will) obey the chroot settings; This is not valid reasoning, as Eric Blake already pointed out you can still access files outside of a chroot even if you're still going through the Cygwin DLL by using Win32 style pathnames since Cygwin passes those through untouched. Aha! So this is the tiny bit that was missing! What you are saying is that the Cygwin DLL does not honor the chroot if the path is in WIN32 format? But why is that? It shouldn't honor the chroot all the time? I mean, this sounds like the right thing to do(tm), if Cygwin is supposed to fully support chroot environments... The final, definitive answer which I already gave last month, and also already years ago. It's all in the archives. It's *impossible* for any kind of Windows user space environment, be it called Cygwin or whatever, to restrict applications to a chroot jail. The reason is that the underlying OS, Windows, does not support this concept. We can restrict application using the Cygwin open call to the jail, but every application is free to call the Win32 call CreateFile or the native NT call NtOpenFile directly, thus circumventing any effort made in the Cygwin DLL easily. So, that's it. Chroot looks interesting on the surface, but implementing it on Windows is eventually just a hoax due to missing OS support. Don't use it. It provides a false sense of security. Actually it's one of my Cygwin inventions I'd rather forget about. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Socket programming with Cygwin
John Emmas wrote: confused about why the program worked when I built it under Linux. As Brian said, glibc's inet_pton() is apparently doing something beyond what the standard requires. Cygwin doesn't use glibc, it uses a different standard C library called newlib. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Finally managed to create a jailed SFTP server, but how secure?
Julio Emanuel wrote: Aha! So this is the tiny bit that was missing! What you are saying is that the Cygwin DLL does not honor the chroot if the path is in WIN32 format? But why is that? It shouldn't honor the chroot all the time? I mean, this sounds like the right thing to do(tm), if Cygwin is supposed to fully support chroot environments... I haven't verified that this is the case, but I suspect that it is. The general philosophy of most of the path handling code is that Win32 paths bypass all Cygwin logic entirely. There are still lots of people that try to use Win32 paths with Cygwin tools despite the fact that it's not supposed to be how things are done (and discouraged.) As to whether it should try to special-case this situation and disallow the use of Win32 paths if a chroot is in effect, I'm not sure if it makes sense. As others in the thread have already said, the chroot feature is meant to be necessary but not sufficient, if you will. I.e. it's a convenience, not an enforecement. Most of the time when you encounter a program that's been put in a chroot jail the reasoning is so that if there is some kind of exploitable vulnerability in that program an attacker cannot gain access to the rest of the system outside of the jail. In this scenario the chroot provided by Cygwin provides zero protection, because if the attacker can run exploit code then can just call directly to the Win32 APIs and bypass Cygwin entirely. No amount of protection in the DLL will ever change this basic fact, so just seems to me like you'd be furthering the illusion of security by trying to add more checks. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Finally managed to create a jailed SFTP server, but how secure?
Hello Julia, * On Wed, Dec 03, 2008 at 11:38:20AM + Julio Emanuel wrote: On Wed, Dec 3, 2008 at 11:01 AM, Brian Dessent [EMAIL PROTECTED] wrote: This is not valid reasoning, as Eric Blake already pointed out you can still access files outside of a chroot even if you're still going through the Cygwin DLL by using Win32 style pathnames since Cygwin passes those through untouched. Aha! So this is the tiny bit that was missing! It was already mentioned elsethread. [...] I known that it is an ugly solution, but surely it would settle the worries for this specific (but more and more frequent) chrooted sftp scenario. But the problem here is: This is just one single problem instance that would (or might) have been fixed. No-one ever cared to check if there are other possibilities. In order to be safe, you would have to audit all relevant parts to find out if there might be other attack vectors. And from the answers, it is clear that no-one of the cygwin developers will take that route, as it is not the aim of the project. Like it or not, but that's how it is currently. Best regards, Spiro. -- Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Socket programming with Cygwin
John Emmas wrote: Forgive me - but as someone who's very new to socket programming, I'm confused about why the program worked when I built it under Linux. Is it because something would have converted localhost to an IP address (is this the lookup stuff that you referred to?) and where can I find out a bit more about all this? Using the older/classic Berkeley API, the socket app calls gethostbyname() to convert a hostname to an address. The newer modern API is getaddrinfo() which has a slightly different interface and is more friendly for name lookups that could return IPv6 results. If you google sockets programming tutorial or the like I'm sure you can find some detailed guides. Keep in mind when reading these things that the native Windows socket API is Winsock, which is similar to the Berkeley socket API but has significant differences. One of the advantages of Cygwin is that you do *not* use the Winsock API, you use Berkeley/POSIX socket API, so don't try to use any Winsock tutorials or example code. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Socket programming with Cygwin
On Dec 3 04:29, Brian Dessent wrote: John Emmas wrote: Forgive me - but as someone who's very new to socket programming, I'm confused about why the program worked when I built it under Linux. Is it because something would have converted localhost to an IP address (is this the lookup stuff that you referred to?) and where can I find out a bit more about all this? Using the older/classic Berkeley API, the socket app calls gethostbyname() to convert a hostname to an address. The newer modern API is getaddrinfo() which has a slightly different interface and is more friendly for name lookups that could return IPv6 results. ... but is only available starting with Cygwin 1.7. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Finally managed to create a jailed SFTP server, but how secure?
This is not valid reasoning, as Eric Blake already pointed out you can still access files outside of a chroot even if you're still going through the Cygwin DLL by using Win32 style pathnames since Cygwin passes those through untouched. Whether or not you can trick the sftp code into letting such a filename through remains to be seen, but the point here is that just because the access occurs via the Cygwin API doesn't mean the chroot is absolute. I am just trying to be logical here. I am exporting only SFTP access to users. Well at least that's what I want, I don't know whether somehow user is able spawn another application via SSHD using something which I am not aware yet. This is one of my questions which hasn't been answered so far (what subsystems are handled internally by SSHD apart from shell and sftp?). So logically, with just SFTP available, what user can do is limited to basically; cd, mkdir, rmdir, get, put, rename, rm. Simply put, he can only manipulate files and directories. And if I understand correctly, one of the possible way for user to bypass check by Cygwin is to use Win32 reserved file names. identifying what filenames are reserved by Win32, this is what I've got (please complete it if I am missing something): Dos devices: CON, COMn, LPTn, AUX, PRN, NUL (n=0, 1, ...) Named Pipes: \\.\Pipe\foo Physical Driver: \\.\PhysicalDriveN (N=0, 1, ...) I tried the following commands from a jailed sftp session: sftp get PRN Fetching /home/user/PRN to PRN Couldn't read from remote file /home/user/PRN : Failure sftp put foo PRN Uploading foo to /home/Administrator/prn foo 100%4 0.0KB/s 00:01 Couldn't write to remote file /home/Administrator/PRN: Permission denied Invalid command. sftp get CON Fetching /home/user/CON to CON Couldn't get handle: Permission denied sftp put foo CON Uploading foo to /home/Administrator/CON Couldn't get handle: Permission denied sftp get NUL Fetching /home/user/NUL to NUL *** successful transfer *** sftp put NUL Uploading NUL to /home/Administrator/NUL NUL100%0 0.0KB/s 00:00 *** successful transfer *** sftp get LPT1 Fetching /home/user/LPT1 to LPT1 Couldn't read from remote file /home/user/LPT1 : Failure sftp get //./Pipe/foo Couldn't stat remote file: No such file or directory File //./Pipe/foo not found. sftp put foo //./Pipe/foo Uploading foo to //./Pipe/foo Couldn't get handle: No such file or directory sftp get COM1 *** stuck *** So far, the only successful transfer is using NUL device (which is harmless) and the one which cause problem was accessing COM1. The client was stuck and I had to kill the SSHD daemon to restore it. If this is the only problem, I can remove all COMn from the host Windows. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Finally managed to create a jailed SFTP server, but how secure?
TheO wrote: identifying what filenames are reserved by Win32, this is what I've got (please complete it if I am missing something): No, we mean get c:/dir/file or get c:\dir\file. (or put //hostname/share/file, shudder.) Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Finally managed to create a jailed SFTP server, but how secure?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to TheO on 12/3/2008 5:57 AM: And if I understand correctly, one of the possible way for user to bypass check by Cygwin is to use Win32 reserved file names. identifying what filenames are reserved by Win32, this is what I've got (please complete it if I am missing something): Dos devices: CON, COMn, LPTn, AUX, PRN, NUL (n=0, 1, ...) Named Pipes: \\.\Pipe\foo Physical Driver: \\.\PhysicalDriveN (N=0, 1, ...) You still haven't tested a biggie (that we've already told you about): DOS file names: c:\path\to\file If someone can convince a remote sftp client to ask your SFTP server to transfer a DOS file name, then the remote machine has effectively looked outside of your jail, because cygwin cannot place DOS filenames inside the chroot. And we are unlikely to slow down cygwin just to plug this hole in the chroot facade, because we aren't interested in auditing what other holes may exist. I don't see why you persist in asking when we've already told you the answer, five times over. chroot does _not_ add security in a cygwin environment, nor will we ever be able to make it add security. It merely adds a facade that makes it easier to port Linux apps that use chroot; and it is up to you, not us, to verify whether that facade is sufficient for your needs, because we don't plan on spending the time to audit it. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk2hZEACgkQ84KuGfSFAYAuwQCcDoGIv1AEN2Le5gRGF4+VYb72 TaQAn1o4eSoPoaoAjRDGak8cPlSmhNg8 =xPny -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Finally managed to create a jailed SFTP server, but how secure?
No, we mean get c:/dir/file or get c:\dir\file. (or put //hostname/share/file, shudder.) This is what I get: sftp cd C:/ Couldn't canonicalise: No such file or directory sftp get C:/foo Couldn't stat remote file: No such file or directory File /home/Administrator/C:/foo not found. Thanks. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Finally managed to create a jailed SFTP server, but how secure?
This is what I get: sftp cd C:/ Couldn't canonicalise: No such file or directory sftp get C:/foo Couldn't stat remote file: No such file or directory File /home/Administrator/C:/foo not found. More to come: sftp cd /cygdrive sftp ls -al dr-xr-xr-x1 root root0 Jan 1 1970 . drwxr-xr-x5 root root0 Dec 1 13:17 .. *** note c/ is missing here *** sftp cd c Couldn't canonicalise: No such file or directory sftp put foo C:/ Uploading foo to /cygdrive/C:/ Couldn't get handle: No such file or directory -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Finally managed to create a jailed SFTP server, but how secure?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to TheO on 12/3/2008 6:29 AM: No, we mean get c:/dir/file or get c:\dir\file. (or put //hostname/share/file, shudder.) This is what I get: sftp cd C:/ Couldn't canonicalise: No such file or directory That's with /. What about with \? The cygwin dll sometimes treats the two separators differently, where using \ is more likely to bypass cygwin checks. And what about Brian's other point - if sshd has a security bug like a buffer overrun (shudder, but possible - look at how often openssh has been updated over the years to fix security holes as soon as someone identifies one), then the attacker merely need exploit the buffer overrun to inject code that calls a native Windows API. Harder to exploit? Yes. But certainly _much_ more of a worry than whether or not you have hidden undesirable file names from honest users. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk2jBkACgkQ84KuGfSFAYAZqQCeOq4Xd19ThRoXeKNRnEmJKhRZ mDEAoJ2UdYEHXhYBLfKWrzvuhQbWXCyN =ttsH -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Finally managed to create a jailed SFTP server, but how secure?
Eric Blake wrote: That's with /. What about with \? The cygwin dll sometimes treats the two separators differently, where using \ is more likely to bypass cygwin checks. Don't forget the other variants, like \\.\c:\foo\bar \\./c:/foo/bar \??\c:\foo\bar \??/c:\foo\bar \??/c:/foo/bar Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
gcc4/gfortran
Hi All, I recently made a fresh new Cygwin installation. I asked for the full installation of the devel category to be installed, which resulted in both gcc and gcc4 to be installed. (BTW, great work with gcc4 package, thanks a lot!!!) I wonder: 1. Is is safe to remove the old gcc (3.*) packages and replace them by symlinks to the new gcc4 executables? 2. In this case, which executables should I point the symlink to? For instance, if I were to replace g77 by a symlink to gfortran, which of the 4 gfortran executables should I use: $ locate gfortran | grep exe /bin/gfortran-4.exe /bin/i686-pc-cygwin-gfortran-4.exe /usr/bin/gfortran-4.exe /usr/bin/i686-pc-cygwin-gfortran-4.exe 3. Lastly, just a dumb question: why do we get multiple executables in the first place? I noticed that g77 also comes in multiple files: $ locate g77 | grep exe /bin/g77.exe /usr/bin/g77.exe Is that really necessary? Thanks a lot, -- Gustavo Seabra Postdoctoral Associate Quantum Theory Project - University of Florida Gainesville - Florida - USA -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Finally managed to create a jailed SFTP server, but how secure?
Don't forget the other variants, like \\.\c:\foo\bar \\./c:/foo/bar \??\c:\foo\bar \??/c:\foo\bar \??/c:/foo/bar I will try different variants definitely. Unfortunately I can only give the feedback tomorrow as I am away from the office now. Thanks for your input. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Finally managed to create a jailed SFTP server, but how secure?
And what about Brian's other point - if sshd has a security bug like a buffer overrun (shudder, but possible - look at how often openssh has been updated over the years to fix security holes as soon as someone identifies one) Such hole would affect all OpenSSH implementation. Even the Linux version. Am I correct? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Finally managed to create a jailed SFTP server, but how secure?
And what about Brian's other point - if sshd has a security bug like a buffer overrun (shudder, but possible - look at how often openssh has been updated over the years to fix security holes as soon as someone identifies one) Such hole would affect all OpenSSH implementation. Even the Linux version. Am I correct? On one level, yes - if the bug is in the sshd code, then there is a good chance all OpenSSH ports would have the same buffer overflow bug (unless the bug is in a platform-dependent #ifdef section). But on another level, _no_, and that is what we are trying to tell you. On Linux, if someone can exploit a buffer overflow, ALL they can corrupt is the chroot jail - the rest of your system is _untouched_. On Cygwin, if someone can exploit a buffer overflow, the ENTIRE OS is up for grabs, and they can alter any file they want, because the OS is not enforcing a chroot jail. One other point: on Cygwin, you have the potential for a buffer overflow in cygwin1.dll (we hope not, but it is possible), which could mean that the cygwin sshd is vulnerable based on the .dll it links against while the same version of sshd on Linux is secure. I suppose the converse is true - a buffer overflow in glibc could make the Linux sshd vulnerable while the Cygwin version is fine; but remember that more people tend to audit glibc code than cygwin code. -- Eric Blake -- View this message in context: http://www.nabble.com/Finally-managed-to-create-a-jailed-SFTP-server%2C-but-how-secure--tp20775267p20815125.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated Cygwin Package: python-2.5.2-1
New News: === I have updated the version of Python to 2.5.2-1. The tarballs should be available on a Cygwin mirror near you shortly. The following are the only notable changes since the previous release: o upgrade to Python 2.5.2 o include pre-built sqlite3 module o include patches for the following issues: - http://bugs.python.org/issue2233 - http://bugs.python.org/issue2234 Old News: === Python is an interpreted, interactive, object-oriented programming language. If interested, see the Python web site for more details: http://www.python.org/ Please read the README file: /usr/share/doc/Cygwin/python-2.5.2.README since it covers requirements, installation, known issues, etc. Standard News: To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. If you have questions or comments, please send them to the Cygwin mailing list at: cygwin@cygwin.com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: zsh-4.3.9-1
Peter A. Castro wrote in An updated version of zsh (zsh-4.3.9-1) has been released and should be at a mirror near you real soon. This is an upstream release. Thanks Peter. I just needed to do a rebaseall gvim /usr/share/doc/Cygwin/rebase*.readme -- zzapper http://www.successtheory.com/tips/vimtips.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Finally managed to create a jailed SFTP server, but how secure?
TheO wrote: Larry Hall wrote: No, you cannot hide it. It is created by Cygwin itself as a convenience to access the virtual 'cygdrive' directory. This is one of a number of virtual directories ('/proc' and '/dev' come to mind) that Cygwin supports. See the description of Special filenames in the User's Guide for more details. I understand why all these virtual directories are necessary at the absolute '/' root level. But here I refer to /cygdrive which is created inside the jail directory, which means in absolute path, /jail/cygdrive (/jail being the root of my jail). Inside the jail, only /cygdrive is created, no other virtual directories (/proc or /dev/xxx) or files are created. Created or not, they exist. Try it. In 1.7, there is a new authentication module that will solve these and other pubkey authentication problems. But 1.7 is not currently released and it's release date is not decided. Thanks for this input. I suppose that to be on safe side, I must restrict it to password based authentication only if I use the current Cygwin. This removes the impersonation piece of the puzzle, yes. And finally one more question. I am only aware of two subsystems supported by sshd more or less implicitely; sftp and shell (interactive logon). Is there any other subsystems which are handled by sshd implicitely (without me having to add anything to /etc/sshd_config)? Can't answer that. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Using -mno-cygwin causes different program behavior
Hello, Here's the source: #include stdio.h int main(){ /* local variable */ char name[25]; printf(What is your name?\n); gets( name ); printf(Hello, %s!\n,name); } If I compile using the following command line argument: $ gcc -o ioProg1 ioProg1.c I check to see which DLL it's using which of course is cygwin1.dll and the program works as expected. But if I compile using the following command line argument: $ gcc -mno-cygwin -o ioProg1 ioProg1.c I find that the DLL being used is msvcrt.dll and the program behaves as if the gets( name ); line had come before the printf(What is your name?); line. Very strange! Any ideas on why this is happening? Thanks! -- View this message in context: http://www.nabble.com/Using--mno-cygwin-causes-different-program-behavior-tp20825507p20825507.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc4/gfortran
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Gustavo Seabra on 12/3/2008 7:38 AM: 1. Is is safe to remove the old gcc (3.*) packages and replace them by symlinks to the new gcc4 executables? Read the archives. Dave has mentioned that he is planning on a future packaging of the gcc packages that use the alternatives package, so that the symlink management of the name gcc can be done automatically to point to either gcc-3 or gcc-4. But at the moment, I'm not sure whether the gcc-4 package requires files provided by the gcc package, in which case blindly deleting all thing gcc 3.* might break gcc-4. 2. In this case, which executables should I point the symlink to? For instance, if I were to replace g77 by a symlink to gfortran, which of the 4 gfortran executables should I use: $ locate gfortran | grep exe /bin/gfortran-4.exe /bin/i686-pc-cygwin-gfortran-4.exe These are identical copies; one is the name preferred when cross-compiling, the other when doing native compiles. But why worry about adding symlinks? Why not just rely on what the package gave you, since it works? Are you really that low on disk space? I suppose they could be made hardlinks to one another, if someone were to invest the time into patching setup.exe to attempt to make hardlinks (instead of its current behavior of blindly creating identical copies, even when the tar file specifies hardlinks). /usr/bin/gfortran-4.exe /usr/bin/i686-pc-cygwin-gfortran-4.exe These two are identical to the ones above - you need to read the manual, and remind yourself that /bin and /usr/bin are mount points that visit the same directory. Removing /bin/gfortran-4.exe would simultaneously make /usr/bin/gfortran-4.exe disappear. 3. Lastly, just a dumb question: why do we get multiple executables in the first place? I noticed that g77 also comes in multiple files: $ locate g77 | grep exe /bin/g77.exe /usr/bin/g77.exe Is that really necessary? Yes, because that's how the default mount points are set up. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk3NDcACgkQ84KuGfSFAYC44gCgy4e7MwOMh9RO1Z+pZVPhZfE8 ZOIAoLF9YRTAbGc6SHz/cvGjcsMPON02 =nQAf -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Using -mno-cygwin causes different program behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to C-Programmer on 12/3/2008 6:29 PM: But if I compile using the following command line argument: $ gcc -mno-cygwin -o ioProg1 ioProg1.c Then you are no longer using cygwin, and this is almost more of a question for the mingw list. I find that the DLL being used is msvcrt.dll and the program behaves as if the gets( name ); line had come before the printf(What is your name?); line. Very strange! Any ideas on why this is happening? Yes. It's called buffering. Native Windows apps have no idea that cygwin emulates pty's with pipes, and blindly assume that all pipes are non-interactive. For performance reasons, when talking to a non-interactive client, all stdio libraries perform block buffering instead of line buffering when stdout is determined to be non-interactive. So, because you are running a native windows app in a cygwin console, your app doesn't realize that you wanted line buffering, and so you don't see output until 4k or end of process, even though the printf completed before the gets. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk3NVQACgkQ84KuGfSFAYBbLgCg1fPBj1EjWjV//aa8FZ5+TSNA 4KUAoKiFDW6hFR0hJD857TNEa7gSAiFK =usqi -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Using -mno-cygwin causes different program behavior
Eric Blake wrote on Thursday, December 04, 2008 1:42 AM:: According to C-Programmer on 12/3/2008 6:29 PM: But if I compile using the following command line argument: $ gcc -mno-cygwin -o ioProg1 ioProg1.c Then you are no longer using cygwin, and this is almost more of a question for the mingw list. I find that the DLL being used is msvcrt.dll and the program behaves as if the gets( name ); line had come before the printf(What is your name?); line. Very strange! Any ideas on why this is happening? Yes. It's called buffering. Native Windows apps have no idea that cygwin emulates pty's with pipes, and blindly assume that all pipes are non-interactive. For performance reasons, when talking to a non-interactive client, all stdio libraries perform block buffering instead of line buffering when stdout is determined to be non-interactive. So, because you are running a native windows app in a cygwin console, your app doesn't realize that you wanted line buffering, and so you don't see output until 4k or end of process, even though the printf completed before the gets. You beat me to it. I would only add that it is a mistake to rely on the default buffering mode of stdio, particularly for interactive programs. If you require a specific mode, you should always set it using one of the functions setbuf, setbuffer, setlinebuf, or setvbuf. In this case, you should call setlinebuf(stdout) to ensure that the newline flushes the output. If instead, you wanted the input to appear on the same line as the prompt, you would need to call setbuf(stdout, 0) to force unbuffered output. Alternatively, you can just call fflush(stdout) before calling gets(). Phil -- This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Using -mno-cygwin causes different program behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to C-Programmer on 12/3/2008 6:29 PM: char name[25]; gets( name ); PS. This is a _disaster_ waiting to happen. You just coded a buffer overflow exploit, where someone can supply a name with more than 25 bytes, and in so doing, overwrite the stack return pointer to jump into arbitrary code and thus execute whatever they want using your program as the gateway. PLEASE don't write code this evil in real life. Use getline(), fgets(), fread(), properly-written fscanf(), or the like, but NEVER gets(). - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk3P+QACgkQ84KuGfSFAYDh2ACfSsrD2vc1vBj3LdDC2DzvD8Z/ LHIAoLI76s26ASySD9+CVAgy6e5uQ+3W =jv+5 -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Updated Cygwin Package: python-2.5.2-1
New News: === I have updated the version of Python to 2.5.2-1. The tarballs should be available on a Cygwin mirror near you shortly. The following are the only notable changes since the previous release: o upgrade to Python 2.5.2 o include pre-built sqlite3 module o include patches for the following issues: - http://bugs.python.org/issue2233 - http://bugs.python.org/issue2234 Old News: === Python is an interpreted, interactive, object-oriented programming language. If interested, see the Python web site for more details: http://www.python.org/ Please read the README file: /usr/share/doc/Cygwin/python-2.5.2.README since it covers requirements, installation, known issues, etc. Standard News: To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. If you have questions or comments, please send them to the Cygwin mailing list at: [EMAIL PROTECTED] . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6