I don't believe we systematically tested this. We will collect that along with
the detailed size increase data.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
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 could be some
Sorry this wasn't clear.
The rpm carries just 'c' (as well as some small, fixed-size metadata for
interpreting it, like hash algorithm)
Just to explain that comment which suggested 'a': we have to compute the Merkle
tree at build time in order to get a root hash to sign. The Merkle tree is
> On Do, 02.12.21 14:36, Ben Cotton (bcotton(a)redhat.com) wrote:
>
> Hmm, so what I am really missing on the feature page: what's the
> attack scenario here? Usually security features come with an attack
> scenario they are supposed to address. But there's no discussion about
> that.
>
Good
> If I enable FS-verity and later find that I need to patch a file to fix
> some problem, how do I as the sysadmin tell Linux that this change is
> authorized? Do I disable FS-verity for that specific file? Disable
> FS-verity globally? Add my own key to the kernel's keyring? Build and
> sign my
You could reinstall the rpm, the fs will reclaim the verity metadata along with
the rest of the old file.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
Errors at installation time should be fully diagnosable, and even if the output
today doesn't make it totally obvious what happened, it would be easy to fix in
rpm.
The errors post-install are a bit trickier. Imagine you install your rpm, and
kick off some long running daemon from it. A month
I omitted one more interesting case.
If the verity metadata (signature, root hash) is corrupted after installation
but before the file is opened, then opening/exec-ing the file can fail. Also,
if pages from a binary read in during the exec itself are corrupted, the system
call itself could
I think there are two cases of interest:
1) a file or signature in the rpm is corrupted, the signature doesn't have a
matching cert installed, etc...
in this case, if the plugin is present, when you attempt to install the rpm the
verity enable ioctl will explicitly fail, and presumably so will
The top-level hash is calculated for each file, then that hash is signed with
the inputted rsa key pair and the signed hash is appended to the array of
signed hashes in the rpm metadata. I am guessing the way we worded the proposal
is a little unclear because we call it "the" signature when
10 matches
Mail list logo
