Re: Every time I run ssh, ssh prompts "password:" with latest OpenSSH package.
Hi Andrey, > This is not the right solution. Right solution would be to change your keys. > While DSA keys aren't inherently insecure (quite opposite), FIPS compliant > systems enforce DSA key length to 1024 bits, which is considered to be weak > nowadays. You CAN use longer DSA keys, but not all systems support it. I created a new 2048-bit RSA key and confirmed that ssh works fine with this key & latest OpenSSH package without PubkeyAcceptedKeyTypes configuration. Thanks, Hiroyuki Kurokawa 2015-09-03 12:48 GMT+09:00 Andrey Repin : > Greetings, Hiroyuki Kurokawa! > >> Thanks Andrey for reply to my question. > >> George gave me an advice by a direct mail. >> And his instruction solve my problem. > >>> If you use dsa key type, you need to add to your ssh client configuration >>> file, either ~/.ssh/config or /etc/ssh_config, the following parameter: >>> >>> PubkeyAcceptedKeyTypes +ssh-dss >>> >>> If you use some other key type, then 'ssh -Q key' will list all supported >>> key types, pick the right one and put it into config file instead of >>> ssh-dss. >>> >>> I had the same problem after the last ssh upgrade. > >> Now the latest ssh works fine with ~/.ssh/config which contains >> "PubkeyAcceptedKeyTypes +ssh-dss" because a type of my key is DSA. > >> I appreciate George so much. > > This is not the right solution. Right solution would be to change your keys. > While DSA keys aren't inherently insecure (quite opposite), FIPS compliant > systems enforce DSA key length to 1024 bits, which is considered to be weak > nowadays. You CAN use longer DSA keys, but not all systems support it. > > > -- > With best regards, > Andrey Repin > Thursday, September 3, 2015 06:46:29 > > Sorry for my terrible english... > -- 黒川裕之 kurok...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Every time I run ssh, ssh prompts "password:" with latest OpenSSH package.
Greetings, Hiroyuki Kurokawa! > Thanks Andrey for reply to my question. > George gave me an advice by a direct mail. > And his instruction solve my problem. >> If you use dsa key type, you need to add to your ssh client configuration >> file, either ~/.ssh/config or /etc/ssh_config, the following parameter: >> >> PubkeyAcceptedKeyTypes +ssh-dss >> >> If you use some other key type, then 'ssh -Q key' will list all supported >> key types, pick the right one and put it into config file instead of ssh-dss. >> >> I had the same problem after the last ssh upgrade. > Now the latest ssh works fine with ~/.ssh/config which contains > "PubkeyAcceptedKeyTypes +ssh-dss" because a type of my key is DSA. > I appreciate George so much. This is not the right solution. Right solution would be to change your keys. While DSA keys aren't inherently insecure (quite opposite), FIPS compliant systems enforce DSA key length to 1024 bits, which is considered to be weak nowadays. You CAN use longer DSA keys, but not all systems support it. -- With best regards, Andrey Repin Thursday, September 3, 2015 06:46:29 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Every time I run ssh, ssh prompts "password:" with latest OpenSSH package.
Hi,
Thanks Andrey for reply to my question.
George gave me an advice by a direct mail.
And his instruction solve my problem.
> If you use dsa key type, you need to add to your ssh client configuration
> file, either ~/.ssh/config or /etc/ssh_config, the following parameter:
>
> PubkeyAcceptedKeyTypes +ssh-dss
>
> If you use some other key type, then 'ssh -Q key' will list all supported key
> types, pick the right one and put it into config file instead of ssh-dss.
>
> I had the same problem after the last ssh upgrade.
Now the latest ssh works fine with ~/.ssh/config which contains
"PubkeyAcceptedKeyTypes +ssh-dss" because a type of my key is DSA.
I appreciate George so much.
Best Regards,
Hiroyuki Kurokawa
2015-09-03 1:47 GMT+09:00 Andrey Repin :
> Greetings, Hiroyuki Kurokawa!
>
>> Hi,
>
>> The ssh command keeps prompting "password:" repeatedly with the latest
>> OpenSSH package after I started ssh-agent and registered key with
>> ssh-add command.
>> Followings are my environment.
>
>> % uname -a
>> CYGWIN_NT-10.0 win8 2.2.1(0.289/5/3) 2015-08-20 11:42 x86_64 Cygwin
>> % ssh -V
>> OpenSSH_7.1p1, OpenSSL 1.0.2d 9 Jul 2015
>
>> If I install back the older OpenSSH package ("OpenSSH_6.9p1, OpenSSL
>> 1.0.2d 9 Jul 2015"), then ssh prompt "password:" only once. Old
>> version works fine!
>> I confirmed that "OpenSSH_7.0p1, OpenSSL 1.0.2d 9 Jul 2015" has same
>> problem as "OpenSSH_7.1p1, OpenSSL 1.0.2d 9 Jul 2015".
>> And I can see same behavior on another machine which OS is windows7.
>
>> So, I believe the latest OpenSSH_7.1p1 & 7.0p1 have same problem.
>
>> If I miss anything, please let me know.
>
> You miss the -vvv log from both client and server.
>
>
> --
> With best regards,
> Andrey Repin
> Wednesday, September 2, 2015 19:46:55
>
> Sorry for my terrible english...
>
--
黒川裕之
kurok...@gmail.com
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Is a disk image created within dd "safe"?
Greetings, Clint Olsen! > I'm also interested in generating images to preserve the entire disk. > What I'm wondering is whether doing this on a live system through > Cygwin would produce a safe, bootable disk image or if the the APIs > that Cygwin has to use or having the disk mounted would make this > unreliable? Bootable? Likely. Safe? not even in the slightest. And as Eric pointed out, this has nothing to do with Cygwin. > A friend speculated that dd might complain about open files or > some-such thing. You don't have files on a block device level. >.< Tell your friend to speculate something better. > I went and tried it on /dev/sda and it seemed to work > without complaining. With conv=noerror ? I'm wondering, what did you expect? > Example: > $ dd if=/dev/sda of=/path/to/NAS/sda.img bs=512 conv=noerror,sync bs=4k at least. NTFS uses 4k clusters by default, there's no reason to use smaller chunks to read it. Actually, even bigger chunks may greatly speed up the read. conv is just bogus. You are trying to create a mess of the image with these options. You don't want any padding. You don't want errors ignored. Writing disk image to NAS uncompressed is even more questionable. Consider piping it through some archiver. > It would be great if something like this would work since dd is so > ubiquitous that I could restore a drive in a number of ways and not > lock me into something proprietary. It wouldn't work. Not directly. For a number of reasons. If you still intend to do it, at the very least consider using ERUNT for registry snapshots. That will let you have a consistent registry copy even if the one in image would turn up damaged. -- With best regards, Andrey Repin Thursday, September 3, 2015 04:50:29 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: setting up private mirror
Greetings, Chris Louden! > I'm currently searching the mailing list archive as well as google but > I thought I would ask out right aw well.. I'm looking to implement a > private Cygwin mirror. The process seem fairly straight forward > setting up an apache instance and rsycing twice a day. However our > NetSec folks have asked is there is any way I can sync the local repo > via an authenticated or encrypted method. I guess to rule out a man in > the middle scenario. If anyone has done anything similar I would > appreciate the feedback. Probably. You could get setup.ini from some secure source and check hashes of the packages after sync. I didn't check if there's any available, but supposedly there should be at least one. -- With best regards, Andrey Repin Thursday, September 3, 2015 04:45:27 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygwin's ping requires privilege elevation.
Greetings, All! I had this issue running for some time, but recently I've (with a little help from my friends) stumbled upon another Cygwin rip-off, and the hack they implemented to get around this issue. (Yes, they just renamed the ping.exe to cygping.) I understand, that some of the ping functionality, indeed, require raw device access, but if it is possible to avoid elevated calls for basic functions, that would be highly appreciated. -- With best regards, Andrey Repin Thursday, September 3, 2015 04:13:09 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [cygwin] Re: Is a disk image created within dd "safe"?
On 09/02/2015 04:23 PM, Jason Pyeron wrote: >> There are various solutions that CAN capture an accurate >> point-in-time disk snapshot. > > For cygwin/Windows use the Volume Shadow Service (VSS). I have used (XP) > cygwin dd and rsync to take (clone) images from the VSS managed drive. What's more, if you are running your Windows machine as a virtual machine on top of qemu/kvm, you can install qemu-guest-agent into your Windows setup, and set things up so that when the hypervisor wants to take a snapshot of your guest, the guest-agent can coordinate with VSS to make the point in time correspond to completely stable I/O (all databases flushed and so forth, so the captured disk state is stable as if you had gracefully powered off) rather than just a random state of unflushed I/O (the disk state is as if you have yanked the power cord, and may have missing transactions; hope your file system had decent journaling if you wanted it to be consistent). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
RE: [cygwin] Re: Is a disk image created within dd "safe"?
> -Original Message- > From: Eric Blake > Sent: Wednesday, September 02, 2015 6:06 PM > > On 09/02/2015 03:57 PM, Clint Olsen wrote: > > > I'm also interested in generating images to preserve the > entire disk. > > What I'm wondering is whether doing this on a live system through > > Cygwin would produce a safe, bootable disk image or if the the APIs > > that Cygwin has to use or having the disk mounted would make this > > unreliable? don't do it with out snapshots... > There are various solutions that CAN capture an accurate > point-in-time disk snapshot. For cygwin/Windows use the Volume Shadow Service (VSS). I have used (XP) cygwin dd and rsync to take (clone) images from the VSS managed drive. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: [ANNOUNCEMENT] New: sl-5.02-1
Mike DePaulo sent the following at Tuesday, September 01, 2015 7:47 PM >On 09/01/2015 07:13 PM, Jared Buck wrote: [...] >> On Tue, Sep 1, 2015 at 4:07 PM, Yaakov Selkowitz >> wrote: >>> The following package has been added to the Cygwin distribution: >>> >>> * sl-5.02-1 >>> >>> SL (Steam Locomotive) runs across your terminal when you type 'sl' >>> as you meant to type 'ls'. It's just a joke command, and not useful at >>> all. > >Damnit Yaakov! You beat me to packaging this. > >I guess my packaging train wasn't fast enough. > >These are really funny btw: http://manpages.org/sl/6 >https://github.com/mtoyoda/sl/pull/31 >https://github.com/mtoyoda/sl/pulls Please upgrade to ver 5.04. It has unicorns! - Barry Disclaimer: Statements made herein are not made on behalf of NIAID.
Re: Is a disk image created within dd "safe"?
On 09/02/2015 03:57 PM, Clint Olsen wrote: > I'm also interested in generating images to preserve the entire disk. > What I'm wondering is whether doing this on a live system through > Cygwin would produce a safe, bootable disk image or if the the APIs > that Cygwin has to use or having the disk mounted would make this > unreliable? The answer is the same on non-cygwin systems. ANY attempt to sequentially read a disk while some other entity may be actively modifying the same disk is doomed to capture incomplete (and probably unusable) state. > > A friend speculated that dd might complain about open files or > some-such thing. I went and tried it on /dev/sda and it seemed to work > without complaining. dd won't complain, but it also won't capture an accurate image. There is a difference between the block layer (read each sector of the disk, regardless of what is happening in other sectors due to file system activity) and the file system layer (read multiple files one at a time, regardless of which sectors the file system currently maps those files to). The only safe way to use dd to clone a disk is if the disk is not currently mounted by any filesystem that might be actively modifying sectors in the block device. There are various solutions that CAN capture an accurate point-in-time disk snapshot. For example, on Linux, you can use LVM and create an LVM snapshot, which separates all data at a given point in time from all further changes to the live disk, so that you can then do a background task that reads the snapshot without worrying about data going inconsistent, and so that the guest can continue to run with the live overlay. Many SAN storage vendors sell specific solutions along these lines, and it is also a hot topic with virtual machine solutions. But in every case, these sorts of solutions require additional storage hierarchies (they are not copying /dev/sda directly, so much as exposing /dev/sda as a layer on top of other storage such that the actual snapshot operation utilizes that other storage for the background copy-on-write overlay magic). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Is a disk image created within dd "safe"?
Hi: I currently use Cygwin and rsync to provide Time Machine-like functionality to a NAS on my home network. This works fine for user data. I'm also interested in generating images to preserve the entire disk. What I'm wondering is whether doing this on a live system through Cygwin would produce a safe, bootable disk image or if the the APIs that Cygwin has to use or having the disk mounted would make this unreliable? A friend speculated that dd might complain about open files or some-such thing. I went and tried it on /dev/sda and it seemed to work without complaining. Example: $ dd if=/dev/sda of=/path/to/NAS/sda.img bs=512 conv=noerror,sync It would be great if something like this would work since dd is so ubiquitous that I could restore a drive in a number of ways and not lock me into something proprietary. Thanks, -Clint -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
setting up private mirror
Hello, I'm currently searching the mailing list archive as well as google but I thought I would ask out right aw well.. I'm looking to implement a private Cygwin mirror. The process seem fairly straight forward setting up an apache instance and rsycing twice a day. However our NetSec folks have asked is there is any way I can sync the local repo via an authenticated or encrypted method. I guess to rule out a man in the middle scenario. If anyone has done anything similar I would appreciate the feedback. -Chris -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.1
Corinna Vinschen writes: > This is the "new POSIX ACL handling reloaded" release. Oh joy… I just have no time to test it thoroughly (or even at all) during the next three weeks. I'll try to at least install it locally tomorrow (the mirrors hadn't cought up in the afternoon) and give it a quick look. > - setfacl(1) now accepts the combination of the -b and -k options, just as > on Linux (here's looking at you Achim ;)). Blush… thanks, that'll make fixing build directories actual one-liners like I had hoped for some time. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] New: hunspell-1.3.3-1
On Sat, 2015-08-29 at 16:52 -0400, Ken Brown wrote: > On 8/29/2015 1:15 PM, Ken Brown wrote: > > hunspell seems to have a problem with UTF-8: > > > > $ hunspell > > error: unknown encoding UTF8: using iso88591 as fallback > > error: unknown encoding UTF8: using iso88591 as fallback > > error: unknown encoding UTF8: using iso88591 as fallback > > error: unknown encoding UTF8: using iso88591 as fallback > > > > I have LANG=en_US.UTF-8 in my environment. If I unset LANG, the error > > message > > goes away. > > The problem seems to be that /usr/share/myspell/en_US.aff starts with "SET > UTF8" > Changing that to "SET UTF-8" fixes it. The same problem exists in the > other > en_*.aff files. Thanks for the details. Fixed in 2015.08.24-2: https://github.com/cygwinports/scowl/commit/09652ef -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problems with ssh connection
Looks like I hit a wall with this problem. I would appreciate if someone could help out with this issue. On 2015-08-17 21:39, yaro...@hotmail.com wrote: I have Cygwin installed on a couple of servers in a domain environment. Of all machines regular user accounts can ssh to only one box. Once installed I configured Cygwin using the following in a .bat file. c:\cygwin\bin\bash --login -c "chmod +r /etc/passwd" c:\cygwin\bin\bash --login -c "chmod u+w /etc/passwd" c:\cygwin\bin\bash --login -c "chmod +r /etc/group" c:\cygwin\bin\bash --login -c "chmod u+w /etc/group" c:\cygwin\bin\bash --login -c "chown -R domain_account /var/empty" c:\cygwin\bin\bash --login -c "chmod 755 /var/empty" c:\cygwin\bin\bash --login -c "chown domain_account /etc/ssh*" c:\cygwin\bin\bash --login -c "chmod 755 /var/" c:\cygwin\bin\bash --login -c "touch /var/log/sshd.log" c:\cygwin\bin\bash --login -c "chown domain_account /var/log/sshd.log" c:\cygwin\bin\bash --login -c "chmod 664 /var/log/sshd.log" c:\cygwin\bin\bash --login -c "editrights -l -u domain_account" c:\cygwin\bin\bash --login -c "editrights -a SeAssignPrimaryTokenPrivilege -u domain_account" c:\cygwin\bin\bash --login -c "editrights -a SeCreateTokenPrivilege -u domain_account" c:\cygwin\bin\bash --login -c "editrights -a SeTcbPrivilege -u domain_account" c:\cygwin\bin\bash --login -c "editrights -a SeServiceLogonRight -u domain_account" c:\cygwin\bin\bash --login -c "editrights -l -u domain_account" c:\cygwin\bin\bash --login -c "/bin/ssh-host-config -y -c ntsec -u domain_account -w “password" Somehow the permissions on the sshd_config file are diferent on the box where the sftp connection works -rw-r--r-- 1 my_domain_account root 3679 Jul 24 12:44 /etc/sshd_config where on all others I see -rw-r--r-- 1 domain_account Administrators 3584 Jul 26 20:51 /etc/sshd_config where the domain_account is the account under which the Cygwin service is running. When checking NTFS permissions I see in both cases the domain_account as the owner. I read somewhere that I need to run chown root:system /etc/password to fix the permissions but the account reports as invalid. Same if I try just root or just system. Am I even close focusing on the permissions of sshd_config? No idea why they're different. I think I used the same method on all servers but there were not installed at the same time so it's possible I messed something up. I don't want to break the working box keeping it as a reference. On others I noticed that a regular domain user can connect when their accounts get added to local admins which is what I would like to avoid. The permissions on the box that works was a false route as I found another folder with cygwin in the root of C: probably some old install. The cygwin service however points to the one I installed and when a non-admin user connects via sftp that's where they go. Interestingly the user I spoke to when testing isn't even listed in the passwd file which is indeed how it's supposed to work. For a test I enabled debugging on both a non-working and the reference server with sshd.exe -ddd and here are the results: sshd_BAD $ /usr/sbin/sshd.exe -ddd debug2: load_server_config: filename /etc/sshd_config debug2: load_server_config: done config len = 310 debug2: parse_server_config: config /etc/sshd_config len 310 debug3: /etc/sshd_config:54 setting AuthorizedKeysFile .ssh/authorized_keys debug3: /etc/sshd_config:110 setting UsePrivilegeSeparation yes debug3: /etc/sshd_config:126 setting Subsystem sftp /usr/sbin/sftp-server debug3: /etc/sshd_config:134 setting KexAlgorithms diffie-hellman-group-exchange -sha1,diffie-hellman-group1-sha1 debug3: kex names ok: [diffie-hellman-group-exchange-sha1,diffie-hellman-group1- sha1] debug1: sshd version OpenSSH_6.8, OpenSSL 1.0.2c 12 Jun 2015 debug1: private host key #0: ssh-rsa SHA256:cyhqUDzDQqpRdUnq9LM9gsrF1lAps77z8T+6 XGzUoPM debug1: private host key #1: ssh-dss SHA256:TvdQxsRU4heg4GJzMb02F6UNylL08eLcz70d s841a0o debug1: private host key #2: ecdsa-sha2-nistp256 SHA256:/Snnl/4giq+ll/tCefiA1Jov nP3blcjChmQ0WS74S6M debug1: private host key #3: ssh-ed25519 SHA256:gpGLcdqxU+D+gZiTp1Je5GRSfoEwFhw2 k2zWLIHe5zE debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-ddd' debug2: fd 3 setting O_NONBLOCK debug3: sock_set_v6only: set socket 3 IPV6_V6ONLY debug1: Bind to port 22 on ::. Server listening on :: port 22. debug2: fd 4 setting O_NONBLOCK debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug1: fd 5 clearing O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 8 config len 310 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: inetd sockets after dupping: 3, 3 Connection from Client_IP port 58319 on 159.156.122.40 port 22 debug1: Client protocol version 2.0; client software version WinSCP_release_4.1.9 debug1: no match:
Re: [OT] Wine + Cygwin: `script -e` exit status forwarding randomly return zero for non zero child process
Dear folks, here is a few update: This bug was originally found with MSYS2, but I've confirm it happens on Cygwin (CYGWIN_NT-5.1 2.2.1(0.289/5/3) 2015-08-20 11:40 i686 Cygwin) as well. For convenient of compile&test I'm mostly debugging on MSYS2, which is rebased above the below Cygwin commit: commit 7f3efa3b65e50b35d4e9f895e625e0878edc196a Author: Corinna Vinschen Date: Tue Aug 25 22:23:01 2015 +0200 winsup.h: Claim Windows 10 support In theory the testing result should be similar enough to recent Cygwin. Forgive me for not compiling Cygwin, I can do that again if anyone ask. Here is some update of debugging information: I added a breakpoint in pinfo::maybe_set_exit_code_from_windows, and started `script -e -c "exit 5"`, with my customer compiled script.exe from util-linux. script.exe hits the breakpoints twice in every debugging session. The following statements are for the first hit point since I found different status in the first hit point for different script.exe exit status. >From my test, whenever script.exe forwards the exit status correctly (returns 5), oexitcode in pinfo::maybe_set_exit_code_from_windows is set to 0x8000500; whenever script.exe forwards the exit status wrongly (returns 0), oexitcode in pinfo::maybe_set_exit_code_from_windows is set to 0x0. Here is some debugging log (gdb) r Starting program: /scripts2/util-linux/src/build-i686-pc-msys/script.exe -e -c "exit 5" [New Thread 253.0x106] [New Thread 253.0xb7] [New Thread 253.0x88] Script started, file is typescript Script done, file is typescript [Switching to Thread 253.0x88] Breakpoint 1, pinfo::maybe_set_exit_code_from_windows()@4 (this=0xa0b70c) at /scripts2/msys2-runtime/src/msys2-runtime/winsup/cygwin/pinfo.cc:183 183 DWORD x = 0xdeadbeef; (gdb) n 184 DWORD oexitcode = self->exitcode; (gdb) 186 if (hProcess && !(self->exitcode & EXITCODE_SET)) (gdb) p/x oexitcode $3 = 0x0 (gdb) bt #0 pinfo::maybe_set_exit_code_from_windows()@4 (this=0xa0b70c) at /scripts2/msys2-runtime/src/msys2-runtime/winsup/cygwin/pinfo.cc:186 #1 0x610c51b1 in proc_waiter (arg=0x611cae80 ) at /scripts2/msys2-runtime/src/msys2-runtime/winsup/cygwin/pinfo.cc:1042 #2 0x61004955 in cygthread::callfunc(bool)@8 (this=0x611b97f0 , issimplestub=false) at /scripts2/msys2-runtime/src/msys2-runtime/winsup/cygwin/cygthread.cc:51 #3 0x61004ae0 in cygthread::stub(void*)@4 (arg=0x611b97f0 ) at /scripts2/msys2-runtime/src/msys2-runtime/winsup/cygwin/cygthread.cc:93 #4 0x610058bd in _cygtls::call2(unsigned long (*)(void*, void*), void*, void*)@16 (this=0xa0ce64, func=0x6100495a , arg=0x611b97f0 , buf=0xa0b818) at /scripts2/msys2-runtime/src/msys2-runtime/winsup/cygwin/cygtls.cc:111 #5 0x61005726 in _cygtls::call (func=0x6100495a , arg=0x611b97f0 ) at /scripts2/msys2-runtime/src/msys2-runtime/winsup/cygwin/cygtls.cc:30 #6 0x6108d5e2 in threadfunc_fe (arg=0x611b97f0 ) at /scripts2/msys2-runtime/src/msys2-runtime/winsup/cygwin/init.cc:32 #7 0x7bc83d80 in ?? () #8 0x7bc86e2f in ?? () #9 0x7bc83d5e in ?? () #10 0x7bc8e01f in ?? () #11 0xb7561f16 in ?? () ---Type to continue, or q to quit--- Regarding the functions in 0x7bc83d80: No symbols here because of limitation of using gdb for windows on top of Wine. this module is Wine's ntdll.dll. the address is call_thread_func_wrapper+0xc in dlls/ntdll/sigail_i386.c, which is part of normal way to start a thread in Wine. Source code: https://github.com/wine-compholio/wine-patched/blob/b4b0eb9f02aef47a0efaae0439aad30d1face1bf/dlls/ntdll/signal_i386.c#L2992 Wine-dbg>disas 0x7bc83d74 0x7bc83d74 call_thread_func_wrapper in ntdll: pushl %ebp 0x7bc83d75 call_thread_func_wrapper+0x1 in ntdll: movl %esp,%ebp 0x7bc83d77 call_thread_func_wrapper+0x3 in ntdll: subl $4,%esp 0x7bc83d7a call_thread_func_wrapper+0x6 in ntdll: pushl 0xc(%ebp) 0x7bc83d7d call_thread_func_wrapper+0x9 in ntdll: call *0x8(%ebp) 0x7bc83d80 call_thread_func_wrapper+0xc in ntdll: leal 0xfffc(%ebp),%esp 0x7bc83d83 call_thread_func_wrapper+0xf in ntdll: pushl %eax 0x7bc83d84 call_thread_func_wrapper+0x10 in ntdll: call 0x7bc8eb00 exit_thread [/media/workspace/src/wine-staging-local/dlls/ntdll/thread.c:386] in ntdll 0x7bc83d89 call_thread_func_wrapper+0x15 in ntdll: int $3 0x7bc83d8a call_thread_func_wrapper+0x16 in ntdll: nop Anyone could provide some hints where did the variable self->exitcode came from? I need to understand why it was 0x0 sometimes and was 0x8000500 the other times. Thanks very much! -- Regards, Qian Hong - http://www.winehq.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Every time I run ssh, ssh prompts "password:" with latest OpenSSH package.
Greetings, Hiroyuki Kurokawa!
> Hi,
> The ssh command keeps prompting "password:" repeatedly with the latest
> OpenSSH package after I started ssh-agent and registered key with
> ssh-add command.
> Followings are my environment.
> % uname -a
> CYGWIN_NT-10.0 win8 2.2.1(0.289/5/3) 2015-08-20 11:42 x86_64 Cygwin
> % ssh -V
> OpenSSH_7.1p1, OpenSSL 1.0.2d 9 Jul 2015
> If I install back the older OpenSSH package ("OpenSSH_6.9p1, OpenSSL
> 1.0.2d 9 Jul 2015"), then ssh prompt "password:" only once. Old
> version works fine!
> I confirmed that "OpenSSH_7.0p1, OpenSSL 1.0.2d 9 Jul 2015" has same
> problem as "OpenSSH_7.1p1, OpenSSL 1.0.2d 9 Jul 2015".
> And I can see same behavior on another machine which OS is windows7.
> So, I believe the latest OpenSSH_7.1p1 & 7.0p1 have same problem.
> If I miss anything, please let me know.
You miss the -vvv log from both client and server.
--
With best regards,
Andrey Repin
Wednesday, September 2, 2015 19:46:55
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Every time I run ssh, ssh prompts "password:" with latest OpenSSH package.
Hi,
The ssh command keeps prompting "password:" repeatedly with the latest
OpenSSH package after I started ssh-agent and registered key with
ssh-add command.
Followings are my environment.
% uname -a
CYGWIN_NT-10.0 win8 2.2.1(0.289/5/3) 2015-08-20 11:42 x86_64 Cygwin
% ssh -V
OpenSSH_7.1p1, OpenSSL 1.0.2d 9 Jul 2015
If I install back the older OpenSSH package ("OpenSSH_6.9p1, OpenSSL
1.0.2d 9 Jul 2015"), then ssh prompt "password:" only once. Old
version works fine!
I confirmed that "OpenSSH_7.0p1, OpenSSL 1.0.2d 9 Jul 2015" has same
problem as "OpenSSH_7.1p1, OpenSSL 1.0.2d 9 Jul 2015".
And I can see same behavior on another machine which OS is windows7.
So, I believe the latest OpenSSH_7.1p1 & 7.0p1 have same problem.
If I miss anything, please let me know.
Best Regards,
--
Hiroyuki Kurokawa
kurok...@gmail.com
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Running Cygwin's "setup.exe" on a new computer
On 02/09/2015 12:53, Dr Rainer Woitok wrote:
Marco,
On Tuesday, 2015-09-01 15:57:03 +0200, you wrote:
...
$ cygcheck -cd | awk 'BEGIN{printf("setup-x86_64.exe ")} {if (NR>2) {
printf ("-P " $1 " ") }} END { printf ("\r\n pause ")}' > cyg-install-x86_64.bat
Even if I slightly compress the command line created that way by using a
single "-P" option followed by the string of comma separated package
names, I end up with a command line consisting of some 16700 characters!
I'm not at all sure how Windows and/or "setup-x86*.exe" would react to
that.
My W7 64bit had no complain for 23004 byte line
;-)
Besides, since "cygcheck" apparently finds the relevant information in
some file, and "setup-x86*.exe" apparently finds the relevant informat-
ion in some file, too, it would perhaps be way easier to just provide
the correct file in the correct location on the new machine.
Any ideas along these lines, anybody?
https://cygwin.com/ml/cygwin/2015-09/msg00023.html
Sincerely,
Rainer
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.1
Hi Cygwin friends and users, I released a new TEST version of Cygwin, 2.3.0-0.1. This is the "new POSIX ACL handling reloaded" release. In local testing I successfully integrated AuthZ into the current Cygwin code to generate more correct user permissions by being able to generate effective permissions for arbitrary users. This success convinced me that it might be possible to pick up the POSIX permission rewrite originally targeted for the 2.0.0 release and try to update it using AuthZ and generally revamp it to reflect effective permissions better. My local testing looks good, but this is a major change, so this code really needs a lot more testing in various scenarios. Especially some Windows ACLs created in corporate environments are often a hard nut to crack, and the example from https://cygwin.com/ml/cygwin/2015-04/msg00513.html which was the ultimate downfall of the original implementation is the stuff which needs some good testing. There's, as usual, a downside: AuthZ leans a bit to the slow side. Cygwin caches information already gathered once on a per-process basis, but in locally crafted worst case scenarios (`ls' on lots of file owned by lots of different users and groups) the slowdown may be up to 25%. But that's really just a worst case, in the usual scenarios the slowdown should be mostly unnoticable. To alleviate the problem, the AuthZ code is fortunately only called for non-Cygwin ACLs and Cygwin ACLs created before this release. Within a pure Cygwin environment (e.g., some build directory only used with Cygwin tools) AuthZ should be practically unused. Apart from the aforementioned code changes to "just do it right", there are two additional changes I implemented for this new POSIX ACL revamp release: - I reverted the questionable change I added to 2.0.0-0.7 in terms of chmod group permission handling. The original description of this change was: If you have a non-trivial ACL with secondary accounts and thus a mask value, chmod is supposed to change only the mask, not the permissions of the primary group. However, if the primary group has few permissions to begin with, the result is really surprising. ls -l would, e.g., show read/write perms for the group, but the group might still have only read perms. Personally I find this chmod behaviour really, really bad, so I took the liberty to change it in a way which gives a much less surprising result: If you call chmod on a non-trivial ACL, the group permissions will be used for the primary group and the mask. - setfacl(1) now accepts the combination of the -b and -k options, just as on Linux (here's looking at you Achim ;)). As for the description what this implementation strives for, please see http://linux.die.net/man/5/acl All changes in this release so far: What's new: --- - New, unified implementation of POSIX permission and ACL handling. The new ACLs now store the POSIX ACL MASK/CLASS_OBJ permission mask, and they allow to inherit the S_ISGID bit. ACL inheritance now really works as desired, in a limited, but theoretically equivalent fashion even for non-Cygwin processes. To accommodate Windows default ACLs, the new code ignores SYSTEM and Administrators group permissions when computing the MASK/CLASS_OBJ permission mask on old ACLs, and it doesn't deny access to SYSTEM and Administrators group based on the value of MASK/CLASS_OBJ when creating the new ACLs. The new code now handles the S_ISGID bit on directories as on Linux: Setting S_ISGID on a directory causes new files and subdirs created within to inherit its group, rather than the primary group of the user who created the file. This only works for files and directories created by Cygwin processes. - posix_madvise(POSIX_MADV_WILLNEED) now utilizes OS functionality available starting with Windows 8/Server 2012. Still a no-op on older systems. - posix_madvise(POSIX_MADV_DONTNEED) now utilizes OS functionality available starting with Windows 8.1/Server 2012R2. Still a no-op on older systems. - sysconf() now supports returning CPU cache information: _SC_LEVEL1_ICACHE_SIZE, _SC_LEVEL1_ICACHE_ASSOC, _SC_LEVEL1_ICACHE_LINESIZE, _SC_LEVEL1_DCACHE_SIZE, _SC_LEVEL1_DCACHE_ASSOC, _SC_LEVEL1_DCACHE_LINESIZE, _SC_LEVEL2_CACHE_SIZE, _SC_LEVEL2_CACHE_ASSOC, _SC_LEVEL2_CACHE_LINESIZE, _SC_LEVEL3_CACHE_SIZE, _SC_LEVEL3_CACHE_ASSOC, _SC_LEVEL3_CACHE_LINESIZE, _SC_LEVEL4_CACHE_SIZE, _SC_LEVEL4_CACHE_ASSOC, _SC_LEVEL4_CACHE_LINESIZE What changed: - - setfacl(1) now allows to use the -b and -k option combined to allow reducing an ACL to only reflect standard POSIX permissions. Bug Fixes - - Fix a hang when stracing a forking or spawning process without activating stracing of child processes. Addresses: https://cygwin.com/ml/cygwin/2015-08/msg00390.html - Fix long-s
Re: Running Cygwin's "setup.exe" on a new computer
Marco,
On Tuesday, 2015-09-01 15:57:03 +0200, you wrote:
> ...
> $ cygcheck -cd | awk 'BEGIN{printf("setup-x86_64.exe ")} {if (NR>2) {
> printf ("-P " $1 " ") }} END { printf ("\r\n pause ")}' >
> cyg-install-x86_64.bat
Even if I slightly compress the command line created that way by using a
single "-P" option followed by the string of comma separated package
names, I end up with a command line consisting of some 16700 characters!
I'm not at all sure how Windows and/or "setup-x86*.exe" would react to
that.
Besides, since "cygcheck" apparently finds the relevant information in
some file, and "setup-x86*.exe" apparently finds the relevant informat-
ion in some file, too, it would perhaps be way easier to just provide
the correct file in the correct location on the new machine.
Any ideas along these lines, anybody?
Sincerely,
Rainer
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Running Cygwin's "setup.exe" on a new computer
> having installed Cygwin on my old computer it's now time to move to new > hardware. Are there any Cygwin configuration or status files I could > copy from the old box to the new one which would cause "setup.exe" on > the new machine to automatically install the same packages as on the old > computer (except for version changes or new dependencies)? You can drop /etc/setup/installed.db into the new installation directory and make them all "outdated": sed -i.bak -re 's/^(.+) .+ 0$/\1 \1-0-0.tar.bz 0/' /etc/setup/installed.db Running setup on this will then "update" all these packages. It will complain about the missing package lst.gz files of course, but you can ignore that. > One minor additional problem perhaps: the old box is 32 bit, while the > new one is 64 bit. There's only a handful of packages left where that makes a difference. > PS: Please also reply by personal mail as I am not subscribed to the > Cygwin mailing list. No can do via Gmane and the list is set up specificaly to prevent this anyway. In general, if you do indeed care about the answers you can always check Gmane or the mailing list archives. Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
