Hi Linus,
Please pull these fixes for the Keys subsystem by Eric Biggers.
The following changes since commit 3a99df9a3d14cd866b5516f8cba515a3bfd554ab:
Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace
(2017-11-01 16:04:27 -0700)
are available
Hi Linus,
Please pull these fixes for the Keys subsystem by Eric Biggers.
The following changes since commit 3a99df9a3d14cd866b5516f8cba515a3bfd554ab:
Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace
(2017-11-01 16:04:27 -0700)
are available
Hi James,
Can you pull this collection of fixes for Linux keyrings and pass them along
to Linus. They include:
(1) Fix a bunch of places where kernel drivers may access revoked user-type
keys and don't do it correctly.
(2) Fix some ecryptfs bits.
(3) Fix big_key to require
Hi James,
Can you pull this collection of fixes for Linux keyrings and pass them along
to Linus. They include:
(1) Fix a bunch of places where kernel drivers may access revoked user-type
keys and don't do it correctly.
(2) Fix some ecryptfs bits.
(3) Fix big_key to require
+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
+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
Hi James,
Can you pull this collection of fixes for Linux keyrings and pass them along
to Linus. They include:
(1) Fix a bunch of places where kernel drivers may access revoked user-type
keys and don't do it correctly.
(2) Fix some ecryptfs bits.
(3) Fix big_key to require
Hi James,
Can you pull this collection of fixes for Linux keyrings and pass them along
to Linus. They include:
(1) Fix a bunch of places where kernel drivers may access revoked user-type
keys and don't do it correctly.
(2) Fix some ecryptfs bits.
(3) Fix big_key to require
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.
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.
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 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
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
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
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
Hi James,
Can you pull these and pass them on to Linus. There are two sets of
patches here:
(1) A bunch of core keyrings bug fixes from Eric Biggers.
(2) Fixing big_key to use safe crypto from Jason A. Donenfeld.
There are more patches to come from Eric, but I haven't reviewed at them
yet,
Hi James,
Can you pull these and pass them on to Linus. There are two sets of
patches here:
(1) A bunch of core keyrings bug fixes from Eric Biggers.
(2) Fixing big_key to use safe crypto from Jason A. Donenfeld.
There are more patches to come from Eric, but I haven't reviewed at them
yet,
Please pull these fixes for the keys code.
>From David:
" (1) Fix mpi_powm()'s handling of a number with a zero exponent
[CVE-2016-8650].
(2) Fix double free in X.509 error handling.
Ver #3:
- Integrate my and Andrey's patches for mpi_powm() and use mpi_resize()
instead of
Please pull these fixes for the keys code.
>From David:
" (1) Fix mpi_powm()'s handling of a number with a zero exponent
[CVE-2016-8650].
(2) Fix double free in X.509 error handling.
Ver #3:
- Integrate my and Andrey's patches for mpi_powm() and use mpi_resize()
instead of
Please pull these fixes from David Howells:
(1) Fix a buffer overflow when displaying /proc/keys [CVE-2016-7042].
(2) Fix broken initialisation in the big_key implementation that can
result in an oops.
(3) Make big_key depend on having a random number generator available in
Please pull these fixes from David Howells:
(1) Fix a buffer overflow when displaying /proc/keys [CVE-2016-7042].
(2) Fix broken initialisation in the big_key implementation that can
result in an oops.
(3) Make big_key depend on having a random number generator available in
Please pull these fixes for the keys code.
>From David Howells:
" Here are three miscellaneous fixes:
(1) Fix a panic in some debugging code in PKCS#7. This can only happen
by explicitly inserting a #define DEBUG into the code.
(2) Fix the calculation of the digest length in the PE
Please pull these fixes for the keys code.
>From David Howells:
" Here are three miscellaneous fixes:
(1) Fix a panic in some debugging code in PKCS#7. This can only happen
by explicitly inserting a #define DEBUG into the code.
(2) Fix the calculation of the digest length in the PE
On Thu, 2014-09-18 at 14:23 +0100, 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
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
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
On Thu, 18 Sep 2014, David Howells wrote:
James Morris jmor...@namei.org 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 Morris jmor...@namei.org 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
On Thu, 2014-09-18 at 14:23 +0100, David Howells wrote:
James Morris jmor...@namei.org 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
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
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
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 Morris
James Morris jmor...@namei.org 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
Hi James,
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 made more obvious.
They
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
Hi James,
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 made more obvious.
David
Hi James,
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 made more obvious.
David
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
David Howells dhowe...@redhat.com 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
Hi James,
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 made more obvious.
They
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
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.
David
---
The following changes since commit 50b719f811583a47762ecb7e480d253abc2eb22f:
Merge branch 'smack-for-3.13' of
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.
David
---
The following changes since commit 50b719f811583a47762ecb7e480d253abc2eb22f:
Merge branch 'smack-for-3.13' of
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 Morris
46 matches
Mail list logo
