libselinux version bump past 99

libselinux version bump past 99

[Eamon Walsh]

Libselinux has reached version 2.0.99 and I need to push a bug fix, just checking to make sure 2.0.100 is fine and won't cause any problems e.g. with upgrades.


-- 

Eamon Walsh 
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: libselinux version bump past 99

[Stephen Smalley]

On Tue, 2011-03-08 at 17:26 -0500, Eamon Walsh wrote:
> Libselinux has reached version 2.0.99 and I need to push a bug fix, just checking to make sure 2.0.100 is fine and won't cause any problems e.g. with upgrades.

Shouldn't be a problem.  However, it does raise the question of when
we'll move to 2.1.0.  If the version string consists of
major.minor.revision, then possibly we should be incrementing minor and
resetting revision whenever there is a new release on
userspace.selinuxproject.org?

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: libselinux version bump past 99

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/09/2011 08:06 AM, Stephen Smalley wrote:
> On Tue, 2011-03-08 at 17:26 -0500, Eamon Walsh wrote:
>> Libselinux has reached version 2.0.99 and I need to push a bug fix, just checking to make sure 2.0.100 is fine and won't cause any problems e.g. with upgrades.
> 
> Shouldn't be a problem.  However, it does raise the question of when
> we'll move to 2.1.0.  If the version string consists of
> major.minor.revision, then possibly we should be incrementing minor and
> resetting revision whenever there is a new release on
> userspace.selinuxproject.org?
> 
Make sense to me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk13oUEACgkQrlYvE4MpobNdHwCgkTYbCc+K5ese7BudUBVZpkUb
VZ8AoKCPhpN3CoZN/LO1GNR5oJ3SwmSM
=6VnG
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: libselinux version bump past 99

[Steve Lawrence]

On 03/09/2011 10:48 AM, Daniel J Walsh wrote:
> On 03/09/2011 08:06 AM, Stephen Smalley wrote:
>> On Tue, 2011-03-08 at 17:26 -0500, Eamon Walsh wrote:
>>> Libselinux has reached version 2.0.99 and I need to push a bug fix, just checking to make sure 2.0.100 is fine and won't cause any problems e.g. with upgrades.
> 
>> Shouldn't be a problem.  However, it does raise the question of when
>> we'll move to 2.1.0.  If the version string consists of
>> major.minor.revision, then possibly we should be incrementing minor and
>> resetting revision whenever there is a new release on
>> userspace.selinuxproject.org?
> 
> Make sense to me.

Sounds good to me.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: libselinux version bump past 99

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/08/2011 05:26 PM, Eamon Walsh wrote:
> Libselinux has reached version 2.0.99 and I need to push a bug fix, just checking to make sure 2.0.100 is fine and won't cause any problems e.g. with upgrades.
> 
> 
Should not be a problem
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk13nXwACgkQrlYvE4MpobNbrQCg4N7NcntXyOSOd5jbiV94JgzK
pwgAn1oiJUXXKT4Jb6Biu7v8EYKLZyIS
=pZ1b
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: libselinux version bump past 99

[Paul Gortmaker]

On 11-03-08 05:26 PM, Eamon Walsh wrote:
> Libselinux has reached version 2.0.99 and I need to push a bug fix, just checking to make sure 2.0.100 is fine and won't cause any problems e.g. with upgrades.
>
>

On a related note, is there a reason why the shared objects don't
track a similar versioning number?    We came across a situation
where an internal update added a new dir for libs.   But note the
shared objects are hard coded to version 1,  and the old selinux
libs just happened to be found 1st.   Which leads to a cryptic
internal selinux error message like this:

"libsepol.policydb_read: policydb module version 10 does not
match my version range 4-8"

Granted, this may not be a common problem, but the solution that
came to me was to simply let the normal ld.so dynamic library
versioning do its job in determining which bins need which libs;
something that it is remarkably good at.  :)

To that end, a trivial patch like the below, applied to the two main
libraries seems to fix things up. If this seems OK, then I can send
proper patches with a Signed-off-by, but I guess that would leave
you folks stuck with the question of when to make the switchover...

Thanks,
Paul.

-------------------

--- a/src/Makefile
+++ b/src/Makefile
@@ -15,7 +15,7 @@ RUBYINSTALL ?= $(LIBDIR)/ruby/site_ruby/
 LIBBASE=$(shell basename $(LIBDIR))
 
 VERSION = $(shell cat ../VERSION)
-LIBVERSION = 1
+LIBVERSION = $(VERSION)
 
 LIBA=libselinux.a
 TARGET=libselinux.so


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: libselinux version bump past 99

[Russell Coker]

On Tue, 15 Mar 2011, Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> On a related note, is there a reason why the shared objects don't
> track a similar versioning number?    We came across a situation
> where an internal update added a new dir for libs.   But note the
> shared objects are hard coded to version 1,  and the old selinux
> libs just happened to be found 1st.   Which leads to a cryptic
> internal selinux error message like this:

So what's the plans for libselinux at the moment?  Are we going to get a .so 
version change in the near future?

I'm trying to build version 2.0.98 on Debian and I get the following error 
when going from 2.0.96.  If we are going to increase the .so version in the 
near future then I won't bother trying to solve this right now.  Although from 
a quick inspection of the code it doesn't seem likely that this will cause any 
problems, it seems that selabelsublist should never have been exported and is 
extremely unlikely to have been used.

dpkg-gensymbols: warning: 
/usr/src/libselinux/libselinux-2.0.98/debian/libselinux1/DEBIAN/symbols 
doesn't match completely debian/libselinux1.symbols
--- debian/libselinux1.symbols (libselinux1_2.0.98-1_i386)
+++ dpkg-gensymbolszEQkRf       2011-03-15 21:36:52.486698524 +1100
@@ -136,7 +136,7 @@
  selabel_lookup_raw@Base 2.0.65
  selabel_open@Base 2.0.65
  selabel_stats@Base 2.0.65
- selabelsublist@Base 2.0.82
+#MISSING: 2.0.98-1# selabelsublist@Base 2.0.82
  selinux_binary_policy_path@Base 1.32
  selinux_booleans_path@Base 1.32
  selinux_check_passwd_access@Base 1.32

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: libselinux version bump past 99

[Stephen Smalley]

On Tue, 2011-03-15 at 22:24 +1100, Russell Coker wrote:
> On Tue, 15 Mar 2011, Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> > On a related note, is there a reason why the shared objects don't
> > track a similar versioning number?    We came across a situation
> > where an internal update added a new dir for libs.   But note the
> > shared objects are hard coded to version 1,  and the old selinux
> > libs just happened to be found 1st.   Which leads to a cryptic
> > internal selinux error message like this:
> 
> So what's the plans for libselinux at the moment?  Are we going to get a .so 
> version change in the near future?
> 
> I'm trying to build version 2.0.98 on Debian and I get the following error 
> when going from 2.0.96.  If we are going to increase the .so version in the 
> near future then I won't bother trying to solve this right now.  Although from 
> a quick inspection of the code it doesn't seem likely that this will cause any 
> problems, it seems that selabelsublist should never have been exported and is 
> extremely unlikely to have been used.

I'm not aware of any plan to change the .so version of libselinux. It
looks like you are correct about selabelsublist.  We should likely add
a .map file for libselinux as with libsemanage and libsepol and
explicitly enumerate the exported symbols.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: libselinux version bump past 99

[Stephen Smalley]

On Mon, 2011-03-14 at 19:26 -0400, Paul Gortmaker wrote:
> On 11-03-08 05:26 PM, Eamon Walsh wrote:
> > Libselinux has reached version 2.0.99 and I need to push a bug fix, just checking to make sure 2.0.100 is fine and won't cause any problems e.g. with upgrades.
> >
> >
> 
> On a related note, is there a reason why the shared objects don't
> track a similar versioning number?    We came across a situation
> where an internal update added a new dir for libs.   But note the
> shared objects are hard coded to version 1,  and the old selinux
> libs just happened to be found 1st.   Which leads to a cryptic
> internal selinux error message like this:
> 
> "libsepol.policydb_read: policydb module version 10 does not
> match my version range 4-8"
> 
> Granted, this may not be a common problem, but the solution that
> came to me was to simply let the normal ld.so dynamic library
> versioning do its job in determining which bins need which libs;
> something that it is remarkably good at.  :)

As I understand it, the .so version should only be changed upon an
incompatible ABI change, not upon implementation changes or compatible
ABI changes.  And per-symbol versioning seems to be preferred these
days, as per:
http://www.akkadia.org/drepper/dsohowto.pdf

See libsemanage.map for an example.

But the question of what policy version is supported by a given release
of libsepol has nothing to do with its ABI.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: libselinux version bump past 99

[Paul Gortmaker]

On 11-03-15 08:10 AM, Stephen Smalley wrote:
> On Mon, 2011-03-14 at 19:26 -0400, Paul Gortmaker wrote:
>> On 11-03-08 05:26 PM, Eamon Walsh wrote:
>>> Libselinux has reached version 2.0.99 and I need to push a bug fix, just checking to make sure 2.0.100 is fine and won't cause any problems e.g. with upgrades.
>>>
>>>
>> On a related note, is there a reason why the shared objects don't
>> track a similar versioning number?    We came across a situation
>> where an internal update added a new dir for libs.   But note the
>> shared objects are hard coded to version 1,  and the old selinux
>> libs just happened to be found 1st.   Which leads to a cryptic
>> internal selinux error message like this:
>>
>> "libsepol.policydb_read: policydb module version 10 does not
>> match my version range 4-8"
>>
>> Granted, this may not be a common problem, but the solution that
>> came to me was to simply let the normal ld.so dynamic library
>> versioning do its job in determining which bins need which libs;
>> something that it is remarkably good at.  :)
> As I understand it, the .so version should only be changed upon an
> incompatible ABI change, not upon implementation changes or compatible

Sure, and the above error message clearly indicates that
this has not been done in the past.   So as I'd hinted at,
the question then becomes when to start implementing
it, if people agree it makes sense to do what every other
library does.

The simplest answer seems to be to align it upon the
next incompatible ABI change you have queued up.
Leaving it hard coded at 1 forever just seems misleading,
and causes errors like the one I showed above.

Thanks,
Paul.

> ABI changes.  And per-symbol versioning seems to be preferred these
> days, as per:
> http://www.akkadia.org/drepper/dsohowto.pdf
>
> See libsemanage.map for an example.
>
> But the question of what policy version is supported by a given release
> of libsepol has nothing to do with its ABI.
>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: libselinux version bump past 99

[Stephen Smalley]

On Wed, 2011-03-16 at 12:04 -0400, Paul Gortmaker wrote:
> On 11-03-15 08:10 AM, Stephen Smalley wrote:
> > On Mon, 2011-03-14 at 19:26 -0400, Paul Gortmaker wrote:
> >> On 11-03-08 05:26 PM, Eamon Walsh wrote:
> >>> Libselinux has reached version 2.0.99 and I need to push a bug fix, just checking to make sure 2.0.100 is fine and won't cause any problems e.g. with upgrades.
> >>>
> >>>
> >> On a related note, is there a reason why the shared objects don't
> >> track a similar versioning number?    We came across a situation
> >> where an internal update added a new dir for libs.   But note the
> >> shared objects are hard coded to version 1,  and the old selinux
> >> libs just happened to be found 1st.   Which leads to a cryptic
> >> internal selinux error message like this:
> >>
> >> "libsepol.policydb_read: policydb module version 10 does not
> >> match my version range 4-8"
> >>
> >> Granted, this may not be a common problem, but the solution that
> >> came to me was to simply let the normal ld.so dynamic library
> >> versioning do its job in determining which bins need which libs;
> >> something that it is remarkably good at.  :)
> > As I understand it, the .so version should only be changed upon an
> > incompatible ABI change, not upon implementation changes or compatible
> 
> Sure, and the above error message clearly indicates that
> this has not been done in the past.   So as I'd hinted at,
> the question then becomes when to start implementing
> it, if people agree it makes sense to do what every other
> library does.
> 
> The simplest answer seems to be to align it upon the
> next incompatible ABI change you have queued up.
> Leaving it hard coded at 1 forever just seems misleading,
> and causes errors like the one I showed above.

That's not an ABI change.  The application interface to libsepol did not
change.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: libselinux version bump past 99

[Paul Gortmaker]

On 11-03-16 12:07 PM, Stephen Smalley wrote:
> On Wed, 2011-03-16 at 12:04 -0400, Paul Gortmaker wrote:
>> On 11-03-15 08:10 AM, Stephen Smalley wrote:
>>> On Mon, 2011-03-14 at 19:26 -0400, Paul Gortmaker wrote:
>>>> On 11-03-08 05:26 PM, Eamon Walsh wrote:
>>>>> Libselinux has reached version 2.0.99 and I need to push a bug fix, just checking to make sure 2.0.100 is fine and won't cause any problems e.g. with upgrades.
>>>>>
>>>>>
>>>> On a related note, is there a reason why the shared objects don't
>>>> track a similar versioning number?    We came across a situation
>>>> where an internal update added a new dir for libs.   But note the
>>>> shared objects are hard coded to version 1,  and the old selinux
>>>> libs just happened to be found 1st.   Which leads to a cryptic
>>>> internal selinux error message like this:
>>>>
>>>> "libsepol.policydb_read: policydb module version 10 does not
>>>> match my version range 4-8"
>>>>
>>>> Granted, this may not be a common problem, but the solution that
>>>> came to me was to simply let the normal ld.so dynamic library
>>>> versioning do its job in determining which bins need which libs;
>>>> something that it is remarkably good at.  :)
>>> As I understand it, the .so version should only be changed upon an
>>> incompatible ABI change, not upon implementation changes or compatible
>> Sure, and the above error message clearly indicates that
>> this has not been done in the past.   So as I'd hinted at,
>> the question then becomes when to start implementing
>> it, if people agree it makes sense to do what every other
>> library does.
>>
>> The simplest answer seems to be to align it upon the
>> next incompatible ABI change you have queued up.
>> Leaving it hard coded at 1 forever just seems misleading,
>> and causes errors like the one I showed above.
> That's not an ABI change.  The application interface to libsepol did not
> change.

Well you folks are the maintainers in the end and it is your call.

As an end user, the above message didn't really hit home with
me what the underlying issue was, and when I got rid of the
stale libraries, the incompatibility issue was gone.   Whether
it is an ABI change or any other kind of incompatibility is just
going to seem like splitting hairs to the person who can't make
their system work.

I hope you are open to taking advantage of the library version
number in the future, when the opportunity arises.

Thanks,
Paul.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.