[ANNOUNCEMENT] update: gsl-1.10-1 (GNU Scientific Library)

[Teun Burgers]

The cygwin gsl package (GNU Scientific Library) has been updated
to 1.10-1. This is a new upstream release.

For the announcement of gsl version 1.10 see:

http://sources.redhat.com/ml/gsl-announce/2007/msg1.html

The homepage for the GSL is http://www.gnu.org/software/gsl/

The gsl package comes in four parts:

gsl:   the shared libraries (dlls)
gsl-apps:  gsl-histogram.exe and gsl-randist.exe
gsl-doc:   documentation
gsl-devel: development resources (headers, static- and import
   libraries)

NOTE: Starting from gsl-1.6-2,if you want to use the GSL, your path
should contain /usr/lib/lapack. This directory is added by
/etc/profile.d/lapack.sh. If you use the start-up scripts from the
base-files packages this script is executed automatically.

Teun Burgers

UPDATE
==

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.

  *** 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.









--
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: dd Bug using \.\PhysicalDriveX ?

[Corinna Vinschen]

On Sep 19 14:53, DePriest, Jason R. wrote:
> On 9/19/07, Eric Blake <> wrote:
> > Scalzott, Todd <> writes:
> > > I've discovered what I believe to be a problem with "dd" on several
> > > different XP SP2 systems with Cygwin installed involving the usage of
> > > Windows' \\.\PhysicalDrive nomenclature.
> >
> > That's your problem.  Cygwin is a Linux emulation, and use of Window's \\.\
> > nomenclature is not guaranteed to work.  Using the corresponding posix-y 
> > name
> > is more likely to succeed, in which case the bug is not in dd but in your 
> > usage.
> >
> > [...]
> I concur with Eric Blake.  I have used dd, dd_rescue, aimage, and the
> sleuthkit under Cygwin using the /dev/sdX nomenclature.
> It works once you can figure out which /dev/sdX corresponds to which
> device+partition.

...which isn't that tricky.  In the Disk Management tool (for instance
right click "My Computer" -> "Manage" to get there via the "Computer
Management" admin tool) disks are numbered "Disk 0", "Disk 1", etc.
This order corresponds with /dev/sda, /dev/sdb, etc.  Partitions are
numbered left to right.  /dev/sda1 corresponds to the first partition,
etc.

Similar for CD-ROM and DVD drives.  In the Disk Management tool they are
numbered "CD-ROM 0", "CD-ROM 1", etc, which corresponds to /dev/sr0,
/dev/sr1, etc..  Alternatively to /dev/scd0, /dev/scd1, etc.

For tape drives, have a look into the Device Manager.  The properties
dialog of each tape drive has a tab "Tape Symbolic Name".  Tape0
corresponds to /dev/st0, /dev/nst0, Tape1 to /dev/st1, /dev/nst1, etc.


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: NFS mount problem: portmap error

[DanieleRm]

maybe this is my same problem...
http://www.paul.sladen.org/vserver/archives/200303/0186.html

anyone know how can i solve it?

Thank you

Daniele
-- 
View this message in context: 
http://www.nabble.com/NFS-mount-problem%3A-portmap-error-tf4465246.html#a12792695
Sent from the Cygwin Users 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: file locking problem

[Corinna Vinschen]

On Sep 19 19:30, BJ wrote:
> I have a file locking problem that is solved under Mac and Linux using
> fcntl:
> int lockRepFile (int fd, char lock, size_t from, size_t length) {
> struct flock fl;
> 
>   fl.l_start = from;
>   fl.l_len = length;
>   fl.l_pid = 0;
> 
>   if (lock == 'r') fl.l_type = F_RDLCK;
>   else if (lock == 'w')  fl.l_type = F_WRLCK;
>   else if (lock == 'u')  fl.l_type = F_UNLCK;
>   fl.l_whence = SEEK_SET;
> 
>   return (fcntl(fd, F_SETLKW, &fl));
> }
> 
> Now, unfortunately this hangs occasionally using cygwin - gcc.
> 
> I would appreciate any comments and suggestions on how debug this and how to
> improve the performance i.e. stop it from hanging...

F_SETLKW is supposed to hang if the lock is held by another application.
Use F_SETLK instead.

Apart from that, Cygwin has a problem in that Windows doesn't support
advisory locks as are default on Linux and BSD.  Windows only supports
mandatory locking.  So far Cygwin's fcntl uses Window's mandatory
locking, it doesn't implement its own advisory locking.  Maybe that's
your problem.

If none of the above helps, maybe a more detailed problem report with a
reproducible testcase might be the way to go.  See
http://cygwin.com/problems.html


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/

occasional problem: .bash_profile permission denied

[Ronald Fischer]

I configured my system so that it automatically starts Cygwin
during boot time via the Windows autostart feature, by using
startxwin and Cygwin/X to start several xterm and rxvt terminals,
and also to start one bash shell in plain Cygwin (outside X).

Occasionally, one or two of the shells started that way complain

  bash: /cygdrive/h/.bash_profile: Permission denied

Of course there is nothing wrong with my .bash_profile, and if I
then do a manual

  . .bash_profile

in these shells, everything works manually.

It is certainly not a X specific issue, because it had occured already
in the plain Cygwin shell too.

My first idea was that perhaps that it could be a race condition between
Windows starting the Autostart applications and mounting the network
drives,
because my $HOME is on a network drive. But this would not explain the 
following: When I start several xterm's from my startxwin.bat, it
happens
sometimes that the "permission denied" error occurs on one of the
terminals
started *later*, while the earlier started ones don't have this problem.

Any idea what could be wrong here?

Ronald
-- 
Ronald Fischer <[EMAIL PROTECTED]>
Phone: +49-89-452133-162

--
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: Is there someone offering cygwin paid support?

[Warren Young]

Will Parsons wrote:

why would cygwin be less secure?


The more moving parts, the more things there are to break.

Postulate that you have a program that's been audited to the point that 
you're absolutely certain it's 100% secure when run on Linux.


Then you port it to Cygwin.  Is it secure?  The answer cannot be "Yes" 
until you have also audited Cygwin itself to the same level of assurance.


Just one way it could fail is if there is a buffer overflow in the 
implementation of one of Cygwin's interfaces, and your "100% secure" 
program calls it.  It's then only a matter of time for a skilled hacker 
to turn that buffer overflow into an arbitrary code execution 
vulnerability.  At minimum, the hacker will then have the privileges of 
the program.  Once the hacker has local access, chances are good that he 
can parlay that into a privilege escalation attack, and it's Game Over 
for you.


Security is hard.

--
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: bash: fork: Permission denied -- how can I fix this?

[Dave Korn]

On 19 September 2007 23:28, James Adams wrote:

> I fixed the problem by installing into another directory other than
> C:\cygwin.  I have no idea why this fixes the problem, but probably it has
> something to do with security packages installed on the computer (it's a new
> work laptop which appears to have several security related programs
> installed on it by corporate IT).
> 
> --James

  It might be worth checking the http://cygwin.com/acronyms#BLODA.  I owe
Cygwin 1 FAQ entry for this, in the meantime the latest version of the list
can be seen at

http://cygwin.com/ml/cygwin-talk/2007-q3/msg00174.html


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
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: if [ -w branching: how to spot a locked USB stick

[Fergus]

A couple of months ago

  http://www.cygwin.com/ml/cygwin/2007-07/msg00313.html

I wondered whether a user could use "if [ -w " branching in Cygwin to 
distinguish a locked stick from an unlocked stick. Apparently the answer 
was No but Corinna identified an easy fix


  http://www.cygwin.com/ml/cygwin/2007-07/msg00335.html

I have recently changed to Vista from XP SP2 and amongst other 
annoyances I now find that "if [ -w " branching breaks when the test 
medium is a CD. (It's now reported as "write-able".)


Can anybody confirm this?

The fact that in Vista the directory c:/Windows is not accessible while 
c:/tmp is accessible seems to be correctly reported. The root c:/ is 
inaccessible in a strange new way, to me ("A required privilege is not 
held by the client" instead of "Access is denied") but in fact the 
output from "if -w /c" suggests, wrongly, that it is write-able.


Can anybody confirm this?

I suppose we could all post our individual experiences about how 
disconcertingly horrible Vista is, and how much it has broken or (seems 
to have) got wrong or how much existing established good stuff it has 
merely rendered in need of fixing. I suppose it would soon get wearisome 
for everybody else but I feel, and am, absolutely de-railed by it. 
Currently I am making much use of the command

  export MY_DIR=`cygpath $LOCALAPPDATA`

Fergus


--
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] New package: flip 1.19 -- Convert text file line endings between Unix and DOS formats

[Jari Aalto]

PACKAGE DESCRIPTION
===

Homepage: http://packages.debian.org/sid/flip
License : GPL

Flip converts line endings of text files between MS-DOS and
**IX formats. It detects binary files in a nearly foolproof way and
leaves them alone unless you override this. It will also leave files
alone that are already in the right format and preserves file
timestamps. User interrupts are handled gracefully and no garbage or
corrupted files left behind. 'flip' does not convert files to a
different character set, and it can not handle Apple Macintosh line
endings (CR only). For that (and more), you can use the 'recode'
program (package 'recode').

CHANGES SINCE LAST RELEASE
==

None

INSTALL OR UPGRADE NOTES


Standard install

CYGWIN INSTALLATION INFORMATION
===

To install this package, click on the "Install Cygwin now" link on the
 web page. This downloads setup.exe to your
system. Then, run setup and answer all of the questions. You'll find
the package listed in the "All" category. After installation, read the
documentation at directories:

/usr/share/doc//*
/usr/share/doc/Cygwin/.README

If you have questions or comments, please send them to the Cygwin
mailing list at .

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


This message has been sent to cygwin-announce list.

If you want to unsubscribe from the 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:

cygwin-announce-unsubscribe-you=yourdomain.com AT cygwin.com

More information on unsubscribing can be found:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at the above URL.

-- 
Welcome to FOSS revolution: we fix and modify until it shines

--
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: Re: dd Bug using \.\PhysicalDriveX ?

[Scalzott, Todd]

Thank you for the correction on coreutils.

Yes, I am using cmd.exe.  The quotes are necessary (try it) or dd goes
off searching for an UNC.

I have  no problem using /dev/sdb, etc., but others that need to know
how to do a simple image burn do.  So believe it or not, the physical
drive mapping is easier for them.

Thank you all for your help 

-Original Message-
From: Eric Blake [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 19, 2007 2:24 PM
To: cygwin@cygwin.com
Subject: Re: dd Bug using \.\PhysicalDriveX ?

Scalzott, Todd  kastle.com> writes:

> 
> I believe that this is part of CORE, which I have at 6.9-5.  I did 
> update to all of the latest just a short while ago and reverified the 
> problem.

There's no such thing as CORE in the cygwin distribution; you meant
coreutils.

> 
> I've discovered what I believe to be a problem with "dd" on several 
> different XP SP2 systems with Cygwin installed involving the usage of 
> Windows' \\.\PhysicalDrive nomenclature.

That's your problem.  Cygwin is a Linux emulation, and use of Window's
\\.\ nomenclature is not guaranteed to work.  Using the corresponding
posix-y name is more likely to succeed, in which case the bug is not in
dd but in your usage.

> 
> That is, reading from \\.\PhysicalDrive1 with the below command works
> flawlessly:
> dd if=^\^\.^\PhysicalDrive1 of=tmp.img bs=16384

That's an unusual quoting style; it certainly doesn't work under bash.
Are you by chance trying this under cmd.com?  In which case, why are you
bothering with quoting? cmd.com passes \ through without the need for
quoting.

At any rate, what you probably wanted something more like this (less
typing, and no need for quoting, whether in cmd.com or bash):

dd if=tmp.img of=/dev/sda bs=16K

See http://cygwin.com/cygwin-ug-net/using-specialnames.html for more
details.

--
Eric Blake
volunteer cygwin coreutils maintainer



--
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: Python 2.5.1: Potential Bug in "print"

[Dave Korn]

On 20 September 2007 07:23, Mike MacFerrin wrote:

> I'm a grad student in a Compiler Tools course, and (as part of the course)
> we're compiling a subset of the Python language down to C, and from there
> to x86 Assmebly.  Our code has to pass a lengthy series of test-suites for
> correctness (comparing the output of our compiled C Code with that of
> native Python code), and I stumbled across what seems to be a quirky bug in
> Cygwin Python 2.5.1 (the most recent install). 


> Any suggestions or workarounds?

  Can you roll back your install?  2.4.3 doesn't reproduce the problem.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
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/

CVS STATUS_OBJECT_NAME_INVALID definition missing?

[Brian Ford]

A CVS compile error; FYI:

../../../../cygwin/winsup/cygwin/path.cc: In member function `int
symlink_info::check(char*, const suffix_info*, unsigned int)':
../../../../cygwin/winsup/cygwin/path.cc:3549: error:
`STATUS_OBJECT_NAME_INVALID' undeclared (first use this function)

-- 
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

--
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: Re: dd Bug using \.\PhysicalDriveX ?

[Corinna Vinschen]

On Sep 20 10:14, Scalzott, Todd wrote:
> Thank you for the correction on coreutils.
> 
> Yes, I am using cmd.exe.  The quotes are necessary (try it) or dd goes
> off searching for an UNC.
> 
> I have  no problem using /dev/sdb, etc., but others that need to know
> how to do a simple image burn do.  So believe it or not, the physical
> drive mapping is easier for them.
> 

But it won't work as you expect.  There's special handling for the
raw devices which only works if the used device name is the POSIX
device name.  If you're using the unsupported \\.\foo syntax, you're
on your own.  If it doesn't work... *shrug*.


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: occasional problem: .bash_profile permission denied

[Matthew Woehlke]

Ronald Fischer wrote:

I configured my system so that it automatically starts Cygwin
during boot time via the Windows autostart feature, by using
startxwin and Cygwin/X to start several xterm and rxvt terminals,
and also to start one bash shell in plain Cygwin (outside X).

Occasionally, one or two of the shells started that way complain

  bash: /cygdrive/h/.bash_profile: Permission denied
[snip]
My first idea was that perhaps that it could be a race condition between
Windows starting the Autostart applications and mounting the network
drives, because my $HOME is on a network drive. But this would not
explain the  following: When I start several xterm's from my
startxwin.bat, it happens sometimes that the "permission denied"
error occurs on one of the terminals started *later*, while the
earlier started ones don't have this problem.


I'm not sure that means anything, since it could happen that you start 
one xterm, it gets preempted to run your .bat, which starts another 
xterm that tries to read the not-yet-mounted home drive, and then the 
drive is mounted and the first xterm gets scheduled again.


Does adding a sleep to your .bat help?

--
Matthew
"Passion is inversely proportional to the amount of real information 
available." -- Benford's Law of Controversy

http://en.wikipedia.org/wiki/Benford%27s_law_of_controversy


--
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/

[Packaging BUG] Re: [ANNOUNCEMENT] Updated: mutt-1.4.2.2-2

[Dr. Volker Zell]

> Christopher Faylor writes:

> I've made a new version of 'mutt' available for installation.  Mutt is a
> text mode mail user agent.  This version uses the shared version of
> libiconv which reduces the size of mutt.exe dramatically.  More
> importantly, it fixes the problems that were reported with FAT32
> filesystems:

/etc/{Muttrc|mime.types} will be overridden everytime you install a new 
version. Would it be possible to place both below /etc/defaults/etc and copy 
via 
postinstall script to /etc?

Ciao
  Volker
  

--
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: [Packaging BUG] Re: [ANNOUNCEMENT] Updated: ncftp-3.2.1-1

[Dr. Volker Zell]

> I wrote:

> Jonathan C Allen writes:
>> PACKAGE DESCRIPTION
>> ===

>> ncftp - An improved FTP client 

> A diff between the package listing of the last version and the new
> version shows that all the documentation and man pages are missing.
> It looks like a packaging bug to me.

> Processing package ncftp Version: 3.2.1 Releasenumber: 1
> Cygwin Package Information
> Package  VersionStatus
> ncftp3.2.0-1OK
> 1a2,3
>> etc/postinstall/
>> etc/postinstall/ncftp.sh
> 10a13,38
>> usr/share/
>> usr/share/doc/
>> usr/share/doc/Cygwin/
>> usr/share/doc/Cygwin/ncftp-3.2.0.README
>> usr/share/doc/ncftp-3.2.0/
>> usr/share/doc/ncftp-3.2.0/CHANGELOG.txt
>> usr/share/doc/ncftp-3.2.0/FIREWALLS_AND_PROXIES.txt
>> usr/share/doc/ncftp-3.2.0/index.html
>> usr/share/doc/ncftp-3.2.0/LICENSE.txt
>> usr/share/doc/ncftp-3.2.0/ncftp.html
>> usr/share/doc/ncftp-3.2.0/ncftpbatch.html
>> usr/share/doc/ncftp-3.2.0/ncftpget.html
>> usr/share/doc/ncftp-3.2.0/ncftpls.html
>> usr/share/doc/ncftp-3.2.0/ncftpput.html
>> usr/share/doc/ncftp-3.2.0/ncftpspooler.html
>> usr/share/doc/ncftp-3.2.0/READLINE.txt
>> usr/share/doc/ncftp-3.2.0/README.txt
>> usr/share/doc/ncftp-3.2.0/what_changed_between_v2_v3.txt
>> usr/share/man/
>> usr/share/man/man1/
>> usr/share/man/man1/ncftp.1.gz
>> usr/share/man/man1/ncftpbatch.1.gz
>> usr/share/man/man1/ncftpget.1.gz
>> usr/share/man/man1/ncftpls.1.gz
>> usr/share/man/man1/ncftpput.1.gz
>> usr/share/man/man1/ncftpspooler.1.gz

Ping


--
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: Is there someone offering cygwin paid support?

[Igor Peshansky]

On Thu, 20 Sep 2007, Christopher Faylor wrote:

> On Thu, Sep 20, 2007 at 03:08:55AM -0600, Warren Young wrote:
> >Will Parsons wrote:
> >>why would cygwin be less secure?
> >
> >The more moving parts, the more things there are to break.
> >
> >Postulate that you have a program that's been audited to the point that
> >you're absolutely certain it's 100% secure when run on Linux.
> >
> >Then you port it to Cygwin.  Is it secure?  The answer cannot be "Yes"
> >until you have also audited Cygwin itself to the same level of
> >assurance.
> >
> >Just one way it could fail is if there is a buffer overflow in the
> >implementation of one of Cygwin's interfaces, and your "100% secure"
> >program calls it.  It's then only a matter of time for a skilled hacker
> >to turn that buffer overflow into an arbitrary code execution
> >vulnerability.  At minimum, the hacker will then have the privileges of
> >the program.  Once the hacker has local access, chances are good that
> >he can parlay that into a privilege escalation attack, and it's Game
> >Over for you.
> >
> >Security is hard.
>
> I don't think I've given out a gold star for a clear explanation in a
> long time but can we get one over here?

Certainly: .
Igor
P.S. I also owe quite a few to folks on the cygwin-apps list...
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Belief can be manipulated.  Only knowledge is dangerous.  -- Frank Herbert

--
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: Is there someone offering cygwin paid support?

[Christopher Faylor]

On Thu, Sep 20, 2007 at 03:08:55AM -0600, Warren Young wrote:
>Will Parsons wrote:
>>why would cygwin be less secure?
>
>The more moving parts, the more things there are to break.
>
>Postulate that you have a program that's been audited to the point that
>you're absolutely certain it's 100% secure when run on Linux.
>
>Then you port it to Cygwin.  Is it secure?  The answer cannot be "Yes"
>until you have also audited Cygwin itself to the same level of
>assurance.
>
>Just one way it could fail is if there is a buffer overflow in the
>implementation of one of Cygwin's interfaces, and your "100% secure"
>program calls it.  It's then only a matter of time for a skilled hacker
>to turn that buffer overflow into an arbitrary code execution
>vulnerability.  At minimum, the hacker will then have the privileges of
>the program.  Once the hacker has local access, chances are good that
>he can parlay that into a privilege escalation attack, and it's Game
>Over for you.
>
>Security is hard.

I don't think I've given out a gold star for a clear explanation in a
long time but can we get one over here?

cgf

--
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: Is there someone offering cygwin paid support?

[Dave Korn]

On 20 September 2007 10:09, Warren Young wrote:

> Will Parsons wrote:
>> why would cygwin be less secure?

> Just one way it could fail is if there is a buffer overflow in the
> implementation of one of Cygwin's interfaces, and your "100% secure"
> program calls it.  It's then only a matter of time for a skilled hacker
> to turn that buffer overflow into an arbitrary code execution
> vulnerability.  At minimum, the hacker will then have the privileges of
> the program.  Once the hacker has local access, chances are good that he
> can parlay that into a privilege escalation attack, and it's Game Over
> for you.

  It's worse than that - he's dead, Jim.  Cygwin does actually introduce one
gaping security hole: the shared memory section.

  It's an artifact of the fact that we're trying to emulate an entire posix
system, and so we need to maintain global state across multiple processes.
Because we're not the kernel, we can't just keep process lists and so on in
kernel memory where all processes can access them, so we have to find a way of
sharing memory between different processes in used mode; the shared section is
a way of doing this.

  Unfortunately, that means that low-privilege processes (running as a limited
user) and high-privilege processes (running services as SYSTEM, for example)
have an uncontrolled connection between them.  It's entirely likely that a
guest user, by manipulating the contents of the shared memory section, could
inject code into or otherwise divert or seize control of any SYSTEM-level
cygwin process.

  That's yer privilege escalation right there, that is.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
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: Ls POSIX style slink output

[Matt Seitz (matseitz)]

From: Brian Dessent [mailto:[EMAIL PROTECTED] 
> 
> Yes, those symlinks in /etc are explicitly created with Win32 
> paths by the base-files postinstall script.  I think the 
> reasoning here is that if a POSIX path were used for the 
> target of the symlink then it would have to be updated if the 
> user ever changed the name of the /cygdrive prefix, whereas 
> just using a Win32 path is always correct and insulates from 
> that variable.

I appreciate your taking the time to read my suggestion and respond so
quickly with such a complete clear and complete explanation.  

As an alternative suggestion, how about using forward slashes instead of
backwards slashes ("C:/windows/system32/drivers/etc/hosts") in the
base-files postinstall script?  That would allow pasting the "ls -l"
ouput to "cd", without using the riskier "/cygdrive" prefix.

--
Matt Seitz
Manager, File System Virtualization
Cisco Systems, Inc.
.:|:.:|:.  

--
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: Ls POSIX style slink output

[Brian Dessent]

"Matt Seitz (matseitz)" wrote:

> I appreciate your taking the time to read my suggestion and respond so
> quickly with such a complete clear and complete explanation.
> 
> As an alternative suggestion, how about using forward slashes instead of
> backwards slashes ("C:/windows/system32/drivers/etc/hosts") in the
> base-files postinstall script?  That would allow pasting the "ls -l"
> ouput to "cd", without using the riskier "/cygdrive" prefix.

That would be up to the base-files package maintainer, however I don't
think it's necessary.  As I said the current DLL code already normalizes
symlink targets so if you use a snapshot you will see those links in
POSIX form with "ls -l" even though they're stored on disk as Win32
paths.  If you want a temporary local fix that doesn't involve using a
snapshot you can just recreate the links in any form you want, as the
base-files postinstall will not overwrite or recreate them if they
exist.

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: Ls POSIX style slink output

[Matt Seitz (matseitz)]

From: Brian Dessent [mailto:[EMAIL PROTECTED] 
> 
> That would be up to the base-files package maintainer, 
> however I don't think it's necessary.  As I said the current 
> DLL code already normalizes symlink targets so if you use a 
> snapshot you will see those links in POSIX form with "ls -l" 
> even though they're stored on disk as Win32 paths.  

Good point. I'll look forward to the new release, and just use your
suggested workaround for now.  Thank you again for your help.

--
Matt Seitz
Manager, File System Virtualization
Cisco Systems, Inc.
.:|:.:|:.  

--
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/

Upgrade to git 1.5.3 broke git-commit

[chris ortman]

I just upgraded my cygwin git package to 1.5.3 and how when I try to commit and
allow git to launch vim to enter a commit message i have problems.

The commit message normally has some content already in it, but it is now blank
and won't let me save because it says the file can not be opened for writing.


--
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: Upgrade to git 1.5.3 broke git-commit

[Eric Blake]

chris ortman  gmail.com> writes:

> 
> I just upgraded my cygwin git package to 1.5.3 and how when I try to commit 
and
> allow git to launch vim to enter a commit message i have problems.
> 
> The commit message normally has some content already in it, but it is now 
blank
> and won't let me save because it says the file can not be opened for writing.

IWJFFM.  It sounds like you may have a stale file, or awkward permissions which 
are getting in the way, when vi tries to open and/or overwrite 
the .git/COMMIT_EDITMSG file.

Also, are you using 1.5.24 or a CVS snapshot?  There was a window of CVS 
snapshots that failed to create files on certain filesystems, but that appears 
to be fixed now.  Also, with the latest CVS snapshot, there are still problems 
with pipe behavior that can interfere with gitk and git-gui.

One other thing: git 1.5.3.2 was announced today, and I'll probably be building 
a new package soon.  So it would be nice to ensure that I don't need some sort 
of cygwin-local patch to work around your issue, since I can't reproduce it.

-- 
Eric Blake
volunteer cygwin git maintainer



--
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: Upgrade to git 1.5.3 broke git-commit

[chris ortman]

I am currently on git 1.5.2.2 that came with cygwin.
I'm not sure what permissions are required, and also don't really understand how
setting permissions in cygwin corresponds with XP.

That said, my .git folder looks like
drwxr-xr-x+ and the user is my user name and group is mkgroup-l-d

I used filemon and didn't see any access denied messages.
I also tried creating the .git/COMMIT_EDITMSG file myself but then when i ran
git commit it deleted that file and then told me it couldn't write a new file.

One thing that may be odd about my setup is that i have a c:\code folder that is
substd to q: and then i access files via /cygdrive/q/project/.git



--
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: Upgrade to git 1.5.3 broke git-commit

[Eric Blake]

chris ortman  gmail.com> writes:

> 
> That said, my .git folder looks like
> drwxr-xr-x+ and the user is my user name and group is mkgroup-l-d

You should probably fix that, although I don't know if it will affect your 
problem.
http://cygwin.com/faq/faq.using.html#faq.using.chmod

> git commit it deleted that file and then told me it couldn't write a new file.

Again, what version of cygwin are you using?  Sending the output of 'cygcheck -
svr' as a text attachment is essential for me to do any more analysis.

> Problem reports:   http://cygwin.com/problems.html

-- 
Eric Blake




--
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/

Console background color changes when exiting vi, less, more, man, and possibly other programs

[Chris Cole]

When exiting any of several common programs, the backgound color of
the console is changed.  This has been reported several times,
including as recently as 2006, but no cause has been isolated.  Here
is a reproducible sequence of events that will lead to the failure and
hopefully the solution.  Using the console Properties dialog, Color
tab, set the Screen Background to white.  Using the same dialog,
Layout tab, set the Window Size Width to 160 and Height to 84.
Execute "vi".  Exit it.  The screen background will be set to black.
Execute "clear" to return it to white.

The following widths and heights are the maximum that can be set to
avoid this problem:
149 89
151 88
152 87
154 86
156 85
158 84
160 83

Increasing either the width or the height by one from any pair of
values on this list surfaces the problem.

--
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/

gcc header file help should be a minor problem

[patrickinminneapolis]

I'm trying to get the CSharp Swig Callback example to work with Cygwin.  
I'm just stuck on an include header problem.  

This works fine : 
gcc -c -fpic example.c example_wrap.c

But I want to include files in a different directory, so just to test, I
moved example_wrap.c to c:\ , i tested
gcc -c -fpic -I/cygdrive/c/ example.c example_wrap.c  //failed (couldn't
find example_wrap.c)
gcc -c -fpic -Ic:\ example.c example_wrap.c // that failed (couldn't
find example_wrap.c)
gcc -c -fpic -I\c:\ example.c example_wrap.c // that failed (couldn't
find example_wrap.c)

and a bunch of other combinations, double slashes, etc...  
ultimately i want to include the following: /cygdrive/c/Program\
Files/Microsoft\ Visual\ Studio\ 8/VC/include/ 

thanks
patrick

-- 
View this message in context: 
http://www.nabble.com/gcc-header-file-help-should-be-a-minor-problem-tf4490680.html#a12807222
Sent from the Cygwin Users 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: gcc header file help should be a minor problem

[Greg Chicares]

On 2007-09-20 22:25Z, patrickinminneapolis wrote:
> 
> This works fine : 
> gcc -c -fpic example.c example_wrap.c

I thought that'd give a (harmless) warning about '-fpic', but anyway...

> But I want to include files in a different directory, so just to test, I
> moved example_wrap.c to c:\ , i tested
> gcc -c -fpic -I/cygdrive/c/ example.c example_wrap.c  //failed (couldn't
> find example_wrap.c)

'-I' is for finding headers named in an #include directive. But
'example_wrap.c' is a source file, not a header, so do this:

gcc -c example.c /cygdrive/c/example_wrap.c

--
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: one more thing

[patrickinminneapolis]

>>'-I' is for finding headers named in an #include directive. But
'>>example_wrap.c' is a source file, not a header, so do this:
>>gcc -c example.c /cygdrive/c/example_wrap.c 

example_wrap.c includes , but gcc can't find it, can you tell me
how to tell gcc to look in c:\Program Files\Microsoft Visual Studio
8\VC\include\ for it? 


-- 
View this message in context: 
http://www.nabble.com/gcc-header-file-help-should-be-a-minor-problem-tf4490680.html#a12809503
Sent from the Cygwin Users 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: dd Bug using \.\PhysicalDriveX ?

[DePriest, Jason R.]

On 9/20/07, Corinna Vinschen <[EMAIL PROTECTED]> wrote:
>
> ...which isn't that tricky.  In the Disk Management tool (for instance
> right click "My Computer" -> "Manage" to get there via the "Computer
> Management" admin tool) disks are numbered "Disk 0", "Disk 1", etc.
> This order corresponds with /dev/sda, /dev/sdb, etc.  Partitions are
> numbered left to right.  /dev/sda1 corresponds to the first partition,
> etc.
>
> Similar for CD-ROM and DVD drives.  In the Disk Management tool they are
> numbered "CD-ROM 0", "CD-ROM 1", etc, which corresponds to /dev/sr0,
> /dev/sr1, etc..  Alternatively to /dev/scd0, /dev/scd1, etc.
>
> For tape drives, have a look into the Device Manager.  The properties
> dialog of each tape drive has a tab "Tape Symbolic Name".  Tape0
> corresponds to /dev/st0, /dev/nst0, Tape1 to /dev/st1, /dev/nst1, etc.
>
>
> Corinna
>
> --
> Corinna Vinschen  Please, send mails regarding Cygwin to
> Cygwin Project Co-Leader  cygwin AT cygwin DOT com
> Red Hat

Corinna, thanks for the tip about the order in Disk Management
corresponding to the /dev/sdX order.

I never thought of that since I was always trying to find a tool to
give me the information from the command-line.

That will make things easier in the future.

-Jason

--
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: one more thing

[Larry Hall (Cygwin)]

patrickinminneapolis wrote:

'-I' is for finding headers named in an #include directive. But

'>>example_wrap.c' is a source file, not a header, so do this:
gcc -c example.c /cygdrive/c/example_wrap.c 


example_wrap.c includes , but gcc can't find it, can you tell me
how to tell gcc to look in c:\Program Files\Microsoft Visual Studio
8\VC\include\ for it? 



If I did that, I'd be doing you a disservice.  You don't want to mix and
match stuff from VC++ and gcc/g++.  That's just asking for trouble.  I'd
recommend just changing the reference to "stdio.h" and using gcc's.  If
you simply *must* have 'cstdio', you can install the Boost package (see
'setup.exe') and then use its:

'/usr/include/boost-1_33_1/boost/compatibility/cpp_c_headers/cstdio'



--
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/

Re: one more thing

[Brian Dessent]

patrickinminneapolis wrote:

> example_wrap.c includes , but gcc can't find it, can you tell me
> how to tell gcc to look in c:\Program Files\Microsoft Visual Studio
> 8\VC\include\ for it?

Setting aside for a moment the fact that you're trying to do something
totally wrong and broken, the reason the compiler cannot find 
is that you named the file with a .c extension and are compiling it with
gcc.  If you want to use C++, you need to compile with g++.  If you name
your files with C++ extensions (.cc, .cpp, .C) then gcc will be able to
detect that you want C++ mode and that will also work, however you will
likely get linking errors if you try to link with gcc when you should be
using g++.  In other words: always use g++ when compiling or linking C++
code.

With that out of the way, you're trying to do something nutso by telling
gcc to use MSVC's C++ headers.  There's no way that's going to work. 
Implementations of C++ standard libraries and headers are very tightly
bound to internal details of the compiler, so you have to use gcc's
 if you want to use C++ -- and you shouldn't ever need any
special flags to get the compiler's own C++ headers, providing that you
invoke the right driver.  And even if C++ headers were not tied to the
compiler implementation, g++ and MSVC++ implement different ABIs so
trying to link C++ objects/libraries across vendors will fail.

The only exchange of headers that typically works is when you are
dealing with pure C only, and when the headers are designed to be
generic and portable.  Otherwise, don't expect to be able to point gcc
at MSVC internal headers and have anything but great failure.

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: one more thing

[patrickinminneapolis]

>>If I did that, I'd be doing you a disservice.  You don't want to mix and
>>match stuff from VC++ and gcc/g++.  That's just asking for trouble.  I'd
>>recommend just changing the reference to "stdio.h" and using gcc's.  If
>>you simply *must* have 'cstdio', you can install the Boost package (see
>>'setup.exe') and then use its: 
'/usr/include/boost-1_33_1/boost/compatibility/cpp_c_headers/cstdio'

I can't really change the the header file. SWIG autogenerates
example_wrap.c, so if i start changing it around, i'll be in other kinds of
trouble. Here's what I've been reading, http://www.swig.org/tutorial.html
(scroll down to " Building a C# module") 
-- 
View this message in context: 
http://www.nabble.com/gcc-header-file-help-should-be-a-minor-problem-tf4490680.html#a12810371
Sent from the Cygwin Users 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/