Re: Removal of krb5-devel from "stable" F29 buidroot broke my package

[Tomas Mraz]

On Thu, 2019-05-16 at 07:50 +0200, Vít Ondruch wrote:
> Dne 15. 05. 19 v 17:29 Dominique Martinet napsal(a):
> > Michal Schorm wrote on Wed, May 15, 2019 at 05:14:23PM +0200:
> > > Another possible cause came up my mind.
> > > 
> > > Another package in the buildroot could have brought it as a
> > > dependency, but does not bring it anymore ?
> > Yeah, it used to come with openssl-devel, but got removed very
> > recently:
> > https://src.fedoraproject.org/rpms/openssl/c/7a654fc69c499b54f38543ca40f765fbaf9bdf84
> > 
> 
> This was removed on my request, triggered by this PR [1].
> Nevertheless I
> concur that this should happen just in Rawhide and never be
> backported
> into stable releases.

Well... that's debatable. There is no promise that the stable releases
won't break broken packages working only accidentaly. The fix is simple
add the proper build dependency if you need it and do not depend on it
being pulled in by something else.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: sign_and_send_pubkey: signing failed: agent refused operation

[Jakub Jelen]

On Thu, 2019-05-16 at 10:09 -0700, Brian C. Lane wrote:
> On Wed, May 15, 2019 at 05:09:41PM -0400, Steve Dickson wrote:
> > Hello,
> > 
> > I'm getting the following error when I'm access the fedora git
> > trees.
> > 
> > sign_and_send_pubkey: signing failed: agent refused operation
> > ste...@pkgs.fedoraproject.org: Permission denied (publickey).
> > fatal: Could not read from remote repository.
> > 
> > Please make sure you have the correct access rights
> > and the repository exists.
> > 
> > Now I know I have the correct publickey (id_rsa/id_rsa.pub)
> > because they work on a different host. and generally 
> > when I have the wrong keys, I get the above error minus
> > 
> > sign_and_send_pubkey: signing failed: agent refused operation
> > 
> > Any idea what is happening? 
> 
> Do you have multiple keys loaded? ISTR hitting this when I had a
> large
> number of different keys and it would hit a limit trying them. In my
> ~/.ssh/config I have this:
> 
> HOST *.fedoraproject.org fedorapeople.org *.fedorahosted.org
> fedorahosted.org
> IdentityFile ~/.ssh/fedora
> 
> to force it to use the right key on the 1st try.

No, this would be different error from server saying too many
authentication attempts.

Regards,
-- 
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: arm03-packager00: wrong Rawhide mock config

[Mikolaj Izdebski]

On Fri, May 17, 2019 at 5:22 AM Jerry James  wrote:
>
> Where should problem reports with the test machines be directed?  I
> can't build for Rawhide in mock on arm03-packager00 because
> /etc/mock/fedora-rawhide-armhfp.cfg refers to Fedora 30.  The correct
> config is in /etc/mock/fedora-rawhide-armhfp.cfg.rpmnew.  Can somebody
> with admin privileges fix that up, please?

Thanks for the report. I've fixed the problem.

Issues with maintainer test machines should be reported to the
respective contact listed on the wiki page [1], in this case
ad...@fedoraproject.org

--
Mikolaj Izdebski

[1] 
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: xindy, texlive, and concurrency

[Miro Hrončok]

On 17. 05. 19 3:54, Jerry James wrote:

And, going off on a really steep tangent, I was just reading about
Flock and wishing I could go.  I've been hanging around the Fedora
community for something on the order of 14 years now, believe it or
not, and I have yet to meet a single other Fedora contributor in
person.  There's no way I'm going to make it to Hungary, I'm afraid.
What is coming up in North America in the next year or so that will
have significant numbers of Fedorans present?  I would love to put
some faces to the names I've been seeing on my screen all these years.


Would love to meet you Jerry!
I think that next Flock after Hungary is supposed to happen in NA.

It normally rotates between NA and Europe every year, but a shift in schedule 
was needed, hence 2019 is in Europe again, so 2020 can be in NA.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Announcing Fedora CI SIG

[Aleksandra Fedorova]

Hi, all,

I'd like to announce a Fedora Special Interest Group dedicated to the
topics of Continuous Integration, Continuous Delivery, Gating and
everything.

I've created a wiki page with the initial data:

https://fedoraproject.org/wiki/SIGs/CI

Please join, add yourself to member list, bring your ideas and work items.

I'd like to also setup a bi-weekly IRC meeting, so please think about what
time would work best for you. Let's have a separate discussion on that next
week.

Feedback is welcome.


Quote from the wiki:

== Goal ==

The goal of the SIG is to bring together CI enthusiasts interested in
developing tools, best practices, standards, and workflows to implement
Continuous Integration at a larger scale.

While CI is well-known and used by many software projects, it is usually
applied at an individual component level. Scaling it up is a challenge from
both technical and organizational points of view. Here in Fedora, we have
an opportunity to explore and develop the CI/CD topic beyond simple
pull-request testing.

== Topics ==

* CI for Fedora
* Containerized CI
* CI on bare-metal
* Gating at scale
* Packaging and CI
* CI and Upstream
* CI engines, Artifact storages, Test analytics

== Benefit to Fedora ==

CI is rarely associated with packaged Linux distributions even though it is
nowadays used in most of them. We’d like to change this perception, to show
that packaging and CI can and should be used together.

We also would like to establish Fedora as a perfect CI platform.
Virtualization, containerization and many other tools available in Fedora
provide a good foundation to build flexible, open and modern CI solutions
and CI architectures on top of it. Let's make use of them.

-- 
Aleksandra Fedorova
bookwar on IRC
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

[Stephen Gallagher]

On Thu, May 16, 2019 at 2:54 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/DisableRootPasswordLoginInSshd
>
> == Summary ==
> The upstream OpenSSH disabled password logins for root back in 2015.
> The Fedora should follow to keep security expectation and avoid users
> surprises with this configuration.
>
> == Owner ==
> * Name: [[User:jjelen| Jakub Jelen]], OpenSSH maintainer
> * Email: jje...@redhat.com
>
> == Detailed Description ==
>
> The OpenSSH server configuration contains a configuration option
> `PermitRootLogin`, which controls whether the root user is allowed to
> login using passwords or using public key authentication. The root
> login is target of most of the random or targeted attack on Linux
> systems and password is usually the weakest part. For that reason, the
> upstream OpenSSH changed this option in 2015 to `prohibit-password`,
> which still allows public-key authentication, but prevents the
> password logins. Fedora was for many practical reasons keeping the old
> configuration since then, but the difference is no longer bearable and
> might confuse users expecting the root logins will not be enabled out
> of the box.
>
> On the other hand, there is still a lot of infrastructure, installers
> and test instances that simply might depend on this configuration and
> therefore this change needs to go through the system-wide change so
> everyone is onboard.
>
> == Benefit to Fedora ==
>
> This will provide more secure Fedora installations out of the box and
> prevent inadvertently accessible root logins in the wild.
>

I'm not particularly *opposed* to this change in behavior, but in the
Fedora Server case, SSH is the primary mechanism for gaining access to
the system. If we disallow password logins for root, then many
installs will be inaccessible and users will get... grumpy.

There aren't really any major problems for interactive installs where
the user has direct console access, so I'll disregard that case for
the moment. For kickstart-based installs, I suppose users would
normally know to put their SSH public keys in place, so that's also
less of a concern.

The problematic case I see is the remote VNC headless install. The
installation is interactive, but there may not be a way to gain direct
access to the installed system after that. We need to ensure that the
resulting system is always accessible. Right now, the interactive
installer would allow us (even encourage us) to set up that machine
with only a root user and password, which after this Change would mean
that the system is not reachable.

I see some possible options here, all requiring Anaconda changes:
1) Provide a checkbox in the root user creation spoke (defaulting to
"off") to enable root password logins over SSH. Ideally with notes
about why it's recommended not to do this.
2) Allow users to provide a public SSH key for the root user. Since
this is generally not performed in an environment where the keys can
be copy-pasted, we'd probably need to allow specifying a [tiny]URL for
an authorized_keys file.
3) Force Anaconda to require the creation of a non-root user that is a
member of the `wheel` group, so that this user can be used to SSH in
and administer the system. Essentially, remove the root user creation
spoke as an option from the interactive install.
4) Force Cockpit to be installed and available on any system that
doesn't select a non-root user at installation time. This will allow a
password-based login and allows the root user to set up their SSH keys
via the "Accounts" tab.

I'm all for hearing what other options we may have here, but those are
the simplest ones I can think of.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

[Martin Kolman]

On Fri, 2019-05-17 at 08:23 -0400, Stephen Gallagher wrote:
> On Thu, May 16, 2019 at 2:54 PM Ben Cotton  wrote:
> > https://fedoraproject.org/wiki/Changes/DisableRootPasswordLoginInSshd
> > 
> > == Summary ==
> > The upstream OpenSSH disabled password logins for root back in 2015.
> > The Fedora should follow to keep security expectation and avoid users
> > surprises with this configuration.
> > 
> > == Owner ==
> > * Name: [[User:jjelen| Jakub Jelen]], OpenSSH maintainer
> > * Email: jje...@redhat.com
> > 
> > == Detailed Description ==
> > 
> > The OpenSSH server configuration contains a configuration option
> > `PermitRootLogin`, which controls whether the root user is allowed to
> > login using passwords or using public key authentication. The root
> > login is target of most of the random or targeted attack on Linux
> > systems and password is usually the weakest part. For that reason, the
> > upstream OpenSSH changed this option in 2015 to `prohibit-password`,
> > which still allows public-key authentication, but prevents the
> > password logins. Fedora was for many practical reasons keeping the old
> > configuration since then, but the difference is no longer bearable and
> > might confuse users expecting the root logins will not be enabled out
> > of the box.
> > 
> > On the other hand, there is still a lot of infrastructure, installers
> > and test instances that simply might depend on this configuration and
> > therefore this change needs to go through the system-wide change so
> > everyone is onboard.
> > 
> > == Benefit to Fedora ==
> > 
> > This will provide more secure Fedora installations out of the box and
> > prevent inadvertently accessible root logins in the wild.
> > 
> 
> I'm not particularly *opposed* to this change in behavior, but in the
> Fedora Server case, SSH is the primary mechanism for gaining access to
> the system. If we disallow password logins for root, then many
> installs will be inaccessible and users will get... grumpy.
> 
> There aren't really any major problems for interactive installs where
> the user has direct console access, so I'll disregard that case for
> the moment. For kickstart-based installs, I suppose users would
> normally know to put their SSH public keys in place, so that's also
> less of a concern.
> 
> The problematic case I see is the remote VNC headless install. The
> installation is interactive, but there may not be a way to gain direct
> access to the installed system after that. We need to ensure that the
> resulting system is always accessible. Right now, the interactive
> installer would allow us (even encourage us) to set up that machine
> with only a root user and password, which after this Change would mean
> that the system is not reachable.
> 
> I see some possible options here, all requiring Anaconda changes:
> 1) Provide a checkbox in the root user creation spoke (defaulting to
> "off") to enable root password logins over SSH. Ideally with notes
> about why it's recommended not to do this.
> 2) Allow users to provide a public SSH key for the root user. Since
> this is generally not performed in an environment where the keys can
> be copy-pasted, we'd probably need to allow specifying a [tiny]URL for
> an authorized_keys file.
> 3) Force Anaconda to require the creation of a non-root user that is a
> member of the `wheel` group, so that this user can be used to SSH in
> and administer the system. Essentially, remove the root user creation
> spoke as an option from the interactive install.
The current policy during ineractive install is, one of (or both) must exists:
- a root account that is not locked
- a user in the wheel group

This could be tweaked accordingly (eq. always require at least one user in the 
wheel
group regardless of the state of the root account).

> 4) Force Cockpit to be installed and available on any system that
> doesn't select a non-root user at installation time. This will allow a
> password-based login and allows the root user to set up their SSH keys
> via the "Accounts" tab.
> 
> I'm all for hearing what other options we may have here, but those are
> the simplest ones I can think of.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

[Mauricio Tavares]

On Fri, May 17, 2019 at 8:24 AM Stephen Gallagher  wrote:
>
> On Thu, May 16, 2019 at 2:54 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/DisableRootPasswordLoginInSshd
> >
> > == Summary ==
> > The upstream OpenSSH disabled password logins for root back in 2015.
> > The Fedora should follow to keep security expectation and avoid users
> > surprises with this configuration.
> >
> > == Owner ==
> > * Name: [[User:jjelen| Jakub Jelen]], OpenSSH maintainer
> > * Email: jje...@redhat.com
> >
> > == Detailed Description ==
> >
> > The OpenSSH server configuration contains a configuration option
> > `PermitRootLogin`, which controls whether the root user is allowed to
> > login using passwords or using public key authentication. The root
> > login is target of most of the random or targeted attack on Linux
> > systems and password is usually the weakest part. For that reason, the
> > upstream OpenSSH changed this option in 2015 to `prohibit-password`,
> > which still allows public-key authentication, but prevents the
> > password logins. Fedora was for many practical reasons keeping the old
> > configuration since then, but the difference is no longer bearable and
> > might confuse users expecting the root logins will not be enabled out
> > of the box.
> >
> > On the other hand, there is still a lot of infrastructure, installers
> > and test instances that simply might depend on this configuration and
> > therefore this change needs to go through the system-wide change so
> > everyone is onboard.
> >
> > == Benefit to Fedora ==
> >
> > This will provide more secure Fedora installations out of the box and
> > prevent inadvertently accessible root logins in the wild.
> >
>
> I'm not particularly *opposed* to this change in behavior, but in the
> Fedora Server case, SSH is the primary mechanism for gaining access to
> the system. If we disallow password logins for root, then many
> installs will be inaccessible and users will get... grumpy.
>
> There aren't really any major problems for interactive installs where
> the user has direct console access, so I'll disregard that case for
> the moment. For kickstart-based installs, I suppose users would
> normally know to put their SSH public keys in place, so that's also
> less of a concern.
>
> The problematic case I see is the remote VNC headless install. The
> installation is interactive, but there may not be a way to gain direct
> access to the installed system after that. We need to ensure that the
> resulting system is always accessible. Right now, the interactive
> installer would allow us (even encourage us) to set up that machine
> with only a root user and password, which after this Change would mean
> that the system is not reachable.
>
> I see some possible options here, all requiring Anaconda changes:

  What would be the fail-safe setting if any?

> 1) Provide a checkbox in the root user creation spoke (defaulting to
> "off") to enable root password logins over SSH. Ideally with notes
> about why it's recommended not to do this.

  Which could be shown in a popup "Do you really want to do this?"
 window of sorts.

> 2) Allow users to provide a public SSH key for the root user. Since
> this is generally not performed in an environment where the keys can
> be copy-pasted, we'd probably need to allow specifying a [tiny]URL for
> an authorized_keys file.

  Or pipe it using netcat/something.

> 3) Force Anaconda to require the creation of a non-root user that is a
> member of the `wheel` group, so that this user can be used to SSH in
> and administer the system. Essentially, remove the root user creation
> spoke as an option from the interactive install.

  That seems similar to the approach adopted by ubuntu and it has
worked. With that said, I do not see the difference between ssh'ing
using an user in the wheel group vs root as both can do the same. But
that is me. Being able to tell who sudo'ed, yes.

> 4) Force Cockpit to be installed and available on any system that
> doesn't select a non-root user at installation time. This will allow a
> password-based login and allows the root user to set up their SSH keys
> via the "Accounts" tab.
>
> I'm all for hearing what other options we may have here, but those are
> the simplest ones I can think of.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.o

Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

[Stephen Gallagher]

On Fri, May 17, 2019 at 9:09 AM Mauricio Tavares  wrote:
>
> On Fri, May 17, 2019 at 8:24 AM Stephen Gallagher  wrote:
> > 3) Force Anaconda to require the creation of a non-root user that is a
> > member of the `wheel` group, so that this user can be used to SSH in
> > and administer the system. Essentially, remove the root user creation
> > spoke as an option from the interactive install.
>
>   That seems similar to the approach adopted by ubuntu and it has
> worked. With that said, I do not see the difference between ssh'ing
> using an user in the wheel group vs root as both can do the same. But
> that is me. Being able to tell who sudo'ed, yes.


There are two big advantages here:
1) As you pointed out, you have the sudo log to inform you of which
user took the action.
2) It confounds automated attack scripts. Unless your admin user has a
well-known or easily-guessable name, automated attacks will probably
not know what user to try. 'root' is a big target at least in part
because it always exists.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

[Stephen Gallagher]

On Fri, May 17, 2019 at 8:37 AM Martin Kolman  wrote:
>
> On Fri, 2019-05-17 at 08:23 -0400, Stephen Gallagher wrote:
> > 3) Force Anaconda to require the creation of a non-root user that is a
> > member of the `wheel` group, so that this user can be used to SSH in
> > and administer the system. Essentially, remove the root user creation
> > spoke as an option from the interactive install.
> The current policy during ineractive install is, one of (or both) must exists:
> - a root account that is not locked
> - a user in the wheel group
>
> This could be tweaked accordingly (eq. always require at least one user in 
> the wheel
> group regardless of the state of the root account).
>

I might not have been clear in my original email. My point was mainly
that I want these problems identified, a solution agreed-upon and
added to the Change Proposal before it goes to a FESCo vote. I'd be
inclined to vote -1 without a plan in place to deal with this. This is
indeed probably the least-intrusive change we can make (and aligns us
a little closer to how other popular distros are doing things these
days), and if Anaconda team is willing to commit to doing that work
here, that would be great.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Schedule for Friday's FESCo Meeting (2019-05-17)

[Petr Šabata]

Following is the list of topics that will be discussed in the
FESCo meeting Friday at 15:00UTC in #fedora-meeting on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2019-05-17 15:00 UTC'

Links to all issues to be discussed can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= Followups =

#topic #2128 Policy needed: Modules built against EOL Fedora releases
.fesco 2128
https://pagure.io/fesco/issue/2128

= New business =

#topic #2127 Election Interview Questions — FESCo (Jun 2019) 
.fesco 2127
https://pagure.io/fesco/issue/2127

= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Atomic Host Two Week Release Announcement: 29.20190516.0

[Dusty Mabe]

On 5/16/19 6:27 PM, nore...@fedoraproject.org wrote:
> 
> A new Fedora Atomic Host update is available via an OSTree update:
> 
> Version: 29.20190516.0
> Commit(x86_64): 
> 7f719bf60b865ca96aacd0e8ae3e6074c7eb5783d8ceb9003dbba5dfd5a29ba3
> Commit(aarch64): 
> 3930a03b8ffcce1aa66f17b8811e2a4da80aedb8234a1f47b62d603986b580ec
> Commit(ppc64le): 
> 144bb02d1485234b79ba385b47dc64199a7df159d3a0a3f17837cc7fb90cf7e1
> 
> 
> We are releasing images from multiple architectures but please note
> that x86_64 architecture is the only one that undergoes automated
> testing at this time.
> 
> Existing systems can be upgraded in place via e.g. `atomic host upgrade`.
> 
> Corresponding image media for new installations can be downloaded from:
> 
> https://getfedora.org/en/atomic/download/
> 
> Alternatively, image artifacts can be found at the following links:
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190516.0.aarch64.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190516.0.aarch64.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20190516.0.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190516.0.ppc64le.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190516.0.ppc64le.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20190516.0.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190516.0.x86_64.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190516.0.x86_64.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190516.0.x86_64.vagrant-libvirt.box
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190516.0.x86_64.vagrant-virtualbox.box
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20190516.0.iso
> 
> Respective signed CHECKSUM files can be found here:
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190516.0-aarch64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20190516.0-aarch64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190516.0-ppc64le-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20190516.0-ppc64le-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190516.0-x86_64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190516.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20190516.0-x86_64-CHECKSUM
> 
> For direct download, the "latest" targets are always available here:
> x86_64:
> https://getfedora.org/atomic_qcow2_x86_64_latest
> https://getfedora.org/atomic_raw_x86_64_latest
> https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest
> https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest
> https://getfedora.org/atomic_dvd_ostree_x86_64_latest
> 
> aarch64:
> https://getfedora.org/atomic_qcow2_aarch64_latest
> https://getfedora.org/atomic_raw_aarch64_latest
> https://getfedora.org/atomic_dvd_ostree_aarch64_latest
> 
> ppc64le:
> https://getfedora.org/atomic_qcow2_ppc64le_latest
> https://getfedora.org/atomic_raw_ppc64le_latest
> https://getfedora.org/atomic_dvd_ostree_ppc64le_latest
> 
> Filename fetching URLs are available here:
> x86_64:
> https://getfedora.org/atomic_qcow2_x86_64_latest_filename
> https://getfedora.org/atomic_raw_x86_64_latest_filename
> https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename
> https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename
> https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename
> 
> aarch64:
> https://getfedora.org/atomic_qcow2_aarch64_latest_filename
> https://getfedora.org/atomic_raw_aarch64_latest_filename
> https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename
> 

[Test-Announce] Fedora 31 Rawhide 20190517.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 31 Rawhide 20190517.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20190514.n.0: anaconda-31.11-1.fc31.src, 20190517.n.0: 
anaconda-31.12-1.fc31.src
lorax - 20190514.n.0: lorax-31.5-1.fc31.src, 20190517.n.0: lorax-31.6-1.fc31.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/31

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190517.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190517.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190517.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190517.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190517.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190517.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190517.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

[Julen Landa Alustiza]

We are not disabling root access entirely, you can log on local console or
use su after loging with a normal user.

After installing server without the proposed changes (that could be great,
but not needed) you can log in with the normal user and use su to scalate
privileges and either change sshd_config or add a pubkey on authorized_keys.

Right now we will need a normal user to be able to access as root after a
remote install, but it does not neccesary need to be part of wheel (I
believe that su is not restricted)

Just a root user and not a regular one will finish with a box that is not
accesible remotely and that could be a problem

Stephen Gallagher  igorleak hau idatzi zuen (2019 mai.
17, or. 16:20):

> On Fri, May 17, 2019 at 8:37 AM Martin Kolman  wrote:
> >
> > On Fri, 2019-05-17 at 08:23 -0400, Stephen Gallagher wrote:
> > > 3) Force Anaconda to require the creation of a non-root user that is a
> > > member of the `wheel` group, so that this user can be used to SSH in
> > > and administer the system. Essentially, remove the root user creation
> > > spoke as an option from the interactive install.
> > The current policy during ineractive install is, one of (or both) must
> exists:
> > - a root account that is not locked
> > - a user in the wheel group
> >
> > This could be tweaked accordingly (eq. always require at least one user
> in the wheel
> > group regardless of the state of the root account).
> >
>
> I might not have been clear in my original email. My point was mainly
> that I want these problems identified, a solution agreed-upon and
> added to the Change Proposal before it goes to a FESCo vote. I'd be
> inclined to vote -1 without a plan in place to deal with this. This is
> indeed probably the least-intrusive change we can make (and aligns us
> a little closer to how other popular distros are doing things these
> days), and if Anaconda team is willing to commit to doing that work
> here, that would be great.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

[Julen Landa Alustiza]

Sorry, I'm in mobile and I miss send the draft :S

I'm not sure if it's clear: we don't really need so many constraints on
anaconda. (active root with pass and regular user) or regular user on wheel
group would be enough to elevate privileges on a just installed box remotely

Julen Landa Alustiza  igorleak hau idatzi zuen (2019
mai. 17, or. 16:40):

> We are not disabling root access entirely, you can log on local console or
> use su after loging with a normal user.
>
> After installing server without the proposed changes (that could be great,
> but not needed) you can log in with the normal user and use su to scalate
> privileges and either change sshd_config or add a pubkey on authorized_keys.
>
> Right now we will need a normal user to be able to access as root after a
> remote install, but it does not neccesary need to be part of wheel (I
> believe that su is not restricted)
>
> Just a root user and not a regular one will finish with a box that is not
> accesible remotely and that could be a problem
>
> Stephen Gallagher  igorleak hau idatzi zuen (2019
> mai. 17, or. 16:20):
>
>> On Fri, May 17, 2019 at 8:37 AM Martin Kolman  wrote:
>> >
>> > On Fri, 2019-05-17 at 08:23 -0400, Stephen Gallagher wrote:
>> > > 3) Force Anaconda to require the creation of a non-root user that is a
>> > > member of the `wheel` group, so that this user can be used to SSH in
>> > > and administer the system. Essentially, remove the root user creation
>> > > spoke as an option from the interactive install.
>> > The current policy during ineractive install is, one of (or both) must
>> exists:
>> > - a root account that is not locked
>> > - a user in the wheel group
>> >
>> > This could be tweaked accordingly (eq. always require at least one user
>> in the wheel
>> > group regardless of the state of the root account).
>> >
>>
>> I might not have been clear in my original email. My point was mainly
>> that I want these problems identified, a solution agreed-upon and
>> added to the Change Proposal before it goes to a FESCo vote. I'd be
>> inclined to vote -1 without a plan in place to deal with this. This is
>> indeed probably the least-intrusive change we can make (and aligns us
>> a little closer to how other popular distros are doing things these
>> days), and if Anaconda team is willing to commit to doing that work
>> here, that would be great.
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

[Stephen John Smoogen]

On Fri, 17 May 2019 at 10:41, Julen Landa Alustiza 
wrote:

> We are not disabling root access entirely, you can log on local console or
> use su after loging with a normal user.
>
>
So a lot of sites have set up that you remotely kickstart a system and then
ansible in as root with the rest of the configurations. It is the biggest
reason we have been keeping this as active for a long time.  You are
breaking all those configs with a 'oh you can just login on a local
console'. That kickstart may not have any of that..  and the last thing a
sysadmin wants when they are building 4000 nodes somewhere is find out that
they need to add another 20 steps to their post..

Make it a predefined kickstart thing they can do so all they have to do is
add a line in it that says

ssh_remote --user= --keyfile= --yesIwantrootandIknowitsbad

and you have covered your bases. Turning off expected options in the name
of security sounds great and easy.. and the one thing I have learned in
computer security is that is the siren song which dashes your ship on the
rocks of pissed off system administrators.




> After installing server without the proposed changes (that could be great,
> but not needed) you can log in with the normal user and use su to scalate
> privileges and either change sshd_config or add a pubkey on authorized_keys.
>
> Right now we will need a normal user to be able to access as root after a
> remote install, but it does not neccesary need to be part of wheel (I
> believe that su is not restricted)
>
> Just a root user and not a regular one will finish with a box that is not
> accesible remotely and that could be a problem
>
> Stephen Gallagher  igorleak hau idatzi zuen (2019
> mai. 17, or. 16:20):
>
>> On Fri, May 17, 2019 at 8:37 AM Martin Kolman  wrote:
>> >
>> > On Fri, 2019-05-17 at 08:23 -0400, Stephen Gallagher wrote:
>> > > 3) Force Anaconda to require the creation of a non-root user that is a
>> > > member of the `wheel` group, so that this user can be used to SSH in
>> > > and administer the system. Essentially, remove the root user creation
>> > > spoke as an option from the interactive install.
>> > The current policy during ineractive install is, one of (or both) must
>> exists:
>> > - a root account that is not locked
>> > - a user in the wheel group
>> >
>> > This could be tweaked accordingly (eq. always require at least one user
>> in the wheel
>> > group regardless of the state of the root account).
>> >
>>
>> I might not have been clear in my original email. My point was mainly
>> that I want these problems identified, a solution agreed-upon and
>> added to the Change Proposal before it goes to a FESCo vote. I'd be
>> inclined to vote -1 without a plan in place to deal with this. This is
>> indeed probably the least-intrusive change we can make (and aligns us
>> a little closer to how other popular distros are doing things these
>> days), and if Anaconda team is willing to commit to doing that work
>> here, that would be great.
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

[Julen Landa Alustiza]

If someone is remotely installing with kickstart on a non interactive way I
assume they have enough knownledge to modify that ks to either add a pubkey
to root or modify sshd_config

Anyhow yeah, would be great to help making this easy with a ks default, or
macros

Stephen John Smoogen  igorleak hau idatzi zuen (2019 mai.
17, or. 17:10):

>
>
> On Fri, 17 May 2019 at 10:41, Julen Landa Alustiza 
> wrote:
>
>> We are not disabling root access entirely, you can log on local console
>> or use su after loging with a normal user.
>>
>>
> So a lot of sites have set up that you remotely kickstart a system and
> then ansible in as root with the rest of the configurations. It is the
> biggest reason we have been keeping this as active for a long time.  You
> are breaking all those configs with a 'oh you can just login on a local
> console'. That kickstart may not have any of that..  and the last thing a
> sysadmin wants when they are building 4000 nodes somewhere is find out that
> they need to add another 20 steps to their post..
>
> Make it a predefined kickstart thing they can do so all they have to do is
> add a line in it that says
>
> ssh_remote --user= --keyfile= --yesIwantrootandIknowitsbad
>
> and you have covered your bases. Turning off expected options in the name
> of security sounds great and easy.. and the one thing I have learned in
> computer security is that is the siren song which dashes your ship on the
> rocks of pissed off system administrators.
>
>
>
>
>> After installing server without the proposed changes (that could be
>> great, but not needed) you can log in with the normal user and use su to
>> scalate privileges and either change sshd_config or add a pubkey on
>> authorized_keys.
>>
>> Right now we will need a normal user to be able to access as root after a
>> remote install, but it does not neccesary need to be part of wheel (I
>> believe that su is not restricted)
>>
>> Just a root user and not a regular one will finish with a box that is not
>> accesible remotely and that could be a problem
>>
>> Stephen Gallagher  igorleak hau idatzi zuen (2019
>> mai. 17, or. 16:20):
>>
>>> On Fri, May 17, 2019 at 8:37 AM Martin Kolman 
>>> wrote:
>>> >
>>> > On Fri, 2019-05-17 at 08:23 -0400, Stephen Gallagher wrote:
>>> > > 3) Force Anaconda to require the creation of a non-root user that is
>>> a
>>> > > member of the `wheel` group, so that this user can be used to SSH in
>>> > > and administer the system. Essentially, remove the root user creation
>>> > > spoke as an option from the interactive install.
>>> > The current policy during ineractive install is, one of (or both) must
>>> exists:
>>> > - a root account that is not locked
>>> > - a user in the wheel group
>>> >
>>> > This could be tweaked accordingly (eq. always require at least one
>>> user in the wheel
>>> > group regardless of the state of the root account).
>>> >
>>>
>>> I might not have been clear in my original email. My point was mainly
>>> that I want these problems identified, a solution agreed-upon and
>>> added to the Change Proposal before it goes to a FESCo vote. I'd be
>>> inclined to vote -1 without a plan in place to deal with this. This is
>>> indeed probably the least-intrusive change we can make (and aligns us
>>> a little closer to how other popular distros are doing things these
>>> days), and if Anaconda team is willing to commit to doing that work
>>> here, that would be great.
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives:
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>
>
> --
> Stephen J Smoogen.
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedora

Fedora Rawhide-20190517.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Atomichost raw-xz x86_64
Atomichost qcow2 x86_64

Compose FAILS proposed Rawhide gating check!
6 of 47 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.cloud.all

Failed openQA tests: 11/146 (x86_64), 4/24 (i386), 1/2 (arm)

ID: 402075  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/402075
ID: 402092  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/402092
ID: 402103  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/402103
ID: 402104  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/402104
ID: 402105  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/402105
ID: 402117  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/402117
ID: 402118  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/402118
ID: 402128  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/402128
ID: 402130  Test: x86_64 universal install_anaconda_text **GATING**
URL: https://openqa.fedoraproject.org/tests/402130
ID: 402149  Test: x86_64 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/402149
ID: 402154  Test: x86_64 universal install_blivet_ext3
URL: https://openqa.fedoraproject.org/tests/402154
ID: 402160  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/402160
ID: 402173  Test: x86_64 universal install_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/402173
ID: 402207  Test: i386 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/402207
ID: 402212  Test: i386 universal install_blivet_ext3
URL: https://openqa.fedoraproject.org/tests/402212
ID: 402217  Test: i386 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/402217

Soft failed openQA tests: 3/24 (i386), 6/146 (x86_64)
(Tests completed, but using a workaround for a known bug)

ID: 402078  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/402078
ID: 402079  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/402079
ID: 402090  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/402090
ID: 402097  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/402097
ID: 402098  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/402098
ID: 402102  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/402102
ID: 402184  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/402184
ID: 402186  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/402186
ID: 402188  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/402188

Passed openQA tests: 119/146 (x86_64), 17/24 (i386)

Skipped gating openQA tests: 4/146 (x86_64)

ID: 402109  Test: x86_64 KDE-live-iso base_update_cli **GATING**
URL: https://openqa.fedoraproject.org/tests/402109
ID: 402110  Test: x86_64 KDE-live-iso base_system_logging **GATING**
URL: https://openqa.fedoraproject.org/tests/402110
ID: 402112  Test: x86_64 KDE-live-iso desktop_terminal **GATING**
URL: https://openqa.fedoraproject.org/tests/402112
ID: 402113  Test: x86_64 KDE-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/402113

Skipped non-gating openQA tests: 7 of 172
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Summary/Minutes from today's FESCo Meeting (2019-05-17)

[Petr Šabata]

===
#fedora-meeting: FESCO (2019-05-17)
===

Meeting started by contyk at 15:00:00 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2019-05-17/fesco.2019-05-17-15.00.log.html


Meeting summary
---
* init process  (contyk, 15:00:06)

* #2128 Policy needed: Modules built against EOL Fedora releases
  (contyk, 15:03:45)
  * LINK: https://pagure.io/fesco/issue/2128   (contyk, 15:03:49)
  * AGREED: Policy for modules in Fedora and EPEL is that all modules
being shipped in the stable repositories must have been built
against a currently-active release of Fedora, EPEL or Rawhide (+9,
0, -0)  (contyk, 15:34:08)

* #2127 Election Interview Questions — FESCo (Jun 2019)  (contyk,
  15:34:44)
  * LINK: https://pagure.io/fesco/issue/2127   (contyk, 15:34:48)
  * AGREED: The same set of questions will be used again (+5, 0, -0)
(contyk, 15:37:19)

* Next week's chair  (contyk, 15:37:38)
  * ACTION: sgallagh will chair next meeting  (contyk, 15:40:00)

* Open Floor  (contyk, 15:40:08)

Meeting ended at 15:55:36 UTC.


Action Items

* sgallagh will chair next meeting


Action Items, by person
---
* sgallagh
  * sgallagh will chair next meeting


People Present (lines said)
---
* contyk (103)
* sgallagh (58)
* bowlofeggs (43)
* mhroncok (39)
* nirik (25)
* zbyszek (18)
* zodbot (17)
* bookwar (8)
* jforbes (7)
* ignatenkobrain (4)
* bcotton (2)
* otaylor (0)


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora rawhide compose report: 20190517.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20190515.n.1
NEW: Fedora-Rawhide-20190517.n.0

= SUMMARY =
Added images:7
Dropped images:  3
Added packages:  11
Dropped packages:1
Upgraded packages:   86
Downgraded packages: 0

Size of added packages:  14.54 MiB
Size of dropped packages:2.41 MiB
Size of upgraded packages:   2.97 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -23.09 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20190517.n.0-sda.raw.xz
Image: Astronomy_KDE live i386
Path: Labs/i386/iso/Fedora-Astronomy_KDE-Live-i386-Rawhide-20190517.n.0.iso
Image: SoaS live i386
Path: Spins/i386/iso/Fedora-SoaS-Live-i386-Rawhide-20190517.n.0.iso
Image: LXDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXDE-armhfp-Rawhide-20190517.n.0-sda.raw.xz
Image: SoaS live x86_64
Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20190517.n.0.iso
Image: Minimal raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Minimal-Rawhide-20190517.n.0.aarch64.raw.xz
Image: LXQt raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20190517.n.0-sda.raw.xz

= DROPPED IMAGES =
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20190515.n.1.iso
Image: Design_suite live i386
Path: Labs/i386/iso/Fedora-Design_suite-Live-i386-Rawhide-20190515.n.1.iso
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20190515.n.1.iso

= ADDED PACKAGES =
Package: R-clisymbols-1.2.0-1.fc31
Summary: Unicode Symbols at the R Prompt
RPMs:R-clisymbols
Size:26.91 KiB

Package: R-ini-0.3.1-1.fc31
Summary: Read and Write '.ini' Files
RPMs:R-ini
Size:22.78 KiB

Package: R-parsedate-1.2.0-1.fc31
Summary: Recognize and Parse Dates in Various Formats
RPMs:R-parsedate
Size:317.14 KiB

Package: R-rappdirs-0.3.1-1.fc31
Summary: Determine Where to Save Data, Caches, and Logs
RPMs:R-rappdirs
Size:631.55 KiB

Package: R-xopen-1.0.0-1.fc31
Summary: Open System Files, 'URLs', Anything
RPMs:R-xopen
Size:24.41 KiB

Package: R-zeallot-0.1.0-1.fc31
Summary: Multiple, Unpacking, and Destructuring Assignment
RPMs:R-zeallot
Size:65.97 KiB

Package: igt-gpu-tools-1.23-1.20190516git555019f.fc31
Summary: Test suite and tools for DRM drivers
RPMs:igt-gpu-tools igt-gpu-tools-docs
Size:12.13 MiB

Package: nodejs-co-1:4.6.0-7.fc31
Summary: Generator async flow control goodness
RPMs:nodejs-co
Size:12.63 KiB

Package: python-mailmerge-1.9-1.fc31
Summary: Simple command line mail merge tool
RPMs:python3-mailmerge
Size:25.85 KiB

Package: quilter-1.8.4-2.20190425git5c7a1ca.fc31
Summary: Focus on your writing
RPMs:quilter
Size:1.28 MiB

Package: setconf-0.7.6-1.fc31
Summary: Utility for changing settings in configuration text files
RPMs:setconf
Size:32.14 KiB


= DROPPED PACKAGES =
Package: homerun-1.2.5-5.fc24
Summary: KDE Application Launcher
RPMs:homerun homerun-devel homerun-libs
Size:2.41 MiB


= UPGRADED PACKAGES =
Package:  R-IRkernel-1.0.1-2.fc31
Old package:  R-IRkernel-1.0.1-1.fc31
Summary:  Native R Kernel for the 'Jupyter Notebook'
RPMs: R-IRkernel
Size: 200.91 KiB
Size change:  -16 B
Changelog:
  * Thu May 16 2019 Elliott Sales de Andrade  - 
1.0.1-2
  - Make path to R in kernelspec truly noarch


Package:  R-gamlss.dist-5.1.4-1.fc31
Old package:  R-gamlss.dist-5.1.3-1.fc31
Summary:  Distributions for Generalized Additive Models for Location Scale 
and Shape
RPMs: R-gamlss.dist
Size: 19.32 MiB
Size change:  56.90 KiB
Changelog:
  * Wed May 15 2019 Elliott Sales de Andrade  - 
5.1.4-1
  - Update to latest version


Package:  R-rvest-0.3.4-1.fc31
Old package:  R-rvest-0.3.3-1.fc31
Summary:  Easily Harvest (Scrape) Web Pages
RPMs: R-rvest
Size: 918.00 KiB
Size change:  -324 B
Changelog:
  * Wed May 15 2019 Elliott Sales de Andrade  - 
0.3.4-1
  - Update to latest version


Package:  aime-8.20190516-1.fc31
Old package:  aime-8.20190416-1.fc31
Summary:  An application embeddable programming language interpreter
RPMs: aime aime-devel
Size: 3.85 MiB
Size change:  36.69 KiB
Changelog:
  * Thu May 16 2019 Filipe Rosset  - 8.20190516-1
  - Updated to new 8.20190516 upstream version, fixes rhbz #1706479


Package:  akmods-0.5.6-20.fc31
Old package:  akmods-0.5.6-19.fc31
Summary:  Automatic kmods build and install tool
RPMs: akmods
Size: 23.26 KiB
Size change:  132 B
Changelog:
  * Wed May 15 2019 Nicolas Vi??ville  - 0.5.6-20
  - Fix akmodsposttrans after kernel update/install on Fedora >= 28 and 
RHEL >= 7 - rhbz#1709055


Package:  apr-api-docs-1.7.0-1.fc31
Old package:  apr-api-docs-1.6.5-1.fc30
Summary:  Apache Portable Runtime API documenta

Re: Self Introduction: Jordan Ogas

[Daniel Walsh]

On 5/17/19 11:15 AM, Ogas, Jordan Andrew wrote:
>
> Not personally but my team are experimenting with Buildah/Podman.
>
I am really interested in rootless podman as an alternative to
Singularity, And if there are any shortcomings.
>
>  
>
> *From: *Daniel Walsh 
> *Organization: *Red Hat
> *Reply-To: *"dwa...@redhat.com" , Development
> discussions related to Fedora 
> *Date: *Thursday, May 16, 2019 at 2:23 PM
> *To: *"devel@lists.fedoraproject.org" 
> *Subject: *Re: Self Introduction: Jordan Ogas
>
>  
>
> On 5/16/19 3:17 PM, Ogas, Jordan Andrew via devel wrote:
>
> Greetings,
>
>  
>
> My name is Jordan, I'm a member of the Programming and Runtime
> Environment
>
> team for the High Performance Computing Division (HPC) at the Los
> Alamos
>
> National Laboratory (LANL). I have been encouraged by my package
> reviewer,
>
> Dave Love, to introduce myself to the community in an effort to
> assimilate
>
> Fedora packaging culture and increase the likely hood of being
> sponsored.
>
>  
>
> It is my goal to become the official Charliecloud package
> maintainer and an expert
>
> in software packaging. The Charliecloud package under review is
> the first package
>
> I've ever created. Thus, I am hoping to find a sponsor who will be
> patient with me
>
> as I continue to grow and learn from my mistakes.
>
>  
>
> As a member of the PRE team at LANL I am responsible for testing and
>
> maintaining programming environments on a large collection of
> super computers
>
> with various specifications, e.g., hardware, architecture (hello
> aarch64),
>
> interconnects, size, etc. I spend a lot of time contributing to
> LANL's novel
>
> unprivileged Linux container runtime, Charliecloud.
>
> Have you experimented and played with rootless podman?
>
>  
>
> Outside of work you can usually find me relaxing with my wife or
> taming
>
> dinosaurs and dying to piranhas in the video game 'Ark: Survival
> Evolved' with
>
> my 9 year old son.
>
>  
>
> Package under review (in need of sponsorship):
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1690046
>
>  
>
> Best,
>
>  
>
> Jordan Ogas
>
>
>
> ___
>
> devel mailing list -- devel@lists.fedoraproject.org 
> 
>
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org 
> 
>
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>  
>

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

[Chris Adams]

Once upon a time, Stephen John Smoogen  said:
> So a lot of sites have set up that you remotely kickstart a system and then
> ansible in as root with the rest of the configurations. It is the biggest
> reason we have been keeping this as active for a long time.  You are
> breaking all those configs with a 'oh you can just login on a local
> console'. That kickstart may not have any of that..  and the last thing a
> sysadmin wants when they are building 4000 nodes somewhere is find out that
> they need to add another 20 steps to their post..

Well, I'd assume before building 4000 nodes, they'd test the kickstart
(I test mine extensively on VMs before using on a real box).  It isn't
"another 20 steps" - either a sed one-liner to allow root or a mkdir and
a echo to add an SSH key (which you'd probably do anyway if you're doing
the rest with Ansible).

> Make it a predefined kickstart thing they can do so all they have to do is
> add a line in it that says
> 
> ssh_remote --user= --keyfile= --yesIwantrootandIknowitsbad

If this is the desired path, I'd go with a couple of additional
arguments to existing directives:

  --enablerootssh (for rootpw or maybe auth?)
  --sshkey (for both rootpw and user directives)

No matter if this proposal is done, having an --sshkey option would be
nice, especially for Ansible use.

I think this OpenSSH change to follow upstream (and many other OS)
config is a good and overdue thing.
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

[Christopher]

On Fri, May 17, 2019 at 8:24 AM Stephen Gallagher  wrote:
>
> On Thu, May 16, 2019 at 2:54 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/DisableRootPasswordLoginInSshd
> >
> > == Summary ==
> > The upstream OpenSSH disabled password logins for root back in 2015.
> > The Fedora should follow to keep security expectation and avoid users
> > surprises with this configuration.
> >
> > == Owner ==
> > * Name: [[User:jjelen| Jakub Jelen]], OpenSSH maintainer
> > * Email: jje...@redhat.com
> >
> > == Detailed Description ==
> >
> > The OpenSSH server configuration contains a configuration option
> > `PermitRootLogin`, which controls whether the root user is allowed to
> > login using passwords or using public key authentication. The root
> > login is target of most of the random or targeted attack on Linux
> > systems and password is usually the weakest part. For that reason, the
> > upstream OpenSSH changed this option in 2015 to `prohibit-password`,
> > which still allows public-key authentication, but prevents the
> > password logins. Fedora was for many practical reasons keeping the old
> > configuration since then, but the difference is no longer bearable and
> > might confuse users expecting the root logins will not be enabled out
> > of the box.
> >
> > On the other hand, there is still a lot of infrastructure, installers
> > and test instances that simply might depend on this configuration and
> > therefore this change needs to go through the system-wide change so
> > everyone is onboard.
> >
> > == Benefit to Fedora ==
> >
> > This will provide more secure Fedora installations out of the box and
> > prevent inadvertently accessible root logins in the wild.
> >
>
> I'm not particularly *opposed* to this change in behavior, but in the
> Fedora Server case, SSH is the primary mechanism for gaining access to
> the system. If we disallow password logins for root, then many
> installs will be inaccessible and users will get... grumpy.
>
> There aren't really any major problems for interactive installs where
> the user has direct console access, so I'll disregard that case for
> the moment. For kickstart-based installs, I suppose users would
> normally know to put their SSH public keys in place, so that's also
> less of a concern.
>
> The problematic case I see is the remote VNC headless install. The
> installation is interactive, but there may not be a way to gain direct
> access to the installed system after that. We need to ensure that the
> resulting system is always accessible. Right now, the interactive
> installer would allow us (even encourage us) to set up that machine
> with only a root user and password, which after this Change would mean
> that the system is not reachable.
>
> I see some possible options here, all requiring Anaconda changes:
> 1) Provide a checkbox in the root user creation spoke (defaulting to
> "off") to enable root password logins over SSH. Ideally with notes
> about why it's recommended not to do this.
> 2) Allow users to provide a public SSH key for the root user. Since
> this is generally not performed in an environment where the keys can
> be copy-pasted, we'd probably need to allow specifying a [tiny]URL for
> an authorized_keys file.
> 3) Force Anaconda to require the creation of a non-root user that is a
> member of the `wheel` group, so that this user can be used to SSH in
> and administer the system. Essentially, remove the root user creation
> spoke as an option from the interactive install.

+1 to option 3 for interactive installs. I like option 1 a little...
but I don't think Anaconda should be in the business of messing with
default upstream OpenSSH settings any more than it needs to, and I
don't think it needs to here.

For the non-interactive case, cloud-init users can already create new
user accounts. Kickstart users can script new user creation or
sshd_config changes, as they would any other non-default change they
would prefer in their install.

> 4) Force Cockpit to be installed and available on any system that
> doesn't select a non-root user at installation time. This will allow a
> password-based login and allows the root user to set up their SSH keys
> via the "Accounts" tab.
>
> I'm all for hearing what other options we may have here, but those are
> the simplest ones I can think of.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

[Stephen John Smoogen]

On Fri, 17 May 2019 at 14:02, Chris Adams  wrote:

> Once upon a time, Stephen John Smoogen  said:
> > So a lot of sites have set up that you remotely kickstart a system and
> then
> > ansible in as root with the rest of the configurations. It is the biggest
> > reason we have been keeping this as active for a long time.  You are
> > breaking all those configs with a 'oh you can just login on a local
> > console'. That kickstart may not have any of that..  and the last thing a
> > sysadmin wants when they are building 4000 nodes somewhere is find out
> that
> > they need to add another 20 steps to their post..
>
> Well, I'd assume before building 4000 nodes, they'd test the kickstart
> (I test mine extensively on VMs before using on a real box).  It isn't
> "another 20 steps" - either a sed one-liner to allow root or a mkdir and
> a echo to add an SSH key (which you'd probably do anyway if you're doing
> the rest with Ansible).
>
>
Look its Friday. I don't drink, I don't smoke, and I am trying to cut
swearing. All that leaves me is a nice can of hyperbole.

You are right, 1-4 lines is what might be needed to do things.


> > Make it a predefined kickstart thing they can do so all they have to do
> is
> > add a line in it that says
> >
> > ssh_remote --user= --keyfile= --yesIwantrootandIknowitsbad
>
> If this is the desired path, I'd go with a couple of additional
> arguments to existing directives:
>
>   --enablerootssh (for rootpw or maybe auth?)
>   --sshkey (for both rootpw and user directives)
>
>
Yeah.. --sshkey is a better name than --keyfile
and --enablerootssh is better than --yesIwantrootandIknowitsbad


> No matter if this proposal is done, having an --sshkey option would be
> nice, especially for Ansible use.
>
> I think this OpenSSH change to follow upstream (and many other OS)
> config is a good and overdue thing.
>

I am not disagreeing... but having been the person to do such security
changes in the past.. it usually pisses of the people deploying the
software enough to jump to something completely different. It always gets
taken as 'You are more worried about security than usability' and a general
feeling of disrespect to the sysadmins stuck with coming up with the change
have 0 time to actually do that work. After 30+ years of being a security
jerk.. I am just trying to say 'look people we can do better. if someone
needs to get this done.. we should at least make it easier for them to do
so in way that is clear to an auditor later.' [Ah there goes another can of
hyperbole.. ]



> --
> Chris Adams 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction: Jordan Ogas

[Jonathan Billings]

On Fri, May 17, 2019 at 01:56:20PM -0400, Daniel Walsh wrote:
> On 5/17/19 11:15 AM, Ogas, Jordan Andrew wrote:
> > Not personally but my team are experimenting with Buildah/Podman.
> >
> I am really interested in rootless podman as an alternative to
> Singularity, And if there are any shortcomings.

As far as I know, rootless containers with podman require populating
entries for each user in /etc/sub{uid,gid}, which isn't currently
something easy to do if you have your users coming from sssd-ldap or
sssd-ad.  Those files are updated when using useradd though, but it
doesn't scale up to tens of thousands of users, particularly when the
user list changes daily.

-- 
Jonathan Billings 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

[Kevin Fenzi]

On 5/17/19 11:34 AM, Stephen John Smoogen wrote:
> On Fri, 17 May 2019 at 14:02, Chris Adams  wrote:
...snip...
>>> Make it a predefined kickstart thing they can do so all they have to do
>> is
>>> add a line in it that says
>>>
>>> ssh_remote --user= --keyfile= --yesIwantrootandIknowitsbad
>>
>> If this is the desired path, I'd go with a couple of additional
>> arguments to existing directives:
>>
>>   --enablerootssh (for rootpw or maybe auth?)
>>   --sshkey (for both rootpw and user directives)
>>
>>
> Yeah.. --sshkey is a better name than --keyfile
> and --enablerootssh is better than --yesIwantrootandIknowitsbad

Some may notice this has already happened in Fedora 22:

https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html?highlight=ssh#sshkey

I think there were some arm install cases that still needed ssh root
login post install, but those might be covered now (for example, a host
that needs to join a ipa realm, so you need to login as root to set that
up). CCing dgillmore here as I think he was the one who had the example
last time this was brought up.

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction: Jordan Ogas

[Daniel Walsh]

On 5/17/19 2:34 PM, Jonathan Billings wrote:
> On Fri, May 17, 2019 at 01:56:20PM -0400, Daniel Walsh wrote:
>> On 5/17/19 11:15 AM, Ogas, Jordan Andrew wrote:
>>> Not personally but my team are experimenting with Buildah/Podman.
>>>
>> I am really interested in rootless podman as an alternative to
>> Singularity, And if there are any shortcomings.
> As far as I know, rootless containers with podman require populating
> entries for each user in /etc/sub{uid,gid}, which isn't currently
> something easy to do if you have your users coming from sssd-ldap or
> sssd-ad.  Those files are updated when using useradd though, but it
> doesn't scale up to tens of thousands of users, particularly when the
> user list changes daily.
>
Yes I have open bug reports with the glibc/gcc teams to add nssswitch
support for those files.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction: Jordan Ogas

[Daniel Walsh]

On 5/17/19 3:50 PM, Ogas, Jordan Andrew wrote:
>
> > I am really interested in rootless podman as an alternative to
> Singularity,
>
> > And if there are any shortcomings.
>
>  
>
> One of the limitations we need to work around in our production
> environments
>
> is the inability to use setuid helpers, e.g., newuidmap and newgidmap.
>
> Unfortunately, container implementations with setuid helpers like
> Singularity
>
> (and perhaps Podman?) are not an option for our production clusters.
>
Not that this changes things much, but newuidmap and newgidmap use
FileCaps and thus

only have SETUID and SETGID respectively.

 getcap /usr/bin/new*idmap
/usr/bin/newgidmap = cap_setgid+ep
/usr/bin/newuidmap = cap_setuid+ep

>  
>
> Best,
>
> Jordan
>
>  
>
> *From: *Daniel Walsh 
> *Organization: *Red Hat
> *Reply-To: *"dwa...@redhat.com" 
> *Date: *Friday, May 17, 2019 at 11:56 AM
> *To: *"Ogas, Jordan Andrew" , Development discussions
> related to Fedora 
> *Subject: *Re: Self Introduction: Jordan Ogas
>
>  
>
> On 5/17/19 11:15 AM, Ogas, Jordan Andrew wrote:
>
> Not personally but my team are experimenting with Buildah/Podman.
>
> I am really interested in rootless podman as an alternative to
> Singularity, And if there are any shortcomings.
>
>  
>
> *From: *Daniel Walsh  
> *Organization: *Red Hat
> *Reply-To: *"dwa...@redhat.com" 
>  , Development
> discussions related to Fedora 
> 
> *Date: *Thursday, May 16, 2019 at 2:23 PM
> *To: *"devel@lists.fedoraproject.org"
> 
>  
> *Subject: *Re: Self Introduction: Jordan Ogas
>
>  
>
> On 5/16/19 3:17 PM, Ogas, Jordan Andrew via devel wrote:
>
> Greetings,
>
>  
>
> My name is Jordan, I'm a member of the Programming and Runtime
> Environment
>
> team for the High Performance Computing Division (HPC) at the
> Los Alamos
>
> National Laboratory (LANL). I have been encouraged by my
> package reviewer,
>
> Dave Love, to introduce myself to the community in an effort
> to assimilate
>
> Fedora packaging culture and increase the likely hood of being
> sponsored.
>
>  
>
> It is my goal to become the official Charliecloud package
> maintainer and an expert
>
> in software packaging. The Charliecloud package under review
> is the first package
>
> I've ever created. Thus, I am hoping to find a sponsor who
> will be patient with me
>
> as I continue to grow and learn from my mistakes.
>
>  
>
> As a member of the PRE team at LANL I am responsible for
> testing and
>
> maintaining programming environments on a large collection of
> super computers
>
> with various specifications, e.g., hardware, architecture
> (hello aarch64),
>
> interconnects, size, etc. I spend a lot of time contributing
> to LANL's novel
>
> unprivileged Linux container runtime, Charliecloud.
>
> Have you experimented and played with rootless podman?
>
>
>  
>
> Outside of work you can usually find me relaxing with my wife
> or taming
>
> dinosaurs and dying to piranhas in the video game 'Ark:
> Survival Evolved' with
>
> my 9 year old son.
>
>  
>
> Package under review (in need of sponsorship):
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1690046
>
>  
>
> Best,
>
>  
>
> Jordan Ogas
>
>
>
>
> ___
>
> devel mailing list -- devel@lists.fedoraproject.org 
> 
>
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org 
> 
>
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
>
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>  
>
>  
>

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

[Kevin Fenzi]

On 5/17/19 5:23 AM, Stephen Gallagher wrote:

...snip...

> 3) Force Anaconda to require the creation of a non-root user that is a
> member of the `wheel` group, so that this user can be used to SSH in
> and administer the system. Essentially, remove the root user creation
> spoke as an option from the interactive install.

So, this is basically the old cloud-init makes a user that can sudo to
root thing. Can anyone explain in small words how this is more secure?

I mean, in this case the attacker would need to guess the username in
addition to the password (where in the cloud cause this is known), but
otherwise why not just keep root password access ?

I always found that cloud default anoying and useless and haven't yet
seen a good argument to not do it.

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction: Jordan Ogas

[Omar Diaa]

PLEASE I AM NOT SUBSCRIBING THIS THREAD AND ALL FEDORA ANYMORE IAM NOT IN
GSOC I DO NOT WANT THESE MAILS PLASE !!!

On Fri, May 17, 2019 at 10:00 PM Daniel Walsh  wrote:

> On 5/17/19 3:50 PM, Ogas, Jordan Andrew wrote:
>
> > I am really interested in rootless podman as an alternative to
> Singularity,
>
> > And if there are any shortcomings.
>
>
>
> One of the limitations we need to work around in our production
> environments
>
> is the inability to use setuid helpers, e.g., newuidmap and newgidmap.
>
> Unfortunately, container implementations with setuid helpers like
> Singularity
>
> (and perhaps Podman?) are not an option for our production clusters.
>
> Not that this changes things much, but newuidmap and newgidmap use
> FileCaps and thus
>
> only have SETUID and SETGID respectively.
>
>  getcap /usr/bin/new*idmap
> /usr/bin/newgidmap = cap_setgid+ep
> /usr/bin/newuidmap = cap_setuid+ep
>
>
>
> Best,
>
> Jordan
>
>
>
> *From: *Daniel Walsh  
> *Organization: *Red Hat
> *Reply-To: *"dwa...@redhat.com"  
> 
> *Date: *Friday, May 17, 2019 at 11:56 AM
> *To: *"Ogas, Jordan Andrew"  ,
> Development discussions related to Fedora 
> 
> *Subject: *Re: Self Introduction: Jordan Ogas
>
>
>
> On 5/17/19 11:15 AM, Ogas, Jordan Andrew wrote:
>
> Not personally but my team are experimenting with Buildah/Podman.
>
> I am really interested in rootless podman as an alternative to
> Singularity, And if there are any shortcomings.
>
>
>
> *From: *Daniel Walsh  
> *Organization: *Red Hat
> *Reply-To: *"dwa...@redhat.com"  
> , Development discussions related to Fedora
>  
> *Date: *Thursday, May 16, 2019 at 2:23 PM
> *To: *"devel@lists.fedoraproject.org" 
>  
> *Subject: *Re: Self Introduction: Jordan Ogas
>
>
>
> On 5/16/19 3:17 PM, Ogas, Jordan Andrew via devel wrote:
>
> Greetings,
>
>
>
> My name is Jordan, I'm a member of the Programming and Runtime Environment
>
> team for the High Performance Computing Division (HPC) at the Los Alamos
>
> National Laboratory (LANL). I have been encouraged by my package reviewer,
>
> Dave Love, to introduce myself to the community in an effort to assimilate
>
> Fedora packaging culture and increase the likely hood of being sponsored.
>
>
>
> It is my goal to become the official Charliecloud package maintainer and
> an expert
>
> in software packaging. The Charliecloud package under review is the first
> package
>
> I've ever created. Thus, I am hoping to find a sponsor who will be patient
> with me
>
> as I continue to grow and learn from my mistakes.
>
>
>
> As a member of the PRE team at LANL I am responsible for testing and
>
> maintaining programming environments on a large collection of super
> computers
>
> with various specifications, e.g., hardware, architecture (hello aarch64),
>
> interconnects, size, etc. I spend a lot of time contributing to LANL's
> novel
>
> unprivileged Linux container runtime, Charliecloud.
>
> Have you experimented and played with rootless podman?
>
>
>
>
> Outside of work you can usually find me relaxing with my wife or taming
>
> dinosaurs and dying to piranhas in the video game 'Ark: Survival Evolved'
> with
>
> my 9 year old son.
>
>
>
> Package under review (in need of sponsorship):
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1690046
>
>
>
> Best,
>
>
>
> Jordan Ogas
>
>
>
>
> ___
>
> devel mailing list -- devel@lists.fedoraproject.org
>
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
>
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

[Omar Diaa]

؛/ٍُِ

On Fri, May 17, 2019 at 10:35 PM Kevin Fenzi  wrote:

> On 5/17/19 5:23 AM, Stephen Gallagher wrote:
>
> ...snip...
>
PLEASE I AM NOT SUBSCRIBING THIS THREAD AND ALL FEDORA ANYMORE IAM NOT IN
GSOC I DO NOT WANT THESE MAILS PLASE !!!



>
> > 3) Force Anaconda to require the creation of a non-root user that is a
> > member of the `wheel` group, so that this user can be used to SSH in
> > and administer the system. Essentially, remove the root user creation
> > spoke as an option from the interactive install.
>
> So, this is basically the old cloud-init makes a user that can sudo to
> root thing. Can anyone explain in small words how this is more secure?
>
> I mean, in this case the attacker would need to guess the username in
> addition to the password (where in the cloud cause this is known), but
> otherwise why not just keep root password access ?
>
> I always found that cloud default anoying and useless and haven't yet
> seen a good argument to not do it.
>
> kevin
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Summary/Minutes from today's FESCo Meeting (2019-05-17)

[Omar Diaa]

PLEASE I AM NOT SUBSCRIBING THIS THREAD AND ALL FEDORA ANYMORE IAM NOT IN
GSOC I DO NOT WANT THESE MAILS PLASE !!!


On Fri, May 17, 2019 at 6:14 PM Petr Šabata  wrote:

> ===
> #fedora-meeting: FESCO (2019-05-17)
> ===
>
> Meeting started by contyk at 15:00:00 UTC. The full logs are available
> at
>
> https://meetbot.fedoraproject.org/fedora-meeting/2019-05-17/fesco.2019-05-17-15.00.log.html
>
>
> Meeting summary
> ---
> * init process  (contyk, 15:00:06)
>
> * #2128 Policy needed: Modules built against EOL Fedora releases
>   (contyk, 15:03:45)
>   * LINK: https://pagure.io/fesco/issue/2128   (contyk, 15:03:49)
>   * AGREED: Policy for modules in Fedora and EPEL is that all modules
> being shipped in the stable repositories must have been built
> against a currently-active release of Fedora, EPEL or Rawhide (+9,
> 0, -0)  (contyk, 15:34:08)
>
> * #2127 Election Interview Questions — FESCo (Jun 2019)  (contyk,
>   15:34:44)
>   * LINK: https://pagure.io/fesco/issue/2127   (contyk, 15:34:48)
>   * AGREED: The same set of questions will be used again (+5, 0, -0)
> (contyk, 15:37:19)
>
> * Next week's chair  (contyk, 15:37:38)
>   * ACTION: sgallagh will chair next meeting  (contyk, 15:40:00)
>
> * Open Floor  (contyk, 15:40:08)
>
> Meeting ended at 15:55:36 UTC.
>
>
> Action Items
> 
> * sgallagh will chair next meeting
>
>
> Action Items, by person
> ---
> * sgallagh
>   * sgallagh will chair next meeting
>
>
> People Present (lines said)
> ---
> * contyk (103)
> * sgallagh (58)
> * bowlofeggs (43)
> * mhroncok (39)
> * nirik (25)
> * zbyszek (18)
> * zodbot (17)
> * bookwar (8)
> * jforbes (7)
> * ignatenkobrain (4)
> * bcotton (2)
> * otaylor (0)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: arm03-packager00: wrong Rawhide mock config

[Omar Diaa]

PLEASE I AM NOT SUBSCRIBING THIS THREAD AND ALL FEDORA ANYMORE IAM NOT IN
GSOC I DO NOT WANT THESE MAILS
PLASE, FEDORA UNSUBSCRIBE ME FROM THIS!!! !!!


On Fri, May 17, 2019 at 11:08 AM Mikolaj Izdebski 
wrote:

> On Fri, May 17, 2019 at 5:22 AM Jerry James  wrote:
> >
> > Where should problem reports with the test machines be directed?  I
> > can't build for Rawhide in mock on arm03-packager00 because
> > /etc/mock/fedora-rawhide-armhfp.cfg refers to Fedora 30.  The correct
> > config is in /etc/mock/fedora-rawhide-armhfp.cfg.rpmnew.  Can somebody
> > with admin privileges fix that up, please?
>
> Thanks for the report. I've fixed the problem.
>
> Issues with maintainer test machines should be reported to the
> respective contact listed on the wiki page [1], in this case
> ad...@fedoraproject.org
>
> --
> Mikolaj Izdebski
>
> [1]
> https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Summary/Minutes from today's FESCo Meeting (2019-05-17)

[Miro Hrončok]

On 17. 05. 19 22:47, Omar Diaa wrote:
PLEASE I AM NOT SUBSCRIBING THIS THREAD AND ALL FEDORA ANYMORE IAM NOT IN GSOC I 
DO NOT WANT THESE MAILS PLASE !!!



Sorry to hear that Omar, but no need for Caps Lock. All these e-mails have a 
header called List-Unsubscribe - it informs you that all you have to do is to 
send and e-mail to devel-le...@lists.fedoraproject.org


Have a nice weekend.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Summary/Minutes from today's FESCo Meeting (2019-05-17)

[Samuel Sieb]

On 5/17/19 1:47 PM, Omar Diaa wrote:
PLEASE I AM NOT SUBSCRIBING THIS THREAD AND ALL FEDORA ANYMORE IAM NOT 
IN GSOC I DO NOT WANT THESE MAILS PLASE !!!


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


At the bottom of each email, there's a message about how to unsubscribe.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Summary/Minutes from today's FESCo Meeting (2019-05-17)

[Omar Diaa]

PLEASE I DO NOT WANT THESE MAILS BLOCK ME FEDORA I AM NOT IN GSoC ANYMORE,
I UNSUBSCRIBEd +10 TIMES PLEASE UNSUBSCRIBE MY GMAIL FROM THIS  PLEASE
PLEASE PLEASE

On Fri, May 17, 2019 at 10:54 PM Miro Hrončok  wrote:

> On 17. 05. 19 22:47, Omar Diaa wrote:
> > PLEASE I AM NOT SUBSCRIBING THIS THREAD AND ALL FEDORA ANYMORE IAM NOT
> IN GSOC I
> > DO NOT WANT THESE MAILS PLASE !!!
>
>
> Sorry to hear that Omar, but no need for Caps Lock. All these e-mails have
> a
> header called List-Unsubscribe - it informs you that all you have to do is
> to
> send and e-mail to devel-le...@lists.fedoraproject.org
>
> Have a nice weekend.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

[Nico Kadel-Garcia]

On Thu, May 16, 2019 at 2:54 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/DisableRootPasswordLoginInSshd
>
> == Summary ==
> The upstream OpenSSH disabled password logins for root back in 2015.
> The Fedora should follow to keep security expectation and avoid users
> surprises with this configuration.

Since the default has been to enable root logins since the first Red
Hat releases, long before Fedora was first split off, it's going to be
a surprise. As an old SSH admin (since ssh-1 was first published), It
seems reasonable in this day and age to set disabled by default. I
would definitely want anaconda to add an option, to enable it at OS
installation time. While sudo access is useful, sometimes admins lose
passwords, and I've certainly dealt with environments where admins
lost their passwords or network based credentials failed and required
console access, or where someone had to run fsck on an attached
filesystem from the console.

It will compel people to tunnel remote controlled arbotrary root
privileged operations through an authorized "sudo" user, which does
not completely eliminate risk. Some tools, like ansible, manage this
quite well. I've personally encountered the difficulty that sudo
privileges are *fragile*. It's quite easy to misconfigure a sudo file
and break root access. I've found a locked away root SSH password to
be useful for such situations, but I'm willing to sacrifice that
privilege.

> == Owner ==
> * Name: [[User:jjelen| Jakub Jelen]], OpenSSH maintainer
> * Email: jje...@redhat.com
>
> == Detailed Description ==
>
> The OpenSSH server configuration contains a configuration option
> `PermitRootLogin`, which controls whether the root user is allowed to
> login using passwords or using public key authentication. The root
> login is target of most of the random or targeted attack on Linux
> systems and password is usually the weakest part. For that reason, the
> upstream OpenSSH changed this option in 2015 to `prohibit-password`,
> which still allows public-key authentication, but prevents the
> password logins. Fedora was for many practical reasons keeping the old
> configuration since then, but the difference is no longer bearable and
> might confuse users expecting the root logins will not be enabled out
> of the box.

Make sure to draw the distinction between "no root login" and "no root
login via SSH". "No root login" requires locking the root password for
console access, which would disable fsck on a failed filesystem at
boot time. That happens less than it used to, but it's going to be
more of an issue as old SSD drives start wearing out more.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction: Jordan Ogas

[Stephen John Smoogen]

This person has been unsubscribed.

On Fri, 17 May 2019 at 16:47, Omar Diaa  wrote:

> PLEASE I AM NOT SUBSCRIBING THIS THREAD AND ALL FEDORA ANYMORE IAM NOT IN
> GSOC I DO NOT WANT THESE MAILS PLASE !!!
>
> On Fri, May 17, 2019 at 10:00 PM Daniel Walsh  wrote:
>
>> On 5/17/19 3:50 PM, Ogas, Jordan Andrew wrote:
>>
>> > I am really interested in rootless podman as an alternative to
>> Singularity,
>>
>> > And if there are any shortcomings.
>>
>>
>>
>> One of the limitations we need to work around in our production
>> environments
>>
>> is the inability to use setuid helpers, e.g., newuidmap and newgidmap.
>>
>> Unfortunately, container implementations with setuid helpers like
>> Singularity
>>
>> (and perhaps Podman?) are not an option for our production clusters.
>>
>> Not that this changes things much, but newuidmap and newgidmap use
>> FileCaps and thus
>>
>> only have SETUID and SETGID respectively.
>>
>>  getcap /usr/bin/new*idmap
>> /usr/bin/newgidmap = cap_setgid+ep
>> /usr/bin/newuidmap = cap_setuid+ep
>>
>>
>>
>> Best,
>>
>> Jordan
>>
>>
>>
>> *From: *Daniel Walsh  
>> *Organization: *Red Hat
>> *Reply-To: *"dwa...@redhat.com"  
>> 
>> *Date: *Friday, May 17, 2019 at 11:56 AM
>> *To: *"Ogas, Jordan Andrew"  ,
>> Development discussions related to Fedora 
>> 
>> *Subject: *Re: Self Introduction: Jordan Ogas
>>
>>
>>
>> On 5/17/19 11:15 AM, Ogas, Jordan Andrew wrote:
>>
>> Not personally but my team are experimenting with Buildah/Podman.
>>
>> I am really interested in rootless podman as an alternative to
>> Singularity, And if there are any shortcomings.
>>
>>
>>
>> *From: *Daniel Walsh  
>> *Organization: *Red Hat
>> *Reply-To: *"dwa...@redhat.com"  
>> , Development discussions related to Fedora
>>  
>> *Date: *Thursday, May 16, 2019 at 2:23 PM
>> *To: *"devel@lists.fedoraproject.org" 
>>  
>> *Subject: *Re: Self Introduction: Jordan Ogas
>>
>>
>>
>> On 5/16/19 3:17 PM, Ogas, Jordan Andrew via devel wrote:
>>
>> Greetings,
>>
>>
>>
>> My name is Jordan, I'm a member of the Programming and Runtime Environment
>>
>> team for the High Performance Computing Division (HPC) at the Los Alamos
>>
>> National Laboratory (LANL). I have been encouraged by my package reviewer,
>>
>> Dave Love, to introduce myself to the community in an effort to assimilate
>>
>> Fedora packaging culture and increase the likely hood of being sponsored.
>>
>>
>>
>> It is my goal to become the official Charliecloud package maintainer and
>> an expert
>>
>> in software packaging. The Charliecloud package under review is the first
>> package
>>
>> I've ever created. Thus, I am hoping to find a sponsor who will be
>> patient with me
>>
>> as I continue to grow and learn from my mistakes.
>>
>>
>>
>> As a member of the PRE team at LANL I am responsible for testing and
>>
>> maintaining programming environments on a large collection of super
>> computers
>>
>> with various specifications, e.g., hardware, architecture (hello aarch64),
>>
>> interconnects, size, etc. I spend a lot of time contributing to LANL's
>> novel
>>
>> unprivileged Linux container runtime, Charliecloud.
>>
>> Have you experimented and played with rootless podman?
>>
>>
>>
>>
>> Outside of work you can usually find me relaxing with my wife or taming
>>
>> dinosaurs and dying to piranhas in the video game 'Ark: Survival Evolved'
>> with
>>
>> my 9 year old son.
>>
>>
>>
>> Package under review (in need of sponsorship):
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1690046
>>
>>
>>
>> Best,
>>
>>
>>
>> Jordan Ogas
>>
>>
>>
>>
>> ___
>>
>> devel mailing list -- devel@lists.fedoraproject.org
>>
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>>
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>>
>>
>>
>>
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an e

Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

[Chris Adams]

Once upon a time, Kevin Fenzi  said:
> Some may notice this has already happened in Fedora 22:
> 
> https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html?highlight=ssh#sshkey

Ahh, good to know.  I admit, I mostly do kickstart installs on CentOS,
so I hadn't seen this.  Guess I will soon, with the pending release of
CentOS 8.
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

[Chris Adams]

Once upon a time, Stephen John Smoogen  said:
> Look its Friday. I don't drink, I don't smoke, and I am trying to cut
> swearing. All that leaves me is a nice can of hyperbole.

:)  Sorry, didn't mean to pick on you, though yeah, that's what it
sounded like.

I guess I'm in favor of this because I've been making this change in my
default install scripts since at least RHEL 3 and Fedora 1 (as far back
as I have at hand).  Even when I make root-only servers or VMs, I always
drop an SSH key in during kickstart %post or with virt-sysprep.

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Summary/Minutes from today's FESCo Meeting (2019-05-17)

[stan via devel]

On Fri, 17 May 2019 22:56:37 +0200
Omar Diaa  wrote:

> PLEASE I DO NOT WANT THESE MAILS BLOCK ME FEDORA I AM NOT IN GSoC
> ANYMORE, I UNSUBSCRIBEd +10 TIMES PLEASE UNSUBSCRIBE MY GMAIL FROM
> THIS  PLEASE PLEASE PLEASE

To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org