Error loading /pgp after generating key

[ageis]

Thanks for this plugin! It's pretty great.

But I'm now getting this error on loading /pgp. That page worked before I generated the main key. I used the rake task generate_redmine_pgpkey to do so. Let me know if you can reproduce this.

Started GET "/pgp" for 162.158.255.86 at 2015-09-09 12:08:06 -0700
Processing by PgpkeysController#index as HTML
  Current user: kevin (id=6)
  Rendered plugins/openpgp/app/views/pgpkeys/index.html.erb within layouts/base (244.9ms)
Completed 500 Internal Server Error in 252ms (ActiveRecord: 0.8ms)

ActionView::Template::Error (EOFError):
    65:             </p>
    66:             <p>
    67:               <%= label_tag 'metadata', l(:label_metadata) %>
    68:               <%= text_area_tag 'meta', @server_pgpkey.metadata, rows: "4", readonly: true %>
    69:             </p>
    70:             <p>
    71:               <%= label_tag 'key', l(:label_public_key) %>
  lib/redmine/sudo_mode.rb:63:in `sudo_mode'

Update: I tried using update_redmine_pgpkey with an existing key and I'm still getting this error.

[ageis]

Looks like @server_pgpkey.metadata and @server_pgpkey.public_key are tripping things up.

[ageis]

This might be related to the format of my key file - it contained the public key in addition to the private key. Also the user I was running the Rake task as was different from the webserver/Redmine process user, so they were referring to different keyrings. In any case, I got things working by manually importing the secret key and this issue can be considered resolved for myself anyway.

[garrettr]

@ageis So is this still an issue at all? Or is it invalid because you were confused by running the Rake task as a different user than the webserver/redmine process user?

[garrettr]

Either way, if the rake tasks need to be run as a particular user for them to work, that should either be fixed or documented to avoid this kind of "gotcha" in the future.

[ageis]

I agree the instructions should be updated to specify that rake tasks should be run as the user owning the Redmine process, and think that was the main issue here considering that I used the built-in key generation.

When I went to try key importation on the other hand, there may have been a separate user error involving the key file I was importing - which contained multiple private keys - and that may have caused a problem as well, though I can't be sure because I haven't investigated or tried to reproduce it enough to rule out the permissions factor - but I think the update_redmine_pgpkey task should probably do some checking to make sure it only imports one private key, and that's an other recommendation.

[timegrid]

wrong user

I see, I'll add that note concerning the owner of the redmine process, thanks.

wrong key ring

@ageis If you just imported the key manually into gpg without using any of the provided methods, I think, there might be a problem on the /pgp view showing the public key to users, although decryption should still work. If you imported the key in the right key ring manually after the "redmine" import into the wrong key ring, the right fingerprint should be still in the database. If you see the public key for the server (on the right side) on the /pgp view, everything is fine.

Background for saving the fingerprint in the database: Actually I wanted to add the same abstraction for picking a private key for decryption, as I implemented for picking the public keys for the encrytion part, using the fingerprints as the identifier for the gpg key ring search. In the end, there was at least no obvios way to choose a certain key for decryption in mail-gpg / gpgme, so I left it be. I assume, gpgme is just picking the right one using the key ID. Nevertheless, the public key shown to other users has to be deliberately chosen by the redmine admin, so there's still a reason behind using the fingerprint as identifier for the private key.

validity check

There is a regex check in place. But you are right, I have not thought about the possiblity of multiple private keys. I'll refine that check and perhaps that part of the readme file.