Re: [foreman-dev] Getting Foreman and Smart-Proxy to run in FIPS environment.

[Dmitri Dolguikh]

Do you have some examples how such an abort looks like with and without GDB?

with gdb + .gdbinit:

Program received signal SIGABRT, Aborted.
0x7fb45991e1f7 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
$1 = (rb_vm_t *) 0x117ef20
* #
0x7fb45259accc :in `digest'
(irb):5:in `irb_binding'
0x7fb45a80b318 :in `eval'
/home/vagrant/.rvm/rubies/ruby-2.4.2/lib/ruby/2.4.0/irb/workspace.rb:87:in
`evaluate'
/home/vagrant/.rvm/rubies/ruby-2.4.2/lib/ruby/2.4.0/irb/context.rb:381:in
`evaluate'
/home/vagrant/.rvm/rubies/ruby-2.4.2/lib/ruby/2.4.0/irb.rb:493:in
`block (2 levels) in eval_input'
...

with gdb only:
Program received signal SIGABRT, Aborted.
0x7f080307f1f7 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0  0x7f080307f1f7 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x7f08030808e8 in __GI_abort () at abort.c:90
#2  0x7f07f9f2498f in OpenSSLDie (file=file@entry=0x7f07fa066cd3
"md5_dgst.c", line=line@entry=82,
assertion=assertion@entry=0x7f07fa066cb0 "Digest MD5 forbidden in FIPS
mode!") at cryptlib.c:1002
#3  0x7f07f9f2b209 in MD5_Init (c=0x34af790) at md5_dgst.c:82
#4  0x7f07fbcfbea0 in algo_init (algo=0x7f07fa518d60 ,
pctx=0x34af790) at digest.c:586
#5  0x7f07fbcfbf4d in rb_digest_base_alloc (klass=54958520) at
digest.c:606
#6  0x7f0803e6a6de in rb_obj_alloc (klass=54958520) at object.c:1863
#7  0x7f07fbcfbd32 in rb_digest_class_s_digest (argc=0,
argv=0x7f0804387668, klass=54958520) at digest.c:472
#8  0x7f0803f5997b in call_cfunc_m1 (func=0x7f07fbcfbccc
, recv=54958520, argc=1,
argv=0x7f0804387660) at vm_insnhelper.c:1589
...



> Why I am asking. Once we start supporting FIPS, I wonder how we are
> gonna provide support for users and customers who are in FIPS mode and
> "someting is breaking apart". Installing GDB would be really the last
> thing to do. I wonder if there is any chance of using SystemTap or
> even ABRT (Automatic Bug Reporting Tool) data (stacktrace with debug
> info, core dump). Trying to find a workflow which we will use for
> retrospective analysis to find the Ruby code which is causing this.
>
> Was wondering if we can hook into ABRT and print stacktrace similarly
> as we do for:
>
> https://github.com/theforeman/foreman/blob/698e916ce208b5040b83a908a058c8
> 3c94d158ee/config/initializers/sig_ttin_trap.rb


I tried installing an abrt signal handler when I was preparing this note,
but it never gets called, possibly due to openssl calling exit immediately
after raising 'abrt' [1]. Similarly, rubygem-abrt isn't catching 'abrt'
signals raised by openssl. The only thing that worked for me was the
approach I documented.

-d

 [1]
http://docs.huihoo.com/doxygen/openssl/1.0.1c/cryptlib_8c_source.html#l00912

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Nominating cfouant for write access to hammer-cli-katello

[Chris Roberts]

+1 from me

On Tuesday, November 21, 2017 at 11:40:48 AM UTC-5, Andrew Kofink wrote:
>
> I hereby nominate Christine Fouant to gain commit access to 
> hammer-cli-katello. She currently has 12 merged PRs 
> 
>  and 
> has helped to review 11 merged PRs 
> 
> .
>
> Let the +/-1's begin!
>
> -- 
> Andrew Kofink
> ako...@redhat.com 
> IRC: akofink
> Software Engineer
> Red Hat Satellite
>

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[foreman-dev] Nominating cfouant for write access to hammer-cli-katello

[Andrew Kofink]

I hereby nominate Christine Fouant to gain commit access to
hammer-cli-katello. She currently has 12 merged PRs

and
has helped to review 11 merged PRs

.

Let the +/-1's begin!

-- 
Andrew Kofink
akof...@redhat.com
IRC: akofink
Software Engineer
Red Hat Satellite

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re: [foreman-dev] Re: 1.15.4 - 1.16 RC.1 - 1.17 status

[Ewoud Kohl van Wijngaarden]

On Tue, Nov 21, 2017 at 11:10:41AM +0200, Ohad Levy wrote:

On Tue, Nov 21, 2017 at 11:02 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:


On Sun, Nov 19, 2017 at 09:35:04PM +0100, Ewoud Kohl van Wijngaarden wrote:


On Sun, Nov 19, 2017 at 11:27:57AM +0200, Ohad Levy wrote:



Can anyone shed some light on ETA for 1.16 GA?


I should have given an update earlier.

So far we've been wanting to include the foreman tasks as a service from
core rather than from foreman-tasks. As always we want that change to first
land in develop but we've been struggling with broken nightlies for quite
some time. It loked like it was fixed since the builds started to pass
aagin but we have no validation on the actual UI. Turns out that's broken
and we have no automated testing for this.



After bumping some dependencies and fixing some koji issues I can now open
the UI and end up without javascript compilation errors in the console.
Haven't verified much more than clicking through various pages but this
will allow us to start focussing on the needed packaging changes (dynflow,
Rails 5.1).



great news, thanks :) just wondering, i assume we can now release 1.16
first (which imho is a higher prio dynflow, and rails 5.1?)


I agree it's higher prio, but I can't judge if the current release could 
be considered ready to release or if the dynflow change is halfway in 
the migration. I'll let Daniel and Ivan discuss that further while I 
work on getting dynflow in nightly.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Getting Foreman and Smart-Proxy to run in FIPS environment.

[Lukas Zapletal]

Thanks, so ABRT is raised when a FIPS-enabled library (e.g. openssl)
catches an attempt to use non-approved cipher.

Do you have some examples how such an abort looks like with and without GDB?

Why I am asking. Once we start supporting FIPS, I wonder how we are
gonna provide support for users and customers who are in FIPS mode and
"someting is breaking apart". Installing GDB would be really the last
thing to do. I wonder if there is any chance of using SystemTap or
even ABRT (Automatic Bug Reporting Tool) data (stacktrace with debug
info, core dump). Trying to find a workflow which we will use for
retrospective analysis to find the Ruby code which is causing this.

Was wondering if we can hook into ABRT and print stacktrace similarly
as we do for:

https://github.com/theforeman/foreman/blob/698e916ce208b5040b83a908a058c83c94d158ee/config/initializers/sig_ttin_trap.rb

LZ

On Mon, Nov 20, 2017 at 8:05 PM, Dmitri Dolguikh  wrote:
>
>
> On Mon, Nov 20, 2017 at 2:05 AM, Lukas Zapletal  wrote:
>>
>> Perhaps - can you bit elaborate the GDB
>> thing? Is this some kind of hook that use used for FIPS stack to
>> report "mistakes" (e.g. signal or exception when you attempt to use
>> md5 hash)? I wonder if there is a way to catch these without GDB, for
>> example with SystemTap which would allow to catch these also in
>> production. Perhaps I misinterpret how this works, I haven't opened
>> the PDFs to be honest yet :-)
>
>
> DGB + ruby-specific .gdbinit are used to report ruby callstack when ABRT is
> caught. I didn't look for alternatives, seeing that gdb + .gdbinit
> combination is pretty trivial to use. I don't really care what we use here
> as long as we can get ruby callstack back.
>
>>
>>
>> I understand you only investigated core and smart proxy and I assume
>> plugin authors will need to do the similar audit themselves. Since we
>> are dealing with security, I would like to propose to create kind of
>> FIPS CHECKLIST somewhere (perhaps our wikipage) so we could follow it
>> and also add own findings/places to look for. In security world it's
>> much more useful to have blueprints or checklists, I would not like to
>> reinvent the wheel when doing this for discovery or other plugins.
>
>
> Sure, sounds like a good idea. I think it's going to consist of the list of
> hash-functions and ciphers not to use and a recommendation to test changes
> on a system with FIPS enabled.
>
>>
>>
>> Once we settle down on your proposal, please do create tracker
>> issue(s) so we can associate our audits or changes to it. If you find
>> anything that needs to be done for all plugins, please create tracker
>> issue as well.
>
>
> Tracker issue for Foreman already exists:
> http://projects.theforeman.org/issues/3511.
>
> -d
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Later,
  Lukas @lzap Zapletal

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Foreman instrumentation for telemetry proposal

[Lukas Zapletal]

Thanks for question, this will be completely opt-in via
/etc/foreman/settings.yaml. You can turn off (default behavior when
not set), or on via prometheus, statsd or logging implementation (for
debugging purposes - sends stats to Rails log / production.log).

On Mon, Nov 20, 2017 at 4:31 PM, Bryan Kearney  wrote:
> How would folks disable it opt out of sending this data?
>
> On Nov 20, 2017 9:46 AM, "Lukas Zapletal"  wrote:
>>
>> Hey,
>>
>> on the last demo I presented my proposal for telemetry (it is actually
>> a separate video). I am looking for non-intrusive approach with broad
>> integration possibilities:
>>
>> https://www.youtube.com/watch?v=gCLSI9-4QpE
>>
>> This was also showed on our demo last week (the same content):
>> https://www.youtube.com/watch?v=QHzNIFjMpTM
>>
>> I am starting this thread to gather feedback before I open a PR with
>> this. Currently the code is mostly in Rails initializer and looks like
>> this:
>>
>> # get telemetry singleton instance and setup it
>> telemetry = Foreman::Telemetry.instance.setup(... some options ...)
>>
>> # register measurements
>> telemetry.add_counter(:http_requests, 'A counter of HTTP requests
>> made', [:controller, :action])
>> telemetry.add_histogram(:http_request_total_duration, 'Total
>> duration', [:controller, :action])
>> telemetry.add_counter(:activerecord_instances, 'Number of instances of
>> AR models', [:class])
>>
>> # send measurements from Rails instrumentation or from code base
>> telemetry.increment_counter(:http_requests, 1, :controller =>
>> controller, :action => action, :status => status)
>> telemetry.observe_histogram(:http_request_total_duration, duration,
>> :controller => controller, :action => action)
>>
>> The proposed API is a single class (a singleton actually) with three
>> registering methods and three measure methods. I don't think such a
>> simple class needs proper separation of concerns, but we can talk
>> about this in the PR. The registration part could be turned into some
>> kind of DSL, currently it takes metric name, description and list of
>> keys which will be part of an instance for those frameworks which do
>> not support arbitrary amount of key-value pairs.
>>
>> If there are no objections, I will add settings and better error
>> handling and file the PR.
>>
>> --
>> Later,
>>   Lukas @lzap Zapletal
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to foreman-dev+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Later,
  Lukas @lzap Zapletal

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re: [foreman-dev] Re: 1.15.4 - 1.16 RC.1 - 1.17 status

[Ohad Levy]

On Tue, Nov 21, 2017 at 11:02 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> On Sun, Nov 19, 2017 at 09:35:04PM +0100, Ewoud Kohl van Wijngaarden wrote:
>
>> On Sun, Nov 19, 2017 at 11:27:57AM +0200, Ohad Levy wrote:
>>
>>>
>>> Can anyone shed some light on ETA for 1.16 GA?
>>>
>>>
>> I should have given an update earlier.
>>
>> So far we've been wanting to include the foreman tasks as a service from
>> core rather than from foreman-tasks. As always we want that change to first
>> land in develop but we've been struggling with broken nightlies for quite
>> some time. It loked like it was fixed since the builds started to pass
>> aagin but we have no validation on the actual UI. Turns out that's broken
>> and we have no automated testing for this.
>>
>
> After bumping some dependencies and fixing some koji issues I can now open
> the UI and end up without javascript compilation errors in the console.
> Haven't verified much more than clicking through various pages but this
> will allow us to start focussing on the needed packaging changes (dynflow,
> Rails 5.1).


great news, thanks :) just wondering, i assume we can now release 1.16
first (which imho is a higher prio dynflow, and rails 5.1?)

>
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re: [foreman-dev] Re: 1.15.4 - 1.16 RC.1 - 1.17 status

[Ewoud Kohl van Wijngaarden]

On Sun, Nov 19, 2017 at 09:35:04PM +0100, Ewoud Kohl van Wijngaarden wrote:

On Sun, Nov 19, 2017 at 11:27:57AM +0200, Ohad Levy wrote:


Can anyone shed some light on ETA for 1.16 GA?



I should have given an update earlier.

So far we've been wanting to include the foreman tasks as a service 
from core rather than from foreman-tasks. As always we want that 
change to first land in develop but we've been struggling with broken 
nightlies for quite some time. It loked like it was fixed since the 
builds started to pass aagin but we have no validation on the actual 
UI. Turns out that's broken and we have no automated testing for this.


After bumping some dependencies and fixing some koji issues I can now 
open the UI and end up without javascript compilation errors in the 
console. Haven't verified much more than clicking through various pages 
but this will allow us to start focussing on the needed packaging 
changes (dynflow, Rails 5.1).


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.