bugGNUstep - Bugs: bug #46410, [Gorm] secure textfield in NIB...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #46410: [Gorm] secure textfield in NIB -> Gorm conversion

Submitted by:  Riccardo Mottola <rmottola>
Submitted on:  Mon 09 Nov 2015 09:31:15 PM UTC  
 
Category: GormSeverity: 3 - Normal
Item Group: BugStatus: None
Privacy: PublicAssigned to: Gregory John Casamento <gcasa>
Open/Closed: Open

Sun 29 Oct 2017 11:59:53 PM UTC, comment #2:

When reverse engineering the nib files I noticed there were a lot of errors which Apple had made in encoding. The nib in question is, I believe from
10.4. Examples of such errors are name mispellings and etc some of which are compensated for in the nib decoding Logic. I believe this is such a case where the cell is never coded in IB as a secure cell and during deciding it should just be assumed that it is. Thus this is not a perfect solution in the general case as it means that the developer can’t explicitly set a class which is different than the one which is assumed to go with the field type.

I believe the solution here is to make the assumption that if we are decoding a secure text field that a secure cell should be provided. Why this was not done by Apple is beyond me, but it nevertheless was not. Riccardo and I have dug deeply into this issue in the past.

I will create a pull request for this and you guys can review it and decide whether it is good or not. The challenge has been making this change function in the general case. I believe I might have a solution that will address this.

Gregory John Casamento <gcasa>
Project AdministratorIn charge of this item.
Sun 29 Oct 2017 09:08:07 AM UTC, comment #1:

I understand what is happening here, but not why. What is happening:

A secure text field in a nib is stored as NSTextField with custom class set to NSSecureTextField. So when the nib is loaded, you start off with a text field and a text field cell.

There is code specifically designed to handle this case, in -gui: GSNibLoading.m has -[NSClassSwapper unarchiver:didDecodeObject:] which is explicitly documented to handle the NSSecureTextFieldCell case. It tests for whether the new class responds to +cellName and replaces the cell object if so.

What I see in that method is that _originalClassName is NSSecureTextField, but newClass is NSTextField so +[newClass cell] returns NSTextFieldCell, and that is what gets set on the nib.

I understand that reversing the sense of that test fixes the problem, but do not understand that code well enough to know why that should be so or what other effects would result.

Graham Lee <leeg>
Mon 09 Nov 2015 09:31:15 PM UTC, original submission:

In the same PasswordPanel.nib of GNUMail, the secure text field is interpreted as such (and can be checked in the inspector) however once run, I see:

NSTextFieldCell(instance) does not recognize setEchosBullets:

I suppose thus that the Field class is correct, but not the underlying TextFieldCell, which is a normal one and not a Secure one.

Riccardo Mottola <rmottola>
Project Member

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by gcasa (Posted a comment)
  • -unavailable- added by leeg (Posted a comment)
  • -unavailable- added by rmottola (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    No Changes Have Been Made to This Item

    Back to the top


    Powered by Savane 3.1-cleanup1