It is possible to copy text from a password field (BTextView)

[ksmith]

When a BTextView is set to HideTyping, it is still possible to copy the text from the BTextView and paste it into another app (i.e., StyledEdit) and read the password.

[ksmith]

Proposed fix to this issue. It simply doesn't allow a user to copy text from a password field.

[jackburton]

How does BeOS behave here ?

[kaoutsis]

Replying to jackburton:

How does BeOS behave here ?

copied the from a password field; pastes the (i find it very logic!)

[jackburton]

Replying to kaoutsis:

Replying to jackburton:

How does BeOS behave here ?

copied the from a password field; pastes the (i find it very logic!)

I thought so (behaves like windows or gnome). So the patch isn't correct.

[ksmith]

Replying to jackburton:

Replying to kaoutsis:

Replying to jackburton:

How does BeOS behave here ?

copied the from a password field; pastes the (i find it very logic!)

I thought so (behaves like windows or gnome). So the patch isn't correct.

Sorry, I suppose I should have checked how BeOS behaves before proposing a patch. I will continue looking into this.

[johndrinkwater]

Replying to jackburton:

Replying to kaoutsis:

Replying to jackburton:

How does BeOS behave here ?

copied the from a password field; pastes the (i find it very logic!)

I thought so (behaves like windows or gnome). So the patch isn't correct.

Can we deviate from this behaviour, why would anyone want to copy from a password field? Just ignore the request and leave clipboard untouched. Unless copying from one password field to another works (a really bad idea), it seems wholly stupid imo.

[ksmith]

This patch uses the GetString method from the TextGapBuffer to obtain the "bulleted" text from the TextView if it is in password mode.

[ksmith]

Replying to johndrinkwater:

Replying to jackburton:

Replying to kaoutsis:

Replying to jackburton:

How does BeOS behave here ?

copied the from a password field; pastes the (i find it very logic!)

I thought so (behaves like windows or gnome). So the patch isn't correct.

Can we deviate from this behaviour, why would anyone want to copy from a password field? Just ignore the request and leave clipboard untouched. Unless copying from one password field to another works (a really bad idea), it seems wholly stupid imo.

If copying is infact allowed, you will only be copying a string of bullets, not the password, so pasting into another password field would not work. I think its silly to allow copying from password fields because of this reason (Mac OS X does not allow copying from password fields. If you attempt to copy from one, an error sound will play). However, BeOS allowed it and I suppose they want Haiku to function in a similar way to BeOS.

[axeld]

While we're indeed striving for BeOS binary compatibility, that does not mean we want to imitate all of its quirks. In this case, I'd think copying the dots is pretty much the stupidest thing that could happen (well, after copying the actual password, of course :-)). I think that's just a good opportunity to play the system beep.

[kaoutsis]

Replying to axeld:

While we're indeed striving for BeOS binary compatibility, that does not mean we want to imitate all of its quirks. In this case, I'd think copying the dots is pretty much the stupidest thing that could happen (well, after copying the actual password, of course :-)). I think that's just a good opportunity to play the system beep.

second thought, (correcting my ... logic:)): you are right! there is no meaning copying the asterisks. The system should disallow the copy, play a system beep and may be display an alert message.

[jackburton]

Replying to kaoutsis:

second thought, (correcting my ... logic:)): you are right! there is no meaning copying the asterisks. The system should disallow the copy, play a system beep and may be display an alert message.

And actually, I was wrong: Neither Windows nor Gnome let you copy from a password field. I was obviously confused since you can _PASTE TO_ a password field, I just never tried (before now) to copy from one. Windows displays a tooltip saying you can't do that. Gnome copies the bullets. But I agree this is stupid.

[jackburton]

Replying to jackburton:

And actually, I was wrong: Neither Windows nor Gnome let you copy from a password field. I was obviously confused since you can _PASTE TO_ a password field, I just never tried (before now) to copy from one. Windows displays a tooltip saying you can't do that. Gnome copies the bullets. But I agree this is stupid.

So, I'll apply the patch, plus I'll let the system beep() in case one tries to copy from the password field.

[jackburton]

Replying to jackburton:

Replying to jackburton:

And actually, I was wrong: Neither Windows nor Gnome let you copy from a password field. I was obviously confused since you can _PASTE TO_ a password field, I just never tried (before now) to copy from one. Windows displays a tooltip saying you can't do that. Gnome copies the bullets. But I agree this is stupid.

So, I'll apply the patch, plus I'll let the system beep() in case one tries to copy from the password field.

Oh, I forgot: Should we also forbid copying text using the BTextView methods ? I mean: what should happen if the developer calls BTextView::Copy() from its code ? And what happens on R5 when the developer calls BTextView::Text() or TextLength() ? And how should we handle that case anyway ?

[stippi]

I think the application that the text view is embedded in can be trusted. Therefor all methods to get the text should work. However, special care needs to be taken when messaging/scripting is involved. Especially when the reply target is not in the same team... :-)

[jackburton]

Replying to stippi:

I think the application that the text view is embedded in can be trusted. Therefor all methods to get the text should work. However, special care needs to be taken when messaging/scripting is involved. Especially when the reply target is not in the same team... :-)

But if the app sends a B_COPY message, the message will come from the same team, no? I.E: in case the user hits ALT-C or ALT-X, it's the window which will handle the message. So we either forbid copying in every case (also when the Copy() (and Cut()) function is called directly) or never.

[jackburton]

Fixed in hrev22129. I opted for this solution:

When the Copy() or Cut() public methods are called, you get the real text. If they're called via scripting or via messages, you get a beep.