F30 System-Wide Change proposal: Switch cryptsetup default metadata
format to LUKS2
by Ben Cotton
https://fedoraproject.org/wiki/Changes/SwitchCryptsetupDefaultToLUKS2
== Summary ==
The change switches Fedora system default metadata format for full
disk encryption from LUKS1 to LUKS2. It mostly involves cryptsetup
package and Anaconda installer so that both creates new LUKS2
containers by default.
== Owner ==
* Name: [[User:Okozina| Ondřej Kozina]] and [[User:Vponcova | Vendula Poncova]]
* Email: okozina AT redhat DOT com, vponcova AT redhat DOT com
== Detailed Description ==
The LUKS2 is evolution of current LUKS standard for software full disk
encryption. It's enabler for new features: introduces new Argon2 kdf
(alongside current PBKDF2) for keyslots, better support for
auto-activation, support for wrapped key ciphers (paes cipher),
experimental authenticated encryption. Plus coming new features
(online-reencryption).
The LUKS2 format is available and supported since cryptsetup release
2.0.0 (included in Fedora 28).
== Scope ==
* Proposal owners:
Ensure LUKS2 is declared default in upstream (owner is involved in
upstream development). Currently upstream aims for LUKS2 being default
in cryptsetup-2.1 (next release). We can switch it even before
cryptsetup 2.1 release by overriding the default via configuration
switch, but owner would prefer upstream default way.
* Other developers:
Installer (Anaconda & co) should adapt to the change (and create new
LUKS2 containers by default if user selects "encrypted storage" during
installation).
* Release engineering: [https://pagure.io/releng/issue/8028 #8028]
** List of deliverables: N/A
* Policies and guidelines:
* Trademark approval: N/A
== Upgrade/compatibility impact ==
There should be none with regard to currently supported Fedora
distributions. Both Fedora 28 and 29 provides cryptsetup-2.0.6 (at
least via updates streams) that is fully compatible with LUKS2 format.
LUKS1 stays to be fully supported even with LUKS2 being new default.
== How To Test ==
Basically there will be two areas to test:
* cryptsetup luksFormat command creates LUKS2 devices by default
* Anaconda installs on LUKS2 devices by default when users selects
"encrypted storage" option.
In general this test plan should not cover bugs related to LUKS2
format itself. Those bugs should be covered by development testsuite
shipped with cryptsetup package.
== User Experience ==
The everyday experience should not be affected by the change in any
way. The basic LUKS2 operations (open, close, add new keyslots, remove
keyslot) is handled via same CLI.
More experienced users gain access to new features with default
installation as stated in detailed description.
== Dependencies ==
Currently only Anaconda installer. It would be inconvenient to install
Fedora (encrypted storage) using different LUKS format by default if
cryptsetup used LUKS2. The contact person is listed among Owners of
this change.
== Contingency Plan ==
* Contingency mechanism: Stay with LUKS1 format as default
* Contingency deadline: Beta freeze
* Blocks release? No
* Blocks product? N/A
= Documentation ==
[https://gitlab.com/cryptsetup/LUKS2-docs/blob/master/luks2_doc_wip.pdf
LUKS2 specification document]
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 3 months
What does delaying F31 mean for packagers/users?
by Owen Taylor
One of the key parts of making a decision to delay/skip F31 is
figuring out, ahead of the decision, what the expected experience is
for users and packagers. Does F30 have normal stability, or do we try
to keep users happy by moving things forward with ad-hoc updates and
cross-our-fingers and hope nothing breaks?
I tend to think about this in terms of GNOME - would we rebase to
GNOME 3.34 in the middle of F30 or not? But there's a lot of other
pieces of software where similar considerations apply: container
tools, cockpit, NetworkManager, etc.
And if we did do updates like that, would we consider respinning media
and making a "F30.1"?
Owen
5 years, 3 months
Call for participation: FOSDEM 2019
by Zacharias Mitzelos
Hello everyone,
FOSDEM[0], the biggest free and non-commercial event organized by and for the community in Europe, is less than a month away. The conference will be held in Brussels, Belgium, on February 2 & 3. As every year, EMEA Ambassadors organize the booth at FOSDEM, where many developers, contributors and students visit it to discuss with us or get some swag.
This is an open call especially for Fedora developers and technical contributors, to participate in our booth at FOSDEM. One of your main tasks would be to assist people and represent Fedora from a technical point of view. Our theme is about extending the Fedora Project by developing new solutions, packaging, helping users get installed, and troubleshoot any errors that they may have. We are looking for experienced packagers and developers who have extensive knowledge on packaging, rpm, Gnome, or in general have extensive knowledge of the ins and outs of Fedora, willing to help users and answer technical questions. We want to focus on helping users be successful with Fedora, and not try to be a general helpdesk for all technologies as most of them have their own communities present. We are also welcoming new contributors who didn’t get the chance to come in the previous years. While we prefer contributors from EMEA to allow us to use our budget to bring the most contributors, we make our decision based on fit for our goals at the conference first and money second.
There is also some budget in place and we can provide travel and lodging funding to some developers and technical contributors in order to attend and assist at the booth. Sponsored contributors are expected to work for 8 hours at the booth during the two days of the conference. We will try to accommodate your needs, but we need to keep the booth fully staffed so we will be building the schedule for you. If you would like to request funding, open a funding request at the EMEA funding request tracker[1], explaining why you are asking for funding, why you should get it and how you are going to contribute to the booth. We will start reviewing requests on January 8, so submit early to get selected.
Have a nice weekend,
Zach
[0] https://fosdem.org
[1] https://pagure.io/ambassadors-emea/funding_requests/new_issue
--
Zacharias Mitzelos
<mitzie at mitzelos dot com>
mitzie on freenode
http://zacharias.mitzelos.com
5 years, 3 months
[HEADS UP] Removal of obsolete scriptlets
by Igor Gnatenko
I'm going to push multiple commits to packages (I'll send list later)
which execute scriptlets which are not needed anymore for Fedora.
However, people tend to keep same spec for Fedora and EPEL which makes
everything much more complicated. So please, if you have such package,
guard scriptlets by `%if 0%{?rhel} && 0%{?rhel} <= 8` (because I
believe that RHEL8 doesn't have all required things).
https://fedoraproject.org/wiki/Changes/RemoveObsoleteScriptlets
--
-Igor Gnatenko
5 years, 3 months
F30 System-Wide Change proposal: Flicker Free Boot
by Ben Cotton
https://fedoraproject.org/wiki/Changes/FlickerFreeBoot
== Summary ==
Make Fedora Workstation boot graphically smooth, without the display
briefly turning off and without any abrupt graphical transitions.
== Owner ==
* Name: [[User:jwrdegoede| Hans de Goede]]
* Email: hdegoede(a)redhat.com
== Detailed Description ==
A lot of work to make flickerfree boot possible has already been done,
see [[Changes/HiddenGrubMenu|the Hidden Grub Menu change page]] and
[https://hansdegoede.livejournal.com/19224.html this blog post]. This
change is about getting the final bits in place, this consists of 2
parts:
Part 1 is to enable the i915 drivers fastboot behavior by default in
coordination with the i915 upstream developers and the Fedora kernel
team.
Part 2 is [https://hansdegoede.livejournal.com/19673.html a new
plymouth theme] which incorporates the firmware's bootsplash image for
a smooth transition from the firmware bootsplash to plymouth. This new
theme is being created with input from the Fedora and GNOME design
inputs. Specifically it will follow
[https://wiki.gnome.org/Design/OS/BootProgress these GNOME design Boot
Progress mockups].
[https://fedorapeople.org/~jwrdegoede/flickerfree-videos/workstation-bgrt-...
Here] and [https://fedorapeople.org/~jwrdegoede/flickerfree-videos/laptop-diskcrypt-...
here] are some videos showing a flicker free boot with an early
version of the plymouth theme and
[https://fedorapeople.org/~jwrdegoede/diskunlock-adwaita-dark-hansg-dell.png
here] is a screenshot of the diskunlock dialog in a newer version of
the theme. Please keep in mind this is still a work in progress.
== Benefit to Fedora ==
A smooth boot process will make Fedora look better, more professional
and polished and will lead to a better end-user experience.
== Scope ==
* Proposal owners:
# Work with i915 upstream and Fedora kernel team to
# Finish new plymouth theme and add it to the Fedora plymouth package
# Add the Fedora logo watermark used in the theme to fedora-logos
(copy existing fedora-gdm-logo.png to where plymouth looks for the
watermark image)
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/8024]
** List of deliverables: all
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: Not needed for this Change.
== Upgrade/compatibility impact ==
The plan is to move users who are using the default charge plymouth
theme automatically over to the new theme. Users who have selected a
different plymouth theme themselves will keep their selection.
== How To Test ==
# Take a machine with i915 graphics (amd/nvidia graphics will still
see the monitor turn off briefly for now)
# Do a fresh install of Fedora Workstation, replacing any other OS on
the machine (so single boot not multiboot)
# Reboot, check that the monitor stays on at all time and that all
graphics transitions until gdm is shown are smooth
== User Experience ==
Single OS Workstation installs boot moothly using a new modern theme
all the way into the graphical login manager (gdm).
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism:
# If enabling i915 fastboot by default is causing regressions, disable it again
# If the new plymouth theme is broken, revert back to the old charge theme
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? Workstation
== Documentation ==
See [https://hansdegoede.livejournal.com/19673.html my blog post on this].
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 3 months
F30 System-Wide Change proposal: uEFI for ARMv7
by Ben Cotton
(This change was originally proposed for Fedora 29, but was pulled
from that release. The Change proposal is unchanged, but I am
re-circulating it for visibility.)
https://fedoraproject.org/wiki/Changes/uEFIforARMv7
== Summary ==
Move to uEFI as the default boot mechanism for ARMv7 devices.
== Owner ==
* Name: [[User:pbrobinson| Peter Robinson]]
* Email: pbrobinson at fedoraproject dot org
== Detailed Description ==
Currently ARMv7 uses extlinux to boot the kernel on ARMv7. This has
served us very well and has allowed us to standardise the ARMv7 boot
process with the vast majority of devices booting this way OOTB due to
the support being in a wide variety of u-boot releases. Over recent
years there have been a number of improvement to uEFI including robust
support in u-boot. We've supported uEFI on aarch64 as the only way of
booting Fedora supporting both Tianocore, proprietary uEFI
implementations and since Fedora 27 we've supported uEFI via u-boot
too. The uEFI provided by u-boot is now stable enough that we can now
move ARMv7 to this method too allowing us to move ARMv7 to grub2-efi
and have a single standard booth path/stack for both ARMv7 and
aarch64.
== Benefit to Fedora ==
This allows ARMv7 to move to grub2 providing the same experience to
ARMv7 users as all other architectures across the distribution. It
simplifies a number of software stacks across the distribution due to
being able to use a single install/support/upgrade path as well as
providing a single set of docs.
== Scope ==
* Proposal owners: Patches, updates to the process, testing
* Other developers: System component owners will need to review and
merge patches for certain components.
* Release engineering: [https://pagure.io/releng/issue/7606 #7606] (a
check of an impact with Release Engineering is needed)
** List of deliverables: N/A
* Policies and guidelines: N/A I don't believe this changes any
policies or guidelines
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Upgrades from prior versions of Fedora will continue to work as they
do currently. Devices booting with extlinux will continue to upgrade
and work as planned. For recent (F-25 and later) clean installs there
will be a documented migration process for those that wish to migrate
to grub2 boot process. For older installs (those without a VFAT
partition for firmware) will need to do a clean install. Devices with
non Fedora built u-boot will need to ensure they have a recent enough
u-boot to support the required uEFI functionality.
== How To Test ==
The process for testing will be the same as aarch64. This process will
be further updated and expanded once all the components are in place
and the final process is known.
== User Experience ==
The user experience will be the same as uEFI on aarch64 and x86_64
with the grub2 menu and features. This will provide a consistent
experience across all Fedora architectures and resolves a number of
issues seen with the basic extlinux menu system on ARMv7.
== Dependencies ==
There's patches need for the following software in Fedora:
* anaconda stack - anaconda/blivet/lorax
* build dependencies - oz/imagefactory
* grub2-efi build for ARMv7
* support in virt stack - virt-manager/virt-install
== Contingency Plan ==
* Contingency mechanism: Revert back to current extlinux boot process.
The support for this process will remain and these images will
continue to be built along side the new images until we're certain the
new boot process is robust.
* Contingency deadline: Beta Freeze
* Blocks release? Yes
* Blocks product? IoT
== Documentation ==
Yes. There will need to be a review of the documentation pertaining to
ARMv7, in a lot of cases this will be deleting the old process so the
universal distribution defaults are the only docs.
== Release Notes ==
To be written once process is complete
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 3 months
