First, you need to go to Hudson's system config screen to tell Hudson where's your JIRA. This plugin has an optional feature to update JIRA issues with a back pointer to Hudson build pages. This allows the submitter and watchers to quickly find out which build they need to pick up to get the fix. If you also want to use this feature, you need to supply a valid user id/password.If you need the comment only to be visible to a certain JIRA group, e.g. Software Development, enter the groupname.
JIRA also needs to be configured for Hudson to remotely login. Go to the general configuration screen and enable remote API calls. Again, this is only needed if you use the abovementioned optional feature, and if you forget to do so, Hudson will nicely warn you.
With that, JIRA keys in changelogs are now hyperlinked to the corresponding JIRA pages (complete with tooltips!)
To have Hudson update JIRA issues with back pointers to builds, you also need to configure jobs. I figured you might not always have write access to the JIRA (say you have a Hudson build for one of the Apache commons project that you depend on), so that's why this is optional.
And the following screen shows how JIRA issue is updated.
By taking advantages of Hudson's fingerprint feature, when your other projects that depend on this project picks up a build with a fix, those build numbers can be also recorded to JIRA. This is quite handy when a bug is fixed in one of the libraries, yet the submitter wants a fix in a different project. This happens often in my work, where a bug is reported against JAX-WS but the fix is in JAXB.
For curious mind, see this thread for how this works behind the scene.