Is not working for me.
I am trying to release container-selinux-2.124.0 to F31 but the web app
just spins after I hit submit. No error messages but no success. Am I
doing something wrong or is the updates system broken?
== Summary ==
Remove ''nullok'' parameter from pam_unix module in default PAM
configuration in order to disallow authentication with empty password.
== Owner ==
* Name: [[User:pbrezina| Pavel Březina]]
* Email: <pbrezina(a)redhat.com>
== Detailed Description ==
Current default configuration allows users to login with an empty
password by setting nullok parameter to pam_unix module. This affects
only logins to local machine, it does not affect ssh logins as this
must be explicitly allowed in sshd_config. We want to disallow empty
password by default for local logins as well to improve system
Note: It is possible to disallow empty passwords with authselect call
(authselect enable-feature without-nullok) or by removing nullok
manually, however it creates possible issues in other components that
must be addressed.
=== Affected Components ===
* '''passwd''' - calling passwd -d to remove users password must be
denied if empty passwords are disallowed otherwise the user will be
locked out of the system
* '''AccountService''' - D-Bus methods ''SetPassword'' and
''SetPasswordMode'' on ''org.freedesktop.Accounts.User'' interface can
remove user’s password and lock the user out of the system if empty
password is disallowed. These calls must be denied in this case.
Additionally, these methods can be run by normal users as opposed to
''passwd -d'' and ''chage -d 0'' which can be run only by root.
Therefore only root should be able to call these methods.
* '''Gnome’s Control Center''' - when creating new users, it provides
an option to “require password to be set on first login” which creates
user with expired empty password. This would again lock the user out
of the system.
* '''Other Desktop Environments''' - may have the same issue as Gnome
=== Solution Step by Step ===
==== Step 1) Provide a unified way to read if nullok is enabled or not ====
We will create an authselect library call that would parse existing
PAM configuration (not necessarily generated by authselect) and return
list of enabled/disabled features. We will implement only ''nullok''
feature in the scope of this change but if needed it can be extended
in the future.
==== Step 2) Fix passwd -d ====
Calling ''passwd -d'' to remove user's password will fail if
''nullok'' is disabled.
==== Step 3) Fix AccountService ====
These methods on ''org.freedesktop.Accounts.User'' D-Bus interface
will be callable only by ''root'' and must return an error if
''nullok'' is disabled.
==== Step 4) Fix Desktop Environments ====
“Require password change on next login” must keep working. This
feature currently relies on setting an empty password. A new option
''nullresetok'' will be implemented for ''pam_unix'' module that will
allow user to authenticate with empty password only if a password
change for this user is enforced upon login. Authentication with empty
passwords which are not expired will be prohibited (unless ''nullok''
==== Step 5) Update PAM configuration to disable nullok by default ====
In authselect and pam components for new installations. Upgrading from
older systems will keep nullok present.
== Benefit to Fedora ==
Changes in described components (Step 1 - Step 4) are necessary to
implement in order to make sure that user accounts and tools works
correctly when authentication with empty password is disabled by
system administrator. Changing system default to disallow
authentication with empty passwords (Step 5) improves system
== Scope ==
* Proposal owners: Coordinate the work. Make sure all required changes
* Other developers: All affected component must be fixed. Changes are
described in ''Detailed Description''
* Release engineering: [https://pagure.io/releng/issue/9038 #9038] (a
check of an impact with Release Engineering is needed) <!-- REQUIRED
FOR SYSTEM WIDE CHANGES -->
<!-- Does this feature require coordination with release engineering
(e.g. changes to installer image generation or update package
delivery)? Is a mass rebuild required? include a link to the releng
The issue is required to be filed prior to feature submission, to
ensure that someone is on board to do any process development work and
testing, and that all changes make it into the pipeline; a bullet
point in a change is not sufficient communication -->
* Policies and guidelines: No updates needed.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This does not affect system upgrades because only new installation
will have changed default.
== How To Test ==
* Calling ''passwd -d user'' as root must fail with default configuration.
* Calling ''org.freedesktop.Accounts.User.SetPassword("", hint)'' and
''org.freedesktop.Accounts.User.SetPasswordMode(x)'' must fail with
* "require password reset on first login" must keep working when
creating users from Desktop Environment's GUI tools
== User Experience ==
Users will no longer be able to use empty passwords by default.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Default behavior will not be changed.
* Contingency deadline: Beta
* Blocks release? No
* Blocks product? No
== Documentation ==
He / Him / His
Fedora Program Manager
The Minimization Objective has been going on for a while. There are two
high-level goals: making things smaller, and keeping things smaller. On the
keeping smaller side, the team prototyped a service called Feedback
Pipeline  that monitors use cases for their installation size and
dependencies, including a size history. This will help us see bigger
changes in size for things the community cares about .
I already got some feedback from a few individuals I asked while developing
it, but I feel it's in a good enough state for a more broad feedback. So I
have a few questions:
1/ We plan to send weekly size updates to the devel list. Would that be
useful? What should they include?
2/ Regarding the use cases , especially the container ones, could people
please review and give feedback to those? Are all the packages there
actually required? I'm specifically looking at the "nss_wrapper" package
that drags in Perl and cmake which makes it huge.
3/ Are there any other use cases we should track? I'm sure there are!
4/ And a more general one: is there something you're working on that's
related Minimization? Please let me know.
PS: The service is a prototype, so please excuse if there are some rough
edges — like the history graph showing multiple values of the same color.
If you happen to be interested to contribute, I'd be glad to accept issues
(or even PRs!) in the repo .
 Objective: https://docs.fedoraproject.org/en-US/minimization/
 Feedback Pipeline: https://minimization.github.io
 Things the community cares about: There is an initial list  of use
cases defined by the Minimization Team, and we're now looking for feedback
and suggestions for new ones.
 Use cases:
 Feedback Pipeline repo:
Senior Software Engineer
I tried to submit a new update for txt2man for EPEL 8.
It was a PITA but I *THOUGHT* I got it correct. Now I see the wrong package
was included in the update.
Problem 1: bodhi couldn't find the update so I tried to paste it in
manually (which was a PITA in itself).
Instead it chose tpm2-tss-2.3.1-1.el7 instead of txt2man-1.6.0-7.el8 which
is what I pasted in.
Problem 2: It didn't find the correct bug so I pasted it in manually...
Only when I clicked "done" in the iOS input, it chose the tmp2 bug instead.
I tried multiple times. The only way I got it to accept the correct bug was
to paste in the BZ# and then add a "space".
So now I have an update I can't modify with the correct BZ# (after multiple
attempts) and with the WRONG update.
In the modern world with the pervasiveness of mobile devices, this needs to
work in a predictable manner.
what are the gcc 10 plans for Fedora 32? Will there be a change proposal for
that? Is Fedora 32 the target for gcc 10?
I remember that gcc was updated to 9 during Fedora 30 cycle without a change
proposal and the change proposal was submitted later, after the deadline and
after gcc was already updated.
I'd like to avoid repeating this situation.
Fedora 32 System Wide Changes are to be submitted by the end of this year:
Please, if you plan to update gcc to 10 in Fedora 32, submit the proposal early,
with some kind of estimated time line.
If you already have a place to test our packages with gcc 10 (such as a copr
with gcc snapshot), please do tell, I'd like to see what Python versions are