The pull request you sent on Wed, 10 Feb 2021 14:59:34 +:
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
> tags/keys-misc-20210126
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c03c21ba6f4e95e406a1a7b4c34ef334b977c194
Thank you!
--
Deet-
On Mon, Dec 14, 2020 at 12:49:27PM -0800, Linus Torvalds wrote:
> The pain just isn't worth it, but more importantly, you simply need to
> get your workflow in order, and not send me completely untested
> garbage that hasn't even been compiled.
I have now more bandwidth. It was mostly eaten by SGX
Hi Linus,
On Mon, 14 Dec 2020 13:05:51 -0800 Linus Torvalds
wrote:
>
> On Mon, Dec 14, 2020 at 12:49 PM Linus Torvalds
> wrote:
> >
> > I suspect the fix is trivial (change the "," to "|"), but I will not
> > be pulling this - or anything else that hasn't been in linux-next -
> > from you this
On Mon, Dec 14, 2020 at 12:49 PM Linus Torvalds
wrote:
>
> I suspect the fix is trivial (change the "," to "|"), but I will not
> be pulling this - or anything else that hasn't been in linux-next -
> from you this merge window.
It looks like Stephen Rothwell saw it in next yesterday, and fixed it
On Mon, Dec 14, 2020 at 2:04 AM David Howells wrote:
>
> Here's a set of minor fixes/cleanups that I've collected from various
> people for the next merge window.
This doesn't even build.
And no, that's not because of some merge error on my part. Just to
verify, I tried to build the head of what
The pull request you sent on Tue, 02 Jun 2020 17:28:00 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
> tags/keys-next-20200602
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a484a497c98a0447aca2d70de19d11b1d66e6ef7
Thank you!
--
Deet-
I added a bunch of tests to the keyutils testsuite, currently on my -next
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/keyutils.git/log/?h=next
See:
Add a keyctl command for granting a permit on a key
Handle kernel having key/keyring ACLs
I've added
On Fri, 2019-08-16 at 14:36 +0100, David Howells wrote:
> Mimi Zohar wrote:
>
> > Sorry for the delay. An exception is needed for loading builtin keys
> > "KEY_ALLOC_BUILT_IN" onto a keyring that is not writable by userspace.
> > The following works, but probably is not how David would handle t
On Fri, 2019-08-16 at 14:36 +0100, David Howells wrote:
> Mimi Zohar wrote:
>
> > Sorry for the delay. An exception is needed for loading builtin keys
> > "KEY_ALLOC_BUILT_IN" onto a keyring that is not writable by userspace.
> > The following works, but probably is not how David would handle t
Mimi Zohar wrote:
> Sorry for the delay. An exception is needed for loading builtin keys
> "KEY_ALLOC_BUILT_IN" onto a keyring that is not writable by userspace.
> The following works, but probably is not how David would handle the
> exception.
I think the attached is the right way to fix it.
Hi Linus,
On Wed, 2019-07-10 at 18:59 -0700, Linus Torvalds wrote:
> Anyway, since it does seem like David is offline, I've just reverted
> this from my tree, and will be continuing my normal merge window pull
> requests (the other issues I have seen have fixes in their respective
> trees).
Sorry
On Wed, Jul 10, 2019 at 1:15 PM Eric Biggers wrote:
>
> Also worth noting that the key ACL patches were only in linux-next for 9 days
> before the pull request was sent.
Yes. I was not entirely happy with the whole key subsystem situation.
See my concerns in
https://lore.kernel.org/lkml/CAHk-
On Wed, Jul 10, 2019 at 12:46:22PM -0700, Eric Biggers wrote:
> On Wed, Jul 10, 2019 at 11:35:07AM -0700, Linus Torvalds wrote:
> > On Fri, Jul 5, 2019 at 2:30 PM David Howells wrote:
> > >
> > > Here's my fourth block of keyrings changes for the next merge window.
> > > They
> > > change the pe
On Wed, Jul 10, 2019 at 11:35:07AM -0700, Linus Torvalds wrote:
> On Fri, Jul 5, 2019 at 2:30 PM David Howells wrote:
> >
> > Here's my fourth block of keyrings changes for the next merge window. They
> > change the permissions model used by keys and keyrings to be based on an
> > internal ACL by
On Fri, Jul 5, 2019 at 2:30 PM David Howells wrote:
>
> Here's my fourth block of keyrings changes for the next merge window. They
> change the permissions model used by keys and keyrings to be based on an
> internal ACL by the following means:
It turns out that this is broken, and I'll probably
The pull request you sent on Fri, 05 Jul 2019 22:20:44 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
> tags/keys-namespace-20190627
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2e12256b9a76584fa3a6da19210509d4775aee36
Thank you!
--
The pull request you sent on Fri, 05 Jul 2019 22:13:34 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
> tags/keys-request-20190626
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f771fde82051976a6fc0fd570f8b86de4a92124b
Thank you!
--
De
The pull request you sent on Fri, 05 Jul 2019 22:03:39 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
> tags/keys-misc-20190619
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/504b69eb3c95180bc59f1ae9096ad4b10bbbf254
Thank you!
--
Deet-
The pull request you sent on Fri, 05 Jul 2019 22:30:39 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
> tags/keys-acl-20190703
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0f75ef6a9cff49ff612f7ce0578bced9d0b38325
Thank you!
--
Deet-d
On Wed, 29 May 2019, David Howells wrote:
> Hi James,
>
> Here are some miscellaneous keyrings fixes and improvements intended for
> the next merge window, if you could pull them please.
>
Linus has asked for security subsystem PRs to go directly to him.
--
James Morris
On Wed, May 29, 2019 at 11:01:35PM +0100, David Howells wrote:
>
> (2) Implement a keyctl to allow a key to be moved from one keyring to
> another, with the option of prohibiting key replacement in the
> destination keyring.
>
What is the use case, and where are the tests and document
On Tue, 25 Sep 2018, Greg KH wrote:
> On Tue, Sep 25, 2018 at 11:17:00AM +0100, David Howells wrote:
> > Greg KH wrote:
> >
> > > I'll wait a few days on this one...
> >
> > Can you at least apply the reversion patch? UAPI is currently broken by the
> > change that needs reverting.
>
> Yes, a
On Tue, Sep 25, 2018 at 11:17:00AM +0100, David Howells wrote:
> Greg KH wrote:
>
> > I'll wait a few days on this one...
>
> Can you at least apply the reversion patch? UAPI is currently broken by the
> change that needs reverting.
Yes, as that's obviously correct. I think you should wait fo
Greg KH wrote:
> I'll wait a few days on this one...
Can you at least apply the reversion patch? UAPI is currently broken by the
change that needs reverting.
David
On Tue, Sep 25, 2018 at 07:40:06AM +1000, James Morris wrote:
> Please pull this revert and update, from David Howells:
>
> "Here's a pair of fixes that need to go upstream asap, please:
>
> (1) Revert an incorrect fix to the keyrings UAPI for a C++ reserved word
> used as a struct member n
+Cc tyhi...@canonical.com
Hi David,
On Tue, Oct 17, 2017 at 11:57:33PM +0100, David Howells wrote:
>
> (2) Fix some ecryptfs bits.
Sorry for the late notice, but just looking at it again I think the patch
"ecryptfs: fix out-of-bounds read of key payload" is broken because the
->private_key is
On Thu, Sep 28, 2017 at 12:08:36PM +1000, James Morris wrote:
> On Wed, 27 Sep 2017, Eric Biggers wrote:
>
> > On Thu, Sep 28, 2017 at 09:14:58AM +1000, James Morris wrote:
> > > On Wed, 27 Sep 2017, David Howells wrote:
> > >
> > > > (2) Fixing big_key to use safe crypto from Jason A. Donenfeld
On Wed, 27 Sep 2017, Eric Biggers wrote:
> On Thu, Sep 28, 2017 at 09:14:58AM +1000, James Morris wrote:
> > On Wed, 27 Sep 2017, David Howells wrote:
> >
> > > (2) Fixing big_key to use safe crypto from Jason A. Donenfeld.
> > >
> >
> > I'm concerned about the lack of crypto review mentioned
On Thu, Sep 28, 2017 at 09:14:58AM +1000, James Morris wrote:
> On Wed, 27 Sep 2017, David Howells wrote:
>
> > (2) Fixing big_key to use safe crypto from Jason A. Donenfeld.
> >
>
> I'm concerned about the lack of crypto review mentioned by Jason -- I
> wonder if we can get this rewrite any m
On Wed, 27 Sep 2017, David Howells wrote:
> (2) Fixing big_key to use safe crypto from Jason A. Donenfeld.
>
I'm concerned about the lack of crypto review mentioned by Jason -- I
wonder if we can get this rewrite any more review from crypto folk.
Also, are there any tests for this code? If n
On Wed, 12 Apr 2017, David Howells wrote:
>
> Hi James,
>
> Could you pull these changes into security/next please:
>
> (1) Provide a blacklist keyring and a blacklist key type such that X.509
> keys and PKCS#7 certs can be blacklisted. It is possible to load the
> blacklist from a
On Thu, 5 May 2016, David Howells wrote:
> The following changes since commit 9735a22799b9214d17d3c231fe377fc852f042e9:
>
> Linux 4.6-rc2 (2016-04-03 09:09:40 -0500)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
> tags/k
On Fri, 4 Mar 2016, David Howells wrote:
> Hi James,
>
> Could you pull this into security/next, please?
>
Done.
--
James Morris
James Morris wrote:
> Have these been in next yet?
No.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux
On Thu, 22 Oct 2015, David Howells wrote:
> Hi James,
>
> Could you pull these changes into your next branch please?
>
> There are three groups:
>
> (1) Miscellaneous cleanups.
>
> (2) Add scripts for extracting system cert list and module sigs.
>
> (3) Condense the type-specific data in t
On Mon, Oct 19, 2015 at 7:50 PM, James Morris wrote:
> Please pull these key susbystem fixes for 4.3, per the message from David
> Howells:
Oops. I already pulled David's tree.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
On Mon, 6 Oct 2014, David Howells wrote:
> Hi James,
>
> Can you pull these fixes into your next branch?
>
> (1) Handle error codes in pointers correctly so as not to crash.
>
> (2) Fix the asymmetric key description to make module signature checking work
> right (I changed the descripti
James Morris wrote:
> Ok, pulled to my next branch.
Thanks!
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://ww
On Mon, 22 Sep 2014, David Howells wrote:
> James Morris wrote:
>
> > > Can you please pull these changes into security/next. They include the
> > > fixes
> > > tag I previously requested as there's a dependency between these changes
> > > and
> > > the fixes.
> > >
> >
> > I'm getting this
James Morris wrote:
> > Can you please pull these changes into security/next. They include the
> > fixes
> > tag I previously requested as there's a dependency between these changes and
> > the fixes.
> >
>
> I'm getting this warning after pulling your code:
>
> CC crypto/hash_info.o
James Morris wrote:
> I'm getting this warning after pulling your code:
>
> CC crypto/hash_info.o
> crypto/asymmetric_keys/asymmetric_type.c: In function
> asymmetric_key_hex_to_key_id:
> crypto/asymmetric_keys/asymmetric_type.c:110: warning: ignoring return
> value of hex2bin, declared
On Tue, 16 Sep 2014, David Howells wrote:
> Hi James,
>
> Can you please pull these changes into security/next. They include the fixes
> tag I previously requested as there's a dependency between these changes and
> the fixes.
>
I'm getting this warning after pulling your code:
CC cryp
James Morris wrote:
> > > No, if they go direct to Linus, they don't go into -next.
> >
> > Can you then sync your -next branch to Linus after Linus takes them please?
>
> Nope, I only want to sync on point releases unless absolutely necessary.
In that case, can you please just pull the reques
On Thu, 18 Sep 2014, David Howells wrote:
> James Morris wrote:
>
> > No, if they go direct to Linus, they don't go into -next.
>
> Can you then sync your -next branch to Linus after Linus takes them please?
Nope, I only want to sync on point releases unless absolutely necessary.
--
James M
James Morris wrote:
> No, if they go direct to Linus, they don't go into -next.
Can you then sync your -next branch to Linus after Linus takes them please?
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
On Tue, 16 Sep 2014, David Howells wrote:
> > Can you please pull these fixes and send them on upstream:
>
> Can you also pull them into your next branch as I have stuff for your next
> branch that depends on those changes?
No, if they go direct to Linus, they don't go into -next.
--
James Mo
David Howells wrote:
>
> Can you please pull these fixes and send them on upstream:
>
> (1) Reinstate the production of EPERM for key types beginning with '.' in
> requests from userspace.
>
> (2) Tidy up the cleanup of PKCS#7 message signed information blocks and fix a
> bug this
> Can you please pull these fixes and send them on upstream:
Can you also pull them into your next branch as I have stuff for your next
branch that depends on those changes?
Thanks,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord
On Tue, 1 Apr 2014, James Morris wrote:
> On Mon, 31 Mar 2014, David Howells wrote:
>
> > James Morris wrote:
> >
> > > > Can you pull this pair of patches please? They move the flags that are
> > > > used to request specific permissions to a more public header file so
> > > > that
> > > > th
On Mon, 31 Mar 2014, David Howells wrote:
> James Morris wrote:
>
> > > Can you pull this pair of patches please? They move the flags that are
> > > used to request specific permissions to a more public header file so that
> > > they can then be used by Smack (and other security modules).
> >
James Morris wrote:
> > Can you pull this pair of patches please? They move the flags that are
> > used to request specific permissions to a more public header file so that
> > they can then be used by Smack (and other security modules).
>
> These should be going via my tree.
Okay, if you coul
On Mon, 31 Mar 2014, David Howells wrote:
>
> Hi Linus,
>
> Can you pull this pair of patches please? They move the flags that are used
> to request specific permissions to a more public header file so that they can
> then be used by Smack (and other security modules).
These should be going vi
Linus Torvalds wrote:
> > Could you pull the following fixes for the keyring stuff.
>
> Pulled. However, I notice that the following issue remains with module
> key signing, and I *think* it was introduced in the -rc1 pull:
>
> - start with clean kernel sources
>
> - build kernel ("make -j16
Linus Torvalds wrote:
> Pulled. However, I notice that the following issue remains with module
> key signing, and I *think* it was introduced in the -rc1 pull:
I posted four patches on Friday. Does:
[PATCH 1/4] X.509: Fix certificate gathering
fix your problem?
David
--
To unsubscrib
David Howells wrote:
> > - build kernel again ("make -j" - nothing has changed):
> >
> >...
> >X.509 certificate list changed
>
> Hmmm... I don't see this.
I take that back. I do, but only on the first rebuild. The problem appears
to be that kernel/Makefile does not predict the pa
Linus Torvalds wrote:
> > Could you pull the following fixes for the keyring stuff.
>
> Pulled. However, I notice that the following issue remains with module
> key signing, and I *think* it was introduced in the -rc1 pull:
>
> - start with clean kernel sources
>
> - build kernel ("make -j16
On Tue, Dec 10, 2013 at 12:40 PM, David Howells wrote:
>
> Could you pull the following fixes for the keyring stuff.
Pulled. However, I notice that the following issue remains with module
key signing, and I *think* it was introduced in the -rc1 pull:
- start with clean kernel sources
- build
On Wed, 30 Oct 2013, David Howells wrote:
>
> Hi James,
>
> Could you pull these five commits into your next branch? They are a set of
> fixes, some for the commits you have there and some for the upstream kernel.
Thanks, pulled.
Again, please aim for around -rc4 in the future.
--
James Mo
58 matches
Mail list logo
