qx.Crypto package (BZ#808)

[qx-bug-importer]

Christian Boulanger (@swernerx) wrote:

Here are base64, md5 and sha functions in a Crypto package released under a BSD license and repackaged from the OAT toolkeit with the request to include it into the qooxdoo library. Thanks.

assigned to Bill Adams (badams)

[qx-bug-importer]

Christian Boulanger (@swernerx) wrote:

qx.Crypto class

ERROR: no way found to migrate Crypto.js (application/x-javascript) from bugzilla.

[qx-bug-importer]

Sebastian Werner (@swernerx) wrote:

Could this wait for 0.8 or do you need this earlier? In 0.8 we already have a basic base64 encoder, so it might be a good idea to improve on this one.

[qx-bug-importer]

Fabian Jakobs (@fjakobs) wrote:

to ae

[qx-bug-importer]

Andreas Ecker (@ecker) wrote:

Work with Bill Adams on polishing Crypto in qooxdoo-contrib

[qx-bug-importer]

Andreas Ecker (@ecker) wrote:

.

[qx-bug-importer]

Bill Adams (badams) wrote:

Hi All, This is of great interest to me. The Crypto.OpenPGP package also has base64 and sha1 classes. I just ported the whole Hanewinkel solution to get my project going. We can rationalize these with Christian's contribution and 0.8 and probably remove them from OpenPGP.

Due to very unusual circumstances, I will not get back to this until August. Feel free to forge ahead in the mean time. Thanks, Bill

[qx-bug-importer]

Sebastian Werner (@swernerx) wrote:

to contrib

[qx-bug-importer]

Andreas Ecker (@ecker) wrote:

.

[qx-bug-importer]

Andreas Ecker (@ecker) wrote:

Hi Bill, Christian, this is a very old request, which didn't make it into the Crypto contribution. I doubt there'll be a focus on that any time soon. So I'd suggest to just close it. Once the topic of improved crypto features comes up again, we should open an enhancement with some more recent code samples, agreed?

[qx-bug-importer]

Christian Boulanger (@swernerx) wrote:

> Hi Bill, Christian, this is a very old request, which didn't make it into the > Crypto contribution. I doubt there'll be a focus on that any time soon. So I'd > suggest to just close it. Once the topic of improved crypto features comes up > again, we should open an enhancement with some more recent code samples, > agreed?

Sure. I currently don't need crypto support. However, this seems to me an essential package to have at some point. Since there are all these license-friendly solutions already out there, it shouldn't be a lot of work to stitch them together in a nice qx contrib wrapper. No need to reinvent the wheel.

Cheers, C.