Public key authorization problem with latest snapshot

Public key authorization problem with latest snapshot

[Ken Brown]

Here's some more weirdness involving the recent changes to exception 
handling on 64-bit Cygwin.

I have an ordinary user kbrown and an administrator user kbrown-admin. 
I use the following command to simulate "su":

   ssh kbrown-admin@$(hostname) .

With the current (2014-03-18) x86_64 snapshot, this doesn't work if I 
try to use public key authorization.  I simply get a message

   Connection closed by fe80::81db:bf3a:6434:6015%11

and I'm not even prompted for my passphrase [*].  But if I move my 
id_rsa and id_rsa.pub out of the way, I'm prompted for a password, and I 
can login successfully.

Reverting to the 2014-03-17 snapshot fixes the problem.

Ken

[*] Here's the result of using ssh -vv, in case it provides a clue:

OpenSSH_6.6, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /home/kbrown/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to desktop-new [fe80::81db:bf3a:6434:6015%11] port 22.
debug1: Connection established.
debug1: identity file /home/kbrown/.ssh/id_rsa type 1
debug1: identity file /home/kbrown/.ssh/id_rsa-cert type -1
debug1: identity file /home/kbrown/.ssh/id_dsa type -1
debug1: identity file /home/kbrown/.ssh/id_dsa-cert type -1
debug1: identity file /home/kbrown/.ssh/id_ecdsa type -1
debug1: identity file /home/kbrown/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/kbrown/.ssh/id_ed25519 type -1
debug1: identity file /home/kbrown/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6
debug1: match: OpenSSH_6.6 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: 
curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: 
ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-ed25519,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: 
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: 
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: 
hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: 
hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: 
curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: 
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: 
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: 
hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: 
hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: setup hmac-md5-etm@openssh.com
debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com none
debug2: mac_setup: setup hmac-md5-etm@openssh.com
debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 
0f:ff:3f:f3:82:5e:ca:cd:90:a7:cd:bf:ae:51:60:4b
debug1: Host 'desktop-new' is known and matches the ECDSA host key.
debug1: Found key in /home/kbrown/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/kbrown/.ssh/id_rsa (0x60006d9e0),
debug2: key: /home/kbrown/.ssh/id_dsa (0x0),
debug2: key: /home/kbrown/.ssh/id_ecdsa (0x0),
debug2: key: /home/kbrown/.ssh/id_ed25519 (0x0),
debug1: Authentications that can continue: 
publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/kbrown/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
Connection closed by fe80::81db:bf3a:6434:6015%11


--
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: Public key authorization problem with latest snapshot

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

On Mar 19 11:37, Ken Brown wrote:
> Here's some more weirdness involving the recent changes to exception
> handling on 64-bit Cygwin.
> 
> I have an ordinary user kbrown and an administrator user
> kbrown-admin. I use the following command to simulate "su":
> 
>   ssh kbrown-admin@$(hostname) .
> 
> With the current (2014-03-18) x86_64 snapshot, this doesn't work if
> I try to use public key authorization.  I simply get a message
> 
>   Connection closed by fe80::81db:bf3a:6434:6015%11
> 
> and I'm not even prompted for my passphrase [*].  But if I move my
> id_rsa and id_rsa.pub out of the way, I'm prompted for a password,
> and I can login successfully.
> 
> Reverting to the 2014-03-17 snapshot fixes the problem.

I just checked in a change.  Please give it a try.  If this doesn't work
either, I don't know how to proceed.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Public key authorization problem with latest snapshot

[Ken Brown]

On 3/19/2014 12:09 PM, Corinna Vinschen wrote:
> On Mar 19 11:37, Ken Brown wrote:
>> Here's some more weirdness involving the recent changes to exception
>> handling on 64-bit Cygwin.
>>
>> I have an ordinary user kbrown and an administrator user
>> kbrown-admin. I use the following command to simulate "su":
>>
>>    ssh kbrown-admin@$(hostname) .
>>
>> With the current (2014-03-18) x86_64 snapshot, this doesn't work if
>> I try to use public key authorization.  I simply get a message
>>
>>    Connection closed by fe80::81db:bf3a:6434:6015%11
>>
>> and I'm not even prompted for my passphrase [*].  But if I move my
>> id_rsa and id_rsa.pub out of the way, I'm prompted for a password,
>> and I can login successfully.
>>
>> Reverting to the 2014-03-17 snapshot fixes the problem.
>
> I just checked in a change.  Please give it a try.  If this doesn't work
> either, I don't know how to proceed.

This fixes the public key authorization problem, but the timeout during 
the starting of gtk applications is back.  The "window-default" program 
from the other thread is still a test case for that problem.

Ken


--
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: Public key authorization problem with latest snapshot

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

On Mar 19 12:46, Ken Brown wrote:
> On 3/19/2014 12:09 PM, Corinna Vinschen wrote:
> >On Mar 19 11:37, Ken Brown wrote:
> >>Here's some more weirdness involving the recent changes to exception
> >>handling on 64-bit Cygwin.
> >>
> >>I have an ordinary user kbrown and an administrator user
> >>kbrown-admin. I use the following command to simulate "su":
> >>
> >>   ssh kbrown-admin@$(hostname) .
> >>
> >>With the current (2014-03-18) x86_64 snapshot, this doesn't work if
> >>I try to use public key authorization.  I simply get a message
> >>
> >>   Connection closed by fe80::81db:bf3a:6434:6015%11
> >>
> >>and I'm not even prompted for my passphrase [*].  But if I move my
> >>id_rsa and id_rsa.pub out of the way, I'm prompted for a password,
> >>and I can login successfully.
> >>
> >>Reverting to the 2014-03-17 snapshot fixes the problem.
> >
> >I just checked in a change.  Please give it a try.  If this doesn't work
> >either, I don't know how to proceed.
> 
> This fixes the public key authorization problem, but the timeout
> during the starting of gtk applications is back.  The
> "window-default" program from the other thread is still a test case
> for that problem.

Ok, I give up.  I have no idea anymore how to change that.

The code is now practically equivalent to what is in 1.7.28.  Only the
VectoredContinueHandler, which was the reason Cygwin's exception handler
could be called twice, is not called anymore.  Instead there's a vectored
exception handler which is only called during debugging.

Before:

  if (!handler_installed)
    {
      handler_installed = true;
      SetUnhandledExceptionFilter (handle);
      AddVectoredContinueHandler (1, handle);
    }

After:

  if (!handler_installed)
    {
      handler_installed = true;
      SetUnhandledExceptionFilter (handle);
      AddVectoredExceptionHandler (1, handle_while_being_debugged);
    }

If anybody can explain this weird behaviour, please educate me.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Public key authorization problem with latest snapshot

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2767 bytes --]

On Mar 19 18:05, Corinna Vinschen wrote:
> On Mar 19 12:46, Ken Brown wrote:
> > On 3/19/2014 12:09 PM, Corinna Vinschen wrote:
> > >On Mar 19 11:37, Ken Brown wrote:
> > >>Here's some more weirdness involving the recent changes to exception
> > >>handling on 64-bit Cygwin.
> > >>
> > >>I have an ordinary user kbrown and an administrator user
> > >>kbrown-admin. I use the following command to simulate "su":
> > >>
> > >>   ssh kbrown-admin@$(hostname) .
> > >>
> > >>With the current (2014-03-18) x86_64 snapshot, this doesn't work if
> > >>I try to use public key authorization.  I simply get a message
> > >>
> > >>   Connection closed by fe80::81db:bf3a:6434:6015%11
> > >>
> > >>and I'm not even prompted for my passphrase [*].  But if I move my
> > >>id_rsa and id_rsa.pub out of the way, I'm prompted for a password,
> > >>and I can login successfully.
> > >>
> > >>Reverting to the 2014-03-17 snapshot fixes the problem.
> > >
> > >I just checked in a change.  Please give it a try.  If this doesn't work
> > >either, I don't know how to proceed.
> > 
> > This fixes the public key authorization problem, but the timeout
> > during the starting of gtk applications is back.  The
> > "window-default" program from the other thread is still a test case
> > for that problem.
> 
> Ok, I give up.  I have no idea anymore how to change that.

I have a big problem here.  I reverted the entire exception handling to
1.7.28 state, and the "window-default" application still hangs for me
and generates the

  WARNING **: Error retrieving accessibility bus address:
  org.freedesktop.DBus.Error.NoReply: Did not receive a reply [etc]

message before the window opens.  Then I rebuild the same code, without
any changes, just with -g -O2 instead of just -g, and the window-default
application didn't hang.  If I build everything with -g and only the
files which include exception.h with -O2, I would have expected that it
works, but not so.  It still hangs.  

I tried every variation of execption handler installation and the kitchen
sink, but whatever change I try, the only variation which works for
window-default is the 1.7.28 version compiled with -O2.  Which is not
good given that the exception handler is called twice.  Every change to
make sure the vectored continue handler is only called in the debugger
result in window-default hanging again.

I just can't find a stable state which does not fail one way or the other :(

We need to know what happens there, but the various dbus-FOO processes
started at once are a bit overwhelming.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Public key authorization problem with latest snapshot

[Andrey Repin]

Greetings, Corinna Vinschen!

> The code is now practically equivalent to what is in 1.7.28.  Only the
> VectoredContinueHandler, which was the reason Cygwin's exception handler
> could be called twice, is not called anymore.  Instead there's a vectored
> exception handler which is only called during debugging.

> Before:

>   if (!handler_installed)
>     {
>       handler_installed = true;
>       SetUnhandledExceptionFilter (handle);
>       AddVectoredContinueHandler (1, handle);
>     }

> After:

>   if (!handler_installed)
>     {
>       handler_installed = true;
>       SetUnhandledExceptionFilter (handle);
>       AddVectoredExceptionHandler (1, handle_while_being_debugged);
>     }

> If anybody can explain this weird behaviour, please educate me.

I can't explain the behavior, but I could say, that setting
"handler_installed = true;" before the handler is actually installed is not
quite right.
Unless that variable is used inside either of two functions called afterward,
I would move it down to the end of `if' block.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 20.03.2014, <01:56>

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: Public key authorization problem with latest snapshot

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]

On Mar 20 01:58, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> > The code is now practically equivalent to what is in 1.7.28.  Only the
> > VectoredContinueHandler, which was the reason Cygwin's exception handler
> > could be called twice, is not called anymore.  Instead there's a vectored
> > exception handler which is only called during debugging.
> 
> > Before:
> 
> >   if (!handler_installed)
> >     {
> >       handler_installed = true;
> >       SetUnhandledExceptionFilter (handle);
> >       AddVectoredContinueHandler (1, handle);
> >     }
> 
> > After:
> 
> >   if (!handler_installed)
> >     {
> >       handler_installed = true;
> >       SetUnhandledExceptionFilter (handle);
> >       AddVectoredExceptionHandler (1, handle_while_being_debugged);
> >     }
> 
> > If anybody can explain this weird behaviour, please educate me.
> 
> I can't explain the behavior, but I could say, that setting
> "handler_installed = true;" before the handler is actually installed is not
> quite right.
> Unless that variable is used inside either of two functions called afterward,
> I would move it down to the end of `if' block.

BTDT.  This isn't the problem.  I *may* have found the culprit today,
but I ripped apart a lot of the code so I'm not really sure yet.  Stay
tuned.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Public key authorization problem with latest snapshot

[Ken Brown]

On 3/20/2014 11:02 AM, Corinna Vinschen wrote:
> On Mar 20 01:58, Andrey Repin wrote:
>> Greetings, Corinna Vinschen!
>>
>>> The code is now practically equivalent to what is in 1.7.28.  Only the
>>> VectoredContinueHandler, which was the reason Cygwin's exception handler
>>> could be called twice, is not called anymore.  Instead there's a vectored
>>> exception handler which is only called during debugging.
>>
>>> Before:
>>
>>>    if (!handler_installed)
>>>      {
>>>        handler_installed = true;
>>>        SetUnhandledExceptionFilter (handle);
>>>        AddVectoredContinueHandler (1, handle);
>>>      }
>>
>>> After:
>>
>>>    if (!handler_installed)
>>>      {
>>>        handler_installed = true;
>>>        SetUnhandledExceptionFilter (handle);
>>>        AddVectoredExceptionHandler (1, handle_while_being_debugged);
>>>      }
>>
>>> If anybody can explain this weird behaviour, please educate me.
>>
>> I can't explain the behavior, but I could say, that setting
>> "handler_installed = true;" before the handler is actually installed is not
>> quite right.
>> Unless that variable is used inside either of two functions called afterward,
>> I would move it down to the end of `if' block.
>
> BTDT.  This isn't the problem.  I *may* have found the culprit today,
> but I ripped apart a lot of the code so I'm not really sure yet.  Stay
> tuned.

The problems I've reported seem to all be fixed in the latest snapshot 
(2014-03-29 15:21:43 UTC).  Thanks!

Ken


--
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: Public key authorization problem with latest snapshot

[Christopher Faylor]

On Sat, Mar 29, 2014 at 12:25:07PM -0400, Ken Brown wrote:
>On 3/20/2014 11:02 AM, Corinna Vinschen wrote:
>> On Mar 20 01:58, Andrey Repin wrote:
>>> Greetings, Corinna Vinschen!
>>>
>>>> The code is now practically equivalent to what is in 1.7.28.  Only the
>>>> VectoredContinueHandler, which was the reason Cygwin's exception handler
>>>> could be called twice, is not called anymore.  Instead there's a vectored
>>>> exception handler which is only called during debugging.
>>>
>>>> Before:
>>>
>>>>    if (!handler_installed)
>>>>      {
>>>>        handler_installed = true;
>>>>        SetUnhandledExceptionFilter (handle);
>>>>        AddVectoredContinueHandler (1, handle);
>>>>      }
>>>
>>>> After:
>>>
>>>>    if (!handler_installed)
>>>>      {
>>>>        handler_installed = true;
>>>>        SetUnhandledExceptionFilter (handle);
>>>>        AddVectoredExceptionHandler (1, handle_while_being_debugged);
>>>>      }
>>>
>>>> If anybody can explain this weird behaviour, please educate me.
>>>
>>> I can't explain the behavior, but I could say, that setting
>>> "handler_installed = true;" before the handler is actually installed is not
>>> quite right.
>>> Unless that variable is used inside either of two functions called afterward,
>>> I would move it down to the end of `if' block.
>>
>> BTDT.  This isn't the problem.  I *may* have found the culprit today,
>> but I ripped apart a lot of the code so I'm not really sure yet.  Stay
>> tuned.
>
>The problems I've reported seem to all be fixed in the latest snapshot 
>(2014-03-29 15:21:43 UTC).  Thanks!

I'm sure Corinna will be happy to hear that.  She put in LONG hours
getting that issue sorted out.

I helped too, of course, by offering important "I don't like that
implementation" style feedback.  It was one of those 50/50 collaborations
where one person does all the work and the other person mentions it on
a mailing list.

cgf

--
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: Public key authorization problem with latest snapshot

[Larry Hall (Cygwin)]

On 3/29/2014 3:29 PM, Christopher Faylor wrote:
> On Sat, Mar 29, 2014 at 12:25:07PM -0400, Ken Brown wrote:
>> On 3/20/2014 11:02 AM, Corinna Vinschen wrote:
>>> On Mar 20 01:58, Andrey Repin wrote:
>>>> Greetings, Corinna Vinschen!
>>>>
>>>>> The code is now practically equivalent to what is in 1.7.28.  Only the
>>>>> VectoredContinueHandler, which was the reason Cygwin's exception handler
>>>>> could be called twice, is not called anymore.  Instead there's a vectored
>>>>> exception handler which is only called during debugging.
>>>>
>>>>> Before:
>>>>
>>>>>     if (!handler_installed)
>>>>>       {
>>>>>         handler_installed = true;
>>>>>         SetUnhandledExceptionFilter (handle);
>>>>>         AddVectoredContinueHandler (1, handle);
>>>>>       }
>>>>
>>>>> After:
>>>>
>>>>>     if (!handler_installed)
>>>>>       {
>>>>>         handler_installed = true;
>>>>>         SetUnhandledExceptionFilter (handle);
>>>>>         AddVectoredExceptionHandler (1, handle_while_being_debugged);
>>>>>       }
>>>>
>>>>> If anybody can explain this weird behaviour, please educate me.
>>>>
>>>> I can't explain the behavior, but I could say, that setting
>>>> "handler_installed = true;" before the handler is actually installed is not
>>>> quite right.
>>>> Unless that variable is used inside either of two functions called afterward,
>>>> I would move it down to the end of `if' block.
>>>
>>> BTDT.  This isn't the problem.  I *may* have found the culprit today,
>>> but I ripped apart a lot of the code so I'm not really sure yet.  Stay
>>> tuned.
>>
>> The problems I've reported seem to all be fixed in the latest snapshot
>> (2014-03-29 15:21:43 UTC).  Thanks!
>
> I'm sure Corinna will be happy to hear that.  She put in LONG hours
> getting that issue sorted out.
>
> I helped too, of course, by offering important "I don't like that
> implementation" style feedback.  It was one of those 50/50 collaborations
> where one person does all the work and the other person mentions it on
> a mailing list.

Sounds exhausting.  Perhaps you want to sit down.


-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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: Public key authorization problem with latest snapshot

[Christopher Faylor]

On Sat, Mar 29, 2014 at 09:08:35PM -0400, Larry Hall (Cygwin) wrote:
>On 3/29/2014 3:29 PM, Christopher Faylor wrote:
>>I helped too, of course, by offering important "I don't like that
>>implementation" style feedback.  It was one of those 50/50
>>collaborations where one person does all the work and the other person
>>mentions it on a mailing list.
>
>Sounds exhausting.  Perhaps you want to sit down.

Thanks.  On reflection, I don't want to minimize Corinna's contribution
since it was 100% her effort.  I just provided some much needed self
aggrandizement to this whole exhausting project.

cgf

--
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: Public key authorization problem with latest snapshot

[briansw]

On 3/29/2014 3:29 PM, Christopher Faylor wrote:
>>> The problems I've reported seem to all be fixed in the latest snapshot
(2014-03-29 15:21:43 UTC).  Thanks!
>>
>> I'm sure Corinna will be happy to hear that.  She put in LONG hours
getting that issue sorted out.
>>
>> I helped too; of course, by offering important "I don't like that
implementation" style feedback.  It was one of those 50/50 collaborations
where one person does all the work and the other person mentions it on a
mailing list.
>Sounds exhausting.  Perhaps you want to sit down.
It's a lucky thing you were there to help Corinna.  I'm sure it would have
been too much to do by herself. :)

Seriously, thank you Corinna for all your hard work and everything you do to
support this project (and thank you Christopher for your contributions and
humor).


--
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: Public key authorization problem with latest snapshot

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]

On Mar 29 12:25, Ken Brown wrote:
> On 3/20/2014 11:02 AM, Corinna Vinschen wrote:
> >On Mar 20 01:58, Andrey Repin wrote:
> >>Greetings, Corinna Vinschen!
> >>
> >>>The code is now practically equivalent to what is in 1.7.28.  Only the
> >>>VectoredContinueHandler, which was the reason Cygwin's exception handler
> >>>could be called twice, is not called anymore.  Instead there's a vectored
> >>>exception handler which is only called during debugging.
> >>
> >>>Before:
> >>
> >>>   if (!handler_installed)
> >>>     {
> >>>       handler_installed = true;
> >>>       SetUnhandledExceptionFilter (handle);
> >>>       AddVectoredContinueHandler (1, handle);
> >>>     }
> >>
> >>>After:
> >>
> >>>   if (!handler_installed)
> >>>     {
> >>>       handler_installed = true;
> >>>       SetUnhandledExceptionFilter (handle);
> >>>       AddVectoredExceptionHandler (1, handle_while_being_debugged);
> >>>     }
> >>
> >>>If anybody can explain this weird behaviour, please educate me.
> >>
> >>I can't explain the behavior, but I could say, that setting
> >>"handler_installed = true;" before the handler is actually installed is not
> >>quite right.
> >>Unless that variable is used inside either of two functions called afterward,
> >>I would move it down to the end of `if' block.
> >
> >BTDT.  This isn't the problem.  I *may* have found the culprit today,
> >but I ripped apart a lot of the code so I'm not really sure yet.  Stay
> >tuned.
> 
> The problems I've reported seem to all be fixed in the latest
> snapshot (2014-03-29 15:21:43 UTC).  Thanks!

Thanks to you for reporting the problems, providing testcases,
and generally testing snapshots!


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]