Item12130: Add support for encrypted private key files in S/MIME

[Updated to reflect split with some configure enhancements that were originally bundled with this item. See revision 9 or earlier for the history. ]

The original S/MIME (signed email from Foswiki) support had some restrictions that I've figured out how to lift.

I'm opening this item so I can check-in the baseline work to trunk. It should be non-controversial; I don't think it rises to the level of requiring a feature proposal. It's basically just keeping up with the other wiki.

This changeset uses the existing configure infrastructure to support encrypted private key files and better user feedback. it should only effect sending S/MIME signed mail.

It also includes some additional checker classes in anticipation of other uses of certificates. (Think off-line tasks...)

-- TimotheLitt - 08 Oct 2012

hey Timothe - its consistent-enough-ish It is important to note however that when we release, we essentially release from trunk - we don't have the manpower to use the merge to release method.

-- SvenDowideit - 10 Oct 2012

NeedsMerge is handy if you just want to hold off from committing to the release branch for a while.

That might be because there's an imminent release and merging might cause an unwanted delay, OR the work might need a bit of testing/review before being merged into release branch.

-- PaulHarvey - 11 Oct 2012

In my case, as an infrequent (on average) contributor, I am not confident that I know the status of branches. So I commit to trunk and set NeedsMerge so the release manager or a developer more in tune with the branches can make the call and pull the change. It doesn't mean I have low confidence; I'm careful about what I checkin.

Should be easier on everyone than my former approach of posting a patch on the wiki for someone to (hopefully) grab. But without the risk (and frankly, overhead) for me of checking in to all the branches without being up-to-date on their status.

-- TimotheLitt - 11 Oct 2012

The point being made is that trunk / master IS our planned 1.2 branch. We don't have a separate branch for 1.2 yet. There is trunk (1.2), and one active branch - Release01x01, which will become 1.1.6. Once 1.2 is feature complete (as late as possible), we will create the Release01x02 branch. No worries on what you've committed though.

If you intend your task to be picked up in the release notes, please remember to set TargetRelease and ReleasedIn. Otherwise, your RM needs to go through the commit log and trace them back to missing tasks. Those fields control what the release note searches pick up.

Another really important thing to remember, (and to keep your RM's sane) is don't mix new features with other bugfixes in the same patch. If we have to take a partial patch, using a simple cherry-pick doesn't work. Multiple patches are fine. Just means a series of git cherry-pick commands.

-- GeorgeClark - 12 Oct 2012

I thought I set this back to waiting for mege a while ago. Here we go again.

-- TimotheLitt - 16 Oct 2012

Timothe, This is intended for 1.2, right? If so, it doesn't need merge. Anything in trunk is already merged, as we have not branched yet. We only need the merge if I need to pick up the changes into 1.1.6. And 1.1.6 will be our "final bug-fix release" from the 1.1.x branch. Yes there are some enhancements in 1.1.6, but we're trying to hold that to mostly minor stuff and hold any bigger changes for 1.2. We hope we can get 1.2 out around the same time as 1.1.6.

-- GeorgeClark - 17 Oct 2012

Timothe, I didn't test this, but I'm suspicious that it will work on Foswiki. it uses $this->{session}->writeWarning( "ERROR: Unable to decrypt " in Net.pm, but we don't have that in our API.

It's either Func::WriteWarning or $this->{session}->logger->log( 'warning', "S/MIME FAILED: $@" )

-- GeorgeClark - 07 Nov 2012

Good catch - thanks, a TWiki-ism that got by because no session argument is provided in the uses of Net.pm that I tested.

(Func would be a BAD idea here; that would indirectly bring most of Foswiki into configure.)

As discussed off-line, I took the opportunity to make mail event logging more consistent, centralized and controlable as rev 15942.

The log files should be more useful as a result.

I also made several recent checker improvements; these should be compatible with a patch release if the feedback parsing checkin is in the release. (The checkers do everything in check() if they don't see a FEEDBACK datum from the .spec file; the referenced checkin provides the routines they use to deterime this.) I'm not able to test compatibility here. Also note that the taint error fixes are, I think only necessary in an actual feedback environment (unsaved data comes in via CGI). But the fewer versions, the less support...

-- TimotheLitt - 07 Nov 2012

Oh, just a patch note in case you're inclined to cherry-pick: the final fix for 15935 involved a few more backslashes - that was picked up with the other updates mentioned.

-- TimotheLitt - 07 Nov 2012

I don't think this is waiting for me anymore. The logging was fixed/improved long ago, and further improvements to S/MIME setup should reduce the pain.

Feel free to let me know if I missed anything.

-- TimotheLitt - 07 Dec 2012

Commenting is disabled while not logged in