On Oct 20, 2015 7:46 AM, "Stephen Smalley" <sds@xxxxxxxxxxxxx> wrote:
>
> On 10/20/2015 08:27 AM, Richard Haines wrote:
>>
>>
>>
>>
>>
>>> On Monday, 19 October 2015, 19:10, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
>>>>
>>>> On 10/18/2015 11:00 AM, Richard Haines wrote:
>>>>
>>>>
>>>>> On Sunday, 18 October 2015, 15:07, Dominick Grift
>>>
>>> <dac.override@xxxxxxxxx> wrote:
>>>>
>>>>
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>
>>>>> Hash: SHA512
>>>>>
>>>>> On Sun, Oct 18, 2015 at 12:48:12PM +0000, Richard Haines wrote:
>>>>>>
>>>>>> I added openssl to libselinux to support the new
>>>
>>> selabel_digest(3)
>>>>>>
>>>>>> function.
>>>>>>
>>>>>> I'm not aware of any issues between openssl and gnutls,
>>>
>>> however as
>>>>>>
>>>>>>
>>>>>> selabel_digest was only added last week I guess not much testing.
>>>>>> Well apart from myself as I'm currently adding the
>>>
>>> selinux_restorecon
>>>>>>
>>>>>> feature that makes use of it.
>>>>>>
>>>>>
>>>>> Thanks for clarifying, I am not hitting any issues with it just
>>>>> wondering if instead of openssl, gnutls could be used for this and if
>>>>
>>>>
>>>>> so, if this should be somehow supported or not.
>>>>
>>>>
>>>> I tried using gnutls after I read your initial email, however I
>>>> could not find a way to generate the same digest as openssl
>>>> (I changed the SHA1 function to gnutls_hmac_fast(3) with various
>>>> algorithms and used the selabel_digest util to compare digests).
>>>> It could be that I should use some other function but I could
>>>>
>>>> not find any useful info on this (including web searches).
>>>> If anyone knows how to resolve this please let me know.
>>>>
>>>> I guess what is supported (openssl or gnutls) would be down to
>>>> the maintainers.
>>>
>>>
>>> Wondering if dependency on openssl might be a license issue for Debian
>>> or others. Apparently openssl license is considered GPL-incompatible
>>> [1] [2], and obviously libselinux is linked by a variety of GPL-licensed
>>> programs. Fedora seems to view this as falling under the system library
>>> exception [3] but not clear that other distributions would view it that
>>> way. On the other hand, using gnutls would be subject to the reverse
>>> problem; it would make libselinux depend on a LGPL library, and that
>>> could create issues for non-GPL programs that statically link
>>> libselinux. We might need to revert this change and revisit how to
>>
>>
>>> solve this in a manner that avoids such issues.
>>
>>
>>
>> Would building with the Android mincrypt SHA functions help regarding the
>> licensing issues ??? I've attached a quick patch that seems to work okay
>> using Android system/core/libmincrypt/sha.c
>
>
> That looks BSD-licensed and thus broadly compatible. We would need to amend libselinux/LICENSE to add that license information and we would need to hide those functions from being exposed outside of the library. Other alternative would be to look for a public domain SHA implementation and use that.
>
>
Will CryptLib work:
http://unlicense.org/
>
> _______________________________________________
> Selinux mailing list
> Selinux@xxxxxxxxxxxxx
> To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
> To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
_______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
