On 9/26/2024 11:41 AM, Roberto Sassu wrote:
On Sun, 2024-09-15 at 10:40 +0200, Linus Torvalds wrote:
On Sun, 15 Sept 2024 at 10:08, Herbert Xu wrote:
If the aformentioned EFI use-case is bogus, then distro package
verification is going to be the only application for PGP keys in
the kernel.
On Thu, Sep 26, 2024 at 11:41:51AM +0200, Roberto Sassu wrote:
Good evening, I hope the week has gone well for everyone.
> On Sun, 2024-09-15 at 10:40 +0200, Linus Torvalds wrote:
> > On Sun, 15 Sept 2024 at 10:08, Herbert Xu
> > wrote:
> > >
> > > If the aformentioned EFI use-case is bogus, t
On Sun, 2024-09-15 at 10:40 +0200, Linus Torvalds wrote:
> On Sun, 15 Sept 2024 at 10:08, Herbert Xu wrote:
> >
> > If the aformentioned EFI use-case is bogus, then distro package
> > verification is going to be the only application for PGP keys in
> > the kernel.
>
> So I haven't actually seen
On Sun, Sep 15, 2024 at 07:52:13PM +0200, Roberto Sassu wrote:
Good morning, I hope the day is starting well for everyone.
> On 9/15/2024 11:31 AM, Herbert Xu wrote:
> >On Sun, Sep 15, 2024 at 05:15:25PM +0800, Herbert Xu wrote:
> >>
> >>Roberto, correct me if I'm wrong but your intended use case
On 9/15/2024 11:31 AM, Herbert Xu wrote:
On Sun, Sep 15, 2024 at 05:15:25PM +0800, Herbert Xu wrote:
Roberto, correct me if I'm wrong but your intended use case is
the following patch series, right?
Actually the meat of the changes is in the following series:
https://lore.kernel.org/linux-in
On 9/15/2024 9:11 AM, Linus Torvalds wrote:
On Fri, 13 Sept 2024 at 10:30, Roberto Sassu
[...]
The objections I had were against the whole "start doing policy in
kernel", with what sounded like actually parsing and unpacking rpm
contents and verifying them with a pgp key. *That* still sounds
On Sun, Sep 15, 2024 at 05:15:25PM +0800, Herbert Xu wrote:
>
> Roberto, correct me if I'm wrong but your intended use case is
> the following patch series, right?
Actually the meat of the changes is in the following series:
https://lore.kernel.org/linux-integrity/20240905150543.3766895-1-roberto
On Sun, Sep 15, 2024 at 10:40:15AM +0200, Linus Torvalds wrote:
>
> So I haven't actually seen _that_ series, but as mentioned it does
> smell pretty conceptually broken to me.
>
> But hey, code talks, bullshit walks. People can most certainly try to
> convince me.
Roberto, correct me if I'm wro
On Sun, 15 Sept 2024 at 10:08, Herbert Xu wrote:
>
> If the aformentioned EFI use-case is bogus, then distro package
> verification is going to be the only application for PGP keys in
> the kernel.
So I haven't actually seen _that_ series, but as mentioned it does
smell pretty conceptually broken
On Sun, Sep 15, 2024 at 09:11:04AM +0200, Linus Torvalds wrote:
>
> So honestly, just the series adding pgp key verification I have no
> objection to. The use case where some firmware uses pgp to validate
> allowed keys in EFI variables etc sounds like a "ok, then we need to
> parse them".
The use
On Fri, 13 Sept 2024 at 10:30, Roberto Sassu
wrote:
>
> On Fri, 2024-09-13 at 12:45 +0800, Herbert Xu wrote:
> >
> > Does this address Linus's objections? If not then we cannot proceed.
>
> I hope to get an answer from him.
So honestly, just the series adding pgp key verification I have no
object
On Fri Sep 13, 2024 at 7:45 AM EEST, Herbert Xu wrote:
> Roberto Sassu wrote:
> >
> > For the envisioned use cases, PGP operations cannot be done in user space,
> > since the consumers are in the kernel itself (Integrity Digest Cache and
> > IMA). Also they cannot be done in a trusted initial ram
On Fri, 13 Sept 2024 at 11:32, David Howells wrote:
>
> Herbert Xu wrote:
>
> > Personally I don't think the argument above holds water. With
> > IPsec we had a similar issue of authenticating untrusted peers
> > using public key cryptography. In that case we successfully
> > delegated the task
Herbert Xu wrote:
> Personally I don't think the argument above holds water. With
> IPsec we had a similar issue of authenticating untrusted peers
> using public key cryptography. In that case we successfully
> delegated the task to user-space and it is still how it works
> to this day.
It tra
On Fri, Sep 13, 2024 at 10:30:11AM +0200, Roberto Sassu wrote:
>
> The second problem is, assuming that the task is verified through other
> means other than PGP (but again, we are still relying on the public
> crypto functionality to be performed by the kernel, for this to work),
> that I didn't g
On Fri, 2024-09-13 at 12:45 +0800, Herbert Xu wrote:
> Roberto Sassu wrote:
+ linux-security-module
> >
> > For the envisioned use cases, PGP operations cannot be done in user space,
> > since the consumers are in the kernel itself (Integrity Digest Cache and
> > IMA). Also they cannot be done
Roberto Sassu wrote:
>
> For the envisioned use cases, PGP operations cannot be done in user space,
> since the consumers are in the kernel itself (Integrity Digest Cache and
> IMA). Also they cannot be done in a trusted initial ram disk, since PGP
> operations can occur also while the system is r
From: Roberto Sassu
Support for PGP keys and signatures was proposed by David long time ago,
before the decision of using PKCS#7 for kernel modules signatures
verification was made. After that, there has been not enough interest to
support PGP too.
Lately, there is renewed interest in supporting
18 matches
Mail list logo
