atlassian / nucleus

A configurable and versatile update server for all your Electron apps
Other
398 stars 93 forks source link

rpmsign failing #34

Closed leofidus closed 6 years ago

leofidus commented 6 years ago

When trying to publish a release draft, I get the following log output:

  nucleus:rest Releasing file: vipfy-desktop-0.1.2.x86_64.rpm to version: 0.1.2 for (vipfy/stable) +893ms
  nucleus:positioner Fetching temporary file: bdcfec7513d41ed6953f9c89dbc2e3ba/vipfy-desktop-0.1.2.x86_64.rpm for app: vipfy +1ms
  nucleus:positioner Handling upload (vipfy-desktop-0.1.2.x86_64.rpm) for app (vipfy) and channel (stable) for version (0.1.2) on platform/arch (linux/x64) +128ms
  nucleus:positioner Adding rpm file to yum repo +0ms
  nucleus:rest Unhandled error: /1/channel/4ef58dc1acb88964e2fe2b177b6559a0/temporary_releases/1/release +185ms
  nucleus:rest ChildProcessError: `rpmsign -D "_gpg_name 3727E90CE90B5FC1" --addsign 0.1.2-vipfy-desktop-0.1.2.x86_64.rpm` failed with code 1
  nucleus:rest     at ChildProcess.<anonymous> (/var/www/nucleus-server/node_modules/child-process-promise/lib/index.js:132:23)
  nucleus:rest     at emitTwo (events.js:126:13)
  nucleus:rest     at ChildProcess.emit (events.js:214:7)
  nucleus:rest     at maybeClose (internal/child_process.js:925:16)
  nucleus:rest     at Socket.stream.socket.on (internal/child_process.js:346:11)
  nucleus:rest     at emitOne (events.js:116:13)
  nucleus:rest     at Socket.emit (events.js:211:7)
  nucleus:rest     at Pipe._handle.close [as _onclose] (net.js:567:12) +0ms
  nucleus:rest Fetching temporary releases for app: vipfy and channel: stable +69ms

However, when I run rpmsign -D "_gpg_name 3727E90CE90B5FC1" --addsign 0.1.2-vipfy-desktop-0.1.2.x86_64.rpm on the rpm file generated by electron-forge it shows no output and exits with code 0. What could be causing his issue, or how could I go about debugging it?

I'm running the current master branch of nucleus.

MarshallOfSound commented 6 years ago

@leofidus Are you running this on linux?

leofidus commented 6 years ago

Yes, this is running on Debian 9

MarshallOfSound commented 6 years ago

@leofidus On latest master I added some extra logging in that area for when signing fails, hopefully you'll be able to figure it out 👍

https://github.com/atlassian/nucleus/commit/c5400423434513cfc703f5c33fc0341a088aaf2f#diff-5cf1c987e8a4782d9420df2aed695624R131

If you can't I recommend using the prebuilt docker image to run Nucleus, it's what we use so it should always work 😄

leofidus commented 6 years ago

Thanks, that helped a lot. It now shows the error message as

Failed to sign RPM file
Output:

error: Macro % has illegal name (%define)
error: Macro % has illegal name (%define)
error: Macro % has illegal name (%define)
You must set "%_gpg_name" in your macro file

The problem is double quoting/escaping. https://github.com/atlassian/nucleus/blob/master/src/files/utils/yum.ts#L62 calls getSignRpmCommand with (among other things) `"_gpg_name ${keyId}"`. That's nessesary for the docker variant of getSignRpmCommand because that code path doesn't escape by itself, but the linux path already lets node escape properly, leading to the _gpg_name parameter being escaped twice and thus breaking. Removing the quotes from the invocation in line 62 solves the problem on linux.

I'm not sure what the best fix is. In my opinion the linux path (letting the caller not worry about escaping) is better. But in any case, the handling of the args array should be uniform in both code paths in getSignRpmCommand

MarshallOfSound commented 6 years ago

@leofidus Its not all Linux distros having this issue, as mentioned the docker image works perfectly fine (which is Linux based). If you can find a way that works for all three cases (Linux, docker and non-linux) I'll gladly accept a PR for it :smile: