openssh bugs - Dec 2016 - [Bug 2652] New: PKCS11 login skipped if login required and no pin set

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

            Bug ID: 2652
           Summary: PKCS11 login skipped if login required and no pin set
           Product: Portable OpenSSH
           Version: 7.4p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Smartcard
          Assignee: unassigned-bugs at mindrot.org
          Reporter: openssh at danman.eu

Hi,

first, there is a bug in pin detection: if no pin is supplied to
function, the exit condition is skipped.

Also if no pin is supplied, login is skipped even when card requires
login.

Proposed patch is here:
https://github.com/danielkucera/openssh-portable/commit/d6be677d1befd84fdbef0259316ebf4383feef6c

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
Created attachment 3032
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3032&action=edit
patch

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
Comment on attachment 3032
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3032
patch
>diff --git a/ssh-pkcs11.c b/ssh-pkcs11.c
>index d1f750db0..938535638 100644
>--- a/ssh-pkcs11.c
>+++ b/ssh-pkcs11.c
>@@ -366,19 +366,16 @@ pkcs11_open_session(struct pkcs11_provider *p,
CK_ULONG slotidx, char *pin)
> 
> 	f = p->function_list;
> 	login_required = p->slotinfo[slotidx].token.flags &
CKF_LOGIN_REQUIRED;
>-	if (pin && login_required && !strlen(pin)) {
>-		error("pin required");
>-		return (-1);
>-	}
>+
I'm not sure I understand why this section is removed - could you
explain it?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

--- Comment #3 from Daniel Kucera <openssh at danman.eu> ---
(In reply to Damien Miller from comment #2)
> Comment on attachment 3032 [details]
> patch
> 
> >diff --git a/ssh-pkcs11.c b/ssh-pkcs11.c
> >index d1f750db0..938535638 100644
> >--- a/ssh-pkcs11.c
> >+++ b/ssh-pkcs11.c
> >@@ -366,19 +366,16 @@ pkcs11_open_session(struct pkcs11_provider *p,
CK_ULONG slotidx, char *pin)
> > 
> > 	f = p->function_list;
> > 	login_required = p->slotinfo[slotidx].token.flags &
CKF_LOGIN_REQUIRED;
> >-	if (pin && login_required && !strlen(pin)) {
> >-		error("pin required");
> >-		return (-1);
> >-	}
> >+
> 
> I'm not sure I understand why this section is removed - could you
> explain it?
Because in my case, the pkcs library says it requires login but if you
don't pass it as argument to C_Login, it will ask for it. Thus we
should not exit with error here.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

--- Comment #4 from Daniel Kucera <openssh at danman.eu> ---
(In reply to Daniel Kucera from comment #3)
> Because in my case, the pkcs library says it requires login but if
> you don't pass it as argument to C_Login, it will ask for it. Thus
> we should not exit with error here.
* if you don't pass PIN as argument.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

--- Comment #5 from Daniel Kucera <openssh at danman.eu> ---
(In reply to Damien Miller from comment #2)
> Comment on attachment 3032 [details]
> patch
> 
> >diff --git a/ssh-pkcs11.c b/ssh-pkcs11.c
> >index d1f750db0..938535638 100644
> >--- a/ssh-pkcs11.c
> >+++ b/ssh-pkcs11.c
> >@@ -366,19 +366,16 @@ pkcs11_open_session(struct pkcs11_provider *p,
CK_ULONG slotidx, char *pin)
> > 
> > 	f = p->function_list;
> > 	login_required = p->slotinfo[slotidx].token.flags &
CKF_LOGIN_REQUIRED;
> >-	if (pin && login_required && !strlen(pin)) {
> >-		error("pin required");
> >-		return (-1);
> >-	}
> >+
> 
> I'm not sure I understand why this section is removed - could you
> explain it?
Oh, I remember now: It's because if pin is not set (is null),
login_required is not evaluated so no error is returned so this check
is useless. 

And we don't even need to return error here, login can be performed by
external library after calling C_Login with pin set to zero.

CKF_LOGIN_REQUIRED only means C_Login has to be called, not that the
pin has to be set.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

Jakub Jelen <jjelen at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jjelen at redhat.com

--- Comment #6 from Jakub Jelen <jjelen at redhat.com> ---
Created attachment 3124
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3124&action=edit
allow deferring the PIN prompt to reader keyboard

Well ... the pkcs11_open_session() is called from pkcs11_add_provider()
and that is called either from ssh, ssh-pkcs11-helper or from
ssh-keygen.

 (1) The ssh and ssh-keygen call this function with NULL pin. The ssh
asks for the PIN later. This is fine.

 (2) The ssh-pkcs11-provider and ssh-keygen (CA signing) call this
function directly with pin as provided by user (can be zero-length
string), and in the second case can be also NULL (preferred way).

Given that, the first condition is certainly not useless. It makes
sense to fail before opening session if we know that we can not provide
a pin. There is possibility that the PIN provided by user (through
ssh-agent protocol) is empty string and in that case, we do not have
any way how to prompt for the PIN later. Theoretically, there is still
a way to ask using askpass, but it is not implemented at this moment.

But the other part is true. The interactive-login already detects the
CKF_PROTECTED_AUTHENTICATION_PATH flag, that is used for logging into
the token from reader keypad.

I believe the same thing should be also supported in the ssh-agent
process, but since the pin prompt is in different process than the
actual connection to PKCS#11 library, the user just needs to submit
empty PIN and it needs to be detected later in ssh-agent, but certainly
not based only on the PIN value, but on the proper flags of the token.

In the case of using reader keypad, the pin should be a NULL_PTR as
recommended by specification [1]. Daniel, can you try the attached
patch (should apply on master), if it solves your problem?

[1]
http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

--- Comment #7 from Daniel Kucera <openssh at danman.eu> ---
Ahoj Jakub,

I tried it but it doesn't work:

$ ./ssh-keygen -D /usr/lib/eidklient/libpkcs11_sig_x64.so -e
cannot read public key from pkcs11
$

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

Daniel Kucera <openssh at danman.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #3124|0                           |1
        is obsolete|                            |

--- Comment #8 from Daniel Kucera <openssh at danman.eu> ---
Created attachment 3125
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3125&action=edit
patch_v2

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

--- Comment #9 from Daniel Kucera <openssh at danman.eu> ---
This one I uploaded (patch_v2) works.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

Jakub Jelen <jjelen at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #3125|application/octet-stream    |text/plain
          mime type|                            |
   Attachment #3125|0                           |1
           is patch|                            |

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

--- Comment #10 from Jakub Jelen <jjelen at redhat.com> ---
Thank you for testing the patch. But your changes again change the
semantics and issue the pinpad login even if the PIN is NULL, which is
not what you generally want.

Or is your card requiring the login also for the listing of public
keys? What do you get if you try to list the public objects from
pkcs11-tool?

pkcs11-tool -O /usr/lib/eidklient/libpkcs11_sig_x64.so

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

--- Comment #11 from Daniel Kucera <openssh at danman.eu> ---
(In reply to Jakub Jelen from comment #10)
> Thank you for testing the patch. But your changes again change the
> semantics and issue the pinpad login even if the PIN is NULL, which
> is not what you generally want.
But if CKF_LOGIN_REQUIRED is set why would one want to skip login?
> 
> Or is your card requiring the login also for the listing of public
> keys? What do you get if you try to list the public objects from
> pkcs11-tool?
> 
> pkcs11-tool -O /usr/lib/eidklient/libpkcs11_sig_x64.so
My card requires login for absolutely everything

$ pkcs11-tool -vvv --module /usr/lib/eidklient/libpkcs11_sig_x64.so -O
Using slot 0 with a present token (0x1)
$ pkcs11-tool -vvv --module /usr/lib/eidklient/libpkcs11_sig_x64.so -l
-O
Using slot 0 with a present token (0x1)
Private Key Object; RSA 
  label:      571cd7f3-0935-4218-b7cf-4b43af29d1bc
  ID:         ...
  Usage:      decrypt, sign
  Access:     always authenticate
Certificate Object; type = X.509 cert
  label:      571cd7f3-0935-4218-b7cf-4b43af29d1bc
  ID:         ...

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

--- Comment #12 from Jakub Jelen <jjelen at redhat.com> ---
(In reply to Daniel Kucera from comment #11)
> (In reply to Jakub Jelen from comment #10)
> > Thank you for testing the patch. But your changes again change the
> > semantics and issue the pinpad login even if the PIN is NULL, which
> > is not what you generally want.
> 
> But if CKF_LOGIN_REQUIRED is set why would one want to skip login?
The PKCS#11 specification does not say what can and what can not be
accessed if this flag is provided:
> CKF_LOGIN_REQUIRED: True if there are *some* cryptographic functions that a
user MUST be logged in to perform
From:
http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html

We do not skip login for the private-key operations, but only for the
listing of the keys, which is a valid use case.
> > Or is your card requiring the login also for the listing of public
> > keys? What do you get if you try to list the public objects from
> > pkcs11-tool?
> > 
> > pkcs11-tool -O /usr/lib/eidklient/libpkcs11_sig_x64.so
> 
> My card requires login for absolutely everything
> 
> $ pkcs11-tool -vvv --module /usr/lib/eidklient/libpkcs11_sig_x64.so
> -O
> Using slot 0 with a present token (0x1)
> $ pkcs11-tool -vvv --module /usr/lib/eidklient/libpkcs11_sig_x64.so
> -l -O
> Using slot 0 with a present token (0x1)
> Private Key Object; RSA 
>   label:      571cd7f3-0935-4218-b7cf-4b43af29d1bc
>   ID:         ...
>   Usage:      decrypt, sign
>   Access:     always authenticate
> Certificate Object; type = X.509 cert
>   label:      571cd7f3-0935-4218-b7cf-4b43af29d1bc
>   ID:         ...
Yes, this is the same problem as described in the bug #2430 some while
back, which I hit with some soft tokens and that are also visible in
eID cards as I tried to point out.

Prompting for the PIN for public key operations is nothing we would
like to do automatically, so there really should be some switch to do
the login before listing the keys or the login should be proposed
explicitly by for example a PIN in PKCS#11 URI.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

--- Comment #13 from Daniel Kucera <openssh at danman.eu> ---
(In reply to Jakub Jelen from comment #12)
> 
> Prompting for the PIN for public key operations is nothing we would
> like to do automatically, so there really should be some switch to
> do the login before listing the keys or the login should be proposed
> explicitly by for example a PIN in PKCS#11 URI.
I see two reasonable options here: either to check return of all
functions for CKR_USER_NOT_LOGGED_IN return code and retry them after
login or login always when CKF_LOGIN_REQUIRED is set. 

Moreover, not every time when you call login with NULL pin you are
required to put it in. In my case the library ask for it only time to
time (you can see my usecase here:
https://blog.danman.eu/ssh-autentifikacia-s-eid-obcianskym-preukazom-pod-linuxom/
) probably because it keeps the session with card open.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

--- Comment #14 from Jakub Jelen <jjelen at redhat.com> ---
(In reply to Daniel Kucera from comment #13)
> (In reply to Jakub Jelen from comment #12)
> > Prompting for the PIN for public key operations is nothing we would
> > like to do automatically, so there really should be some switch to
> > do the login before listing the keys or the login should be proposed
> > explicitly by for example a PIN in PKCS#11 URI.
> 
> I see two reasonable options here: either to check return of all
> functions for CKR_USER_NOT_LOGGED_IN return code and retry them
> after login
If you do not see any objects on the card before login, you will not
get any such error so this will not resolve your problem in any way.
> or login always when CKF_LOGIN_REQUIRED is set.
That is not sane default behavior. With most of the cards, certificates
and public keys are visible without login. For the few others, there
should be configuration option to handle this case as I initially
proposed in the referenced bug.
> Moreover, not every time when you call login with NULL pin you are
> required to put it in. In my case the library ask for it only time
> to time (you can see my usecase here:
> https://blog.danman.eu/ssh-autentifikacia-s-eid-obcianskym-preukazom-
> pod-linuxom/ ) probably because it keeps the session with card open.
>From the log, it looks like CardOS V5.0 card, which should work also
with the latest OpenSC.

The PKCS#11 module you are using is probably somehow holding the login
state of your card and presents you its own PIN pad in GUI. That is
certainly not a standard behavior of PKCS#11 modules nor cards.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

--- Comment #15 from Jakub Jelen <jjelen at redhat.com> ---
One more thing. Will a *ssh-agent* work for you with stock OpenSSH? To
my understanding, it already does a login before listing the keys, so a
workaround could be using the keys from ssh-agent:

  eval `ssh-agent`
  ssh-add -s /usr/lib/eidklient/libpkcs11_sig_x64.so
  ssh user at moj.server.sk

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

--- Comment #16 from Daniel Kucera <openssh at danman.eu> ---
(In reply to Jakub Jelen from comment #15)
> One more thing. Will a *ssh-agent* work for you with stock OpenSSH?
> To my understanding, it already does a login before listing the
> keys, so a workaround could be using the keys from ssh-agent:
> 
>   eval `ssh-agent`
>   ssh-add -s /usr/lib/eidklient/libpkcs11_sig_x64.so
>   ssh user at moj.server.sk
$ ssh-add -s /usr/lib/eidklient/libpkcs11_sig_x64.so
Enter passphrase for PKCS#11: 
Could not add card "/usr/lib/eidklient/libpkcs11_sig_x64.so": agent
refused operation

What kind of passphrase does it ask for? I tried card pin but without
success.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

Jakub Jelen <jjelen at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #3124|1                           |0
        is obsolete|                            |

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

--- Comment #17 from Jakub Jelen <jjelen at redhat.com> ---
Sorry, I forgot about the pinpad. For the reader virtual keypad, you
need to use the patch that I attached to the comment #6 (applied to
ssh-agent and ssh-pkcs11-provider, which complicates installation).

It should be still prompting for the pin, but if you just press enter,
you should get past that and should allow to read the keys, if I see
right.

Unfortunately, the ssh-add does not know if there is pinpad at that
moment so it can not skip this prompt, but needs to send empty string
in this case.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

--- Comment #18 from Daniel Kucera <openssh at danman.eu> ---
(In reply to Jakub Jelen from comment #17)
> Sorry, I forgot about the pinpad. For the reader virtual keypad, you
> need to use the patch that I attached to the comment #6 (applied to
> ssh-agent and ssh-pkcs11-provider, which complicates installation).
> 
> It should be still prompting for the pin, but if you just press
> enter, you should get past that and should allow to read the keys,
> if I see right.
> 
> Unfortunately, the ssh-add does not know if there is pinpad at that
> moment so it can not skip this prompt, but needs to send empty
> string in this case.
After applying patch:

it doesn't work with empty string pin:

$ ./ssh-add -s /usr/lib/eidklient/libpkcs11_sig_x64.so
Enter passphrase for PKCS#11: 
Could not add card "/usr/lib/eidklient/libpkcs11_sig_x64.so": agent
refused operation

but it does with correct card pin:

$ ./ssh-add -s /usr/lib/eidklient/libpkcs11_sig_x64.so
Enter passphrase for PKCS#11: 
Card added: /usr/lib/eidklient/libpkcs11_sig_x64.so

$ ./ssh-add -L
ssh-rsa AAAAB3... /usr/lib/eidklient/libpkcs11_sig_x64.so
ssh-rsa AAAAB3... /usr/lib/eidklient/libpkcs11_sig_x64.so
ssh-rsa AAAAB3... /usr/lib/eidklient/libpkcs11_sig_x64.so

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

--- Comment #19 from Jakub Jelen <jjelen at redhat.com> ---
Maybe it still needs some care. I don't have a slovak EiD so I can not
verify this use case.

Anyway, can you try the patch attached in the bug #2430? It should
allow you to use the keys from ssh client and ssh-keygen by trying to
login if there were no public keys visible before.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

--- Comment #20 from Daniel Kucera <openssh at danman.eu> ---
(In reply to Jakub Jelen from comment #19)
> Maybe it still needs some care. I don't have a slovak EiD so I can
> not verify this use case.
> 
> Anyway, can you try the patch attached in the bug #2430? It should
> allow you to use the keys from ssh client and ssh-keygen by trying
> to login if there were no public keys visible before.
Yes, that patch works fine. First time it asks for pin using software
keypad reader, next times it works without asking.

Used command:

./ssh -I /usr/lib/eidklient/libpkcs11_sig_x64.so server

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pkcs11

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #3032|0                           |1
        is obsolete|                            |
   Attachment #3124|0                           |1
        is obsolete|                            |
   Attachment #3125|0                           |1
        is obsolete|                            |
           Assignee|unassigned-bugs at mindrot.org |djm at mindrot.org

--- Comment #21 from Damien Miller <djm at mindrot.org> ---
Created attachment 3226
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3226&action=edit
update patch to post-ECDSA PKCS#11 key merge

This updates the patch after the PKCS#11 ECDSA code has landed. Note
that this patch is now atop the one on bug 2638

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |2915


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=2915
[Bug 2915] Tracking bug for 8.0 release
-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

--- Comment #22 from Jakub Jelen <jjelen at redhat.com> ---
The new patch looks good to me.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

--- Comment #23 from Daniel Kucera <openssh at danman.eu> ---
Looks OK to me too.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #24 from Damien Miller <djm at mindrot.org> ---
This has been committed and will be in OpenSSH 8.0

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #25 from Damien Miller <djm at mindrot.org> ---
Move resolved bugs -> CLOSED after 8.0 release

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2652

Ahmed Sayeed <ahmedsayeed1982 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ahmedsayeed1982 at yahoo.com

--- Comment #26 from Ahmed Sayeed <ahmedsayeed1982 at yahoo.com> ---
If you create a new TUI layout, don't include the status window, and
then change from a layout with the status window to the new one, gdb
crashes. http://www.compilatori.com/category/tech/

(gdb) layout src
(gdb) tui new-layout test src 2 cmd 1
http://www.acpirateradio.co.uk/category/tech/
(gdb) layout test
http://www.logoarts.co.uk/category/tech/
On Windows I get a STATUS_HEAP_CORRUPTION exception (0xc0000374).
It happens because tui_apply_current_layout() deletes all windows that
are no longer needed, but the status (locator) window is never
allocated dynamically.  http://www.slipstone.co.uk/category/tech/
If you create a new TUI layout, don't include the status window, and
then change from a layout with the status window to the new one, gdb
crashes.
http://embermanchester.uk/category/tech/
(gdb) layout src
(gdb) tui new-layout test src 2 cmd 1 http://connstr.net/category/tech/
(gdb) layout test
 http://joerg.li/category/tech/
On Windows I get a STATUS_HEAP_CORRUPTION exception (0xc0000374).
It happens because tui_apply http://www.jopspeech.com/category/tech/
_current_layout() deletes all windows that are no longer needed, but
the status (locator) window is never allocated dynamically.
http://www.wearelondonmade.com/category/tech/
If you create a new TUI layout, don't include the status window, and
then change from a layout with the status window to the new one, gdb
crashes. https://waytowhatsnext.com/category/property/

(gdb) layout src
(gdb) tui new-layout test src 2 cmd 1
http://www.iu-bloomington.com/category/property/
(gdb) layout test
https://komiya-dental.com/category/property/
On Windows I get a STATUS_HEAP_CORRUPTION exception (0xc0000374).
It happens because tui
http://www-look-4.com/category/tech/_apply_current_layout() deletes all
windows that are no longer needed, but the status (locator) window is
never allocated dynamically.
https://www.webb-dev.co.uk/category/property/

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.