User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:126.96.36.199) Gecko/20070725 Firefox/188.8.131.52
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)
Steps to Reproduce:
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.
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.
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.
(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.
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.
(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
The above has been published at http://hyperstruct.net/projects/spock
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 http://www.xuluwarrior.com/development/mccoy-0.5.xuluwarrior.en-US.win32.zip
I've also created a patch of trunk available at http://www.xuluwarrior.com/development/mccoy_cmdline_xuluwarrior.patch
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.
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.
hey, me too ;-) I wrote a small mccoy extension
mccoy.exe -sign <file-url> -key <keyname>
*** Bug 439065 has been marked as a duplicate of this bug. ***
+1 on this feature. I would like a supported cli for mccoy to automate our signing process.
FWIW... I was able to get Adrians patch working and I really liked his approach.
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) http://www.xuluwarrior.com/development/mccoy_cmdline_xuluwarrior.patch
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." https://developer.mozilla.org/en/McCoy
I updated the above URL to reference this Bug.
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
Here's the detail from the Apple problem report:
Process: mccoy 
Version: 0.5 (0.5)
Code Type: X86 (Native)
Parent Process: bash 
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 Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: 0x000000000000000d, 0x0000000000007418
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
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 com.apple.Foundation 0x98bf0b75 __NSFireDelayedPerform + 693
21 com.apple.CoreFoundation 0x97d60edb __CFRunLoopRun + 8059
22 com.apple.CoreFoundation 0x97d5e864 CFRunLoopRunSpecific + 452
23 com.apple.CoreFoundation 0x97d5e691 CFRunLoopRunInMode + 97
24 com.apple.HIToolbox 0x94564f0c RunCurrentEventLoopInMode + 392
25 com.apple.HIToolbox 0x94564cc3 ReceiveNextEventCommon + 354
26 com.apple.HIToolbox 0x94564b48 BlockUntilNextEventMatchingListInMode + 81
27 com.apple.AppKit 0x93c2dac5 _DPSNextEvent + 847
28 com.apple.AppKit 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 com.apple.Foundation 0x98c3bff1 __NSFireMachPort + 325
39 com.apple.CoreFoundation 0x97d64b72 __CFMachPortPerform + 338
40 com.apple.CoreFoundation 0x97d608db __CFRunLoopRun + 6523
41 com.apple.CoreFoundation 0x97d5e864 CFRunLoopRunSpecific + 452
42 com.apple.CoreFoundation 0x97d5e691 CFRunLoopRunInMode + 97
43 com.apple.HIToolbox 0x94564f0c RunCurrentEventLoopInMode + 392
44 com.apple.HIToolbox 0x94564bff ReceiveNextEventCommon + 158
45 com.apple.HIToolbox 0x94564b48 BlockUntilNextEventMatchingListInMode + 81
46 com.apple.AppKit 0x93c2dac5 _DPSNextEvent + 847
47 com.apple.AppKit 0x93c2d306 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156
48 com.apple.AppKit 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
I can no longer work on this project
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?
It will sign the file via the command line but then seg fault.
Yes, using the GUI to sign it works just fine.
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
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)
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"
update.rdf signed via command line with proposed patch (attachment454453 [details]) fails validation by McCoy, however Firefox accepts the update.rdf
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
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 :)
Created attachment 8694032 [details]
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.
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\My-Addon@test.de\install.rdf"