Re: [foreman-dev] Discourse summary week 2 (ish)

[Dmitri Dolguikh]

Another +1 from me -- quite like the UI, email integration seems to be (or
will be?) good enough. As long as the amount of maintenance isn't too big,
I think the move is a good idea.
-d

On Wed, Nov 15, 2017 at 7:05 AM, John Mitsch  wrote:

> Also a +1 from me. Among other things, I like the categories, markdown
> support, and tags.
>
> John Mitsch
> Red Hat Engineering
> (860)-967-7285 <(860)%20967-7285>
> irc: jomitsch
>
> On Wed, Nov 15, 2017 at 9:59 AM, Sebastian Gräßl 
> wrote:
>
>> I am one of the (silent) +1 voices Greg mentioned.
>>
>> Discourse would be a very welcomed move for me, there are a number of
>> reasons, which Greg already mentioned as well.
>>
>> For me the one key reason is the possibility to have multiple categories
>> to have discussions and share information in a proper context.
>>
>>
>> On Wednesday, November 15, 2017 at 3:46:01 PM UTC+1, Greg Sutcliffe wrote:
>>>
>>> On 15/11/17 13:58, Lukas Zapletal wrote:
>>> > I AM STRONGLY AGAINST *MIGRATING* OUR MAILING LISTS TO ANY KIND OF
>>> > FORUM.
>>>
>>> I have included your opinion in both summaries. As a long standing
>>> member of the community, your vote does carry some weight - but shouting
>>> doesn't get you an extra one, and makes it appear like you're trying to
>>> drown out the debate (which I'm sure you don't intend).
>>>
>>> If however you feel you've been misrepresented in either of my summaries
>>> in some way, please let me know so I can correct that.
>>>
>>> > You do not have blessing. You gathered how many opinions? Two dozens?
>>> > How many of us are subscribed here?
>>>
>>> No one decides "blessing" or lack of it unilaterally, not me, or you.
>>> The community decides, and current feedback suggests far more in
>>> *cautious* favour than against - certainly enough to continue the
>>> discussion.
>>>
>>> One thing I have not yet done is post how I see the migration actually
>>> happening *if* we choose to do it. That may help alleviate fears for
>>> some, so I will try to get that posted shortly. My view of that process
>>> won't include a side-by-side site for reasons I already expressed to
>>> Ivan earlier. Again, this is all very much *if*, please don't assume
>>> this is already decided.
>>>
>>> > You gathered how many opinions? Two dozens? How many of us are
>>> > subscribed here?
>>>
>>> 670 addresses according to Google Groups, but I know that's not what you
>>> mean :)
>>>
>>> As with all our discussions, we can only count the opinions that have
>>> actually been stated. We don't wait forever on any decision, and we
>>> frequently take action on 5 votes or less.
>>>
>>> As with other large debates we've had in the past, I'm being quite
>>> reserved with pacing this debate, *precisely* because I know how
>>> intrusive it is. I'm spending some of my time trying to convince those
>>> who haven't said anything yet to contribute (even if they give it a -1)
>>> so that we can be more sure of our final decision, but for sure we
>>> *will* have to take a decision at some point.
>>>
>>> It's worth saying again, no final decisions have been taken, this is
>>> still a consultation for now - but we *do* need to consult with the
>>> users too. It's a far larger community, and I hope we'll get a nice
>>> collection of opinions from them to look through.
>>>
>>> Greg
>>>
>> --
>> 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.
>

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

[Dmitri Dolguikh]

> Given we are targeting Rails 5.1 for the SCL we are building and it's the
> newest, does anything change here with using it?
>

The approach stays the same, I think. My bet would be the problems stay the
same too (i.e. use of MD5 in caches).


> I have heard that the teams that work on those backend projects we use
> are/have looked into FIPS compliancy so we don't need to worry about that
> aspect.
>
> Sounds like we still need to look at the installer to ensure Kafo, Puppet
> and the Puppet modules are all FIPS compliant?
>

Yes, although I'd imagine puppet itself is going to be ok, as long as
FIPS-compatible hash function is configured. Puppet modules have issues,
for example dhcpd and bind puppet modules might use MD5s, as those
dependencies are configured with MD5-based shared secrets.


I suppose we could tests for this? For example, if a user provides custom
> SSL certificates for the web server we could run a check and warn a user?
>

Before a certificate is installed, yes. Might get involved though (as most
things tend to when it comes to SSL/TLS and certificates).


> Is it possible to detect that a system is running in FIPS mode to only
> warn in that case?
>

Yes, it is possible to detect that a system is running in FIPS mode.


>
> How often do you see this CI job running? And I assume this would be
> temporary until we are fully FIPS compliant?
>

A few times a day at first -- to help resolve w/e issues we currently have.
After that -- w/e pattern/schedule we currently have or plan to have, in
other words, we run *all* CI in FIPS mode.


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

Re: [foreman-dev] Koji repo sync metadata problem

[Eric D Helms]

The update seems to have completed, with the new CentOS repository added to
Koji and repositories regenerated. For the moment, the
foreman-nightly*-rhel7-build tags have been updated to remove rhel as an
external repository and have been replaced with CentOS (7.4). If you notice
any oddities building, please let us know so we can work through them.


Eric

On Thu, Nov 16, 2017 at 7:14 PM, Eric D Helms  wrote:

> I started an mrepo run after adding CentOS in a screen session. The run
> appears to be running a lot longer than previous and it's not clear to me
> what exactly it's doing at present or whats safe to do. Lukas could you
> check on it in your morning and see if you spot anything odd about why it
> seems to have stalled or slowed down?
>
> On Thu, Nov 16, 2017 at 6:01 AM, Ewoud Kohl van Wijngaarden <
> ew...@kohlvanwijngaarden.nl> wrote:
>
>> Those sound like good arguments, but if we don't test on older releases
>> then we don't know for sure they work either. IMHO it's acceptable to
>> explicitly only support EL 7.4 and up. We don't have the resources to
>> support older versions especially since CentOS doesn't support that either.
>> If users want verified working versions on EL < 7.4 then they should either
>> help us properly support it or buy support from a vendor that does want to
>> promise it works.
>>
>>
>> On Thu, Nov 16, 2017 at 08:56:39AM +0100, Lukas Zapletal wrote:
>>
>>> I would be against syncing regularly but I don't do much packaging so
>>> it's up to you. The problem I see is "random" breakage. You come to
>>> work on Monday after sync and if you don't realize the package was
>>> deleted from EPEL, you can burn hour or something to figure it out
>>> sometimes. This was pretty clear case but as you know there are
>>> situations (SCL) when it is not that clear.
>>>
>>> If we ever deploy new koji, I'd vote to avoid getting OS updates
>>> completely, just base channels and explicit updates when we need it.
>>> We need reproducible builds, with autosync we are not getting it.
>>>
>>> One note, if we sync CentOS or RHEL base to particular version,
>>> chances are that SELinux won't load on older releases. So basically we
>>> must be ready to do minimum requirements change here.
>>>
>>> Thanks for solving the problem.
>>>
>>> LZ
>>>
>>> On Wed, Nov 15, 2017 at 10:05 PM, Ewoud Kohl van Wijngaarden
>>>  wrote:
>>>
 I think we should sync & update. CentOS has no concept of supported
 minor
 releases and we should be testing with a supported release.


 On Wed, Nov 15, 2017 at 03:57:40PM -0500, Eric D Helms wrote:

>
> This now appears to be working again. One out standing question that
> affects nodejs- packaging builds.
>
> As part of the RHEL 7.4 release, http-parser was removed from EPEL.
> With
> this latest round of Koji external repositories update we now have a
> newer
> EPEL with this package removed. We did not update our CentOS external
> repository that would include this package. Not updating the base OS
> has
> been our policy for a while now it would seem. We have two options:
>
> 1) Sync and update CentOS
> 2) Add http-parser to the overrides tag for foreman-nightly
>
> On Wed, Nov 15, 2017 at 2:11 PM, Eric D Helms 
> wrote:
>
> I had forgotten to run the repo-regen on Koji. That is finishing up
>> now.
>> I
>> will run another test after and report back.
>>
>> On Wed, Nov 15, 2017 at 2:08 PM, Patrick Creech 
>> wrote:
>>
>> On Wed, 2017-11-15 at 14:00 -0500, Patrick Creech wrote:
>>> > On Wed, 2017-11-15 at 19:56 +0100, Lukas Zapletal wrote:
>>> > > I do not have access here, can someone take a look? Are repodata
>>> > > present for EPEL7?
>>> >
>>> > If I have the correct path, it does not appear so:
>>> >
>>> > [root@koji repodata]# pwd
>>> > /mnt/koji/external-repos/epel7-x86_64/epel/repodata
>>> > [root@koji repodata]# ls
>>> > [root@koji repodata]#
>>> >
>>>
>>> I might not have, this path DOES have repodata:
>>>
>>> /mnt/koji/external-repos/www/epel7-x86_64/RPMS.epel/repodata
>>>
>>> > > LZ
>>> > >
>>> > > On Wed, Nov 15, 2017 at 6:15 PM, Ewoud Kohl van Wijngaarden
>>> > >  wrote:
>>> > > > I still get errors when building:
>>> > > >
>>> > > > http://koji.katello.org/koji/taskinfo?taskID=52363
>>> > > > http://koji.katello.org/kojifiles/work/tasks/2363/52363/root
>>> .log
>>> > > >
>>> > > > DEBUG util.py:439:  Error downloading packages:
>>> > > > DEBUG util.py:439:1:nodejs-6.10.3-1.el7.x86_64: failed to
>>> retrieve
>>> > > > nodejs-6.10.3-1.el7.x86_64.rpm from build
>>> > > > DEBUG util.py:439:  error was [Errno 2] Local file does not
>>> exist:
>>> > > > 

Re: [foreman-dev] CDN for the theforeman.org

[Neil Hanlon]

Heavy fastly user here :)

Let me know what you need (or we can chat on freenode if you want)

On Fri, Nov 17, 2017 at 10:14 AM Greg Sutcliffe 
wrote:

> Hi all,
>
> I've signed the contact with our newest sponsor, Fastly, and we now have
> a CDN available for us to use on our web host. This comes with a single
> wildcard certificate, so we should be able to use it for all the vhosts
> on there (yum.tf, deb.tf, etc)
>
> Being entirely honest, I've never set up a CDN before though, so do we
> have anyone in the community who has?
>
> BTW, big thanks to Evgeni (Zhenech) for his help in getting this sorted!
>
> Greg
>
> --
> 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.

[foreman-dev] CDN for the theforeman.org

[Greg Sutcliffe]

Hi all,

I've signed the contact with our newest sponsor, Fastly, and we now have
a CDN available for us to use on our web host. This comes with a single
wildcard certificate, so we should be able to use it for all the vhosts
on there (yum.tf, deb.tf, etc)

Being entirely honest, I've never set up a CDN before though, so do we
have anyone in the community who has?

BTW, big thanks to Evgeni (Zhenech) for his help in getting this sorted!

Greg

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


signature.asc
Description: OpenPGP digital signature

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

[Eric D Helms]

Awesome investigation, explanation and ideas on how we can stay compliant
once we reach that milestone. I have a few specific questions in-line:

On Thu, Nov 16, 2017 at 1:35 PM, Dmitri Dolguikh 
wrote:

> What is FIPS?
> From Wikipedia [1]: The Federal Information Processing Standard (FIPS)
> Publication 140-2, (FIPS PUB 140-2), is a U.S. government computer
> security standard used to approve cryptographic modules. The title is
> Security Requirements for Cryptographic Modules.
>
> What are Implications of FIPS 140-2 Support for Foreman, Katello, and
> Smart-Proxy?
> Linux system, or rather an SSL library in FIPS-compatible mode will
> only have a set of ciphers and hash functions compatible with FIPS.
> [2] contains the list of approved cryptographic functions, Oracle
> graciously compiled the list of not approved ones, which is more
> useful and can be found at [3].
>
>
> OpenSSL in FIPS mode
> My understanding is that only OpenSSL versions 1.0.1 and 1.0.2 have
> FIPS 140-2 validated cryptographic modules. OpenSSL raises ABRT signal
> when it receives a call to one of the unapproved ciphers/functions.
>
>
> Foreman in FIPS mode
> I haven’t looked at pulp, candlepin, qpid, goferd, etc, and at point
> don’t know how and if these can be made to work in FIPS mode. All
> tests I’ve done so far were against Rails 5.0, Considering the number
> of dependencies, we will need to limit FIPS support to just one
> version of Rails.
>

Given we are targeting Rails 5.1 for the SCL we are building and it's the
newest, does anything change here with using it? I have heard that the
teams that work on those backend projects we use are/have looked into FIPS
compliancy so we don't need to worry about that aspect.

Sounds like we still need to look at the installer to ensure Kafo, Puppet
and the Puppet modules are all FIPS compliant?


>
> Rails and other (ruby) dependencies.
> MD5 is used (hard-coded) in a few places in Rails, at this point I’m
> quite certain that its use is constrained to various built-in caches.
> I had to disable *all* Rails caches to be able to run Foreman in FIPS
> mode. Additionally, strong ETAG’s cannot be used, I’m not sure if they
> are used, or there are plans for them.
> Spring uses MD5 to generate application ID, but will use one in
> SPRING_APPLICATION_ID environment variable if it’s available.
> Gravatar uses MD5 hashes in their urls, doesn’t look like other hashes
> are supported.
> I think apipie cache uses MD5, but I will need to verify this.
>

> Foreman
> app/services/password_crypt uses MD5 for grub2 passwords, which will
> need to be switched to SHA512. MD5 will need to be removed from the
> list of hash functions
> SshKey#generate_fingerprint, call to SSHKey.fingerprint uses MD5
>
> A note: with caching disabled, and issues above fixed, I was able to
> get Foreman suite of tests to pass, and get Foreman to start.
>
> Smart-Proxy
> Smart-Proxy codebase appears to be compatible with FIPS (ran and
> passed tests ok without any changes), but there are issues with
> external depdencies.
>
> DHCPD uses MD5-based omapi shared secret. DHCPD shared secret with
> bind is also md5-based.
> BIND when used with dhcpd uses MD5 hashes stored in TXT as host id.
> Puppet needs to be run in FIPS mode (FIPS-compatible hash function
> needs to be configured). I assume this covers all of puppet, including
> mcollective, puppet run, puppetca.
> BMC/IPMI authentication can use MD5 or lower based hashes, older
> clients may not have newer hash functions.
> Salt appears to use MD5 hashes by default, individual nodes must be
> configured to use other hash_type
>
> Any 3rd party SSL certificates that may need to be verified or decoded
> by either Foreman or Smart-Proxy must be generated using
> FIPS-compatible algorithms/hash functions.
>

I suppose we could tests for this? For example, if a user provides custom
SSL certificates for the web server we could run a check and warn a user?
Is it possible to detect that a system is running in FIPS mode to only warn
in that case?


>
> How we can reach FIPS compatibility
> The easiest first step would be to replace offending cryptographic and
> hash functions in Foreman, and in Smart-Proxy case, 3rd party
> configuration files with FIPS-compatible ones. Additionally, any new
> code changes that employ MD5 or other non approved functions shouldn’t
> be accepted.
> The next step would be to create a CI job that will continuously
> execute the the full suite of tests on a VM with FIPS mode enabled.
> GDB configured with Ruby’s project .gdbinit [4] and a tiny batch [5]
> of commands can be used to report on FIPS-related failures.
>

How often do you see this CI job running? And I assume this would be
temporary until we are fully FIPS compliant?


> Considering the amount of dependencies Foreman and Smart-Proxy have, I
> think would be useful to have all CI environments switched to run in
> FIPS mode: this should increase the probability of