== 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
Last week, I put out a blog post and fedora-devel thread describing
the problems that we wanted to solve with Modularity. That thread was
not ultimately as successful as I had hoped.
My intention was to provide some scope to the problem, because it
seemed that a lot of alternatives being floated were not seeing some
of the more subtle cases that we were trying to address. However, the
biggest problem is that nearly every email to the list has been
started with a "Begging the Question" Fallacy. People have started
from the premise that "Modularity is Bad" and all of the rest of the
conversation has continued from there. I'd like to provide an
opportunity for us as a community to *constructively* state our
grievances with Modularity. The fundamental root cause of some of the
miscommunication is, I believe, that Modularity has problems and that
people have assumed that they are fundamental and unfixable.
I'd like to gather a constructive list of the actual use-cases that
you feel Modularity is causing problems for, with the following
stipulations: Any *subjective* problems will be ignored. "I think
writing YAML is harder than writing a spec file" is an example of a
subjective opinion. Similarly, "change inevitably results in some
learning curve" is a basic maxim of innovation and is not in and of
itself an argument not to change. "Modularity requires me to write
both a spec file and a YAML file, thereby increasing the total work"
is an *objective* observation (and a valid one; I'm going to include
it below in my own starter list). If you aren't sure if it's
objective, a useful question is "is it quantitatively measurable?"
(AKA "Can I assign a number to it and see that number increase or
decrease when changing something about the implementation?")
So, in the interest of highlighting some specific cases where the
current, deployed implementation (in no particular order):
1. Once enabled, a module stream is never changed on behalf of the
user. While this adds some strong guarantees to those who want to run
applications built from those streams, the presence of default streams
changes the expected upgrade behavior for users. Traditionally, at
upgrade a user would get the new release's most-updated version of all
packages currently on their system. With Modularity, if one of their
packages comes from a default stream and that stream is not the
default for the next release, they will stay on the current stream (or
be blocked from upgrading, if the current stream is unavailable on the
next release). 
2. Packages moved out of traditional Fedora and into a default module
stream are not available to the non-modular buildroot. 
3. Insufficient guidelines and rules have resulted in some modules
being shipped in a state that makes it difficult or impossible to
build other software for the distribution. In particular, the 'ant'
and 'maven' modules have default streams that own the namespace of
several of their dependencies that have been configured for private
use rather than public to the rest of the distrtibution. 
4. Documentation of how to create a module stream is comprehensive but
daunting. There is a lot of available information, but what is really
lacking is a basic walkthrough for converting a single package to a
5. There is no specification defined for dropping a default or enabled
module stream and returning to non-modular packages.
6. We don't provide a direct solution for parallel-installability.
This is an intentional design decision, but it *is* arguably a
regression from SCL functionality, so I'll include it here.
7. The implementation in DNF occurs in libdnf rather than at the
libsolv layer, which makes it difficult to reimplement for other
packaging or build tools (such as GNOME Software and OBS, resp.)
8. The YAML format for modulemd is complex and can be difficult to get
started with.  
9. We don't have a good document on how to MBS generates modules and
their repositories. This makes it hard for other build-systems to
replicate the behavior. 
10. The MBS has performance issues which make official builds take a
long time. 
11. "Module Stream API" when used in a default stream causes package
incompatibilities and unsupportable configurations. 
12. Packaging a module requires writing both a spec file and a
modulemd YAML file, which increases the total amount of work I need to
I'm sure there are other pain points and I encourage you to share
them. Please adhere to the guidelines about objectively measurable
 I'll highlight with a [N] any of the cases I list that have a
non-deployed fix, mitigation or are under design.
 This is an identified user-experience issue and is under active
design discussion on other threads. Please do not rehash that here.
Some of the options being considered are:
- Record whether the user "locked" themselves on a stream or had it
enabled because it happened to be the default stream and they
installed a package from it.
- Add new metadata for the streams: "Upgrades:" and "Obsoletes:".
- Drop support for default streams in Fedora 32, moving all content
in default streams back into the non-modular space.
 We have an initiative (not a service) called "Ursa Prime" which is
essentially a pungi config that imports the modular repo into the
buildroot and relies on mock using DNF correctly to pull in the
appropriate packages from default streams (meaning it will work on
local mock builds as well as Koji builds so long as we modify the mock
repo config to include the modular repos). This is in contrast to the
original "Ursa Major" project that would have been a separate service
in Fedora Infrastructure dedicated to tagging the artifacts from a
specific set of module streams into the buildroot tags. "Ursa Prime"
is ready and could be deployed at any moment, pending FESCo approval
 The Modularity WG and FESCo agreed a few weeks ago that if any
module stream is shipped as a default, all of its artifacts must
conform to the same behavior as expected of a package shipped in the
traditional manner. This also means that as part of the Fedora 32
process, we would need to go through any default streams and ensure
that they are in compliance or remove their default stream until they
 We have a tool called `fedmod` that has a command `rpm2module`
that does a lot of the bootstrapping work but that no one seems to
 I've proposed a backwards-compatible 'modulemd-packager' YAML
format that trims out the extra content that only the build-system
uses and that the packager could ignore. See
 I wrote a blog post on how to generate module repositories without
using MBS as a reference implementation:
 MBS is aware of this and is re-architecting its worker design to
improve it. https://pagure.io/fm-orchestrator/issue/1311
Good Morning Everyone,
Tomorrow we are planning on deploying a new version of pagure and
pagure-dist-git on production.
These changes come with two changes to the packager workflow:
* Anitya integration in dist-git
Something we lost when loosing pkgdb was the easy integration to anitya
(https://release-monitoring.org). With the coming changes we are getting them
On the left hand-side column, there will be a drop-down button allowing to
change the settings for anitya for the project.
Existing status will be migrated from the fedora-scm-requests repo on pagure to
use this drop-down.
Using the fedora-scm-requests repo for the anitya integration will no longer be
* Change in the de-orphaning process
Currently if a package is orphaned, one has to open a ticket against the releng
project to adopt it. With these changes, anyone will be able to adopt orphaned
projects (not retired on master) directly from dist-git's UI.
If the project is retired or has been orphaned for too long, a ticket on the
releng project will still be required though.
Both of these changes can already be reviewed in staging at:
Looking forward for your feedback!
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://firstname.lastname@example.org...
On Mon, Jan 28, 2019 15:47:00 +0100, J. Scheurich wrote:
> > I'd like to get this package reviewed please:
> > - python-pyscaffold: https://bugzilla.redhat.com/show_bug.cgi?id=1669913#
> > Would anyone like to swap reviews?
> I would review it for wdune sponsoring.
Sorry---I'm not current with the wdune scenario. I assumed you meant
that you'd review it unofficially as part of the work to get sponsored
to the packagers group:
I'm not a sponsor yet so I cannot sponsor you to the group myself, but
once you've done a few reviews, a sponsor will be happy to take a look
at them and guide you through the sponsorship process.
If you've submitted a review ticket for wdune already, I will be happy
to review it and provide comments.
Time zone: Europe/London
Starting a new thread since the old one is hard to navigate at this point.
Modularity is a distribution-level change and requires some mindset
shift from packagers and users alike. I understand the concerns some
people have, feeling it’s something new and half-baked that is being
forced on them.
We’re an open source community and in order to drive innovation, we
need to be able to try new approaches and technologies in the open,
not develop them without any input and hands-on experience behind
closed doors, later serving them on a silver plate. The feedback we’re
getting is extremely valuable, but some of it is too narrowly focused
on one specific problem area and not taking into account the other
aspects, requirements, or goals that we’re pursuing. Our objective is
still to deliver multiple versions, or variants, of our content across
releases or even distributions (think EPEL or CentOS). And it’s a good
The concept of default streams was introduced to make modularity
invisible to anyone who has no interest in alternatives and wants the
system to operate as it historically has. Whether a specific package
is delivered via a module or not shouldn’t matter. (This does not mean
it should be hidden, just that it should have no practical difference
to the system.) This applies to both buildroots and runtime, leaving
the choice of whether to modularize or not to the maintainer.
Obviously, the implementation is falling short in this regard right
now, but we have solutions in development or under design. This
includes making the default streams available in the non-modular
buildroot via Ursa Prime or tracking the module enablement intent in
our software management stack, as Stephen suggested in the original
While these issues are being resolved, we are considering temporarily
disallowing default streams in Fedora. I don’t want to abandon the
idea completely, as doing so reduces the motivation to actually build
modules and reap the benefits they might provide.
Yes, modularity still has some additional development ahead. We need
to improve the software management stack experience; we need to
revisit our release engineering SOPs; we need to stabilize and boost
performance of our infrastructure; and last but not least, we need to
improve the packager experience, providing more features to make the
creation of modules easier, as well as guidance, best practices and
policies that make it easy to collaborate. These changes are similar
to those for other useful but disruptive technologies that Fedora has
successfully introduced in the past.
I do believe we all intend the best, even if we sometimes disagree. We
currently don’t have any other proposal that would fulfill the vision
of our Objective and the needs of our users. The input here helps us
re-focus on the most acute pain points but the manpower and control we
have is also rather limited. If you want to and can help with the
implementation, I’d like to encourage you to do so.
Audacity development (git) requires linking against wxGTK3.1.
The normal Fedora wxGTK3 package is at wxGTK3-3.04 in F29/30/31/devel.
wxGTK3.1 is a development series which eventually leads to wxGTK3.2 release.
Upstream is currently at 3.1.3 and expecting at least a 3.1.4 next year.
Audacity 2.3.3 release is imminent (RC02).
I would like to be able to release the next Audacity (once tested) when
I've been reading about Fedora modules, and am wondering whether the
following would make sense as a potential solution ?:
$ dnf modules list wxGTK3
Fedora Modular 30 - x86_64
Name Stream Profiles Summary
wxGTK3 3.1.n-unstable default [d], devel GTK wxWidgets GUI library
If the module was setup like this, then could the normal repo
Requires: does this get sorted out magically like in a normal package ?
I don't know whether any other wxGTK using packages could or should be
using the wxGTK devel series.
As I'm not on the wxGTK3 package team, can I do this without their
Advice ? Am I on the right track ?
I'm starting to work on a project to make Fedora fully reproducible and bootstrappable from scratch.
I know it is a long term plan and still working on the steps, but it would be good to know the current status, if there is an internal interest in this, if someone is already working (or planning to).
Thanks for the info.