Own base64 decode function, remove openssl dependency

[tomkoen]

Remove openssl dependency: using openssl for only base64 decoding is a bit much. base64 decoding code is taken from http://stackoverflow.com/questions/180947/base64-decode-snippet-in-c (post by LihO). But i've added skipping of non base64 chars instead of terminating the loop. Most of DMG files I've encounted contained \n\r characters in base64 string. Tested with a number of DMG files, works correctly.

[e7appew]

This would be a welcomed change for the purposes of packaging this project in Debian, since darling-dmg's license doesn't explicitly mention an OpenSSL exception. More info on this can be found here: https://lintian.debian.org/tags/possible-gpl-code-linked-with-openssl.html and here: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-specification.

However, the pull request could be improved by updating the CMakeLists.txt file to not link with -lcrypto, and the licensing terms of the original author and other relevant info you've provided in the above comment could be included in the source code.

[LubosD]

OK, will do.

[bugaevc]

@tomkoen is there a reason why the commit messages are duplicated?
@e7appew is Darling (or darling-dmg) being considered to be packaged for Debian official repos, or is this just to make it more future-proof?

[e7appew]

Someone put in an RFP (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711581) for darling years ago, so I'm not sure if anyone else is already working on packaging it. I am working on the darling-dmg component, at the moment just for myself, as I find this part more useful for my purposes. However, anyone working on packaging these and making it part of the official Debian repos would face the same hurdles.

If for example you didn't want to use the replacement base64 implementation, we would have to request that you mention the OpenSSL exception in your licensing, and then only if you granted it would we be able to link with OpenSSL. Otherwise we would have to patch our version to not use OpenSSL.

If it's of any help to you, I have added the missing licensing info based on @tomkohen's changes here: https://github.com/e7appew/darling-dmg/tree/add-missing-licensing.

Thanks.

[tomkoen]

@bugaevc, sorry I don't get it. Which messages are duplicated? 😨

[bugaevc]

@tomkoen it's no big deal, really, but I'm talking about why your commit messages look like this:

,

as opposed to this:

[e7appew]

@tomkohen, perhaps the git client you use automatically does it for you. Based on your contributions, I'm assuming you're on windows? If you use the command line and type "git log" it will become more clear that the comments are being repeated on the first and third lines.

[bugaevc]

@e7appew it'd be great to get Darling to be officially packaged for Debian (and others)! Unfortunately, you can't easily get rid of OpenSSL altogether (see https://github.com/darlinghq/darling-openssl)

[e7appew]

@bugaevc, I'm not too familiar with the rest of the Darling project yet, and I don't know if there are any problems with that particular version of OpenSSL, but as far as I know, Debian isn't concerned with getting rid of its use, only that there aren't any conflicts or incompatibilities with licensing.

[bugaevc]

OpenSSL is being re-licensed to Apache License v. 2.0
https://www.openssl.org/blog/blog/2017/03/20/license/

[tomkoen]

no chance to merge this? I've used this code for years without any problems (and without openSSL 😄 )

[tomkoen]

@bugaevc @LubosD
guys the pull request is >3 years, you don't close it and don't reply, is something wrong with it? I could fix.
If C code is not nice, could use C++ variant from here
could add 3rd party code as separate files as well.

Thanks!

[tomkoen]

From the other hand, if you want to leave openssl to support encrypted volumes, then this PR can be closed...