lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D07PD5NTOXSQ.30D5V19O6KMQS@kernel.org>
Date: Sun, 31 Mar 2024 08:57:08 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Linus Torvalds" <torvalds@...ux-foundation.org>, <dhowells@...hat.com>
Cc: "Peter Huewe" <peterhuewe@....de>, "Jason Gunthorpe" <jgg@...pe.ca>,
 "David Howells" <dhowells@...hat.com>, <linux-integrity@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>, <keyrings@...r.kernel.org>
Subject: Re: [GIT PULL] tpmdd changes for v6.9-rc2

On Sun Mar 31, 2024 at 12:32 AM EET, Linus Torvalds wrote:
> On Tue, 26 Mar 2024 at 07:38, Jarkko Sakkinen <jarkko@...nel.org> wrote:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git tags/tpmdd-v6.9-rc2
>
> So I haven't pulled this, because the subject line (and tag name)
> talks about tpmdd, but this is clearly about key handling.

OK, point taken and it is evolutionary issue really but definitely
needs to be fixed.

I review and test most of the stuff that goes to keyring but other
than trusted keys, I usually pick only few patches every now and
then to my tree.

So obviously we need better grounds for putting this content together.
So probably fastest path to that would be if e.g. David just opens me
push rights to his tree, and then i push the stuff that makes sense
to me to some branch in that tree.

In other words: David would take care of sending the final PR.

As per trusted keys, should I start to make a separate "trusted keys
PR" with its own separate tag? It's fine with me but I just need to
know how to move forward. E.g. now there is one new hardware backend
upcoming for trusted keys so now it is good to realig if any need.




>
> Also, the actual contents seem to be very much an "update", not fixes.
> And it doesn't seem to be an actual improvement, in how it now does
> things from interrupts. That seems to be going backward rather than
> forward.

That's fine and can cope with this np but yeah the first paragraph is
something we need to tackle now :-)

>
>             Linus

BR, Jarkko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ