Due to a bug in rpm-ostree, the /etc/shadow, /etc/shadow-, /etc/gshadow and
/etc/gshadow- files in Fedora CoreOS, IoT, Atomic Desktops have the
world-readable bit set.
== Affected versions ==
All Fedora CoreOS nodes installed starting from the following versions are
impacted:
- stable:
Posting here what I've posted to the Forum thread.
https://github.com/systemd/systemd/pull/29159 has been merged in systemd
upstream and should address the main concerns I had raised in
https://bugzilla.redhat.com/show_bug.cgi?id=2025716#c0.
I don't think we should do this change anymore.
> Would these messages show up, for example, if they opened the terminal app?
They only show up on the console / ssh login prompt if I'm not mistaken:
https://github.com/fwupd/fwupd/tree/main/data/motd
___
devel mailing list --
> Actually, why wouldn't this be used everywhere? I could see this be
> useful when people remote into workstations and apply updates. I know
> of plenty of people that split their desktops between local and remote
> access/administration.
We could enable it everywhere but we've not reached out
Working on having a better Firefox shipped as a Flatpak by default will please
a lot of people that as asking for Firefox to be removed from the base image:
https://github.com/fedora-silverblue/issue-tracker/issues/288
If we can have Cisco host a container image with openh264 as a Flatpak
The main issue with this change for Silverblue/Kinoite is that this introduces
client side layering by default for all users.
To understand why this is not a good idea, I need to recap a few things: how
rpm-ostree client side layering works, the general goal behind rpm-ostree and
image based
Hey folks,
I've started the non-responsive maintainer procedure for pjp
(https://accounts.fedoraproject.org/user/pjp/) with
https://bugzilla.redhat.com/show_bug.cgi?id=2152159
I currently have a pull request that has been blocked for 4 months now:
> On Fri, Dec 9, 2022 at 8:23 AM Timothée Ravier wrote:
> Adding network-online.target is not hard, I could do that easily
> enough. I would need to change the way the service starts to use a
> flag instead of purely relying on firstboot mode though, since I can't
> make firstbo
Sorry I'm late here but while I agree with the idea, I don't think the
implementation is done at the right level.
As currently implemented, this will likely fail as the network won't be
available / ready:
https://pagure.io/fedora-autofirstboot/blob/main/f/systemd/fedora-autofirstboot.service
> Please put your name in https://fedoraproject.org/wiki/SIGs/Flatpak if
> you are interested and I'll try to organize a poll for a weekly meeting
> time. I'd suggest to start the meetings on the second week of January
> when the holidays are over.
Done! Thanks for starting that.
> Some
Thanks, updated
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
Thanks, updated.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
> No, the install script install script in an RPM trigger, so the write is
> still carried out by RPM.
>
> I don't agree. Just because a user can mess with files on the system
> doesn't mean the rpmdb is a lie, nor is it reasonable to go recheck all
> paths on the filesystem just in case they've
Good point. We'll have to do that indeed.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
We'll need to investigate this option. I've added it in
https://pagure.io/fedora-kde/SIG/issue/243
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
> Bootloaders are not single files. Consider UEFI:
>
> For grub2, there's both a .efi and some configuration that I'll handwave
> for purposes of this conversation. For shim, it's more like 4 things -
> the main shim*64.efi, fallback.efi, boot.efi, and boot.csv. These all
> serve different
-key-tasks.html
[4] https://github.com/coreos/fedora-coreos-tracker/issues/1291
Thanks,
Timothée Ravier for the Fedora CoreOS team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
If I understood things correctly, that's not how this would work. We would not
touch the boot order at all.
See https://github.com/rhboot/shim/pull/502 &
https://mivehind.net/2022/08/17/shim-ab-booting-poc/.
___
devel mailing list --
> As we've talked about before, it's not possible to make updates
> transactional. It involves, per spec and depending on processor
> architecture, updating multiple files in different directories,
> potentially on different filesystems entirely, one of which is fat32.
I should probably have
I think that the first steps here would be to:
- package it in Fedora
- write a documentation page on how to use it (the quick docs may be a good
place: https://docs.fedoraproject.org/en-US/quick-docs/)
- do a lot of testing and benchmarks to get memory and performance numbers for
each major
Agree with Dusty here: it's likely that the DNF plugin won't be used at all
with rpm-ostree.
This change would however enable some rpm-ostree variants to more finely select
the firmwares that they want: for example, Fedora CoreOS could skip all WiFi
related firmwares and Fedora Silverblue
The two articles mentioned above all full of errors and misconceptions about
how Flatpak and Flathub works.
See
https://theevilskeleton.gitlab.io/2022/05/16/response-to-flatpak-is-not-the-future.html
___
devel mailing list --
We also probably need a new FESCO ticket. The current one still points to the
one from the F34 change request:
- https://fedoraproject.org/wiki/Changes/FedoraCoreOS
- https://pagure.io/fesco/issue/2516
___
devel mailing list --
text.
>
> (dropping "pkla-compat" given its unmaintained state is Ok to be
> called "legacy" i guess)
I agree that the wording is stronger than it should be. I'll update that.
--
Timothée Ravier
CoreOS engineer & Fedora Kinoite maintainer
_
ould indeed make them fully
optional if we end up being confident we will not break the default user
experience.
--
Timothée Ravier
CoreOS engineer & Fedora Kinoite maintainer
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubs
e an older deployment anymore.
The idea is to make the update happen in two steps:
- First add the `rw` kernel arguments,
- Then set up the `sysroot.readonly` option once all previous deployments have
the rw option.
--
Timothée Ravier
CoreOS engineer &
Hi everyone,
First of all, thanks a lot for all the work that went into podman v4. The
release notes looks great and full of interesting changes!
As I understand it, the podman client and server remote API are version locked:
podman v3 clients can only speak with podman v3 servers, v4 clients
Hi everyone!
I am Timothée Ravier and I am a Linux system and security engineer interested
in safe programming languages and container focused operating systems.
I am currently a Red Hat and Fedora CoreOS engineer.
I maintain an unofficial project nicknamed Kinoite [1] that provide variants
Booting Fedora with Secure Boot enabled will result in Lockdown being enabled
at boot time. This will completly disable the BPF system call for all users
[1][2].
Unfortunately, this breaks the IPAddressAllow & IPAddressDeny systemd feature
[3][4][5].
I don't have a solution for this, but as
to be that a minimal software with
a smaller footprint has less potential issues.
It's easy to forget that there have been much more serious
vulnerabilities in dash than in bash as far as I can remember:
http://blog.cmpxchg8b.com/2013/08/security-debianisms.html
--
Timothée Ravier
--
devel mailing list
devel
30 matches
Mail list logo
