
Signing text within TextWrangler always is unverifiable
Reported by James ODonnell | April 9th, 2011 @ 02:42 AM | in 1.7 (closed)
I have tried to sign text over and over again using TextWrangler and the text always comes out unverifiable. The same issue is viewable within Entourage 2008, however other applications with text services (like ByWord, TextEdit) process signing and verification correctly.
I am assuming this may have to do with the proper processing of invisibles/line breaks in TextWrangler, however I do not have the skill to evaluate how the text is being modified in a way so text is never verifiable.
Comments and changes to this ticket
-
-
Alex (via GPGTools) April 9th, 2011 @ 01:04 PM
- State changed from new to open
- Assigned user set to ronin-140089 (at lighthouseapp)
Thank you for the report. It seems that I cannot verify text within TextWrangler - I get the message: "no verifiable text was found within the selection". But signing works fine.
-
ronin-140089 (at lighthouseapp) April 9th, 2011 @ 01:45 PM
I can verify this too. Sounds very strange - I can sign in TextWrangler but verification of the signed text fails.
However, after copying the text and pasting into TextEdit.app, verifying works fine.After having a look at it, I don't really have a clue what's wrong. According to Clipboard Viewer.app, TextWrangler gives (at least when copying the text) the correct pasteboard data (Application services use the pasteboard for data transfer). It also gives the correct data when using the verify service (at least according to simple logging statements)
-
Alex (via GPGTools) April 9th, 2011 @ 02:00 PM
Maybe asking the TextWrangler guys?
-- sent from my mobile phone
On 09.04.2011, at 13:45, "Lighthouse" <no-reply@lighthouseapp.com> wrote:
> TextWrangler
-
Alex (via GPGTools) April 18th, 2011 @ 02:05 PM
- State changed from open to hold
Sent a message to Bare Bones Software...
-
Alex (via GPGTools) April 18th, 2011 @ 06:05 PM
- Milestone set to 1.6
- Importance changed from High to
-
Alex (via GPGTools) April 18th, 2011 @ 06:45 PM
- State changed from hold to open
And here is the answer:
After some experimentation, this behavior appears to be due to how line endings are being treated on both sides.
Since currently the text exported by TextWrangler is CR-delimited, my guess is that one of these services normalizes (converts) the received text to LF-delimited while the other does not, thus resulting in a mismatch.
(I just ran a test which provided LF-delimited text from TextWrangler, and both services worked properly.)
Thus, I'll log a recommendation to make future versions of TextWrangler normalize the text before providing it.
I also suggest you check how the 'Sign' and 'Verify' services handle text as there may be other situations in which their behavior is inconsistent.
-
ronin-140089 (at lighthouseapp) April 18th, 2011 @ 07:36 PM
GnuPG has the following options which could cause this problems:
-t, --textmode --no-textmode Treat input files as text and store them in the OpenPGP canonical text form with standard "CRLF" line endings. This also sets the necessary flags to inform the recipient that the encrypted or signed data is text and may need its line endings converted back to whatever the local system uses. This option is useful when communicating between two platforms that have different line ending conventions (UNIX-like to Mac, Mac to Windows, etc). --no-textmode disables this option, and is the default.
I'll try playing around with this setting and see if I can improve the verification on our side.
-
ronin-140089 (at lighthouseapp) May 1st, 2011 @ 03:20 PM
After some investigation, this issue is caused by a missing feature in TextWrangler. Per-default, TextWrangler converts all line endings to LF (line feed, default for UNIX).
If you disable this feature (Preferences -> Text Files -> "Translate line breaks"), TextWrangler will show the whole file in one line (it ignores the default line breaks of OSX), but verifying signed text will succeed.
Therefore, TextWrangler destructively modifies all files it opens without any notification.
As I said, disabling this causes verification to succeed, but TextWrangler can't display the file anymore.TextWrangler should implement support for all line breaks without any conversion. The current solution is intolerable for a "code edit" (even TextEdit gets this right).
-
Alex (via GPGTools) May 2nd, 2011 @ 11:16 AM
- State changed from open to hold
Ok, waiting for upstream change and forwarded your comment to Bare Bones Software.
-
Alex (via GPGTools) May 17th, 2011 @ 09:54 PM
- Milestone changed from 1.6 to 1.7
- Importance changed from to
-
Alex (via GPGTools) January 1st, 2012 @ 01:39 PM
- Assigned user changed from ronin-140089 (at lighthouseapp) to Jeff burdges
- State changed from hold to waiting
-
James ODonnell January 1st, 2012 @ 08:44 PM
There are a few apps that have this issue, including TextWrangler (Entourage is a good example of another app). Although this is the "apps" fault for poorly handling line breaks / spaces - it would be nice if there was a configuration (hidden to most users) to do a pre-conversion before encryption to convert the line breaks before processing. rather than waiting for each app vendor to update their code. THe reason I am saying this is b/c MSFT will never update Entourage again, but there are still users out there who use that b/c there is no better email app for Exchange 2003 servers....
-
Alex (via GPGTools) January 1st, 2012 @ 09:01 PM
- State changed from waiting to open
If other apps have the same issue you might be right and maybe we can do something about it...
-
Jeff burdges January 2nd, 2012 @ 03:34 AM
If I understand this problem, we could solve it by adding this code to GPGServices.m's verifyTextString: immediately after the verifySignature: line.
if([sigs count] == 0) { NSString *retry1 = [inputString stringByReplacingOccurrencesOfString:@"\r\n" withString:@"\n"]; sigs = [ctx verifySignature:[retry1 UTF8Data] originalData:nil]; if([sigs count] == 0) { NSString *retry2 = [inputString stringByReplacingOccurrencesOfString:@"\n" withString:@"\r\n"]; sigs = [ctx verifySignature:[retry2 UTF8Data] originalData:nil]; } }
Or should we find some better way using gpg's -t option?
-
Alex (via GPGTools) January 2nd, 2012 @ 09:53 AM
Could work. Easy to test if you've TextWrangler installed (free application).
-
Jeff burdges January 13th, 2012 @ 05:57 PM
- State changed from open to fixed
-
-
-
Support January 15th, 2012 @ 01:45 PM
From what I read in http://support.gpgtools.org/discussions/everything/294-gpgservices-... it seems that currently we have problems with:
- TextWrangler
- Evernote
-
steve January 29th, 2012 @ 03:40 PM
- State changed from open to duplicate
- Importance changed from to Low
Duplicate of http://gpgtools.lighthouseapp.com/projects/73378/tickets/14-keys-wo...
Please subscribe to the libmacgpg ticket if you want to stay up to date if anything changes or is being worked on.
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป