Closed
Bug 396525
Opened 17 years ago
Closed 5 years ago
Add functionality to sign update.rdf from command line
Categories
(Other Applications Graveyard :: McCoy, enhancement)
Other Applications Graveyard
McCoy
Tracking
(Not tracked)
RESOLVED
WONTFIX
M2
People
(Reporter: davide.ficano, Unassigned)
References
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 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: 1. 2. 3.
|
||
Comment 1•17 years ago
|
||
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.
Severity: normal → enhancement
OS: Windows Vista → All
Hardware: PC → All
|
Reporter | |
Comment 2•17 years ago
|
||
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•17 years ago
|
||
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•17 years ago
|
||
(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•17 years ago
|
||
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•17 years ago
|
||
(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 http://hyperstruct.net/projects/spock
|
||
Comment 7•17 years ago
|
||
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.
|
|
||
Comment 8•17 years ago
|
||
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•16 years ago
|
||
hey, me too ;-) I wrote a small mccoy extension https://fireclipse.svn.sourceforge.net/svnroot/fireclipse/trunk/FireclipseExtensions/chromebug/mccoy/signOnTheLine/readme.txt mccoy.exe -sign <file-url> -key <keyname>
|
|
||
Updated•16 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → M2
|
|
||
Updated•16 years ago
|
Assignee: nobody → dtownsend
|
|
||
Updated•16 years ago
|
Status: NEW → ASSIGNED
|
||
Comment 11•15 years ago
|
||
+1 on this feature. I would like a supported cli for mccoy to automate our signing process.
|
|
||
Comment 12•15 years ago
|
||
FWIW... I was able to get Adrians patch working and I really liked his approach.
|
||
Comment 13•15 years ago
|
||
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. Thanks Adrian!!
|
||
Comment 14•14 years ago
|
||
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/McCoy.app/Contents/MacOS/mccoy 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 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
|
|
||
Comment 15•14 years ago
|
||
I can no longer work on this project
Assignee: dtownsend → nobody
Status: ASSIGNED → NEW
|
|
||
Comment 16•14 years ago
|
||
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•14 years ago
|
||
It will sign the file via the command line but then seg fault. Yes, using the GUI to sign it works just fine. Thanks, Matt
|
|
||
Comment 18•14 years ago
|
||
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
|
|
Reporter | |
Comment 19•14 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
update.rdf signed via command line with proposed patch (attachment454453 [details]) fails validation by McCoy, however Firefox accepts the update.rdf
|
||
Comment 22•12 years ago
|
||
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•12 years ago
|
||
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•9 years ago
|
||
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•8 years ago
|
||
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"
|
||
Comment 26•5 years ago
|
||
McCoy is no longer maintained, closing.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
|
||
Updated•5 years ago
|
Product: Other Applications → Other Applications Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•