Hi,

We use DCPCrypt in our projects. Compared to the latest download from Lazarus CCR site, I have made the following changes.

* Split the one .lpk package into two. One that is runtime only and another which is design-time only. This allows DCPCrypt to be used with non-LCL based applications - which was previously not possible.

* I have also updated and tested DCPCrypt to work under 64bit FPC. I also made sure it can compile with FPC 2.4.0-rc1. Previously it did not compile for 64bit or FPC 2.4.0-rc1.

DCPCrypt is not in any repository, so my changes are local in a Git repository. How should I proceed?

* Add DCPCrypt to GitHub or SourceForge?

* Simply email a new source archive so it can be made available for download from Lazarus CCR on SourceForge

* Possibly convince somebody to add it as a new package in FCL in FPC repository.

* Possibly convince somebody to add it to Lazarus repository like what was done with Turbo Power IPPro, AggPas etc.?

As I stated in a email some months ago. I don't mind maintaining DCPCrypt because we use it for our commercial projects. I also don't like the idea of *only* having source archives of DCPCrypt like in the case of Lazarus CCR downloads, because we can't track any source code changes.

I'm leaning to the idea of having it included in FCL, because it is very usable in non-GUI applications as well. In fact, that is how we use it currently, in CGI web applications. But I have no say in any of the FPC or Lazarus repositories.

Any suggestions on what I should do with DCPCrypt and my fixes?

Regards,
- Graeme -

If DPCrypt's license matches the FCL one, I see no reason not to include it.

Michael.

Michael Van Canneyt wrote

If DPCrypt's license matches the FCL one, I see no reason not to include it.

It is already ok I think (MIT/BSD license without advocacy clause). From previous discussions in fpc-pascal mailing list, Marco said this will be fine for FCL.

As for the location in FCL - that is for somebody closer to the FPC developers to decide, but I would imagine on the same level as fcl-fpcunit & fcl-db... etc.
Example: fcl-dcpcrypt and not in fcl-base.

If added to FCL, there are a few more changes I would suggest:
* Replacing dcpcrypt's base64 unit with the one already in FCL.
* Replacing sha1 unit with sha1 unit already in FCL. Or follow the same process as the next option.
* Blowfish already exists in fcl-base... maybe remove that one and keep all encryption & cyphers in dcpcrypt directory. No need in having duplicate functionality all over the place. This would apply to existing blowfish and sha1 implementations.

Should I rather move this discussion to fpc-devel mailing list, or will somebody here be able to add DCPCrypt to FCL? Whatever the decision, just let me know who I need to email the latest "fixed" dcpcrypt code to.

Regards,
- Graeme -

2009/11/16 Michael Van Canneyt :

That too.

All these components have in common that they are used or will be used by Lazarus or the LCL itself.

If it is not added to fpc SVN, I propose to add it to Lazarus CCR svn.

Adding to the FCL is the best option. What is the license, Graeme?

Vincent

[our company is experiencing SMTP problems with our ISP, so excuse any duplicate emails from me]

2009/11/16 Michael Van Canneyt :

If DPCrypt's license matches the FCL one, I see no reason not to include it.

It is already ok I think (MIT/BSD license without advocacy clause). From previous discussions in fpc-pascal mailing list, Marco said this will be fine for FCL.

As for the location in FCL - that is for somebody closer to the FPC developers to decide, but I would imagine on the same level as fcl-fpcunit & fcl-db... etc.
Example: fcl-dcpcrypt and not in fcl-base.

If added to FCL, there are a few more changes I would suggest:
* Replacing dcpcrypt's base64 unit with the one already in FCL.
* Replacing sha1 unit with sha1 unit already in FCL. Or follow the same process as the next option.
* Blowfish already exists in fcl-base... maybe remove that one and keep all encryption & cyphers in dcpcrypt directory. No need in having duplicate functionality all over the place. This would apply to existing blowfish and sha1 implementations.

Should I rather move this discussion to fpc-devel mailing list, or will somebody here be able to add DCPCrypt to FCL? Whatever the decision, just let me know who I need to email the latest "fixed" dcpcrypt code to.

Really ? I am not so sure about this.

This should be taken up first prior to continuing.

Michael.

2009/11/16 Vincent Snijders :

As an intermediate solution, can I send you the archive in private? Making the latest fixes available as download on CCR should suffice until we know the final resting place of DCPCrypt.

That was my guess. So I agree that Lazarus repository should not be the host for DCPCrypt.

If it is not added to fpc SVN, I propose to add it to Lazarus CCR svn.

How maintains or has write access to that repository? Also, if it goes there, where does one send any future patches to? This mailing list, or the forums on SourceForge or somewhere else?

That would be my first choice too, considering that FCL already contains SHA1, Base64 and Blowfish implementations. All things that are included in DCPCrypt too. The license is MIT/BSD license without advocacy clause. So it should be fine for FCL inclusion.

2009/11/16 Michael Van Canneyt :

Really ? I am not so sure about this. This should be taken up first prior to continuing.

What would be the issue? If it's added as a FCL "extra" package (eg: packages/fcl-dcpcrypt/ ), it is not linked to anything in FPC or FCL, only shipped with FPC, I can't see any issues.

In theory that should even allow MPL and GPL packages to be shipped with FPC, because it is only shipped (distributed) with FPC, not compiled and linked into FPC.

If the license is really an issue, I can always email the original author of DCPCrypt (if he is still around) and ask if we can dual-license it for LGPL + static linking exception.

2009/11/16 Graeme Geldenhuys :

Yes, please.

> If it is not added to fpc SVN, I propose to add it to Lazarus CCR svn. How maintains or has write access to that repository?

You will. See also:
http://wiki.lazarus.freepascal.org/Using_the_Lazarus-ccr_SVN_repository

Also, if it goes there, where does one send any future patches to? This mailing list, or the forums on SourceForge or somewhere else?

You have to edit http://wiki.lazarus.freepascal.org/DCPcrypt and add your name in the author section. On that page you can mention your preferred way to handle patches, bug reports etc. There is a bug tracker on SF or you could decide to use the bug tracker on www.freepascal.org

Vincent

2009/11/16 Michael Van Canneyt :

Below is the URL to the MIT license for DCPCrypt. In there it states that pretty much anything can be done to the software (modify, redistribute, used in commercial software etc), as long as the copyright notice stays in the header of the unit. No other requirements.

http://www.cityinthesky.co.uk/files/mit_license.txt

So I really don't see a licensing problem, but then again, I am no licensing expert. ;-)

Unfortunately my original testing was not thorough enough. :-( I did some more testing today (using our projects and data) and found a few more 64-bit related issues that only cropped 've managed to get our projects working again with 64bit DCPCrypt, but I'll try and complete some more testing in the next few days and release another version of DCPCrypt.

Sorry for any inconvenience.

NOTE:
DCPCrypt sure can do with some real unit tests. I can believe the original author released DCPCrypt without any unit tests, except for some minor 'SelfTest' method in each cypher and hash implementation. The latter tests did not find any of the issues I experienced and fixed today. :-(

Regards,
- Graeme -

Is there a reason why it is not possible to get the sourcecode using the SVN repository?

I can easily find the tar.gz file on SF website, but browsing the svn repository I can't seem to find it??

Any advise?

Kind regards,
Torsten Bonde Christiansen.

I have made a patch to the DCPcrypt package, that supports 64-bit en-/decryption using the Rijndael cipher.

As there is no catagory for DCPCrypt package in the bugtracker I have created a new bugreport with "-" as catagory.

Kind regards,
Torsten Bonde Christiansen.

2010/3/26 Torsten Bonde Christiansen :

Torsten, Graeme, who wants to be maintainer of this package on Lazarus-CCR?

Vincent

An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100326/6631743c/attachment.html>

An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100326/62b1aa5c/attachment.html>

Torsten Bonde Christiansen wrote

I have made a patch to the DCPcrypt package, that supports 64-bit en-/decryption using the Rijndael cipher.

Do you saw that?:
http://donaldshimoda.blogspot.com/2010/02/dcpcrypt-for-64-bits-is-here.html

Luiz