> Hi Zbigniew!
>
> On Tue, Apr 2, 2024 at 1:15 PM Zbigniew Jędrzejewski-Szmek <
> zbyszek(a)in.waw.pl> wrote:
>
>
> Thanks. In the period between the proposal was written and published the
> TPM2 provider has landed in Fedora.
> PKCS#11 provider is already here for a while.
The fact that such p
For an example of missing critical functionality, see this comment:
https://github.com/systemd/systemd/pull/29539#issuecomment-1760243611
Aside from that, trying to use the pkcs11 and tpm2 providers just ended up with
unintelligible errors being vomited on the console. No, I did not keep a copy
There are 2 major issues with this:
1) A lot of site-specific build systems implement signing via
private/local/proprietary engines, which means those build systems will no
longer be able to run on Fedora (and if this spreads to CentOS/RHEL, those too)
2) Even open source providers are still mos
> Gerd Hoffmann this AFAIU means that we also need shim in the boot chain if we want to
> support these addons.
Only if you want to use certs in MOK to verify them, otherwise it's not
necessary. The protocol is just LoadImage which every firmware also provides
and checks against DB.
--
> On Thu, May 11, 2023 at 6:26 AM Luca Boccassi
> I definitely am, considering how often there's no space and how easy
> it is to brick many systems through it.
Right, and that's the only other way to convey this information to the
bootloader. And that's one of the r
> On Thu, May 11, 2023 at 3:33 AM Zbigniew Jędrzejewski-Szmek
>
> We already don't do boot counting from the bootloader side. That
> happens in the operating system.
boot counting in the bootloader is a good thing to have, as that's the only
place to catch a few significant failures, and also i
> On Wed, May 10, 2023 at 5:34 PM Chris Murphy wrote:
>
>
> In this idea, the dm-verity parition/file would only be accessed from the
> initrd, once we have enough kernel to ability to interact with physical
> storage, understand partitions, initialize dm-verity, and read *a*
> partition, but po
> On Wed, May 10, 2023 at 2:24 PM Owen Taylor
> fsverity is separate from fscrypt. We can apply filesystem authentication
> today.
fsverity does not protect metadata, and most importantly it does not protect
the filesystem superblock. It has its uses, but this is not it.
> No. It initializes
> On Wed, May 10, 2023 at 03:52:51PM -0000, Luca Boccassi wrote:
>
> If the idea to allow a UKI to contain multiple alternate, signed,
> cmdline line profiles gets accepted [1], then a "rescue" image
> won't neccessarily need to be a separate image anymore. There
> On Tue, 2023-05-09 at 18:32 +0200, Lennart Poettering wrote:
>
> It sounds reasonable for sure.
> The only concern is, given Microsoft creates at most 500MB ESP
> partitions, are we sure all UEFI systems out there will not choke on a
> 1GB one?
>
> Can't we reduce the number of kernels by havin
> On 12/22/22 15:39, Lennart Poettering wrote:
>
>
>
> Well, the thing with a chain of trust is the fact that the only chain
> the user can trust is the one that he himself or the host device he owns
> and operates generated that trust of chain, from link 0 in that chain. (
> And we all know
> On Thu, Dec 22, 2022 at 12:42:38PM -0600, Dennis Gilmore wrote:
> Different architectures have different boot loaders. In particular, s390x and
> ppc64el are very different. The proposal is to add support for UKIs in grub2,
> so
> that we will cover UEFI and non-UEFI machines that use grub2. For
> On 22/12/2022 21:29, Chris Murphy wrote:
>
> I don't think so. Power outage is a very common problem in some countries.
>
> I still remember how unreliable FAT32 was in the Windows 9x era. You
> needed to run a scandisk check after every power failure or pressing the
> reset button. And somet
> On 12/22/22 12:00, Luca Boccassi wrote:
>
> As Neal mentioned earlier, these mechanisms are often broken. Not only
> does some firmware wind up bricking the machine when they are used, they
> also may not support removing the key used to sign Windows. If the
> attacker ca
> On Thu, Dec 22, 2022 at 12:00 PM Luca Boccassi
> Your concept only works in *some* enterprise hardware where it's even
> possible to have full control without breaking something. Even in my
> server gear, I can't do that without breaking the network firmware. If
>
> On Thu, Dec 22, 2022 at 10:51 AM Lennart Poettering
>
> Basically, I'm saying that the model of trust is flawed because users
> are unable to work with it.
>
> And besides, each level up is a smaller scope from the previous. A
> cert trusted by shim can execute anything the firmware trusts, a
> * Vitaly Zaitsev via devel:
>
>
> But they also say this:
>
> | The default state of Secure Boot has a wide circle of trust which can
> | result in customers trusting boot components they may not need. Since
> | the Microsoft 3rd Party UEFI CA certificate signs the bootloaders for
> | all Linu
OwnerData size Description
Go 0x0053 GO BUILDID description data: 62
56 61 67 68 7a 68 5f 53 6e 72 77 70 51 48 49 73 6f 36 41 2f 4a 35 53 4b 51 55
4b 46 59 4c 43 48 41 52 71 61 7a 6d 6c 73 2f 30 73 49 6b 69 77 39 62 6b 32 31
4f 75 7a 39
n.waw.pl/~zbyszek/fedora/f36-elf-unnoted-rpms.txt
>
> (*) Some -data and -langpack- files were excluded to avoid unnecessary
> downloads.
>
> (**) .h is because I did some earlier grep wrong, so some ELFheader.h
> was included in the list :(
>
> (***) an applies-to-orangies
> On Fri, Feb 4, 2022 at 9:07 AM Simo Sorce
> Wait what? pkgconf (our pkg-config implementation) builds on even the
> weird esoteric architectures like ppc32 and m68k. What are we missing
> here?
Yeah, and the older implementation in Debian builds and runs fine even on
architectures that have m
> On 03. 02. 22 16:36, Simo Sorce wrote:
>
> I've just tried to build python-gssapi with notes enabled after krb5 was
> fixed
> and it builds fine.
>
> See https://src.fedoraproject.org/rpms/python-gssapi/pull-request/4
It looks like it's not the first time that krb5-config causes issues becau
> On Wed, Dec 15, 2021, at 1:45 PM, Luca Boccassi wrote:
>
> Hmm. Some interesting stuff going on there but I would have started with a
> new SELinux
> access vector. That'd allow fine-grained constraints, e.g. disallowing
> `init_t` but
> allowing `unconfined_
> We don't have a proof of concept for the LSM module. I agree with you that in
> practice
> it would probably need to implement some kind of "list of files we care
> about",
> but I do not have an intelligent opinion about that.
>
> Based on Roberto's comment in a different sub-thread, there co
> On Fri, Dec 10, 2021 at 10:47:52AM +0100, Vít Ondruch wrote:
>
> Any file covered by fs-verity is immutable after installation. So you
> cannot modify the contents, the kernel refuses. But you can just
> replace the file (like during an upgrade), and of course copy and edit
> in a different loca
> On Mon, Nov 15, 2021 at 10:33 AM Luca Boccassi
> Please mention RPMCoW directly.
Mentioned and also linked the mailing list post you linked above as a
reference, let me know if there's other changes I can do.
___
devel mailing li
> On Mon, Nov 15, 2021 at 10:18 AM Luca Boccassi
> Huh, I guess it was. :/
Does that paragraph address your concerns? If so, I can update it to mention
RPMCoW directly, for future reference.
___
devel mailing list -- devel@lists.fedoraproject.
> On Mon, Nov 8, 2021 at 2:06 PM David Cantrell wrote:
>
> Last cycle, I brought up the problem that it being part of the ELF
> data destroys a lot of the value of the RPMCoW change[1] that is also
> in development for this release. I'm disappointed that the Change
> authors didn't care to resolv
> On Thu, Nov 04, 2021 at 10:26:20AM +, Zbigniew Jędrzejewski-Szmek wrote:
>
> But a binary representation of that could strip it down into ~50%.
Would it though? Have you tested and checked it to make that determination? Can
you share the code to reproduce it?
The values necessarily have t
> On Thu, Oct 28, 2021 at 09:30:18PM +0200, Lennart Poettering wrote:
>
> I was thinking more about this proposal over the past weekend and
> where I keep ending up is that this is really optimizing for a small
> use case by touching ELF metadata all over the system. And that
> strikes me as pret
> On Thu, Oct 28, 2021 at 07:37:27PM +, Zbigniew Jędrzejewski-Szmek wrote:
>
> These are reasonable examples that demonstrate how developers and
> users could benefit from the change proposal. Could more things like
> this be added to:
>
> https://fedoraproject.org/wiki/Changes/Package_infor
> On 10/29/21 3:53 PM, Lennart Poettering wrote:
>
> Does there need to be any parsing at all? WireGuard avoids the problem
> by only using fixed-size fields, so one only needs to check that the
> field is of the correct length. Qubes OS uses the same solution in
> at least its GUI protocol.
>
> On Thu, Oct 28, 2021 at 06:39:38PM -0000, Luca Boccassi wrote:
>
> It depends on how wide of a net you cast. Since package naming is
> user-controlled and distribution-wide rules are enforced by disparate
> build systems and environments, an NVR (or NEVRA) is not unique.
> On Thu, Oct 28, 2021 at 2:40 PM Luca Boccassi
> It is not enough. It's not enough in *any* distribution, because
> people can (re)build and deploy the same NEVRA. You *need* a build-id
> to guarantee uniqueness of the binary. If the NVR is the same but the
> build has been
> On Mon, Oct 25, 2021 at 07:26:47PM +, Zbigniew Jędrzejewski-Szmek wrote:
>
> Thanks for revising the change proposal and filling in more details.
> After reading through it, I have some questions:
>
> 1) The proposal notes that users tend to combine built packages from
> different distribut
> On Wed, Oct 27, 2021 at 02:10:37PM +0100, Daniel P. Berrangé wrote:
>
> It breaks libguestfs. It also breaks basic stuff like "what is
> installed in this container?" "Is this file owned by RPM?" "Has
> this
> file been modified?" I think deleting the RPM database is broken, and
> tools that
> On 27/10/2021 21:38, Luca Boccassi wrote:
>
> I will ask additional information from user if the bug report has no
> useful backtrace.
Which you might get or not, and might be correct or not. This is what we
experience daily - just because you are lucky and don't need it,
> Luca Boccassi wrote:
>
> The problem with your argument is that one "ridiculously negligible"
> overhead and then another and then yet another etc. ends up accumulating and
> we end up with minimum RAM and disk space requirements increased by a factor
> of 10
> Dne 27. 10. 21 v 21:35 Luca Boccassi napsal(a):
>
> In repository in general (can be deb, zypper, local directory). Even the
> offline systems
> have some repository where they
> get the packages from.
>
> Miroslav
How do you know which one is it then? You have a co
> Daniel P. Berrangé wrote:
>
> Well, my take is that it is really weird that the response to "I deleted the
> metadata from my container and now I cannot query the very metadata I
> deleted." (hardly a surprise!) is "Let us just duplicate the same metadata
> somewhere else, bloating the files
> On 27/10/2021 18:40, Daniel P. Berrangé wrote:
>
> As an upstream developer, I prefer only backtraces with debuginfo installed.
As an upstream developer, you get what users send you, which might or might not
be what you prefer. With this change, the bare minimum produced as a corefile
is usef
> Dne 25. 10. 21 v 21:09 Ben Cotton napsal(a):
>
> Why you hesitate to use network? When you allow network access then
> debuginfod already do
> that (more or less).
There can be many reasons, for example:
- privacy: it reveals what you are running to an external service
- security: airgapped o
> * Zbigniew Jędrzejewski-Szmek:
>
>
> The general case of any statically linked code. It could be libgcc,
> startup files, the non-shared bits of glibc, static-only libraries, or
> header-only C++ libraries.
>
> Thanks,
> Florian
This would be indeed useful, but quite harder to do automagical
> Hi,
>
> On Mon, 2021-10-25 at 15:09 -0400, Ben Cotton wrote:
>
> I like this idea. It will be really useful when multiple distros adopt
> it.
>
>
> It isn't immediately clear to me which of the key's will be included.
> The format describes 6 standard ones: type, os, osVersion, name,
> versio
m. Being able to know at a glance to the journal exactly what
is borken, with version info, is extremely valuable to them.
Yes the version info might not be precise for a minority of use cases
that override the binary version with something different than the
source version, but that's fine as
On Fri, 2021-05-14 at 12:41 +0200, Guillem Jover wrote:
> On Sat, 2021-04-10 at 13:38:31 +0100, Luca Boccassi wrote:
> > On Sat, 2021-04-10 at 13:29 +0100, Luca Boccassi wrote:
> > > After an initial discussion [0], recently we have been working on a new
> > > speci
On Thu, 2021-05-06 at 03:17 +0200, Mark Wielaard wrote:
> Hi Luca,
>
> On Tue, 2021-05-04 at 14:43 +0100, Luca Boccassi wrote:
> > On Fri, 2021-04-30 at 19:57 +0200, Mark Wielaard wrote:
> > > Is there a list of default keys (and their canonical spelling, upper-
> >
On Fri, 2021-04-30 at 19:57 +0200, Mark Wielaard wrote:
> Hi,
>
> On Sat, 2021-04-10 at 18:44 +, Zbigniew Jędrzejewski-Szmek wrote:
> > [I'm forwarding the mail from Luca who is not subscribed to fedora-
> > devel]
> > On Sat, Apr 10, 2021 at 01:38:31PM +0100
> On Tue, Apr 13, 2021 at 8:09 AM Zbigniew Jędrzejewski-Szmek
>
> The new metadata guarantees that the ELF data churns, though. For
> example, if I bump the Release in a spec file for something unrelated
> to the build, all the ELF blobs change. The current state means that
> this is deduplicated
> On Wed, 2021-04-14 at 15:29 +, Zbigniew Jędrzejewski-Szmek wrote:
>
> That's fair - if it were possible to get an fd during dump, we could
> use fgetxattr. If not, we can use /proc/$pid/exe - even when deleted
> you can interact with it:
>
> [malmond@malmond-x1 ~]$ ls -l /proc/$$/exe
> lrwx
On Sat, 2021-04-10 at 13:29 +0100, Luca Boccassi wrote:
> Hello,
>
> Cross-posting to the mailing lists of a few relevant projects.
>
> After an initial discussion [0], recently we have been working on a new
> specification [0] to encode rich package-level metadata inside ELF
50 matches
Mail list logo
