http://www.bouncycastle.org/ appears to have the classes needed for this! see also bug 38384 re sPop3 and smtps (TLS/SSL)
would BC be acceptable license-wise? see also bug 45053
For reading signed email messages, it would be nice to be able to test the following: 1. Whether a mail message was signed 2. Who signed the mail message 3. is the signature valid (1) is already possible to some extend with the current Mail Reader Sampler: One can use a Response Assertion that checks the content-type of the message. For (2) and (3) it would be best to create a new Assertion Further the Mail Reader Sampler has to be extended to store the whole Mime message it receives. This is needed to verify the signature in the Assertion.
Created attachment 22123 [details] SMIMEAssertion Created an SMIME Assertion for Jemeter. It depends on the Bouncycastle, namely on the bcprov.jar and the bcmail.jar. It only works together with a MailReaderSampler. I had to make some changes original MailReaderSampler which did not store the whole MIME message retrieved. See Bug 45200 Features: - checks that a mail was signed / or not signed - verifies the signature - checks the identity of the signer. I.e. allows to set constraints on the signer certificate
Created attachment 22165 [details] SMIMEAssertion 2 Adapted the patch such that it works together with the patch in Bug 45200 currently only checks the signature of the first child sample result.
I am currently working on this topic and have used this class with the svn version: 946591 Is there any reason to not include it in the main distribution? I would be willing to correct things that may be pending.
(In reply to comment #1) > would BC be acceptable license-wise? > > see also bug 45053 Yes, Bouncy Castle is OK license-wise
It would be possible to add this, but I think the jars would have to be optional. It looks as though each version of Java needs its own jar, and the jars are relatively large for a feature which is likely to be needed by a small percentage of JMeter users. I don't know if it is possible to code the GUI class so it fails gracefully at run-time if the jars are not present?
Coding the GUI class to fail gracefully in the absence of the jars is not a problem. We can do it by testing if we can instantiate the BouncyCastleProvider: public static boolean isBouncyCastleAvailable() { try { Class.forName("org.bouncycastle.jce.provider.BouncyCastleProvider"); } catch (ClassNotFoundException e) { return false; } return true; } The problem is that the SMIMEAssertion class is also instantiated when we try to open a file that has this assertion. Since the SMIMEAssertion class has several bouncy castle imports, the class loading breaks before we can reach the graceful fail approach of the GUI class. I suppose we can modify the architecture a bit to migrate all BC dependent calls to an auxiliary class. But please keep in mind that the SMTPSampler also references the BC library. But I suppose we can also implement a graceful failure interface there. See bug45053
Created attachment 25481 [details] SMIMEAssertion patch This patch contains a SMIMEAssertion with a graceful failure presentation at the GUI level when the bouncy castle jar is not present.
Do we have progress on the acceptance of this patch? Is there anything else missing? I still have some time that I can invest on this topic.
Latest Patch looks good. The GUI loads fine even if the BC jars are missing so they are only needed for compiling JMeter. [I think the "Check values" option should be last as this will allow the radio buttons to appear closer together, but I can fix that later.] It would be helpful to have a patch for the documentation as well, i.e. xdocs/user_manual/component_reference.xml. Would you be able to provide that? The new info should go at the end of the Assertions section (to avoid renumbering everything). Also, some test cases would be good.
Note: existing JUnit tests for Assertions are here: http://svn.apache.org/repos/asf/jakarta/jmeter/trunk/test/src/org/apache/jmeter/assertions in case that helps.
Created attachment 25573 [details] SMIME Assertion screenshot
Created attachment 25574 [details] Patch for the screen shot I have also added the png file as another attachment
Created attachment 25575 [details] Documentation patch I am unsure on how to process this xml file to generate the documentation. It may not generate the output that I expected.
Junit tests will need to wait a couple more days, but I believe I will be able to work on it.
Thanks again. Code has been added to SVN: URL: http://svn.apache.org/viewvc?rev=958022&view=rev Log: Bug 38387 - Add SMIME Assertion Initial checkin, with minor adjustments Added: jakarta/jmeter/trunk/src/components/org/apache/jmeter/assertions/SMIMEAssertion.java (with props) jakarta/jmeter/trunk/src/components/org/apache/jmeter/assertions/SMIMEAssertionTestElement.java (with props) jakarta/jmeter/trunk/src/components/org/apache/jmeter/assertions/gui/SMIMEAssertionGui.java (with props) Modified: jakarta/jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties jakarta/jmeter/trunk/xdocs/usermanual/component_reference.xml URL: http://svn.apache.org/viewvc?rev=958031&view=rev Log: Raw types Missing @Override marker Modified: jakarta/jmeter/trunk/src/components/org/apache/jmeter/assertions/SMIMEAssertion.java jakarta/jmeter/trunk/src/components/org/apache/jmeter/assertions/gui/SMIMEAssertionGui.java URL: http://svn.apache.org/viewvc?rev=958033&view=rev Log: Allow for empty sub-results. Modified: jakarta/jmeter/trunk/src/components/org/apache/jmeter/assertions/SMIMEAssertion.java URL: http://svn.apache.org/viewvc?rev=958035&view=rev Log: Bug 38387 - Add SMIME Assertion Updated screenshot Added: jakarta/jmeter/trunk/docs/images/screenshots/assertion/smime.png (with props) jakarta/jmeter/trunk/xdocs/images/screenshots/assertion/smime.png (with props) Modified: jakarta/jmeter/trunk/xdocs/usermanual/component_reference.xml I had to make a few changes (e.g. GUI now shows normal screen regardless; it's only at run-time that the BC jars are detected). However these were very easy to do as the BC-dependent code is nicely packaged in a single class. == If you do find time to add some JUnit tests, please attach to this issue. Or, if you only have test files and certs, please attach those. Also, if you get a chance to test the code, it will be in nightly builds from r958035 - thanks!
Missing some bouncy castle jar in ant script (download_jars)?
(In reply to comment #18) > Missing some bouncy castle jar in ant script (download_jars)? Well spotted! Fixed in SVN: URL: http://svn.apache.org/viewvc?rev=958074&view=rev Log: Oops - forgot to include the BC jars in the download Props to Milamber for spotting this! Modified: jakarta/jmeter/trunk/build.properties jakarta/jmeter/trunk/build.xml
Compile works fine, thanks!
Created attachment 25650 [details] Small patch for saveservice.properties Include two changes: 1- SMIME 2- JMS (recent changes) https://issues.apache.org/bugzilla/show_bug.cgi?id=49482 All tests works with this patch [java] OK (1984 tests)
(In reply to comment #21) > Created an attachment (id=25650) [details] > Small patch for saveservice.properties > > Include two changes: > 1- SMIME > 2- JMS (recent changes) > https://issues.apache.org/bugzilla/show_bug.cgi?id=49482 > > All tests works with this patch > [java] OK (1984 tests) Thanks again for finding these bugs! Fixed in URL: http://svn.apache.org/viewvc?rev=958761&view=rev Log: Bug 38387 - Add SMIME Assertion Forgot to add saveservice shorthand property names Modified: jakarta/jmeter/trunk/bin/saveservice.properties
Created attachment 25661 [details] smime assertion with added fields
Created attachment 25662 [details] This patch allows the specification of the message position Since we are working on this assertion I thought I should submit this small patch. I have added a small functionality to this assertion. This patch allows to specify the message position that should be asserted. As it currently is implemented it always takes the first one, which is not optimal.
Created attachment 25663 [details] New screenshot for documentation
Good addition, but it would be simpler (and more flexible) to use just a message number, where negative numbers count from the last message, i.e. -1 = last, -2 = penultimate etc. This also means that a variable reference can be used.
What you are suggesting is the same as the message position option but starting from the last and counting backwards. Currently the message position counts from the first message. Having only relative positioning does not solve the problem of the last message (in my patch) or the first message (in your proposition). This occurs since you don't know in advance the number of messages that may be available in the INBOX.
(In reply to comment #27) > What you are suggesting is the same as the message position option but starting > from the last and counting backwards. Only for negative numbers. > Currently the message position counts from the first message. In my version, positive numbers would still do so. > Having only relative positioning does not solve the problem of the last message > (in my patch) or the first message (in your proposition). This occurs since you > don't know in advance the number of messages that may be available in the > INBOX. Huh? For LAST, your code does: msg = getMessageFromResponse(response,subResults.length -1); This is identical to my proposal: int offset = -1; msg = getMessageFromResponse(response,subResults.length+offset); The code would be almost identical, except that instead of 3 radio buttons and a text field, there would only be a text field. I'll probably implement that shortly. However, I'm not yet sure whether to start numbering messages at 0 or 1. Maybe 0 should be reserved for the container message (if there is one), or maybe 0 and 1 should both indicate first.
I see your point. I thought you only wanted to have negative numbers. In that case in your approach it would not be possible to know in advance what would be the first element since you don't know how many messages will come (subResults.length). If you allow positive AND negative numbers than the user can easily specify last and first. Agreed :)
I think this is now complete
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/1670