[RCD] S/MIME encryption and signing plugin

A.L.E.C alec at alec.pl
Mon Jan 11 11:39:37 CET 2016


On 01/11/2016 11:10 AM, Владимир Горпенко wrote:
> I don't know, whether it is correct to connect both ways of encryption
> in one plug-in. Solve it you.

It is correct. That was the idea behind the Enigma plugin from the
beginning.

> I think, 90% of my texts are repeated that you already made for PGP
> encryption. If it is about sharing experience of transformation of the
> message from the S/MIME encryption form to decrypted and back, I am
> ready to make it and to offer code samples. Certainly, the same belongs
> and to signing of messages.

If we extend Enigma you'll get 80% less work in the future and you'll
get support "for free". Similar to the password plugin, S/MIME will be
just a driver, all the rest of code (like engine and UI) will be shared
and supported.

> Also, if the rcube developers accept my changes in the text of the
> program or will offer similar, smime_crypto can be used by users of
> version 1.1.3 +. As I see, the line 1.1 continues to be supported and,
> therefore, changes can be made.

We will not apply any changes to the core in 1.1, especially when they
are not needed in 1.2. And 1.1 will be discontinued after 1.2-stable is
released.

>> It is to be decided if we want a separate interface to manage
>> certificates or to store/display them on the same list with PGP keys.
>> Anyway, some UI work will be needed.
> I think that management of certificates and keys has to be allocated in
> the separate module or management of certificates and keys has to
> provide many possible options. Different users can are need different
> options: storage on the LDAP server, in SQL base or is simple in files.

Storage is the next thing that we could unify and make shared by all
Enigma drivers. At the moment Enigma uses files, but above I was
referring to the UI. We have a list of PGP keys. Do we want a separate
list for certificates or we could merge them on one list?

> Also management of certificates and keys can be transferred to users or
> is made the centralized. For example that option which I will do for
> myself, will be so specific that I won't even offer it to anybody.

I don't know what it is, but we always could add hooks in Enigma, so
you'd create a separate plugin only for this specific functionality.

> It is just simple. There are only two types of data - the certificate
> and a private key. Formats of these data are standard and even not
> necessarily their nobility.)) There is one problem - safe storage of
> private keys. It can be solved differently. It is too the reason for
> allocation of management of certificates and keys in the separate module.

Well, welcome in the server-side encryption word. The same applies to
PGP keys. In this case we just assume server is safe or not. There's
really no point (or just no way) in securing private keys stored on the
server.

> I think that it isn't enough to study only those places where the new
> code is directly built in. It is necessary to know the general structure
> and functioning of an Enigma. And for this purpose it is necessary to
> study some thousands of lines of a code of which it consists. I can't
> make it.

I'm sure it's not so bad ;) At least for the most of work we need.

> I was also so already strongly beaten out from the schedule. Besides,
> there are many of different tasks in which I have to be engaged.

Unfortunately I also have not much time recently to merge your code with
Enigma. But as you provided the code, I'm sure someone if not me will do
this eventually.

-- 
Aleksander 'A.L.E.C' Machniak
Kolab Groupware Developer        [http://kolab.org]
Roundcube Webmail Developer  [http://roundcube.net]
---------------------------------------------------
PGP: 19359DC1 @@ GG: 2275252 @@ WWW: http://alec.pl


More information about the dev mailing list