[
https://issues.apache.org/jira/browse/CODEC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13258295#comment-13258295
]
Gary D. Gregory commented on CODEC-133:
---------------------------------------
Here is my POV: before we go ask @legal if this is OK and so on, let's make it
as simple as possible and maybe we do not even need to go there.
Let's start with the simple case: your (Christian) license. My POV is that you
granted the ASF license to your port. You contribution should be recorded in
the POM as a "Contributor". I'm not sure how to say it correctly (legally or
politically ;) but it seems that your public domain license cannot/should
not/is irrelevant along side the ASF license. Granting your code to the ASF
with the patch having selected the "grant" checkbox takes are of your IP. You
do not get to say "I want my license in the source too". Imagine the mess if
every patch came with it's own license in the patch text. It would be
impossible to deal with. There is one license, the ASF license. Am I making
sense?
The other case is the "beer me" license, which is just as problematic IMO. The
Javadoc can talk about the code history, but the only license should be the ASF
license IMO.
Thoughts? From ANYONE? :)
> Please add a function for the MD5/SHA1/SHA-512 based Unix crypt(3) hash
> variants
> --------------------------------------------------------------------------------
>
> Key: CODEC-133
> URL: https://issues.apache.org/jira/browse/CODEC-133
> Project: Commons Codec
> Issue Type: New Feature
> Affects Versions: 1.6
> Reporter: Christian Hammers
> Labels: MD5, SHA-512, crypt(3), crypto, hash
> Attachments: commons-codec-crypt3.diff,
> crypt3-with-utexas-licence.diff
>
>
> The Linux libc6 crypt(3) function, which is used to generate e.g. the
> password hashes in /etc/shadow, is available in nearly all other programming
> languages (Perl, PHP, Python, C, C++, ...) and databases like MySQL and
> offers MD5/SHA1/SHA-512 based algorithms that were improved by adding a salt
> and several iterations to make rainbow table attacks harder. Thus they are
> widely used to store user passwords.
> Java, though, has due it's platform independence, no direct access to the
> libc functions and still lacks an proper port of the crypt(3) function.
> I already filed a wishlist bug (CODEC-104) for the traditional 56-bit DES
> based crypt(3) method but would also like to see the much stronger algorithms.
> There are other bug reports like DIRSTUDIO-738 that demand those crypt
> variants for some specific applications so there it would benefit other
> Apache projects as well.
> Java ports of most of the specific crypt variants are already existing, but
> they would have to be cleaned up, properly tested and license checked:
> ftp://ftp.arlut.utexas.edu/pub/java_hashes/
> I would be willing to help here by cleaning the source code and writing unit
> tests etc. but I'd like to generally know if you are interested and if
> there's someone who can do a code review (it's security relevant after all
> and I'm no crypto guy)
> bye,
> -christian-
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
