did libselinux grow a new build dependency? (openssl-devel: openssl.h)

did libselinux grow a new build dependency? (openssl-devel: openssl.h)

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

if so, would gnutls be affected in some way?

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWIiiTAAoJENAR6kfG5xmcDecL/3X2VRp3dR0UXDQSXAayD9P+
BEz+hJ9rhZTMoBdiDWvYVpsCVUL6ASIkKocGSvdV5cDfFPOs+wu3t8Xwo+KgNJqy
rMoPGm4QwkZyw9T3lzSMU6oE7l99FiQMDO3I41iDx52GQr+dvSoTHs5eRlU6ldyk
M9dSBIa/p9noQu3xCCWh8wVZSCLTC5b4PiCPwenyAecVZ3tJf7EOZssM4j7FPxnB
ropmU7MGauYUImBbVHFLcBWULIRo8Awwqadcnne4sxugPeFH332HeRcgUKCHGiQU
wovjWgGAKn/oC3tTTW9Tmo8F9rRC33BzP9P7p25MvMFiXPchid/iJiQG7k++qk/g
9+p3vkhqvavff1eDG5pDKOh8hA+pcIzng91/NDGh5+8D+o1uvNxPPyQFHOhnn24p
DhxRk2uD5oiiB7o85Yh3ZubmWLR6UiI/SiNsm9POSEr0QH+ePdg/fSuKGKHxoeF0
DfZuIh4ZorjIQU4oGG+zg+kKB3XNwZph2UtshjUPEQ==
=mhIs
-----END PGP SIGNATURE-----

Re: did libselinux grow a new build dependency? (openssl-devel: openssl.h)

[Richard Haines]

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.





> On Saturday, 17 October 2015, 11:55, Dominick Grift <dac.override@gmail.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> if so, would gnutls be affected in some way?
> 
> - -- 
> 02DFF788
> 4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
> https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
> Dominick Grift
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQGcBAEBCgAGBQJWIiiTAAoJENAR6kfG5xmcDecL/3X2VRp3dR0UXDQSXAayD9P+
> BEz+hJ9rhZTMoBdiDWvYVpsCVUL6ASIkKocGSvdV5cDfFPOs+wu3t8Xwo+KgNJqy
> rMoPGm4QwkZyw9T3lzSMU6oE7l99FiQMDO3I41iDx52GQr+dvSoTHs5eRlU6ldyk
> M9dSBIa/p9noQu3xCCWh8wVZSCLTC5b4PiCPwenyAecVZ3tJf7EOZssM4j7FPxnB
> ropmU7MGauYUImBbVHFLcBWULIRo8Awwqadcnne4sxugPeFH332HeRcgUKCHGiQU
> wovjWgGAKn/oC3tTTW9Tmo8F9rRC33BzP9P7p25MvMFiXPchid/iJiQG7k++qk/g
> 9+p3vkhqvavff1eDG5pDKOh8hA+pcIzng91/NDGh5+8D+o1uvNxPPyQFHOhnn24p
> DhxRk2uD5oiiB7o85Yh3ZubmWLR6UiI/SiNsm9POSEr0QH+ePdg/fSuKGKHxoeF0
> DfZuIh4ZorjIQU4oGG+zg+kKB3XNwZph2UtshjUPEQ==
> =mhIs
> -----END PGP SIGNATURE-----
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to 
> Selinux-request@tycho.nsa.gov.
> 

Re: did libselinux grow a new build dependency? (openssl-devel: openssl.h)

[Dominick Grift]

-----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.

> 
> 
> 
> 
> > On Saturday, 17 October 2015, 11:55, Dominick Grift <dac.override@gmail.com> wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> > 
> > if so, would gnutls be affected in some way?
> > 
> > - -- 
> > 02DFF788
> > 4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
> > Dominick Grift
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2
> > 
> > iQGcBAEBCgAGBQJWIiiTAAoJENAR6kfG5xmcDecL/3X2VRp3dR0UXDQSXAayD9P+
> > BEz+hJ9rhZTMoBdiDWvYVpsCVUL6ASIkKocGSvdV5cDfFPOs+wu3t8Xwo+KgNJqy
> > rMoPGm4QwkZyw9T3lzSMU6oE7l99FiQMDO3I41iDx52GQr+dvSoTHs5eRlU6ldyk
> > M9dSBIa/p9noQu3xCCWh8wVZSCLTC5b4PiCPwenyAecVZ3tJf7EOZssM4j7FPxnB
> > ropmU7MGauYUImBbVHFLcBWULIRo8Awwqadcnne4sxugPeFH332HeRcgUKCHGiQU
> > wovjWgGAKn/oC3tTTW9Tmo8F9rRC33BzP9P7p25MvMFiXPchid/iJiQG7k++qk/g
> > 9+p3vkhqvavff1eDG5pDKOh8hA+pcIzng91/NDGh5+8D+o1uvNxPPyQFHOhnn24p
> > DhxRk2uD5oiiB7o85Yh3ZubmWLR6UiI/SiNsm9POSEr0QH+ePdg/fSuKGKHxoeF0
> > DfZuIh4ZorjIQU4oGG+zg+kKB3XNwZph2UtshjUPEQ==
> > =mhIs
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > Selinux mailing list
> > Selinux@tycho.nsa.gov
> > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> > To get help, send an email containing "help" to 
> > Selinux-request@tycho.nsa.gov.
> > 

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWI6edAAoJENAR6kfG5xmccrgL/i7kT1+kuuBjGBqGAVl3W+ri
Zgx7NnPKslS+dcx9lAMR2nVwG9A7Suh58E/HaUQv4RkFkNiX3Xqv9gRsrw4baWqZ
7at3qy1F/daa9U4hC/SdPwuwpQZYbKhquyfN09YAOb06XR9OtVE1z0DgEqiS5y7f
lWCiYyCUoqu6ifJYEpNVWDgxsdXykfLMsTSWPttEJAkFQHK0/E8/HA3DVxh81mhB
h6vBcFzoAPAyUbWf8n7EfmEVP3JeCoxOyQi61/qVdNyDdYuisZPRM6rAppurR+30
AkGUj7U8YKbaBjhr4u0pOKcUx8/kYRYvkDenvcenuCALH+sGBdIK9ip/i9E5wjxJ
k2HwiZb32t2wKfg3+MSkbfxgCgubErD7ZLMCC1x8TWDLbdonOISufZgal94GpCZf
DyevvV30Ieo3yxwLQj4L8Z0PwfKPTedLhenw1ZjK1tQCgR8KNOaffpW53//Kpcwq
6qN87fA8cB+/fHDIUpaItm3b+vZeI9ElvG/06ruhAw==
=+hHw
-----END PGP SIGNATURE-----

Re: did libselinux grow a new build dependency? (openssl-devel: openssl.h)

[Richard Haines]

> On Sunday, 18 October 2015, 15:07, Dominick Grift <dac.override@gmail.com> 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.


>> >> 
>> 
>> 
>>  > On Saturday, 17 October 2015, 11:55, Dominick Grift 
> <dac.override@gmail.com> wrote:
>>  > > -----BEGIN PGP SIGNED MESSAGE-----
>>  > Hash: SHA512
>>  > 
>>  > if so, would gnutls be affected in some way?
>>  > 
>>  > - -- 
>>  > 02DFF788
>>  > 4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
>>  > 
> https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
>>  > Dominick Grift
>>  > -----BEGIN PGP SIGNATURE-----
>>  > Version: GnuPG v2
>>  > 
>>  > iQGcBAEBCgAGBQJWIiiTAAoJENAR6kfG5xmcDecL/3X2VRp3dR0UXDQSXAayD9P+
>>  > BEz+hJ9rhZTMoBdiDWvYVpsCVUL6ASIkKocGSvdV5cDfFPOs+wu3t8Xwo+KgNJqy
>>  > rMoPGm4QwkZyw9T3lzSMU6oE7l99FiQMDO3I41iDx52GQr+dvSoTHs5eRlU6ldyk
>>  > M9dSBIa/p9noQu3xCCWh8wVZSCLTC5b4PiCPwenyAecVZ3tJf7EOZssM4j7FPxnB
>>  > ropmU7MGauYUImBbVHFLcBWULIRo8Awwqadcnne4sxugPeFH332HeRcgUKCHGiQU
>>  > wovjWgGAKn/oC3tTTW9Tmo8F9rRC33BzP9P7p25MvMFiXPchid/iJiQG7k++qk/g
>>  > 9+p3vkhqvavff1eDG5pDKOh8hA+pcIzng91/NDGh5+8D+o1uvNxPPyQFHOhnn24p
>>  > DhxRk2uD5oiiB7o85Yh3ZubmWLR6UiI/SiNsm9POSEr0QH+ePdg/fSuKGKHxoeF0
>>  > DfZuIh4ZorjIQU4oGG+zg+kKB3XNwZph2UtshjUPEQ==
>>  > =mhIs
>>  > -----END PGP SIGNATURE-----
>>  > _______________________________________________
>>  > Selinux mailing list
>>  > Selinux@tycho.nsa.gov
>>  > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>>  > To get help, send an email containing "help" to 
>>  > Selinux-request@tycho.nsa.gov.
>>  > 
> 
> - -- 
> 02DFF788
> 4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
> https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
> Dominick Grift
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQGcBAEBCgAGBQJWI6edAAoJENAR6kfG5xmccrgL/i7kT1+kuuBjGBqGAVl3W+ri
> Zgx7NnPKslS+dcx9lAMR2nVwG9A7Suh58E/HaUQv4RkFkNiX3Xqv9gRsrw4baWqZ
> 7at3qy1F/daa9U4hC/SdPwuwpQZYbKhquyfN09YAOb06XR9OtVE1z0DgEqiS5y7f
> lWCiYyCUoqu6ifJYEpNVWDgxsdXykfLMsTSWPttEJAkFQHK0/E8/HA3DVxh81mhB
> h6vBcFzoAPAyUbWf8n7EfmEVP3JeCoxOyQi61/qVdNyDdYuisZPRM6rAppurR+30
> AkGUj7U8YKbaBjhr4u0pOKcUx8/kYRYvkDenvcenuCALH+sGBdIK9ip/i9E5wjxJ
> k2HwiZb32t2wKfg3+MSkbfxgCgubErD7ZLMCC1x8TWDLbdonOISufZgal94GpCZf
> DyevvV30Ieo3yxwLQj4L8Z0PwfKPTedLhenw1ZjK1tQCgR8KNOaffpW53//Kpcwq
> 6qN87fA8cB+/fHDIUpaItm3b+vZeI9ElvG/06ruhAw==
> =+hHw
> 
> -----END PGP SIGNATURE-----
> 

Re: did libselinux grow a new build dependency? (openssl-devel: openssl.h)

[Stephen Smalley]

On 10/18/2015 11:00 AM, Richard Haines wrote:
>
>
>> On Sunday, 18 October 2015, 15:07, Dominick Grift <dac.override@gmail.com> 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.

[1] http://www.gnu.org/licenses/license-list.en.html#OpenSSL

[2] https://people.gnome.org/~markmc/openssl-and-the-gpl.html

[3] 
https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F)

Re: did libselinux grow a new build dependency? (openssl-devel: openssl.h)

[Stephen Smalley]

On 10/19/2015 02:09 PM, Stephen Smalley wrote:
> On 10/18/2015 11:00 AM, Richard Haines wrote:
>>
>>
>>> On Sunday, 18 October 2015, 15:07, Dominick Grift
>>> <dac.override@gmail.com> 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.
>
> [1] http://www.gnu.org/licenses/license-list.en.html#OpenSSL
>
> [2] https://people.gnome.org/~markmc/openssl-and-the-gpl.html
>
> [3]
> https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F)

Also, aside from license issues, we likely ought to dlopen libcrypto.so 
so that we don't bring this dependency to all users of libselinux but 
only those that actually use the digest functionality.

Re: did libselinux grow a new build dependency? (openssl-devel: openssl.h)

[Richard Haines]

[-- Attachment #1: Type: text/plain, Size: 2685 bytes --]





> On Monday, 19 October 2015, 19:10, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On 10/18/2015 11:00 AM, Richard Haines wrote:
>> 
>> 
>>>  On Sunday, 18 October 2015, 15:07, Dominick Grift 
> <dac.override@gmail.com> 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


> 
> [1] http://www.gnu.org/licenses/license-list.en.html#OpenSSL
> 
> [2] https://people.gnome.org/~markmc/openssl-and-the-gpl.html
> 
> 
> [3] 
> https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F
> )
> 

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-libselinux-Use-Android-mincrypt-for-selabel_digest-3.patch --]
[-- Type: text/x-patch, Size: 13174 bytes --]

From 624cb4ec0b73c3b34ed0a8f26f9c7c122c44250c Mon Sep 17 00:00:00 2001
From: Richard Haines <richard_c_haines@btinternet.com>
Date: Tue, 20 Oct 2015 13:13:47 +0100
Subject: [PATCH] libselinux: Use Android mincrypt for selabel_digest(3)

Replace the use of openssl with the Android mincrypt SHA
functions. However leave util/selabel_digest still comparing
the result with the openssl command "openssl dgst -sha1 -hex .."

This should resolve any library licensing issues (hopefully).

Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>
---
 libselinux/src/Makefile                 |   2 +-
 libselinux/src/label_internal.h         |   4 +-
 libselinux/src/label_support.c          |   2 +-
 libselinux/src/mincrypt_hash-internal.h |  63 +++++++++++++
 libselinux/src/mincrypt_sha.c           | 155 ++++++++++++++++++++++++++++++++
 libselinux/src/mincrypt_sha.h           |  52 +++++++++++
 libselinux/utils/Makefile               |   2 +-
 7 files changed, 275 insertions(+), 5 deletions(-)
 create mode 100644 libselinux/src/mincrypt_hash-internal.h
 create mode 100644 libselinux/src/mincrypt_sha.c
 create mode 100644 libselinux/src/mincrypt_sha.h

diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
index 8e2223e..feab561 100644
--- a/libselinux/src/Makefile
+++ b/libselinux/src/Makefile
@@ -112,7 +112,7 @@ $(LIBA): $(OBJS)
 	$(RANLIB) $@
 
 $(LIBSO): $(LOBJS)
-	$(CC) $(CFLAGS) -shared -o $@ $^ -lpcre -ldl -lcrypto $(LDFLAGS) -L$(LIBDIR) -Wl,-soname,$(LIBSO),-z,defs,-z,relro
+	$(CC) $(CFLAGS) -shared -o $@ $^ -lpcre -ldl $(LDFLAGS) -L$(LIBDIR) -Wl,-soname,$(LIBSO),-z,defs,-z,relro
 	ln -sf $@ $(TARGET) 
 
 $(LIBPC): $(LIBPC).in ../VERSION
diff --git a/libselinux/src/label_internal.h b/libselinux/src/label_internal.h
index 2aa7a7b..51d1afb 100644
--- a/libselinux/src/label_internal.h
+++ b/libselinux/src/label_internal.h
@@ -11,7 +11,7 @@
 #include <stdlib.h>
 #include <stdarg.h>
 #include <stdio.h>
-#include <openssl/sha.h>
+#include "mincrypt_sha.h"
 #include <selinux/selinux.h>
 #include <selinux/label.h>
 #include "dso.h"
@@ -51,7 +51,7 @@ struct selabel_sub {
  * calculate the hash the hashbuf will hold a concatenation of all the files
  * used. This is released once the value has been calculated.
  */
-#define DIGEST_SPECFILE_SIZE SHA_DIGEST_LENGTH
+#define DIGEST_SPECFILE_SIZE SHA_DIGEST_SIZE
 #define DIGEST_FILES_MAX 8
 struct selabel_digest {
 	unsigned char *digest;	/* SHA1 digest of specfiles */
diff --git a/libselinux/src/label_support.c b/libselinux/src/label_support.c
index ac52885..daa0fba 100644
--- a/libselinux/src/label_support.c
+++ b/libselinux/src/label_support.c
@@ -104,7 +104,7 @@ void hidden digest_gen_hash(struct selabel_digest *digest)
 	if (!digest)
 		return;
 
-	SHA1(digest->hashbuf, digest->hashbuf_size, digest->digest);
+	SHA_hash(digest->hashbuf, digest->hashbuf_size, digest->digest);
 	free(digest->hashbuf);
 	digest->hashbuf = NULL;
 	return;
diff --git a/libselinux/src/mincrypt_hash-internal.h b/libselinux/src/mincrypt_hash-internal.h
new file mode 100644
index 0000000..6c34d1d
--- /dev/null
+++ b/libselinux/src/mincrypt_hash-internal.h
@@ -0,0 +1,63 @@
+/*
+ * Copyright 2007 The Android Open Source Project
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in the
+ *       documentation and/or other materials provided with the distribution.
+ *     * Neither the name of Google Inc. nor the names of its contributors may
+ *       be used to endorse or promote products derived from this software
+ *       without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Google Inc. ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+ * EVENT SHALL Google Inc. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+ * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef MINCRYPT_HASH_INTERNAL_H_
+#define MINCRYPT_HASH_INTERNAL_H_
+
+#include <stdint.h>
+
+#ifdef __cplusplus
+extern "C" {
+#endif  // __cplusplus
+
+struct HASH_CTX;  // forward decl
+
+typedef struct HASH_VTAB {
+  void (* const init)(struct HASH_CTX*);
+  void (* const update)(struct HASH_CTX*, const void*, int);
+  const uint8_t* (* const final)(struct HASH_CTX*);
+  const uint8_t* (* const hash)(const void*, int, uint8_t*);
+  int size;
+} HASH_VTAB;
+
+typedef struct HASH_CTX {
+  const HASH_VTAB * f;
+  uint64_t count;
+  uint8_t buf[64];
+  uint32_t state[8];  // upto SHA2
+} HASH_CTX;
+
+#define HASH_init(ctx) (ctx)->f->init(ctx)
+#define HASH_update(ctx, data, len) (ctx)->f->update(ctx, data, len)
+#define HASH_final(ctx) (ctx)->f->final(ctx)
+#define HASH_hash(data, len, digest) (ctx)->f->hash(data, len, digest)
+#define HASH_size(ctx) (ctx)->f->size
+
+#ifdef __cplusplus
+}
+#endif  // __cplusplus
+
+#endif  // MINCRYPT_HASH_INTERNAL_H_
diff --git a/libselinux/src/mincrypt_sha.c b/libselinux/src/mincrypt_sha.c
new file mode 100644
index 0000000..9548a47
--- /dev/null
+++ b/libselinux/src/mincrypt_sha.c
@@ -0,0 +1,155 @@
+/* sha.c
+**
+** Copyright 2013, The Android Open Source Project
+**
+** Redistribution and use in source and binary forms, with or without
+** modification, are permitted provided that the following conditions are met:
+**     * Redistributions of source code must retain the above copyright
+**       notice, this list of conditions and the following disclaimer.
+**     * Redistributions in binary form must reproduce the above copyright
+**       notice, this list of conditions and the following disclaimer in the
+**       documentation and/or other materials provided with the distribution.
+**     * Neither the name of Google Inc. nor the names of its contributors may
+**       be used to endorse or promote products derived from this software
+**       without specific prior written permission.
+**
+** THIS SOFTWARE IS PROVIDED BY Google Inc. ``AS IS'' AND ANY EXPRESS OR
+** IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+** MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+** EVENT SHALL Google Inc. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+** SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+** PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+** OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+** WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+** OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+** ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+// Optimized for minimal code size.
+
+#include "mincrypt_sha.h"
+
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+
+#define rol(bits, value) (((value) << (bits)) | ((value) >> (32 - (bits))))
+
+static void SHA1_Transform(SHA_CTX* ctx) {
+    uint32_t W[80];
+    uint32_t A, B, C, D, E;
+    uint8_t* p = ctx->buf;
+    int t;
+
+    for(t = 0; t < 16; ++t) {
+        uint32_t tmp =  *p++ << 24;
+        tmp |= *p++ << 16;
+        tmp |= *p++ << 8;
+        tmp |= *p++;
+        W[t] = tmp;
+    }
+
+    for(; t < 80; t++) {
+        W[t] = rol(1,W[t-3] ^ W[t-8] ^ W[t-14] ^ W[t-16]);
+    }
+
+    A = ctx->state[0];
+    B = ctx->state[1];
+    C = ctx->state[2];
+    D = ctx->state[3];
+    E = ctx->state[4];
+
+    for(t = 0; t < 80; t++) {
+        uint32_t tmp = rol(5,A) + E + W[t];
+
+        if (t < 20)
+            tmp += (D^(B&(C^D))) + 0x5A827999;
+        else if ( t < 40)
+            tmp += (B^C^D) + 0x6ED9EBA1;
+        else if ( t < 60)
+            tmp += ((B&C)|(D&(B|C))) + 0x8F1BBCDC;
+        else
+            tmp += (B^C^D) + 0xCA62C1D6;
+
+        E = D;
+        D = C;
+        C = rol(30,B);
+        B = A;
+        A = tmp;
+    }
+
+    ctx->state[0] += A;
+    ctx->state[1] += B;
+    ctx->state[2] += C;
+    ctx->state[3] += D;
+    ctx->state[4] += E;
+}
+
+static const HASH_VTAB SHA_VTAB = {
+    SHA_init,
+    SHA_update,
+    SHA_final,
+    SHA_hash,
+    SHA_DIGEST_SIZE
+};
+
+void SHA_init(SHA_CTX* ctx) {
+    ctx->f = &SHA_VTAB;
+    ctx->state[0] = 0x67452301;
+    ctx->state[1] = 0xEFCDAB89;
+    ctx->state[2] = 0x98BADCFE;
+    ctx->state[3] = 0x10325476;
+    ctx->state[4] = 0xC3D2E1F0;
+    ctx->count = 0;
+}
+
+
+void SHA_update(SHA_CTX* ctx, const void* data, int len) {
+    int i = (int) (ctx->count & 63);
+    const uint8_t* p = (const uint8_t*)data;
+
+    ctx->count += len;
+
+    while (len--) {
+        ctx->buf[i++] = *p++;
+        if (i == 64) {
+            SHA1_Transform(ctx);
+            i = 0;
+        }
+    }
+}
+
+
+const uint8_t* SHA_final(SHA_CTX* ctx) {
+    uint8_t *p = ctx->buf;
+    uint64_t cnt = ctx->count * 8;
+    int i;
+
+    SHA_update(ctx, (uint8_t*)"\x80", 1);
+    while ((ctx->count & 63) != 56) {
+        SHA_update(ctx, (uint8_t*)"\0", 1);
+    }
+    for (i = 0; i < 8; ++i) {
+        uint8_t tmp = (uint8_t) (cnt >> ((7 - i) * 8));
+        SHA_update(ctx, &tmp, 1);
+    }
+
+    for (i = 0; i < 5; i++) {
+        uint32_t tmp = ctx->state[i];
+        *p++ = tmp >> 24;
+        *p++ = tmp >> 16;
+        *p++ = tmp >> 8;
+        *p++ = tmp >> 0;
+    }
+
+    return ctx->buf;
+}
+
+/* Convenience function */
+const uint8_t* SHA_hash(const void* data, int len, uint8_t* digest) {
+    SHA_CTX ctx;
+    SHA_init(&ctx);
+    SHA_update(&ctx, data, len);
+    memcpy(digest, SHA_final(&ctx), SHA_DIGEST_SIZE);
+    return digest;
+}
diff --git a/libselinux/src/mincrypt_sha.h b/libselinux/src/mincrypt_sha.h
new file mode 100644
index 0000000..35c4b86
--- /dev/null
+++ b/libselinux/src/mincrypt_sha.h
@@ -0,0 +1,52 @@
+/*
+ * Copyright 2005 The Android Open Source Project
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in the
+ *       documentation and/or other materials provided with the distribution.
+ *     * Neither the name of Google Inc. nor the names of its contributors may
+ *       be used to endorse or promote products derived from this software
+ *       without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Google Inc. ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+ * EVENT SHALL Google Inc. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+ * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+ * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#ifndef MINCRYPT_SHA1_H_
+#define MINCRYPT_SHA1_H_
+
+#include <stdint.h>
+#include "mincrypt_hash-internal.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif // __cplusplus
+
+typedef HASH_CTX SHA_CTX;
+
+void SHA_init(SHA_CTX* ctx);
+void SHA_update(SHA_CTX* ctx, const void* data, int len);
+const uint8_t* SHA_final(SHA_CTX* ctx);
+
+// Convenience method. Returns digest address.
+// NOTE: *digest needs to hold SHA_DIGEST_SIZE bytes.
+const uint8_t* SHA_hash(const void* data, int len, uint8_t* digest);
+
+#define SHA_DIGEST_SIZE 20
+
+#ifdef __cplusplus
+}
+#endif // __cplusplus
+
+#endif  // MINCRYPT_SHA1_H_
diff --git a/libselinux/utils/Makefile b/libselinux/utils/Makefile
index 5dda66e..cac85c7 100644
--- a/libselinux/utils/Makefile
+++ b/libselinux/utils/Makefile
@@ -28,7 +28,7 @@ LDLIBS += -L../src -lselinux -L$(LIBDIR)
 
 TARGETS=$(patsubst %.c,%,$(wildcard *.c))
 
-sefcontext_compile: LDLIBS += -lpcre -lcrypto ../src/libselinux.a -lsepol
+sefcontext_compile: LDLIBS += -lpcre ../src/libselinux.a -lsepol
 
 ifeq ($(DISABLE_AVC),y)
 	UNUSED_TARGETS+=compute_av compute_create compute_member compute_relabel
-- 
2.4.3

Re: did libselinux grow a new build dependency? (openssl-devel: openssl.h)

[Joshua Brindle]

Stephen Smalley wrote:
<snip>
>
> 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.

LGPL explicitly allows non-GPL programs to link against an LGPL licensed 
library without tainting the non-GPL program, which is the whole point 
of the LGPL. Is there some other issue with static linking or something?

>
> [1] http://www.gnu.org/licenses/license-list.en.html#OpenSSL
>
> [2] https://people.gnome.org/~markmc/openssl-and-the-gpl.html
>
> [3]
> https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F)
>
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to
> Selinux-request@tycho.nsa.gov.

Re: did libselinux grow a new build dependency? (openssl-devel: openssl.h)

[Stephen Smalley]

On 10/20/2015 08:27 AM, Richard Haines wrote:
>
>
>
>
>> On Monday, 19 October 2015, 19:10, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>> On 10/18/2015 11:00 AM, Richard Haines wrote:
>>>
>>>
>>>>   On Sunday, 18 October 2015, 15:07, Dominick Grift
>> <dac.override@gmail.com> 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.

Re: did libselinux grow a new build dependency? (openssl-devel: openssl.h)

[Stephen Smalley]

On 10/20/2015 09:42 AM, Joshua Brindle wrote:
> Stephen Smalley wrote:
> <snip>
>>
>> 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.
>
> LGPL explicitly allows non-GPL programs to link against an LGPL licensed
> library without tainting the non-GPL program, which is the whole point
> of the LGPL. Is there some other issue with static linking or something?

Yes, that's the concern.

Re: did libselinux grow a new build dependency? (openssl-devel: openssl.h)

[Joshua Brindle]

Stephen Smalley wrote:
> On 10/20/2015 09:42 AM, Joshua Brindle wrote:
>> Stephen Smalley wrote:
>> <snip>
>>>
>>> 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.
>>
>> LGPL explicitly allows non-GPL programs to link against an LGPL licensed
>> library without tainting the non-GPL program, which is the whole point
>> of the LGPL. Is there some other issue with static linking or something?
>
> Yes, that's the concern.

So, not static linking but a fully static binary that would pull gnutls 
into the binary?

What static binaries exist like that? It is not a great idea to carry 
around system level libraries statically.

Re: did libselinux grow a new build dependency? (openssl-devel: openssl.h)

[William Roberts]

[-- Attachment #1: Type: text/plain, Size: 3341 bytes --]

On Oct 20, 2015 7:46 AM, "Stephen Smalley" <sds@tycho.nsa.gov> wrote:
>
> On 10/20/2015 08:27 AM, Richard Haines wrote:
>>
>>
>>
>>
>>
>>> On Monday, 19 October 2015, 19:10, Stephen Smalley <sds@tycho.nsa.gov>
wrote:
>>>>
>>>> On 10/18/2015 11:00 AM, Richard Haines wrote:
>>>>
>>>>
>>>>>   On Sunday, 18 October 2015, 15:07, Dominick Grift
>>>
>>> <dac.override@gmail.com> 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@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to
Selinux-request@tycho.nsa.gov.

[-- Attachment #2: Type: text/html, Size: 5198 bytes --]

Re: did libselinux grow a new build dependency? (openssl-devel: openssl.h)

[Richard Haines]

On Tuesday, 20 October 2015, 15:00, William Roberts <bill.c.roberts@gmail.com> wrote:

>
>
>
>On Oct 20, 2015 7:46 AM, "Stephen Smalley" <sds@tycho.nsa.gov> wrote:
>>
>> On 10/20/2015 08:27 AM, Richard Haines wrote:
>>>
>>>
>>>
>>>
>>>
>>>> On Monday, 19 October 2015, 19:10, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>>>>
>>>>> On 10/18/2015 11:00 AM, Richard Haines wrote:
>>>>>
>>>>>
>>>>>>   On Sunday, 18 October 2015, 15:07, Dominick Grift
>>>>
>>>> <dac.override@gmail.com> 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.

>>

I've found a simple implementation at
www.ghostscript.com/doc/jbig2dec/sha1.c

I'll try that first and if fails CryptLib will be next.




>> 
>Will CryptLib work:

>http://unlicense.org/


>
>
>>
>> _______________________________________________
>> Selinux mailing list
>> Selinux@tycho.nsa.gov
>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov
>.
>
>
>

Re: did libselinux grow a new build dependency? (openssl-devel: openssl.h)

[William Roberts]

[-- Attachment #1: Type: text/plain, Size: 4100 bytes --]

FYI you can take just 1 C and H file from crypt lib. You don't need it all.
On Oct 20, 2015 8:42 AM, "Richard Haines" <richard_c_haines@btinternet.com>
wrote:

>
> On Tuesday, 20 October 2015, 15:00, William Roberts <
> bill.c.roberts@gmail.com> wrote:
>
> >
> >
> >
> >On Oct 20, 2015 7:46 AM, "Stephen Smalley" <sds@tycho.nsa.gov> wrote:
> >>
> >> On 10/20/2015 08:27 AM, Richard Haines wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> On Monday, 19 October 2015, 19:10, Stephen Smalley <sds@tycho.nsa.gov>
> wrote:
> >>>>>
> >>>>> On 10/18/2015 11:00 AM, Richard Haines wrote:
> >>>>>
> >>>>>
> >>>>>>   On Sunday, 18 October 2015, 15:07, Dominick Grift
> >>>>
> >>>> <dac.override@gmail.com> 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.
>
> >>
>
> I've found a simple implementation at
> www.ghostscript.com/doc/jbig2dec/sha1.c
>
> I'll try that first and if fails CryptLib will be next.
>
>
>
>
> >>
> >Will CryptLib work:
>
> >http://unlicense.org/
>
>
> >
> >
> >>
> >> _______________________________________________
> >> Selinux mailing list
> >> Selinux@tycho.nsa.gov
> >> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> >> To get help, send an email containing "help" to
> Selinux-request@tycho.nsa.gov
> >.
> >
> >
> >
>

[-- Attachment #2: Type: text/html, Size: 6547 bytes --]

Re: did libselinux grow a new build dependency? (openssl-devel: openssl.h)

[Jason Zaman]

On Tue, Oct 20, 2015 at 09:56:57AM -0400, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On 10/20/2015 09:42 AM, Joshua Brindle wrote:
> >> Stephen Smalley wrote:
> >> <snip>
> >>>
> >>> 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.
> >>
> >> LGPL explicitly allows non-GPL programs to link against an LGPL licensed
> >> library without tainting the non-GPL program, which is the whole point
> >> of the LGPL. Is there some other issue with static linking or something?
> >
> > Yes, that's the concern.
> 
> So, not static linking but a fully static binary that would pull gnutls 
> into the binary?
> 
> What static binaries exist like that? It is not a great idea to carry 
> around system level libraries statically.

>From a quick look through Gentoo, we have a USE-flag to build busybox
and LVM and a few other core tools statically which requres libselinux.a
too.

-- Jason

Re: did libselinux grow a new build dependency? (openssl-devel: openssl.h)

[Richard Haines]

FYI 

The implementation at www.ghostscript.com/doc/jbig2dec/sha1.c
and CryptLib are both from the same original author
Steve Reid <sreid@sea-to-sky.net>

I've now tested and timed both implementations along with the
Android version + openssl.

openssl and Steve's implementations are about twice as fast
as the Android version.

I'll submit a patch based on the sha1 files extracted from CryptLib
as that is the latest one to be updated.