secilc: in segfault

secilc: in segfault

[Dominick Grift]

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

Anyone tried "secilc test/in_test.cil" lately? It dumps core here.

$ secilc test/in_test.cil
Segmentation fault (core dumped)

-- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: secilc: in segfault

[James Carter]

On 09/03/2015 05:48 AM, Dominick Grift wrote:
> Anyone tried "secilc test/in_test.cil" lately? It dumps core here.
>
> $ secilc test/in_test.cil
> Segmentation fault (core dumped)
>
>

It works for me for the current master branch of SELinux userspace installed 
locally. What version are you using?

Jim


-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency

Re: secilc: in segfault

[Dominick Grift]

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

On Thu, Sep 03, 2015 at 08:18:17AM -0400, James Carter wrote:
> On 09/03/2015 05:48 AM, Dominick Grift wrote:
> >Anyone tried "secilc test/in_test.cil" lately? It dumps core here.
> >
> >$ secilc test/in_test.cil
> >Segmentation fault (core dumped)
> >
> >
> 
> It works for me for the current master branch of SELinux userspace installed
> locally. What version are you using?
> 
> Jim

It happens with both secilc-2.4-5.fc24.x86_64 as well as
secilc-2.4-6.fc24.x86_64 (which was spun 2 day's ago by Fedora)

It does work with some old secilc i had laying around in my ~/bin

> 
> 
> -- 
> James Carter <jwcart2@tycho.nsa.gov>
> National Security Agency
> _______________________________________________
> 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
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: secilc: in segfault

[Dominick Grift]

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

On Thu, Sep 03, 2015 at 08:18:17AM -0400, James Carter wrote:
> On 09/03/2015 05:48 AM, Dominick Grift wrote:
> >Anyone tried "secilc test/in_test.cil" lately? It dumps core here.
> >
> >$ secilc test/in_test.cil
> >Segmentation fault (core dumped)
> >
> >
> 
> It works for me for the current master branch of SELinux userspace installed
> locally. What version are you using?
> 
> Jim

It may just be my incompetence but i can't get current master branch
selinux user space to build on Fedora rawhide manually like so:

# cd selinux
# make LIBDIR=/usr/lib64 SHLIBDIR=/lib64

I have installed all the build dependencies i believe

This is what it is failing with here:

cc1: all warnings being treated as errors
Makefile:113: recipe for target 'direct_api.o' failed
make[2]: *** [direct_api.o] Error 1
make[2]: Leaving directory
'/home/kcinimod/Workspace/selinux/libsemanage/src'
Makefile:2: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory
'/home/kcinimod/Workspace/selinux/libsemanage'
Makefile:11: recipe for target 'all' failed
make: *** [all] Error 1

> 
> 
> -- 
> James Carter <jwcart2@tycho.nsa.gov>
> National Security Agency
> _______________________________________________
> 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
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: secilc: in segfault

[Petr Lautrbach]

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

On 09/03/2015 02:40 PM, Dominick Grift wrote:
> On Thu, Sep 03, 2015 at 08:18:17AM -0400, James Carter wrote:
>> On 09/03/2015 05:48 AM, Dominick Grift wrote:
>>> Anyone tried "secilc test/in_test.cil" lately? It dumps core here.
>>>
>>> $ secilc test/in_test.cil
>>> Segmentation fault (core dumped)

Confirmed on Fedora 23, thanks for the report.

https://bugzilla.redhat.com/show_bug.cgi?id=1259730


> It may just be my incompetence but i can't get current master branch
> selinux user space to build on Fedora rawhide manually like so:
> 
> # cd selinux
> # make LIBDIR=/usr/lib64 SHLIBDIR=/lib64
> 
> I have installed all the build dependencies i believe
> 
> This is what it is failing with here:
> 
> cc1: all warnings being treated as errors
> Makefile:113: recipe for target 'direct_api.o' failed
> make[2]: *** [direct_api.o] Error 1
> make[2]: Leaving directory
> '/home/kcinimod/Workspace/selinux/libsemanage/src'
> Makefile:2: recipe for target 'all' failed
> make[1]: *** [all] Error 2
> make[1]: Leaving directory
> '/home/kcinimod/Workspace/selinux/libsemanage'
> Makefile:11: recipe for target 'all' failed
> make: *** [all] Error 1
> 

This report seems to be little stripped so the important messages are
missing. Nevertheless, according to README you should use install
target. The following command works for me on Fedora 23:

make DESTDIR=/home/plautrba/devel/build/selinux  install

Petr
-- 
Petr Lautrbach



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: secilc: in segfault

[Dominick Grift]

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

On Thu, Sep 03, 2015 at 02:53:49PM +0200, Petr Lautrbach wrote:

<snip>

> > 
> > # cd selinux
> > # make LIBDIR=/usr/lib64 SHLIBDIR=/lib64
> > 
> > I have installed all the build dependencies i believe
> > 
> > This is what it is failing with here:
> > 
> > cc1: all warnings being treated as errors
> > Makefile:113: recipe for target 'direct_api.o' failed
> > make[2]: *** [direct_api.o] Error 1
> > make[2]: Leaving directory
> > '/home/kcinimod/Workspace/selinux/libsemanage/src'
> > Makefile:2: recipe for target 'all' failed
> > make[1]: *** [all] Error 2
> > make[1]: Leaving directory
> > '/home/kcinimod/Workspace/selinux/libsemanage'
> > Makefile:11: recipe for target 'all' failed
> > make: *** [all] Error 1
> > 
> 
> This report seems to be little stripped so the important messages are
> missing. Nevertheless, according to README you should use install
> target. The following command works for me on Fedora 23:
> 
> make DESTDIR=/home/plautrba/devel/build/selinux  install
> 

That seems to work, thanks



> _______________________________________________
> 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
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: secilc: in segfault

[Dominick Grift]

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

On Thu, Sep 03, 2015 at 08:18:17AM -0400, James Carter wrote:
> On 09/03/2015 05:48 AM, Dominick Grift wrote:
> >Anyone tried "secilc test/in_test.cil" lately? It dumps core here.
> >
> >$ secilc test/in_test.cil
> >Segmentation fault (core dumped)
> >
> >
> 
> It works for me for the current master branch of SELinux userspace installed
> locally. What version are you using?
> 
> Jim
> 

Ok so that turns out to be a bug in Fedora. However.

I can still get secilc to segfault on "in". I wonder if the following is
or should be supported:

The scenario is: I want to simplify my macros by using
blockabstracts/inherits to provide a single point of failure

As a matter of test i made these two changes:

https://github.com/DefenSec/dssp/commit/85ba6f1848118e16b5544052dc5764663b272262
https://github.com/DefenSec/dssp-contrib/commit/77442e1e4658df99d1ce74732338a9c4ad80a6a3

However this makes secilc segfault, and i do not see why.

I first thought it was because i was using "ARG1" in the blockabstract
(see first commit). However that seems to not be the case.

I am left wondering: what am i doing wrong here (obviously secilc should
not segfault nevertheless)

-- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: secilc: in segfault

[James Carter]

On 09/03/2015 09:20 AM, Dominick Grift wrote:
> On Thu, Sep 03, 2015 at 08:18:17AM -0400, James Carter wrote:
>> On 09/03/2015 05:48 AM, Dominick Grift wrote:
>>> Anyone tried "secilc test/in_test.cil" lately? It dumps core here.
>>>
>>> $ secilc test/in_test.cil
>>> Segmentation fault (core dumped)
>>>
>>>
>>
>> It works for me for the current master branch of SELinux userspace installed
>> locally. What version are you using?
>>
>> Jim
>>
>
> Ok so that turns out to be a bug in Fedora. However.
>
> I can still get secilc to segfault on "in". I wonder if the following is
> or should be supported:
>
> The scenario is: I want to simplify my macros by using
> blockabstracts/inherits to provide a single point of failure
>
> As a matter of test i made these two changes:
>
> https://github.com/DefenSec/dssp/commit/85ba6f1848118e16b5544052dc5764663b272262
> https://github.com/DefenSec/dssp-contrib/commit/77442e1e4658df99d1ce74732338a9c4ad80a6a3
>
> However this makes secilc segfault, and i do not see why.
>

This doesn't appear to be ONLY because of the "in" block. It still segfaults 
even with moving everything inside the block and removing the "in" block.

It looks like one problem is with the use of a blockinherit inside a macro. 
Blocks and blockinherits are not allowed to be used in macros. As we were fixing 
CIL's name resolution last Fall we came to the conclusion that allowing both of 
these would provide little benefit while causing a lot of potential problems. 
But we are open to a discussion if you can provide a compelling use case.

Why not use something like this:

(block exec_blk
	(blockabstract exec_blk)
	(macro exec ((type ARG1))
	       (call can_exec (ARG1 cmd_file))))

(block auditctl
	(blockinherit exec_blk))

(call auditctl.exec (some_type))

instead of:

(block exec_blk
	(blockabstract exec_blk)
	(call can_exec (ARG1 cmd_file)))

(block auditctl
   	(macro exec ((type ARG1))
		(blockinherit exec_blk)))

(call auditctl.exec (some_type))


Jim

> I first thought it was because i was using "ARG1" in the blockabstract
> (see first commit). However that seems to not be the case.
>
> I am left wondering: what am i doing wrong here (obviously secilc should
> not segfault nevertheless)
>


-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency

Re: secilc: in segfault

[Dominick Grift]

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

On Wed, Sep 09, 2015 at 04:17:13PM -0400, James Carter wrote:
<snip>

> 
> This doesn't appear to be ONLY because of the "in" block. It still segfaults
> even with moving everything inside the block and removing the "in" block.
> 
> It looks like one problem is with the use of a blockinherit inside a macro.
> Blocks and blockinherits are not allowed to be used in macros. As we were
> fixing CIL's name resolution last Fall we came to the conclusion that
> allowing both of these would provide little benefit while causing a lot of
> potential problems. But we are open to a discussion if you can provide a
> compelling use case.
> 
> Why not use something like this:
> 
> (block exec_blk
> 	(blockabstract exec_blk)
> 	(macro exec ((type ARG1))
> 	       (call can_exec (ARG1 cmd_file))))
> 
> (block auditctl
> 	(blockinherit exec_blk))
> 
> (call auditctl.exec (some_type))
> 
> instead of:
> 
> (block exec_blk
> 	(blockabstract exec_blk)
> 	(call can_exec (ARG1 cmd_file)))
> 
> (block auditctl
>   	(macro exec ((type ARG1))
> 		(blockinherit exec_blk)))
> 
> (call auditctl.exec (some_type))
> 

Thanks, That looks fine to me. I will try this out tomorrow and see how it goes. I am
not attached to any particular solution. Although I tried what, to me,
felt natural and intuitive. Thanks for the suggestion.

> 
> Jim
> 
> >I first thought it was because i was using "ARG1" in the blockabstract
> >(see first commit). However that seems to not be the case.
> >
> >I am left wondering: what am i doing wrong here (obviously secilc should
> >not segfault nevertheless)
> >
> 
> 
> -- 
> James Carter <jwcart2@tycho.nsa.gov>
> National Security Agency
> _______________________________________________
> 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

iQGcBAEBCgAGBQJV8JpUAAoJENAR6kfG5xmcF7EL/3RpgagwqZHgF8HdbQBhuQBU
7uYaEBLDVgvDFTh8MZqPhNGXxmazCi/DYCL3XgFy96wCCjHG5Ea1HvHLWiy+kWcT
3TunGCAKPbyCX1gHf1MyOgsbmXjdK2aIeOv3FoRiCoY+q1cZZ1F18ORSbd9Qfkcb
Bfg4XEcwZNYcw0LQGjVnuuAIQthGHOisv1DSGcXP4HtVghEBNWwKKMji4dgGbpKP
7AyBfnAux8gFyNLQZVeaCXnDz62iTxGVvKRfSEETx/JWrsqNV4XqhLpRcJcOZGEU
4PLSUO/jz1wdG/CtC6/swq01D46BZwkwri5JrihXPEb2k2CFLjbvJ7Bie1LU1J1T
0s8vPIV/gVFsCfKX3ilnTX4mFCXsoAlOntpgjfk9PkPwTTRpsYbXhJYy91llyuR0
Deg3u9P2eO/yiEoPwpvB0kn7LEZN0vBiZSzCNW+NdVHy2pu2+uqanCUs4qUOj71E
DnAEeXlPBGtVwWyMqfbcU+0Fc119HRJeynJDrDKuig==
=JhA8
-----END PGP SIGNATURE-----

Re: secilc: in segfault

[Dominick Grift]

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

On Wed, Sep 09, 2015 at 04:17:13PM -0400, James Carter wrote:
<snip>

> 
> Why not use something like this:
> 
> (block exec_blk
> 	(blockabstract exec_blk)
> 	(macro exec ((type ARG1))
> 	       (call can_exec (ARG1 cmd_file))))
> 
> (block auditctl
> 	(blockinherit exec_blk))
> 
> (call auditctl.exec (some_type))
> 
> instead of:
> 
> (block exec_blk
> 	(blockabstract exec_blk)
> 	(call can_exec (ARG1 cmd_file)))
> 
> (block auditctl
>   	(macro exec ((type ARG1))
> 		(blockinherit exec_blk)))
> 
> (call auditctl.exec (some_type))
> 

I tried your suggestion above in the following two commits:

https://github.com/DefenSec/dssp/commit/ddb58e7832bf6a815c495f30ae8a4a4060d227b7
https://github.com/DefenSec/dssp-contrib/commit/6ecb6b2f5830aaa7b3f3ec081af95ce0d71d06dc

This time it "really" seems to segfault on "in" (i tried moving it out
of there and that built)

However I prefer to not put these "macros" in the existing blocks. I
want to keep these macros in seperate $module/macros.cil files. Thus i
depend on "in".

This implementation also feels a bit limited and unintuitive but i suppose i could live
with that.

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

iQGcBAEBCgAGBQJV8SyBAAoJENAR6kfG5xmcN3ML/iUukWuwzqYPWvd8VDYpIvSy
mEb+636cQxskiY/6kiw2hFfQm7wrFWYNIyAB+DGGS4jobcKaJ136GqCVjab45kiq
XzmPUs0GEuKLffVuQP02bTbpLLBEC0rtTV6ePpirudoF7ECGHW9mKZGTvWPVTp8N
2wdX4za/qUiloDl33drKOemSUHP/vyn7yu7SMHQgJ0cTYdzA4rweGt3rZCS5W0CA
tEq7CV4nInvNSDiqvNE9eCWAU9xsVV3KnML8LEoPUzd4Y1qYoMuZSkhFm4F0l6te
eZ/s6NdU4LqIaBoBZTVYvNdR4OU5ijzjhmYdv7Qspg+tk7zzvsY7+0qjsXa6G/w7
NEnh7aDuQ6+1QNbf65IaLETqg4Co6jYvfgCWIDk8me2OS6wCOiZWNkl7JTShXf5n
DRgUGKUIvJ78Gp8n6q6l+iBNfg6r+kh2wOMRFeWvBJ/IMgObWZOEH3fnYiozcFen
wV7fj5VDpbuZTEIXS/pv3Xk9J3yJ4TfpeJyMYIk6Dw==
=ORb3
-----END PGP SIGNATURE-----

Re: secilc: in segfault

[Steve Lawrence]

On 09/10/2015 03:08 AM, Dominick Grift wrote:
> On Wed, Sep 09, 2015 at 04:17:13PM -0400, James Carter wrote:
> <snip>
> 
> 
>> Why not use something like this:
> 
>> (block exec_blk
>> 	(blockabstract exec_blk)
>> 	(macro exec ((type ARG1))
>> 	       (call can_exec (ARG1 cmd_file))))
> 
>> (block auditctl
>> 	(blockinherit exec_blk))
> 
>> (call auditctl.exec (some_type))
> 
>> instead of:
> 
>> (block exec_blk
>> 	(blockabstract exec_blk)
>> 	(call can_exec (ARG1 cmd_file)))
> 
>> (block auditctl
>>   	(macro exec ((type ARG1))
>> 		(blockinherit exec_blk)))
> 
>> (call auditctl.exec (some_type))
> 
> 
> I tried your suggestion above in the following two commits:
> 
> https://github.com/DefenSec/dssp/commit/ddb58e7832bf6a815c495f30ae8a4a4060d227b7
> https://github.com/DefenSec/dssp-contrib/commit/6ecb6b2f5830aaa7b3f3ec081af95ce0d71d06dc
> 
> This time it "really" seems to segfault on "in" (i tried moving it out
> of there and that built)
> 
> However I prefer to not put these "macros" in the existing blocks. I
> want to keep these macros in seperate $module/macros.cil files. Thus i
> depend on "in".
> 
> This implementation also feels a bit limited and unintuitive but i suppose i could live
> with that.

The segfault is cause by the in-statement. I'll send a patch shortly.

We don't allow block (and blockinherits/blockabstract) inside macros
because of ordering issues. For example, say you had something like this:

  (block a
    (blockinherit b)
    (call m))

  (block b
    (macro m ()
       ...)

  (macro m ()
    (blockinherit c))

  (block c
    (macro m ()
       ...))

If we performed the blockinherit b first, that would add b.m to block a.
Then if we performed the call m, that would call that b.m that was added
to a. So the global macro m would never be called.

However, if we instead had

  (block a
    (call m)
    (blockinherit b))

and we performed the call m first, that would be equivalent to

  (block a
    (blockinherit c)
    (blockinherit b))

Which would result in the macros from b and c being merged into block a.
So in once case the macro c.m isn't part of block a, but in the other
case it is.

Because of these ordering issues, it was decided to resolve all
blockinherit statements before calls. This has the effect that we can't
allow block, blockinherit, and blockabstract inside macros. This is a
similar reason why we don't allow in-statements and macro statements
inside of macros.

The patch I send out will also include changes to properly restrict
blocks from being defined inside macros.

- Steve

Re: secilc: in segfault

[Dominick Grift]

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

On Thu, Sep 10, 2015 at 09:37:41AM -0400, Steve Lawrence wrote:
<snip>
> 
> The segfault is cause by the in-statement. I'll send a patch shortly.
> 
> We don't allow block (and blockinherits/blockabstract) inside macros
> because of ordering issues. For example, say you had something like this:
> 
>   (block a
>     (blockinherit b)
>     (call m))
> 
>   (block b
>     (macro m ()
>        ...)
> 
>   (macro m ()
>     (blockinherit c))
> 
>   (block c
>     (macro m ()
>        ...))
> 
> If we performed the blockinherit b first, that would add b.m to block a.
> Then if we performed the call m, that would call that b.m that was added
> to a. So the global macro m would never be called.
> 
> However, if we instead had
> 
>   (block a
>     (call m)
>     (blockinherit b))
> 
> and we performed the call m first, that would be equivalent to
> 
>   (block a
>     (blockinherit c)
>     (blockinherit b))
> 
> Which would result in the macros from b and c being merged into block a.
> So in once case the macro c.m isn't part of block a, but in the other
> case it is.
> 
> Because of these ordering issues, it was decided to resolve all
> blockinherit statements before calls. This has the effect that we can't
> allow block, blockinherit, and blockabstract inside macros. This is a
> similar reason why we don't allow in-statements and macro statements
> inside of macros.
> 
> The patch I send out will also include changes to properly restrict
> blocks from being defined inside macros.

Thanks. I have spent some time updating my libsepol/secilc, and I have
to say compared to whatever what I was using this makes a world of
difference.

I haven't tried the above and the "class_permissionset in tunable" yet
but some things i noticed:

- - Some memory leak was fixed ( compiling policy took very long on
  low-spec kvm/qemu guests and occassionally caused secilc to get
  oom-killed ). Now it is compiling fast.

- - My policy had "type bounds violations" which i didnt know about. Now
  secilc reports warnings about those. Which allows me to identify and
  fix them.

- - When some identifiers in a context spec in an optional block were
  unavailable secilc use to print messages about them. This is no longer
  the case
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJV8vsCAAoJENAR6kfG5xmc6o4MAMEg+sgUa2426u8C8m/OPjGU
vOr2VqHi/UW//DJ5J8fJ1DH7xN2WTgY2i5FmEfCWMmdAZZU6VPaW6U8tSgdQ8rBj
zcJ2DblMwjdbGLuDxHY5m7IHkaUrgBxXGJ9lKbjRWYOTvKO3ROuN6xrKubxKw58G
n1w8vtYWfppBQAUW1bEXHjigKfhtbd4nJRdC4PHwTZWf2P+KrbDvT+TtUqCAfuYL
YC1ENl+/+tCMCkitz3Uhtf7EVlicTYdX9r44xNLgVVYYTk+hc8UErY41pfWLaF7D
zl6C+seHszLiJQe37ENkepzoVuE7Tu1EIKDZar66pe9cC01//Sr9/1NApNJp14gi
YdvRwk4D6WKfvGItprh15DoPh999bZHH/8ZhjRQyKmxNUAJUgEmywY5RGLGnzia3
TMOwAEk3P9CAjTjvkpp5k5mw0HBJsEqn7M+b4A7gSQ5wN9oDkDFeecJG2PhG/ZSB
RjQxfsQ2zwFWkOCvbgkQjfb58xJ18Xw2pteeh+cXAA==
=SPBX
-----END PGP SIGNATURE-----