Please upload opengl-1.1.0-9

2008-12-03 Thread André Bleau

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

2008-12-03 Thread André Bleau

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

2008-12-03 Thread André Bleau

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

2008-12-03 Thread Chris Sutcliffe
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

2008-12-03 Thread Corinna Vinschen
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

2008-12-03 Thread Christopher Faylor
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

2008-12-03 Thread i...@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

2008-12-03 Thread Jon TURNEY

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

2008-12-03 Thread Jon TURNEY

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

2008-12-03 Thread Angelo Graziosi

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

2008-12-03 Thread Brian Keener
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

2008-12-03 Thread corinna
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

2008-12-03 Thread corinna
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

2008-12-03 Thread Corinna Vinschen
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?

2008-12-03 Thread Matt Wozniski
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

2008-12-03 Thread John Emmas

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?

2008-12-03 Thread Julio Emanuel
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

2008-12-03 Thread Brian Dessent
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?

2008-12-03 Thread Brian Dessent
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?

2008-12-03 Thread Julio Emanuel
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

2008-12-03 Thread John Emmas
- 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?

2008-12-03 Thread Corinna Vinschen
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

2008-12-03 Thread Warren Young

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?

2008-12-03 Thread Brian Dessent
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?

2008-12-03 Thread Spiro Trikaliotis
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

2008-12-03 Thread Brian Dessent
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

2008-12-03 Thread Corinna Vinschen
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?

2008-12-03 Thread TheO
 
 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?

2008-12-03 Thread Brian Dessent
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?

2008-12-03 Thread Eric Blake
-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?

2008-12-03 Thread TheO
 
 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?

2008-12-03 Thread TheO
 
 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?

2008-12-03 Thread Eric Blake
-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?

2008-12-03 Thread Brian Dessent
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

2008-12-03 Thread Gustavo Seabra
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?

2008-12-03 Thread TheO
 

 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?

2008-12-03 Thread TheO
 

 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?

2008-12-03 Thread Eric Blake

  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

2008-12-03 Thread Jason Tishler
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

2008-12-03 Thread zzapper
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?

2008-12-03 Thread Larry Hall (Cygwin)

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

2008-12-03 Thread C-Programmer

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

2008-12-03 Thread Eric Blake
-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

2008-12-03 Thread Eric Blake
-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

2008-12-03 Thread Phil Betts
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

2008-12-03 Thread Eric Blake
-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

2008-12-03 Thread Jason Tishler
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