reason.Having said
> that, the general understanding appears 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.
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 fa
> 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 questions
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
T
> 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 fi
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:
https://src.fedoraproject.org/rpms/lz4/pull-re
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 up
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
exten
> 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 to
> 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 -- devel@lists.fedoraproject
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.
_
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 Fedo
> 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 used
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 -- devel@lists.fedorap
-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
> 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 purp
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:
https:
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/
Li
> 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
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: https://fe
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: https://fed
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: 38.2023
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 -- devel@lists.fedoraproject.
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 -- devel@lists.fedoraproject.
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 could
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
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 w
ot bee 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 &
We could 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 u
in its
> context.
>
> (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
_
Fedora Linux 41 was released today [[1]]. The Fedora CoreOS `testing`
stream has been rebased and is currently rolling out. In two weeks, it will
be promoted to the `stable` stream.
For more information about Fedora 41, see the Fedora Project’s list of
official Changes [[2]] and the Fedora CoreOS
)
* @gurssing:matrix.org (1)
* @aaradhak:matrix.org (1)
--
Timothée Ravier
CoreOS co-Team Lead
Red Hat <https://www.redhat.com/>
trav...@redhat.com
<https://www.redhat.com/>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send
)
* @apiaseck:matrix.org (1)
* @gurssing:matrix.org (1)
--
Timothée Ravier
CoreOS co-Team Lead
Red Hat <https://www.redhat.com/>
trav...@redhat.com
<https://www.redhat.com/>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubsc
im (2)
* @jbtrystram:matrix.org (2)
* @mnguyen:fedora.im (1)
* @apiaseck:matrix.org (1)
* @romanepo:matrix.org (1)
* @hricky:fedora.im (1)
* @romanepo:fedora.im (1)
--
Timothée Ravier
CoreOS co-Team Lead
Red Hat <https://www.redhat.com/>
trav...@redhat.com
<https://
(2)
* @mnguyen:fedora.im (1)
--
Timothée Ravier
CoreOS co-Team Lead
Red Hat <https://www.redhat.com/>
trav...@redhat.com
<https://www.redhat.com/>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email
35 matches
Mail list logo
