[BULK] upcoming release of xmlsectool 1.2.0

[Ian Young]

On 11 Apr 2013, at 21:38, "Krug, Jeff" <Jeff.Krug at gtri.gatech.edu> wrote:

> I took a look at it today, and I do have some questions regarding the "blacklist" related options, as it feels a little bit unclear how this was intended to work.  It seems like the option "--blacklistDigest" option can be used in a signature verification to cause said verification to potentially fail.  I get how this works, but the context for the list is just this single invocation of the tool, correct?  At least this seems to be the functionality I see.

Yes, --blacklistDigest adds the given digest to the blacklist for that single invocation.  No state is retained between executions, and that's by design.

> This makes the other two options a bit unclear to me.  Executing the listBlacklist shows md5 algorithms that are blacklisted internally to the tool (note this is technically an action command, which is odd context wise regarding the content of the current help which says the action commands are sign/verify/validate).

I'll grant you that the CLI is getting a bit unwieldy.  That's one reason I'm trying to move away from assuming that it can all be documented in the tool itself towards additional external documentation.  It may be that we can improve the documentation in both places, though, and I'd welcome suggestions in that area.

There's no detailed documentation for the blacklist feature at https://wiki.shibboleth.net/confluence/display/SHIB2/XmlSecTool yet, but clearly I need to add some.

> Finally, I am not sure I get when the --clearBlacklist would ever be used.

You'd use it if you wanted complete control over the blacklist, so that only the algorithms you list on the command line are blacklisted and not any pre-defined set.

> The way the current tool works, it does not seem that any state is maintained between executions of the code, and that option doesn't seem to allow you to remove the md5 algorithms from the default blacklist…

You *should* find that if you say --clearBlacklist --listBlacklist that no algorithms are blacklisted, even the MD5 ones.  Similarly, if you say things like this:

--clearBlacklist --blacklistDigest <whatever> --listBlacklist

… that just <whatever> is blacklisted.

> I totally understand the value/purpose of an algorithm blacklist, but it seems like this is not feature complete.  Should I be able to use the command "--blacklistDigest" as an action command to add an algorithm to a tool maintained list?  If that is the intent, such that all 3 of the new commands are action commands as opposed to signature verification options, they make sense...  But they do not work like that as far as I can tell.

There is no intention to establish a persistent blacklist across tool invocations.  I feel that would provide a very powerful foot-shooting tool, and that it's better for people who care about exactly what's being blacklisted for a particular execution to put the command required in a shell alias or something of that kind.

Of course, most people should be fine with the defaults.

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/dev/attachments/20130411/1d066a06/attachment.bin