Article
· Dec 22, 2015 1m read

Sign and verify in SMIME format

In some project, I found the need to use SMIME format https://www.ietf.org/rfc/rfc3851.txt, basically is an standard used to wrap a message together with its signature using a certificate (usually X509). Ensemble don't have a single class to do that but inside the Ensemble installation we have the openssl utility, so in this example I use the "openssl smime" command to sign or verify a message.

The example has two Business Process that able to sign or verify and in order to test I made a simple production.

Hope this helps

Discussion (10)1
Log in or sign up to continue

Is it your account on github ?

Looks like you already know how to create repository and work with github.

Just create another repository,  and create some readme (in english), license file. Most of projects on InterSystems technologies uses MIT license.

In your porject more then one class, so better to export each file separately. Easy to do it with Studio hooks, for example with this project. It can help to export project files automaticaly after compile.

And then after publish your project, Evgeny or somebody else who manage intersystems account, will fork it.

Hi David! Besides listed suggestions there are some another options to work with git from Cache Studio:

1. sc.plugin - Studio hooks tool for exporting/importing COS code in UDL format

2. source control - very simple Studio hooks implementation to export/import in xml format.

To work with github repos and source files you can try github desktop:

Create new repo on github and then click 'Install github Desktop' button as shown here.

Follow instructions.

From the practical point of view, taking into account backward compatibility and trying to cover as wide audience today as possible, I'd still recommend today to create repositories with XML classes exported. In a longer run, UDL export is much easier to handle [and provide better Cache' visibility], but this moment IMHO is not yet achieved.

Back to repositories questions: well, there are several people which has commit permissions to intersystems and intersystems-ru hubs. So many people could create fork of "interesting" project. But usually it's me, who maintain repositories in synchronized state (using this set of scripts if this matter).

So here is the recommended plan - you create personal repo, with reasonable README and accepted license (MIT is recommended, BSD or Apache is ok). Then give us know (via this same channels as we use at the moment).

And, if this sort of question is of some interest for you, in our (originated from Russian office) projects, which we start to recommend this simple set of code guidelines - https://github.com/intersystems-ru/cos-guidelines

You may entirely ignore them, if they are incompatible with your style (and we still ok to fork your code in that case, if it's still interesting and useful), but at least pay your attention. Eventually. [Or better yet open GitHub issue if you have any complaint or suggestion]