Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 396525 - Add functionality to sign update.rdf from command line
: Add functionality to sign update.rdf from command line
Status: NEW
Product: Other Applications
Classification: Client Software
Component: McCoy (show other bugs)
: unspecified
: All All
: -- enhancement with 8 votes (vote)
: M2
Assigned To: Nobody; OK to take it and work on it
: 439065 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2007-09-17 22:28 PDT by Davide Ficano
Modified: 2016-03-08 13:23 PST (History)
17 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

Added a window.setTimeout to patched code (22.34 KB, application/x-javascript)
2010-06-28 00:14 PDT, Davide Ficano
no flags Details
Modified mccoy.js (23.72 KB, application/x-javascript)
2015-11-30 23:46 PST, Serge Lebedev
no flags Details

Description Davide Ficano 2007-09-17 22:28:44 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv: Gecko/20070725 Firefox/
Build Identifier: 

I generate update.rdf from database then it is uploaded on server, the entire process is automatic.
Using McCoy the automatic process isn't applicable because you must interact with GUI.
Should be very useful if McCoy should be called from batch/script.
The command can prompt for master password or use a configuration file (no very safe approach)

Reproducible: Always

Steps to Reproduce:
Comment 1 Dave Townsend [:mossop] 2007-09-18 02:15:50 PDT
I'm concerned about the security of this, it requires that you have your private cryptographic keys held on your webserver which seems to be a bad idea to me.
Comment 2 Davide Ficano 2007-09-18 05:44:15 PDT
No, you don't need to copy private key on webserver.
I describe how figure out the activity (using an unix script):

1. create update.rdf from db and write it on local PC
2. sign the update.rdf using a McCoy command line command; this create a signed update.rdf
2.1 the McCoy command line prompt for your password (not visible)
3. copy (using FTP/SSH/email) only the update.rdf created and point 2. to your webserver.

The point 2.1 should be automated passing a config file, like ssh does for its keys. This second approach represents a security hole because somebody can obtain your private key file but this can also happen with current McCoy version.

Note: Actually the point 2. is not automated because you use the McCoy GUI to create the signed update.rdf.
Comment 3 Dave Townsend [:mossop] 2007-09-18 06:30:24 PDT
Ah I see, sorry I misinterpreted. It shouldn't be too difficult, though with it being xulrunner based it would still have dependencies on a windowing system despite it not displaying anything.
Comment 4 Nils Maier [:nmaier] 2007-09-18 11:54:54 PDT
(In reply to comment #1)
> I'm concerned about the security of this, it requires that you have your
> private cryptographic keys held on your webserver which seems to be a bad idea
> to me.

You might want to think again... Or else stick to this statement and disable https-based updates as the https-enabled webserver needs to hold private keys as well ;)
And, honestly, a webserver is likely far more secure than the average windows box the average extension developer uses.

Anyway, I wanted to second this request, and add that mccoy in CLI mode should work even on a headless system (i.e. no X), or else a compatible CLI tool needs to be developed.
Comment 5 Massimiliano Mirra 2007-09-18 18:33:54 PDT
I have some preliminary code for signing from the command line; dependencies are ruby and libxslt for the tool that prepares update.rdf and libnss/libnspr for the one that generates the digital sign.  No dependencies on graphic environment.

I'm not familiar with the etiquette for posting 3rd party code here -- if anybody is interested in testing, please drop me a mail for now.
Comment 6 Massimiliano Mirra 2007-10-31 18:30:34 PDT
(In reply to comment #5)
> I have some preliminary code for signing from the command line; dependencies
> are ruby and libxslt for the tool that prepares update.rdf and libnss/libnspr
> for the one that generates the digital sign.  No dependencies on graphic
> environment.

The above has been published at
Comment 7 Adrian Williams 2008-01-04 02:54:04 PST
Unfortunately for me, I'm running Windows and couldn't workout how to compile Spock for Windows.  So I spent a few hours hacking McCoy so that it can be run from the command line.  

The results are available at

I've also created a patch of trunk available at

Please don't judge my code too harshly.  It was a rather rushed job and I stopped working on it as soon as it worked for me.  Also RDF still does my head in.
Comment 8 Adrian Williams 2008-01-04 03:06:18 PST
Forgot to say what the command line options are:

To add the public key to the install.rdf:

-command install -installRDF <path> -key <lowercasekeyname>

To sign the update.rdf

-command update -updateRDF <path> -key <lowercasekeyname> [-xpi <pathToXPI>]

If you set -xpi it will generate and add the updateHash

If you have protected your keys with a master password then it will request the password before proceeding.
Comment 9 John J. Barton 2008-03-13 12:04:40 PDT
hey, me too ;-) I wrote a small mccoy extension

mccoy.exe -sign <file-url> -key <keyname>

Comment 10 Dave Townsend [:mossop] 2008-06-13 07:30:10 PDT
*** Bug 439065 has been marked as a duplicate of this bug. ***
Comment 11 Rusty Howell 2009-05-15 11:11:41 PDT
+1 on this feature. I would like a supported cli for mccoy to automate our signing process.
Comment 12 Rusty Howell 2009-05-15 11:58:21 PDT
FWIW... I was able to get Adrians patch working and I really liked his approach.
Comment 13 John Poole 2009-08-24 11:19:56 PDT
I was unable to get John J. Barton's extension to install/work, alas.  However, I did successfully integrate the patch referenced above by Adrian Williams (Comment #7)
and now have McCoy command processing integrated into my Ant environment.

I recommend Williams' patch should be integrated into the trunk so that McCoy no longer has to publish "no support to run McCoy from command line under Windows, but it is planned to add this support in the future."

I updated the above URL to reference this Bug.

Thanks Adrian!!
Comment 14 Matt Cooper 2010-01-26 18:33:02 PST
Has anyone had success with Adrian's patch on Mac OS X 10.6.2?

When I attempt to run with it, I get a segmentation fault:

pure virtual method called
terminate called without an active exception
Abort trap

Here's the detail from the Apple problem report:

Process:         mccoy [3485]
Path:            /Applications/
Identifier:      org.mozilla.mccoy
Version:         0.5 (0.5)
Code Type:       X86 (Native)
Parent Process:  bash [2994]

Date/Time:       2010-01-26 19:25:31.589 -0700
OS Version:      Mac OS X 10.6.2 (10C540)
Report Version:  6

Interval Since Last Report:          243769 sec
Crashes Since Last Report:           7
Per-App Interval Since Last Report:  1376 sec
Per-App Crashes Since Last Report:   4
Anonymous UUID:                      3C21AD80-C078-42E6-966B-200669F04EE0

Exception Codes: 0x000000000000000d, 0x0000000000007418
Crashed Thread:  0  Dispatch queue:

Thread 0 Crashed:  Dispatch queue:
0   ???                           	0x01a54f8c 0 + 27611020
1   XUL                           	0x015df7db XRE_GetFileFromPath + 6038161
2   XUL                           	0x015999a4 XRE_GetFileFromPath + 5751898
3   XUL                           	0x01599d45 XRE_GetFileFromPath + 5752827
4   XUL                           	0x01599e34 XRE_GetFileFromPath + 5753066
5   XUL                           	0x0159a263 XRE_GetFileFromPath + 5754137
6   XUL                           	0x01066fc2 XRE_GetFileFromPath + 301688
7   XUL                           	0x0115cacc XRE_GetFileFromPath + 1308034
8   XUL                           	0x0115cb43 XRE_GetFileFromPath + 1308153
9   XUL                           	0x0115c36c XRE_GetFileFromPath + 1306146
10  XUL                           	0x01159432 XRE_GetFileFromPath + 1294056
11  XUL                           	0x01104c45 XRE_GetFileFromPath + 947963
12  XUL                           	0x01062ca0 XRE_GetFileFromPath + 284502
13  XUL                           	0x01063110 XRE_GetFileFromPath + 285638
14  XUL                           	0x019257c1 JNIEnv_::CallStaticObjectMethod(_jclass*, _jmethodID*, ...) + 7515
15  XUL                           	0x01779f70 NS_GetComponentRegistrar_P + 27290
16  XUL                           	0x01747761 GetSecurityContext(JNIEnv_*, nsISecurityContext**) + 76105
17  XUL                           	0x0172644b JSD_GetValueForObject + 723560
18  XUL                           	0x0170f7f1 JSD_GetValueForObject + 630286
19  XUL                           	0x0170fa6b JSD_GetValueForObject + 630920
20          	0x98bf0b75 __NSFireDelayedPerform + 693
21      	0x97d60edb __CFRunLoopRun + 8059
22      	0x97d5e864 CFRunLoopRunSpecific + 452
23      	0x97d5e691 CFRunLoopRunInMode + 97
24           	0x94564f0c RunCurrentEventLoopInMode + 392
25           	0x94564cc3 ReceiveNextEventCommon + 354
26           	0x94564b48 BlockUntilNextEventMatchingListInMode + 81
27              	0x93c2dac5 _DPSNextEvent + 847
28              	0x93c2d306 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156
29  XUL                           	0x0170f668 JSD_GetValueForObject + 629893
30  XUL                           	0x01726406 JSD_GetValueForObject + 723491
31  XUL                           	0x0172662e JSD_GetValueForObject + 724043
32  XUL                           	0x0170f860 JSD_GetValueForObject + 630397
33  XUL                           	0x01779f0f NS_GetComponentRegistrar_P + 27193
34  XUL                           	0x01747806 GetSecurityContext(JNIEnv_*, nsISecurityContext**) + 76270
35  XUL                           	0x017263c1 JSD_GetValueForObject + 723422
36  XUL                           	0x0170fbf0 JSD_GetValueForObject + 631309
37  XUL                           	0x0170fcf2 JSD_GetValueForObject + 631567
38          	0x98c3bff1 __NSFireMachPort + 325
39      	0x97d64b72 __CFMachPortPerform + 338
40      	0x97d608db __CFRunLoopRun + 6523
41      	0x97d5e864 CFRunLoopRunSpecific + 452
42      	0x97d5e691 CFRunLoopRunInMode + 97
43           	0x94564f0c RunCurrentEventLoopInMode + 392
44           	0x94564bff ReceiveNextEventCommon + 158
45           	0x94564b48 BlockUntilNextEventMatchingListInMode + 81
46              	0x93c2dac5 _DPSNextEvent + 847
47              	0x93c2d306 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156
48              	0x93bef49f -[NSApplication run] + 821
49  XUL                           	0x0170f7d2 JSD_GetValueForObject + 630255
50  XUL                           	0x015ee03f XRE_GetFileFromPath + 6097653
51  XUL                           	0x010092d9 XRE_main + 13891
52  org.mozilla.mccoy             	0x0000326c start + 3040
53  org.mozilla.mccoy             	0x0000278e start + 258
54  org.mozilla.mccoy             	0x000026b5 start + 41
Comment 15 Dave Townsend [:mossop] 2010-05-26 08:15:43 PDT
I can no longer work on this project
Comment 16 Adrian Williams 2010-06-25 03:02:40 PDT
Matt: Did you ever succeed in getting my patch to work on your system.  I don't have access to Mac OS X so can't test it.  However, I am surprised that my changes would cause such a nasty crash.  Looking at the call stack, the problem would appear to be File I/O related.  Are you sure the paths you are supplying on the command line are correct?  Does McCoy work if you use it in GUI mode and select these files?
Comment 17 Matt Cooper 2010-06-25 10:38:22 PDT
It will sign the file via the command line but then seg fault.

Yes, using the GUI to sign it works just fine.

Comment 18 Adrian Williams 2010-06-27 03:35:04 PDT
So it does kind of work, but crashes afterwards.

Unfortunately, this is beyond my ability to help.  Hopefully there are some Mozilla/Mac OS gurus out there
Comment 19 Davide Ficano 2010-06-28 00:14:50 PDT
Created attachment 454453 [details]
Added a window.setTimeout to patched code

The problem seems related to the quit() method that is called while the window is 'under construction'.

I've added a setTimeout to process all command-line related code and seems to work fine.

Tha attached mccoy.js is the result of the Adrian patch plus the window.setTimout()

Tested only on OSX 10.6.4, this should work also on Win and Linux at least with a flashing window (a quick and dirty solution should be to move windows outside screen and then move to the correct position)
Comment 20 Max Dolgov 2011-04-20 14:34:36 PDT
Windows version works fine, thanks a lot, guys! 

But it fails on Linux:
(mccoy:25420): Gtk-WARNING **: cannot open display:

I have patched "mccoy.js" with "attachment454453 [details]" and re-packed mccoy.jar in Linux-version, then try to run it on Debian with command:

./mccoy -command update -updateRDF "./../pool/nix-update.rdf" -key justakey -xpi "./../pool/test.xpi"
Comment 21 V@no 2011-10-30 18:48:32 PDT
update.rdf signed via command line with proposed patch (attachment454453 [details]) fails validation by McCoy, however Firefox accepts the update.rdf
Comment 22 Daniel Mocanu 2012-12-07 08:09:14 PST
Hi Adrian Williams,
I installed the mccoy patch and ran from commandline. It gives me an error: "key not set". The key is in the key list when I open McCoy gui.
The command I ran is:
mccoy.exe -command update -updateRDF C:\update_a.rdf -key aaa
Comment 23 Adrian Williams 2012-12-08 14:02:05 PST
Hi Daniel,

Unfortunately, I haven't needed to use McCoy for a few years now.  I don't even know what I did with my development environment.  As such I probably wouldn't be of much help with your problem.  All I can say at the moment is that it did work for me on Windows XP and for Matt on Mac OS X.

I'm sure with an appropriate prod it would work for you too :)
Comment 24 Serge Lebedev 2015-11-30 23:46:35 PST
Created attachment 8694032 [details]
Modified mccoy.js

For a year I used to sign my update.rdf from command line with McCoy and uhura both, because I didn't managed to make uhura sign update.rdf correctly, and McCoy (with Adrian's patch and modified by me with static absolute paths to my files built-in) couldn't update hashes for my add-on, which has 3 targetApplications.

And so, here you can have my patch for McCoy for Windows (It will not work on Linux because of relative to absolute path calculation function, but it's easy to fix. It's just I don't need McCoy for Linux).

Now McCoy could be run from command line and accepts absolute OR relative paths to your update.rdf and/or .xpi files and updates hashes (sha256) for all targetApplications you have in your update.rdf. It also has a bunch of error messages, so you will know why it doesn't work for you.

This file is mccoy.js from %mccoy_folder%\chrome\mccoy.jar>\content\mccoy.js

How to use:

mccoy -command update -key key_name -updateRDF path_to_update_rdf [-xpi path_to_xpi]

Where key_name [required] is a name of your key, path_to_update_rdf [required] is an absolute or relative (to a folder with McCoy itself) path to your update.rdf, and path_to_xpi [optional] is an absolute or relative path to your .xpi file. It signs your update.rdf. And if you specified a optional path to your .xpi file - it would also update sha256 hashes in update.rdf.

BUT it won't update version number in your update.rdf. (I guess, it's a TODO if xpi-path is specified)

Examples of use:

mccoy -command update -key example_key -updateRDF d:\work\addon\update.rdf

mccoy -command update -key "example key" -updateRDF "d:\my work\addon\update.rdf"

mccoy -command update -key example_key_2 -updateRDF ..\update.rdf

mccoy -command update -key example_key_2 -updateRDF debug\update.rdf

mccoy -command update -key example_key_2 -updateRDF \..\.\update.rdf

mccoy -command update -key example_key_2 -updateRDF \debug\update.rdf

mccoy -command update -key example_key_3 -updateRDF d:\work\addon\update.rdf -xpi d:\work\addon\addon.xpi

mccoy -command update -key example_key_4 -updateRDF "..\\..\..\\..\\..\my work\addon\update.rdf" -xpi "C:\my work\addon\addon.xpi"

mccoy -command update -key example_key_4 -updateRDF "\\release\\update.rdf" -xpi ".\my work\addon\addon.xpi"

So, it should work with/without quotes, with/without trailing slash, with double slashes etc.

Basically, there're two possible behaviors of this:
1) it alerts an error and McCoy window blinks once for a short time;
2) the same as 1), but without alert;

IF no errors alerted AND McCoy window stays (as if you just open it via explorer) - it means that a fatal error occurred (this likely means that I forgot something). You could contact me and maybe I would fix that.
Comment 25 TheRave 2016-03-08 13:23:37 PST
With the latest mccoy.js i did not get the key installed at install.rdf. I need to start the GUI here. Is this patch only related to update.rdf?

I tried this:
E:\Mozilla\Extdev\mccoy\mccoy -command install -key "mykey" -installRDF "E:\Mozilla\Extdev\\install.rdf"

Note You need to log in before you can comment on or make changes to this bug.