[HTTPS-Everywhere] Verifying signatures in a FF extension?

[Jeff Beach]

Resend.


-------- Original Message --------
Subject: 	jeff.beach at newyorkcasual.com can be removed from the HTTPS 
everywhere mailing list.
Date: 	Tue, 17 Jun 2014 16:57:58 +0700
From: 	Jeff Beach <jeff.beach at newyorkcasual.com>
Organization: 	New York Casual
To: 	https-everywhere-request at lists.eff.org



I had originally joined the HTTPS everywhere list to try to get my 
ecommerce website included...but subsequently found out that this was a 
highly technical discussion which was not reasonably suitable for my 
needs.  Fortunately, a kind person on the list generously helped me out 
by including www.newyorkcasual.com on HTTPS everywhere; I very much 
wanted to thank them, but inadvertently had deleted their email...now I 
have no way to thank them.

At any rate, I think it's probably OK at this time to remove 
jeff.beach at newyorkcasual.com from the HTTPS everywhere mailing list.  I 
appreciate the help and will spread the word about HTTPS Everywhere.

*Thank you,*

//

*Jeff Beach*

Founder & CEO

**

**

**

*New York Casual LLC***

*4348 Covey Ct.*

*Grand Blanc, MI 48439*

**

*www.newyorkcasual.com <http://www.newyorkcasual.com>*

**

On 7/7/2014 10:05 PM, Yan Zhu wrote:
> On 07/07/2014 06:31 AM, Yan Zhu wrote:
>> On 07/04/2014 06:57 PM, Red wrote:
>>> On 2014-07-04, 3:57 PM, Yan Zhu wrote:
>>>> One idea is to look through the signing code from Uhura (command line
>>>> signing utility for Mozilla extensions):
>>>> http://www.softlights.net/download.html. This should make the correct
>>>> signature format, since we use it to generate the signature field in
>>>> update.rdf for HTTPS Everywhere.
>>>>
>>>> Actually, it looks like what you want is lines 148-187 in the Linux
>>>> Uhura script.
>>> I appreciate the suggestion!
>>>
>>> I found that Uhura also uses `openssl dgst` to sign data, which is what
>>> I have been using more recently.  The script also, however, explicitly
>>> specifies the use of the "-binary" flag, which appears to be the default
>>> behavior.  Just to be sure, I tried signing and then base64-encoding the
>>> signature of the digest of update.json, but in both cases I ended up
>>> with the same thing.
>>>
>> Have you been doing the weird ASN1 template conversion that Uhura does
>> after generating the signature? I think that part is crucial.
>>
>> You can either port the Uhura script from Perl (ugh) to something more
>> sane that takes a generic string or file as input, or you can maybe use
>> this tool that someone wrote:
>> http://dxr.mozilla.org/mozilla-central/source/security/nss/cmd/pk1sign/pk1sign.c
>>
>> Found the latter via https://bugzilla.mozilla.org/show_bug.cgi?id=685852
> I managed to get your test case to pass using a public key and signature
> generated via nss-tools. Patch attached so you can check that it works
> for you as well.
>
> The process was somewhat convoluted and perhaps infeasible in production
> (no way to install nss-tools on an airgapped machine), but here is a
> gist of how I did it:
> https://gist.github.com/diracdeltas/39d48e315d4ce1a67b83.
>
> It would be useful if you could make a python/shell/perl script based on
> Uhura or pk1sign.c that takes an OpenSSL-generated RSA key and a hash as
> input and outputs the signature.
>
>>
>>
>>
>> _______________________________________________
>> HTTPS-Everywhere mailing list
>> HTTPS-Everywhere at lists.eff.org
>> https://lists.eff.org/mailman/listinfo/https-everywhere
>>
>
>
>
> _______________________________________________
> HTTPS-Everywhere mailing list
> HTTPS-Everywhere at lists.eff.org
> https://lists.eff.org/mailman/listinfo/https-everywhere

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140707/1a3555f8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 12218 bytes
Desc: not available
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140707/1a3555f8/attachment-0001.gif>