Re: [GIT PULL] Keyrings patches
James Morris wrote: > > Hi James, > > > > Could you pull these patches into the security tree? They're based on your > > next branch. > > > > Thanks, pulled. Nagyon köszönöm! 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.org/lkml/
Re: [GIT PULL] Keyrings patches
On Wed, 25 Sep 2013, David Howells wrote: > > Hi James, > > Could you pull these patches into the security tree? They're based on your > next branch. > Thanks, pulled. > The patches can be viewed as a number of sets: > > (1) KEYS: Skip key state checks when checking for possession > > This is a fix for determining the possessed status of keys that have been > invalidated or revoked or that have expired. If nothing else, can you > please pick this and pass it upstream. > > (2) KEYS: Expand the capacity of a keyring > Add a generic associative array implementation > KEYS: Drop the permissions argument from __keyring_search_one() > KEYS: Define a __key_get() wrapper to use rather than atomic_inc() > KEYS: Search for auth-key by name rather than target key ID > KEYS: Introduce a search context structure > KEYS: Consolidate the concept of an 'index key' for key access > KEYS: key_is_dead() should take a const key pointer argument > KEYS: Use bool in make_key_ref() and is_key_possessed() > > Patches to to expand the capacity of a keyring by using an associative > array rather than a flat list and patches to do some preparatory cleanups > for those. > > (3) KEYS: Add per-user_namespace registers for persistent per-UID kerberos > caches > KEYS: Implement a big key type that can save to tmpfs > > Patches to add better support for libkrb5 to save its tokens in a kernel > keyring rather than in files. It already has this ability to some > extent, but that has two problems: your tokens get deleted when you log > out (so your cron jobs can't use them) and the capacity of a user type > key is not sufficient for some of the huge Kerberos tickets one can get. > These patches address that. > > (4) KEYS: Rename public key parameter name arrays > KEYS: Move the algorithm pointer array from x509 to public_key.c > KEYS: Store public key algo ID in public_key struct > KEYS: Split public_key_verify_signature() and make available > KEYS: Store public key algo ID in public_key_signature struct > X.509: struct x509_certificate needs struct tm declaring > X.509: Embed public_key_signature struct and create filler function > X.509: Check the algorithm IDs obtained from parsing an X.509 certificate > X.509: Handle certificates that lack an authorityKeyIdentifier field > X.509: Remove certificate date checks > > Patches to improve the asymmetric key type in various ways, including an > important bugfix to prevent an unset system clock from preventing modules > from being loaded. > > (5) KEYS: Load *.x509 files into kernel keyring > KEYS: Have make canonicalise the paths of the X.509 certs better to > deduplicate > KEYS: Separate the kernel signature checking keyring from module signing > KEYS: Add a 'trusted' flag and a 'trusted only' flag > KEYS: Set the asymmetric-key type default search method > KEYS: Make the system 'trusted' keyring viewable by userspace > KEYS: verify a certificate is signed by a 'trusted' key > KEYS: initialize root uid and session keyrings early > > Patches to provide better support for loading a generic system keyring of > crypto keys which may then be used for other things besides module > signing (such as kexec). > > There are additional patches from others also. > > David > --- > The following changes since commit 5a5f2acfd04269e2e0958067216b68ff461c285c: > > selinux: add Paul Moore as a SELinux maintainer (2013-09-24 11:50:46 +1000) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git > keys-devel > > for you to fetch changes up to eb8948a03704f3dbbfc7e83090e20e93c6c476d2: > > X.509: remove possible code fragility: enumeration values not handled > (2013-09-25 17:17:01 +0100) > > > (from the branch description for keys-devel local branch) > > clone of "master" > > Antonio Alecrim Jr (1): > X.509: remove possible code fragility: enumeration values not handled > > David Howells (27): > KEYS: Skip key state checks when checking for possession > KEYS: Use bool in make_key_ref() and is_key_possessed() > KEYS: key_is_dead() should take a const key pointer argument > KEYS: Consolidate the concept of an 'index key' for key access > KEYS: Introduce a search context structure > KEYS: Search for auth-key by name rather than target key ID > KEYS: Define a __key_get() wrapper to use rather than atomic_inc() > KEYS: Drop the permissions argument from __keyring_search_one() > Add a generic associative array implementation. > KEYS: Expand the capacity of a keyring > KEYS: Implement a big key type that can
Re: [GIT PULL] Keyrings patches
On Wed, 25 Sep 2013, David Howells wrote: Hi James, Could you pull these patches into the security tree? They're based on your next branch. Thanks, pulled. The patches can be viewed as a number of sets: (1) KEYS: Skip key state checks when checking for possession This is a fix for determining the possessed status of keys that have been invalidated or revoked or that have expired. If nothing else, can you please pick this and pass it upstream. (2) KEYS: Expand the capacity of a keyring Add a generic associative array implementation KEYS: Drop the permissions argument from __keyring_search_one() KEYS: Define a __key_get() wrapper to use rather than atomic_inc() KEYS: Search for auth-key by name rather than target key ID KEYS: Introduce a search context structure KEYS: Consolidate the concept of an 'index key' for key access KEYS: key_is_dead() should take a const key pointer argument KEYS: Use bool in make_key_ref() and is_key_possessed() Patches to to expand the capacity of a keyring by using an associative array rather than a flat list and patches to do some preparatory cleanups for those. (3) KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches KEYS: Implement a big key type that can save to tmpfs Patches to add better support for libkrb5 to save its tokens in a kernel keyring rather than in files. It already has this ability to some extent, but that has two problems: your tokens get deleted when you log out (so your cron jobs can't use them) and the capacity of a user type key is not sufficient for some of the huge Kerberos tickets one can get. These patches address that. (4) KEYS: Rename public key parameter name arrays KEYS: Move the algorithm pointer array from x509 to public_key.c KEYS: Store public key algo ID in public_key struct KEYS: Split public_key_verify_signature() and make available KEYS: Store public key algo ID in public_key_signature struct X.509: struct x509_certificate needs struct tm declaring X.509: Embed public_key_signature struct and create filler function X.509: Check the algorithm IDs obtained from parsing an X.509 certificate X.509: Handle certificates that lack an authorityKeyIdentifier field X.509: Remove certificate date checks Patches to improve the asymmetric key type in various ways, including an important bugfix to prevent an unset system clock from preventing modules from being loaded. (5) KEYS: Load *.x509 files into kernel keyring KEYS: Have make canonicalise the paths of the X.509 certs better to deduplicate KEYS: Separate the kernel signature checking keyring from module signing KEYS: Add a 'trusted' flag and a 'trusted only' flag KEYS: Set the asymmetric-key type default search method KEYS: Make the system 'trusted' keyring viewable by userspace KEYS: verify a certificate is signed by a 'trusted' key KEYS: initialize root uid and session keyrings early Patches to provide better support for loading a generic system keyring of crypto keys which may then be used for other things besides module signing (such as kexec). There are additional patches from others also. David --- The following changes since commit 5a5f2acfd04269e2e0958067216b68ff461c285c: selinux: add Paul Moore as a SELinux maintainer (2013-09-24 11:50:46 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git keys-devel for you to fetch changes up to eb8948a03704f3dbbfc7e83090e20e93c6c476d2: X.509: remove possible code fragility: enumeration values not handled (2013-09-25 17:17:01 +0100) (from the branch description for keys-devel local branch) clone of master Antonio Alecrim Jr (1): X.509: remove possible code fragility: enumeration values not handled David Howells (27): KEYS: Skip key state checks when checking for possession KEYS: Use bool in make_key_ref() and is_key_possessed() KEYS: key_is_dead() should take a const key pointer argument KEYS: Consolidate the concept of an 'index key' for key access KEYS: Introduce a search context structure KEYS: Search for auth-key by name rather than target key ID KEYS: Define a __key_get() wrapper to use rather than atomic_inc() KEYS: Drop the permissions argument from __keyring_search_one() Add a generic associative array implementation. KEYS: Expand the capacity of a keyring KEYS: Implement a big key type that can save to tmpfs KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches
Re: [GIT PULL] Keyrings patches
James Morris jmor...@namei.org wrote: Hi James, Could you pull these patches into the security tree? They're based on your next branch. Thanks, pulled. Nagyon köszönöm! 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.org/lkml/
[GIT PULL] Keyrings patches
Hi James, Could you pull these patches into the security tree? They're based on your next branch. The patches can be viewed as a number of sets: (1) KEYS: Skip key state checks when checking for possession This is a fix for determining the possessed status of keys that have been invalidated or revoked or that have expired. If nothing else, can you please pick this and pass it upstream. (2) KEYS: Expand the capacity of a keyring Add a generic associative array implementation KEYS: Drop the permissions argument from __keyring_search_one() KEYS: Define a __key_get() wrapper to use rather than atomic_inc() KEYS: Search for auth-key by name rather than target key ID KEYS: Introduce a search context structure KEYS: Consolidate the concept of an 'index key' for key access KEYS: key_is_dead() should take a const key pointer argument KEYS: Use bool in make_key_ref() and is_key_possessed() Patches to to expand the capacity of a keyring by using an associative array rather than a flat list and patches to do some preparatory cleanups for those. (3) KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches KEYS: Implement a big key type that can save to tmpfs Patches to add better support for libkrb5 to save its tokens in a kernel keyring rather than in files. It already has this ability to some extent, but that has two problems: your tokens get deleted when you log out (so your cron jobs can't use them) and the capacity of a user type key is not sufficient for some of the huge Kerberos tickets one can get. These patches address that. (4) KEYS: Rename public key parameter name arrays KEYS: Move the algorithm pointer array from x509 to public_key.c KEYS: Store public key algo ID in public_key struct KEYS: Split public_key_verify_signature() and make available KEYS: Store public key algo ID in public_key_signature struct X.509: struct x509_certificate needs struct tm declaring X.509: Embed public_key_signature struct and create filler function X.509: Check the algorithm IDs obtained from parsing an X.509 certificate X.509: Handle certificates that lack an authorityKeyIdentifier field X.509: Remove certificate date checks Patches to improve the asymmetric key type in various ways, including an important bugfix to prevent an unset system clock from preventing modules from being loaded. (5) KEYS: Load *.x509 files into kernel keyring KEYS: Have make canonicalise the paths of the X.509 certs better to deduplicate KEYS: Separate the kernel signature checking keyring from module signing KEYS: Add a 'trusted' flag and a 'trusted only' flag KEYS: Set the asymmetric-key type default search method KEYS: Make the system 'trusted' keyring viewable by userspace KEYS: verify a certificate is signed by a 'trusted' key KEYS: initialize root uid and session keyrings early Patches to provide better support for loading a generic system keyring of crypto keys which may then be used for other things besides module signing (such as kexec). There are additional patches from others also. David --- The following changes since commit 5a5f2acfd04269e2e0958067216b68ff461c285c: selinux: add Paul Moore as a SELinux maintainer (2013-09-24 11:50:46 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git keys-devel for you to fetch changes up to eb8948a03704f3dbbfc7e83090e20e93c6c476d2: X.509: remove possible code fragility: enumeration values not handled (2013-09-25 17:17:01 +0100) (from the branch description for keys-devel local branch) clone of "master" Antonio Alecrim Jr (1): X.509: remove possible code fragility: enumeration values not handled David Howells (27): KEYS: Skip key state checks when checking for possession KEYS: Use bool in make_key_ref() and is_key_possessed() KEYS: key_is_dead() should take a const key pointer argument KEYS: Consolidate the concept of an 'index key' for key access KEYS: Introduce a search context structure KEYS: Search for auth-key by name rather than target key ID KEYS: Define a __key_get() wrapper to use rather than atomic_inc() KEYS: Drop the permissions argument from __keyring_search_one() Add a generic associative array implementation. KEYS: Expand the capacity of a keyring KEYS: Implement a big key type that can save to tmpfs KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches KEYS: Rename public key parameter name arrays KEYS: Move the algorithm pointer array from x509 to public_key.c KEYS: Store public key algo ID in public_key
[GIT PULL] Keyrings patches
Hi James, Could you pull these patches into the security tree? They're based on your next branch. The patches can be viewed as a number of sets: (1) KEYS: Skip key state checks when checking for possession This is a fix for determining the possessed status of keys that have been invalidated or revoked or that have expired. If nothing else, can you please pick this and pass it upstream. (2) KEYS: Expand the capacity of a keyring Add a generic associative array implementation KEYS: Drop the permissions argument from __keyring_search_one() KEYS: Define a __key_get() wrapper to use rather than atomic_inc() KEYS: Search for auth-key by name rather than target key ID KEYS: Introduce a search context structure KEYS: Consolidate the concept of an 'index key' for key access KEYS: key_is_dead() should take a const key pointer argument KEYS: Use bool in make_key_ref() and is_key_possessed() Patches to to expand the capacity of a keyring by using an associative array rather than a flat list and patches to do some preparatory cleanups for those. (3) KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches KEYS: Implement a big key type that can save to tmpfs Patches to add better support for libkrb5 to save its tokens in a kernel keyring rather than in files. It already has this ability to some extent, but that has two problems: your tokens get deleted when you log out (so your cron jobs can't use them) and the capacity of a user type key is not sufficient for some of the huge Kerberos tickets one can get. These patches address that. (4) KEYS: Rename public key parameter name arrays KEYS: Move the algorithm pointer array from x509 to public_key.c KEYS: Store public key algo ID in public_key struct KEYS: Split public_key_verify_signature() and make available KEYS: Store public key algo ID in public_key_signature struct X.509: struct x509_certificate needs struct tm declaring X.509: Embed public_key_signature struct and create filler function X.509: Check the algorithm IDs obtained from parsing an X.509 certificate X.509: Handle certificates that lack an authorityKeyIdentifier field X.509: Remove certificate date checks Patches to improve the asymmetric key type in various ways, including an important bugfix to prevent an unset system clock from preventing modules from being loaded. (5) KEYS: Load *.x509 files into kernel keyring KEYS: Have make canonicalise the paths of the X.509 certs better to deduplicate KEYS: Separate the kernel signature checking keyring from module signing KEYS: Add a 'trusted' flag and a 'trusted only' flag KEYS: Set the asymmetric-key type default search method KEYS: Make the system 'trusted' keyring viewable by userspace KEYS: verify a certificate is signed by a 'trusted' key KEYS: initialize root uid and session keyrings early Patches to provide better support for loading a generic system keyring of crypto keys which may then be used for other things besides module signing (such as kexec). There are additional patches from others also. David --- The following changes since commit 5a5f2acfd04269e2e0958067216b68ff461c285c: selinux: add Paul Moore as a SELinux maintainer (2013-09-24 11:50:46 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git keys-devel for you to fetch changes up to eb8948a03704f3dbbfc7e83090e20e93c6c476d2: X.509: remove possible code fragility: enumeration values not handled (2013-09-25 17:17:01 +0100) (from the branch description for keys-devel local branch) clone of master Antonio Alecrim Jr (1): X.509: remove possible code fragility: enumeration values not handled David Howells (27): KEYS: Skip key state checks when checking for possession KEYS: Use bool in make_key_ref() and is_key_possessed() KEYS: key_is_dead() should take a const key pointer argument KEYS: Consolidate the concept of an 'index key' for key access KEYS: Introduce a search context structure KEYS: Search for auth-key by name rather than target key ID KEYS: Define a __key_get() wrapper to use rather than atomic_inc() KEYS: Drop the permissions argument from __keyring_search_one() Add a generic associative array implementation. KEYS: Expand the capacity of a keyring KEYS: Implement a big key type that can save to tmpfs KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches KEYS: Rename public key parameter name arrays KEYS: Move the algorithm pointer array from x509 to public_key.c KEYS: Store public key algo ID in public_key
Re: [GIT PULL] Keyrings patches
James Morris wrote: > > There's a slight change upstream that means that my patchset needs > > regenerating (the initconst changes). Can you bring your -next branch up to > > date with linus/master so that I can rebase on top of it? > > I've merged my tree to -rc2 so you can rebase or merge (probably better). Excellent, 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://www.tux.org/lkml/
Re: [GIT PULL] Keyrings patches
James Morris jmor...@namei.org wrote: There's a slight change upstream that means that my patchset needs regenerating (the initconst changes). Can you bring your -next branch up to date with linus/master so that I can rebase on top of it? I've merged my tree to -rc2 so you can rebase or merge (probably better). Excellent, 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://www.tux.org/lkml/
Re: [GIT PULL] Keyrings patches
On Tue, 17 Sep 2013, David Howells wrote: > > There's a slight change upstream that means that my patchset needs > regenerating (the initconst changes). Can you bring your -next branch up to > date with linus/master so that I can rebase on top of it? I've merged my tree to -rc2 so you can rebase or merge (probably better). -- James Morris -- 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.org/lkml/
Re: [GIT PULL] Keyrings patches
On Tue, 17 Sep 2013, David Howells wrote: There's a slight change upstream that means that my patchset needs regenerating (the initconst changes). Can you bring your -next branch up to date with linus/master so that I can rebase on top of it? I've merged my tree to -rc2 so you can rebase or merge (probably better). -- James Morris jmor...@namei.org -- 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.org/lkml/
Re: [GIT PULL] Keyrings patches
On Wed, 2013-09-18 at 12:53 +0100, David Howells wrote: > Stephen Rothwell wrote: > > > Is there some reason that those fixups cannot be done in a merge commit? > > i.e. are they more than simple text updates? Hi Stephen, the issue is that the patches were created against a newer kernel (eg. next, akpm, Linus' branch), not the earlier one. So it isn't a merge issue per se. Now that -rc1 is out, James will rebase soon. Mimi > That's somewhat up to James. *He* would be the person doing the merge, not > me. I'm changing the lines in my patches also. > > > /me thinks that most rebases people do can be better done (and > > documented) as merges. > > That depends on how you define "better". Better for what? I think it's > better to absorb the changes into my patch series. StGIT is very good for > handling this, since my patches are currently maintained as an StGIT set. > That way, there ends up one fewer commit in the history, assuming no other > collisions with what James merges. > > 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.org/lkml/
Re: [GIT PULL] Keyrings patches
Stephen Rothwell wrote: > Is there some reason that those fixups cannot be done in a merge commit? > i.e. are they more than simple text updates? That's somewhat up to James. *He* would be the person doing the merge, not me. I'm changing the lines in my patches also. > /me thinks that most rebases people do can be better done (and > documented) as merges. That depends on how you define "better". Better for what? I think it's better to absorb the changes into my patch series. StGIT is very good for handling this, since my patches are currently maintained as an StGIT set. That way, there ends up one fewer commit in the history, assuming no other collisions with what James merges. 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.org/lkml/
Re: [GIT PULL] Keyrings patches
Stephen Rothwell s...@canb.auug.org.au wrote: Is there some reason that those fixups cannot be done in a merge commit? i.e. are they more than simple text updates? That's somewhat up to James. *He* would be the person doing the merge, not me. I'm changing the lines in my patches also. /me thinks that most rebases people do can be better done (and documented) as merges. That depends on how you define better. Better for what? I think it's better to absorb the changes into my patch series. StGIT is very good for handling this, since my patches are currently maintained as an StGIT set. That way, there ends up one fewer commit in the history, assuming no other collisions with what James merges. 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.org/lkml/
Re: [GIT PULL] Keyrings patches
On Wed, 2013-09-18 at 12:53 +0100, David Howells wrote: Stephen Rothwell s...@canb.auug.org.au wrote: Is there some reason that those fixups cannot be done in a merge commit? i.e. are they more than simple text updates? Hi Stephen, the issue is that the patches were created against a newer kernel (eg. next, akpm, Linus' branch), not the earlier one. So it isn't a merge issue per se. Now that -rc1 is out, James will rebase soon. Mimi That's somewhat up to James. *He* would be the person doing the merge, not me. I'm changing the lines in my patches also. /me thinks that most rebases people do can be better done (and documented) as merges. That depends on how you define better. Better for what? I think it's better to absorb the changes into my patch series. StGIT is very good for handling this, since my patches are currently maintained as an StGIT set. That way, there ends up one fewer commit in the history, assuming no other collisions with what James merges. 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.org/lkml/
Re: [GIT PULL] Keyrings patches
On Tue, 2013-09-17 at 14:55 +0100, David Howells wrote: > There's a slight change upstream that means that my patchset needs > regenerating (the initconst changes). Can you bring your -next branch up to > date with linus/master so that I can rebase on top of it? Once -rc1 is out, James normally rebases linux-security/next. He's probably en route to LSS. Mimi -- 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.org/lkml/
Re: [GIT PULL] Keyrings patches
Hi Dave, On Tue, 17 Sep 2013 14:55:49 +0100 David Howells wrote: > > There's a slight change upstream that means that my patchset needs > regenerating (the initconst changes). Can you bring your -next branch up to > date with linus/master so that I can rebase on top of it? Is there some reason that those fixups cannot be done in a merge commit? i.e. are they more than simple text updates? /me thinks that most rebases people do can be better done (and documented) as merges. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpFPMoSTFTzZ.pgp Description: PGP signature
Re: [GIT PULL] Keyrings patches
There's a slight change upstream that means that my patchset needs regenerating (the initconst changes). Can you bring your -next branch up to date with linus/master so that I can rebase on top of it? 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://www.tux.org/lkml/
Re: [GIT PULL] Keyrings patches
There's a slight change upstream that means that my patchset needs regenerating (the initconst changes). Can you bring your -next branch up to date with linus/master so that I can rebase on top of it? 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://www.tux.org/lkml/
Re: [GIT PULL] Keyrings patches
Hi Dave, On Tue, 17 Sep 2013 14:55:49 +0100 David Howells dhowe...@redhat.com wrote: There's a slight change upstream that means that my patchset needs regenerating (the initconst changes). Can you bring your -next branch up to date with linus/master so that I can rebase on top of it? Is there some reason that those fixups cannot be done in a merge commit? i.e. are they more than simple text updates? /me thinks that most rebases people do can be better done (and documented) as merges. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpFPMoSTFTzZ.pgp Description: PGP signature
Re: [GIT PULL] Keyrings patches
On Tue, 2013-09-17 at 14:55 +0100, David Howells wrote: There's a slight change upstream that means that my patchset needs regenerating (the initconst changes). Can you bring your -next branch up to date with linus/master so that I can rebase on top of it? Once -rc1 is out, James normally rebases linux-security/next. He's probably en route to LSS. Mimi -- 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.org/lkml/
Re: [GIT PULL] Keyrings patches
On Tue, 10 Sep 2013, David Howells wrote: > James Morris wrote: > > > > > This missed the merge for 3.12. Do you want me to queue the changes > > > > up, > > > > or do you want to send a pull request again after -rc1 ? > > > > > > Can you queue them up now in your 'next' branch? > > > > Nope, new patches can't go into -next until -rc1. > > I think I misunderstood your offer. When you said "to queue the changes up" > did you mean for immediate passage to Linus? If so, is it too late for that? Nope, I meant for -next :) -- James Morris -- 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.org/lkml/
Re: [GIT PULL] Keyrings patches
On Tue, 10 Sep 2013, David Howells wrote: James Morris jmor...@namei.org wrote: This missed the merge for 3.12. Do you want me to queue the changes up, or do you want to send a pull request again after -rc1 ? Can you queue them up now in your 'next' branch? Nope, new patches can't go into -next until -rc1. I think I misunderstood your offer. When you said to queue the changes up did you mean for immediate passage to Linus? If so, is it too late for that? Nope, I meant for -next :) -- James Morris jmor...@namei.org -- 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.org/lkml/
Re: [GIT PULL] Keyrings patches
James Morris wrote: > > > This missed the merge for 3.12. Do you want me to queue the changes up, > > > or do you want to send a pull request again after -rc1 ? > > > > Can you queue them up now in your 'next' branch? > > Nope, new patches can't go into -next until -rc1. I think I misunderstood your offer. When you said "to queue the changes up" did you mean for immediate passage to Linus? If so, is it too late for that? 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.org/lkml/
Re: [GIT PULL] Keyrings patches
James Morris jmor...@namei.org wrote: This missed the merge for 3.12. Do you want me to queue the changes up, or do you want to send a pull request again after -rc1 ? Can you queue them up now in your 'next' branch? Nope, new patches can't go into -next until -rc1. I think I misunderstood your offer. When you said to queue the changes up did you mean for immediate passage to Linus? If so, is it too late for that? 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.org/lkml/
Re: [GIT PULL] Keyrings patches
On Fri, 6 Sep 2013, David Howells wrote: > James Morris wrote: > > > > Could you pull these patches into the security tree? They're based on > > > your > > > next branch. > > > > This missed the merge for 3.12. Do you want me to queue the changes up, > > or do you want to send a pull request again after -rc1 ? > > Can you queue them up now in your 'next' branch? Nope, new patches can't go into -next until -rc1. -- James Morris -- 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.org/lkml/
Re: [GIT PULL] Keyrings patches
James Morris wrote: > > Could you pull these patches into the security tree? They're based on your > > next branch. > > This missed the merge for 3.12. Do you want me to queue the changes up, > or do you want to send a pull request again after -rc1 ? Can you queue them up now in your 'next' branch? 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.org/lkml/
Re: [GIT PULL] Keyrings patches
On Thu, 5 Sep 2013, David Howells wrote: > > Hi James, > > Could you pull these patches into the security tree? They're based on your > next branch. This missed the merge for 3.12. Do you want me to queue the changes up, or do you want to send a pull request again after -rc1 ? > > The patches can be viewed as a number of sets: > > (1) KEYS: Skip key state checks when checking for possession > > This is a fix for determining the possessed status of keys that have been > invalidated or revoked or that have expired. If nothing else, can you > please pick this and pass it upstream. > > (2) KEYS: Expand the capacity of a keyring > Add a generic associative array implementation > KEYS: Drop the permissions argument from __keyring_search_one() > KEYS: Define a __key_get() wrapper to use rather than atomic_inc() > KEYS: Search for auth-key by name rather than target key ID > KEYS: Introduce a search context structure > KEYS: Consolidate the concept of an 'index key' for key access > KEYS: key_is_dead() should take a const key pointer argument > KEYS: Use bool in make_key_ref() and is_key_possessed() > > Patches to to expand the capacity of a keyring by using an associative > array rather than a flat list and patches to do some preparatory cleanups > for those. > > (3) KEYS: Add per-user_namespace registers for persistent per-UID kerberos > caches > KEYS: Implement a big key type that can save to tmpfs > > Patches to add better support for libkrb5 to save its tokens in a kernel > keyring rather than in files. It already has this ability to some > extent, but that has two problems: your tokens get deleted when you log > out (so your cron jobs can't use them) and the capacity of a user type > key is not sufficient for some of the huge Kerberos tickets one can get. > These patches address that. > > (4) KEYS: Rename public key parameter name arrays > KEYS: Move the algorithm pointer array from x509 to public_key.c > KEYS: Store public key algo ID in public_key struct > KEYS: Split public_key_verify_signature() and make available > KEYS: Store public key algo ID in public_key_signature struct > X.509: struct x509_certificate needs struct tm declaring > X.509: Embed public_key_signature struct and create filler function > X.509: Check the algorithm IDs obtained from parsing an X.509 certificate > X.509: Handle certificates that lack an authorityKeyIdentifier field > X.509: Remove certificate date checks > > Patches to improve the asymmetric key type in various ways, including an > important bugfix to prevent an unset system clock from preventing modules > from being loaded. > > (5) KEYS: Load *.x509 files into kernel keyring > KEYS: Have make canonicalise the paths of the X.509 certs better to > deduplicate > KEYS: Separate the kernel signature checking keyring from module signing > KEYS: Add a 'trusted' flag and a 'trusted only' flag > KEYS: Set the asymmetric-key type default search method > KEYS: Make the system 'trusted' keyring viewable by userspace > KEYS: verify a certificate is signed by a 'trusted' key > KEYS: initialize root uid and session keyrings early > > Patches to provide better support for loading a generic system keyring of > crypto keys which may then be used for other things besides module > signing (such as kexec). > > David > --- > The following changes since commit 73203361468894c3c017bfbdd9ddcbb468039604: > > Merge branch 'smack-for-3.12' of git://git.gitorious.org/smack-next/kernel > into ra-next (2013-08-23 02:50:12 +1000) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git > tags/keys-x509-improvements > > for you to fetch changes up to 1d283e8a122f572ef0320f90b0077ce3b9aff464: > > KEYS: initialize root uid and session keyrings early (2013-09-04 19:51:45 > +0100) > > > (from the branch description for keys-devel local branch) > > clone of "master" > X.509 key improvements and fixes > > > David Howells (27): > KEYS: Skip key state checks when checking for possession > KEYS: Use bool in make_key_ref() and is_key_possessed() > KEYS: key_is_dead() should take a const key pointer argument > KEYS: Consolidate the concept of an 'index key' for key access > KEYS: Introduce a search context structure > KEYS: Search for auth-key by name rather than target key ID > KEYS: Define a __key_get() wrapper to use rather than atomic_inc() > KEYS: Drop the permissions argument from __keyring_search_one() > Add a generic associative array implementation. > KEYS: Expand the capacity of a keyring >
Re: [GIT PULL] Keyrings patches
On Thu, 5 Sep 2013, David Howells wrote: Hi James, Could you pull these patches into the security tree? They're based on your next branch. This missed the merge for 3.12. Do you want me to queue the changes up, or do you want to send a pull request again after -rc1 ? The patches can be viewed as a number of sets: (1) KEYS: Skip key state checks when checking for possession This is a fix for determining the possessed status of keys that have been invalidated or revoked or that have expired. If nothing else, can you please pick this and pass it upstream. (2) KEYS: Expand the capacity of a keyring Add a generic associative array implementation KEYS: Drop the permissions argument from __keyring_search_one() KEYS: Define a __key_get() wrapper to use rather than atomic_inc() KEYS: Search for auth-key by name rather than target key ID KEYS: Introduce a search context structure KEYS: Consolidate the concept of an 'index key' for key access KEYS: key_is_dead() should take a const key pointer argument KEYS: Use bool in make_key_ref() and is_key_possessed() Patches to to expand the capacity of a keyring by using an associative array rather than a flat list and patches to do some preparatory cleanups for those. (3) KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches KEYS: Implement a big key type that can save to tmpfs Patches to add better support for libkrb5 to save its tokens in a kernel keyring rather than in files. It already has this ability to some extent, but that has two problems: your tokens get deleted when you log out (so your cron jobs can't use them) and the capacity of a user type key is not sufficient for some of the huge Kerberos tickets one can get. These patches address that. (4) KEYS: Rename public key parameter name arrays KEYS: Move the algorithm pointer array from x509 to public_key.c KEYS: Store public key algo ID in public_key struct KEYS: Split public_key_verify_signature() and make available KEYS: Store public key algo ID in public_key_signature struct X.509: struct x509_certificate needs struct tm declaring X.509: Embed public_key_signature struct and create filler function X.509: Check the algorithm IDs obtained from parsing an X.509 certificate X.509: Handle certificates that lack an authorityKeyIdentifier field X.509: Remove certificate date checks Patches to improve the asymmetric key type in various ways, including an important bugfix to prevent an unset system clock from preventing modules from being loaded. (5) KEYS: Load *.x509 files into kernel keyring KEYS: Have make canonicalise the paths of the X.509 certs better to deduplicate KEYS: Separate the kernel signature checking keyring from module signing KEYS: Add a 'trusted' flag and a 'trusted only' flag KEYS: Set the asymmetric-key type default search method KEYS: Make the system 'trusted' keyring viewable by userspace KEYS: verify a certificate is signed by a 'trusted' key KEYS: initialize root uid and session keyrings early Patches to provide better support for loading a generic system keyring of crypto keys which may then be used for other things besides module signing (such as kexec). David --- The following changes since commit 73203361468894c3c017bfbdd9ddcbb468039604: Merge branch 'smack-for-3.12' of git://git.gitorious.org/smack-next/kernel into ra-next (2013-08-23 02:50:12 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/keys-x509-improvements for you to fetch changes up to 1d283e8a122f572ef0320f90b0077ce3b9aff464: KEYS: initialize root uid and session keyrings early (2013-09-04 19:51:45 +0100) (from the branch description for keys-devel local branch) clone of master X.509 key improvements and fixes David Howells (27): KEYS: Skip key state checks when checking for possession KEYS: Use bool in make_key_ref() and is_key_possessed() KEYS: key_is_dead() should take a const key pointer argument KEYS: Consolidate the concept of an 'index key' for key access KEYS: Introduce a search context structure KEYS: Search for auth-key by name rather than target key ID KEYS: Define a __key_get() wrapper to use rather than atomic_inc() KEYS: Drop the permissions argument from __keyring_search_one() Add a generic associative array implementation. KEYS: Expand the capacity of a keyring KEYS: Implement a big key type that can save to tmpfs KEYS: Add per-user_namespace registers for
Re: [GIT PULL] Keyrings patches
James Morris jmor...@namei.org wrote: Could you pull these patches into the security tree? They're based on your next branch. This missed the merge for 3.12. Do you want me to queue the changes up, or do you want to send a pull request again after -rc1 ? Can you queue them up now in your 'next' branch? 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.org/lkml/
Re: [GIT PULL] Keyrings patches
On Fri, 6 Sep 2013, David Howells wrote: James Morris jmor...@namei.org wrote: Could you pull these patches into the security tree? They're based on your next branch. This missed the merge for 3.12. Do you want me to queue the changes up, or do you want to send a pull request again after -rc1 ? Can you queue them up now in your 'next' branch? Nope, new patches can't go into -next until -rc1. -- James Morris jmor...@namei.org -- 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.org/lkml/
[GIT PULL] Keyrings patches
Hi James, Could you pull these patches into the security tree? They're based on your next branch. The patches can be viewed as a number of sets: (1) KEYS: Skip key state checks when checking for possession This is a fix for determining the possessed status of keys that have been invalidated or revoked or that have expired. If nothing else, can you please pick this and pass it upstream. (2) KEYS: Expand the capacity of a keyring Add a generic associative array implementation KEYS: Drop the permissions argument from __keyring_search_one() KEYS: Define a __key_get() wrapper to use rather than atomic_inc() KEYS: Search for auth-key by name rather than target key ID KEYS: Introduce a search context structure KEYS: Consolidate the concept of an 'index key' for key access KEYS: key_is_dead() should take a const key pointer argument KEYS: Use bool in make_key_ref() and is_key_possessed() Patches to to expand the capacity of a keyring by using an associative array rather than a flat list and patches to do some preparatory cleanups for those. (3) KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches KEYS: Implement a big key type that can save to tmpfs Patches to add better support for libkrb5 to save its tokens in a kernel keyring rather than in files. It already has this ability to some extent, but that has two problems: your tokens get deleted when you log out (so your cron jobs can't use them) and the capacity of a user type key is not sufficient for some of the huge Kerberos tickets one can get. These patches address that. (4) KEYS: Rename public key parameter name arrays KEYS: Move the algorithm pointer array from x509 to public_key.c KEYS: Store public key algo ID in public_key struct KEYS: Split public_key_verify_signature() and make available KEYS: Store public key algo ID in public_key_signature struct X.509: struct x509_certificate needs struct tm declaring X.509: Embed public_key_signature struct and create filler function X.509: Check the algorithm IDs obtained from parsing an X.509 certificate X.509: Handle certificates that lack an authorityKeyIdentifier field X.509: Remove certificate date checks Patches to improve the asymmetric key type in various ways, including an important bugfix to prevent an unset system clock from preventing modules from being loaded. (5) KEYS: Load *.x509 files into kernel keyring KEYS: Have make canonicalise the paths of the X.509 certs better to deduplicate KEYS: Separate the kernel signature checking keyring from module signing KEYS: Add a 'trusted' flag and a 'trusted only' flag KEYS: Set the asymmetric-key type default search method KEYS: Make the system 'trusted' keyring viewable by userspace KEYS: verify a certificate is signed by a 'trusted' key KEYS: initialize root uid and session keyrings early Patches to provide better support for loading a generic system keyring of crypto keys which may then be used for other things besides module signing (such as kexec). David --- The following changes since commit 73203361468894c3c017bfbdd9ddcbb468039604: Merge branch 'smack-for-3.12' of git://git.gitorious.org/smack-next/kernel into ra-next (2013-08-23 02:50:12 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/keys-x509-improvements for you to fetch changes up to 1d283e8a122f572ef0320f90b0077ce3b9aff464: KEYS: initialize root uid and session keyrings early (2013-09-04 19:51:45 +0100) (from the branch description for keys-devel local branch) clone of "master" X.509 key improvements and fixes David Howells (27): KEYS: Skip key state checks when checking for possession KEYS: Use bool in make_key_ref() and is_key_possessed() KEYS: key_is_dead() should take a const key pointer argument KEYS: Consolidate the concept of an 'index key' for key access KEYS: Introduce a search context structure KEYS: Search for auth-key by name rather than target key ID KEYS: Define a __key_get() wrapper to use rather than atomic_inc() KEYS: Drop the permissions argument from __keyring_search_one() Add a generic associative array implementation. KEYS: Expand the capacity of a keyring KEYS: Implement a big key type that can save to tmpfs KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches KEYS: Rename public key parameter name arrays KEYS: Move the algorithm pointer array from x509 to public_key.c KEYS: Store public key algo ID in public_key struct KEYS: Split public_key_verify_signature() and make available
[GIT PULL] Keyrings patches
Hi James, Could you pull these patches into the security tree? They're based on your next branch. The patches can be viewed as a number of sets: (1) KEYS: Skip key state checks when checking for possession This is a fix for determining the possessed status of keys that have been invalidated or revoked or that have expired. If nothing else, can you please pick this and pass it upstream. (2) KEYS: Expand the capacity of a keyring Add a generic associative array implementation KEYS: Drop the permissions argument from __keyring_search_one() KEYS: Define a __key_get() wrapper to use rather than atomic_inc() KEYS: Search for auth-key by name rather than target key ID KEYS: Introduce a search context structure KEYS: Consolidate the concept of an 'index key' for key access KEYS: key_is_dead() should take a const key pointer argument KEYS: Use bool in make_key_ref() and is_key_possessed() Patches to to expand the capacity of a keyring by using an associative array rather than a flat list and patches to do some preparatory cleanups for those. (3) KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches KEYS: Implement a big key type that can save to tmpfs Patches to add better support for libkrb5 to save its tokens in a kernel keyring rather than in files. It already has this ability to some extent, but that has two problems: your tokens get deleted when you log out (so your cron jobs can't use them) and the capacity of a user type key is not sufficient for some of the huge Kerberos tickets one can get. These patches address that. (4) KEYS: Rename public key parameter name arrays KEYS: Move the algorithm pointer array from x509 to public_key.c KEYS: Store public key algo ID in public_key struct KEYS: Split public_key_verify_signature() and make available KEYS: Store public key algo ID in public_key_signature struct X.509: struct x509_certificate needs struct tm declaring X.509: Embed public_key_signature struct and create filler function X.509: Check the algorithm IDs obtained from parsing an X.509 certificate X.509: Handle certificates that lack an authorityKeyIdentifier field X.509: Remove certificate date checks Patches to improve the asymmetric key type in various ways, including an important bugfix to prevent an unset system clock from preventing modules from being loaded. (5) KEYS: Load *.x509 files into kernel keyring KEYS: Have make canonicalise the paths of the X.509 certs better to deduplicate KEYS: Separate the kernel signature checking keyring from module signing KEYS: Add a 'trusted' flag and a 'trusted only' flag KEYS: Set the asymmetric-key type default search method KEYS: Make the system 'trusted' keyring viewable by userspace KEYS: verify a certificate is signed by a 'trusted' key KEYS: initialize root uid and session keyrings early Patches to provide better support for loading a generic system keyring of crypto keys which may then be used for other things besides module signing (such as kexec). David --- The following changes since commit 73203361468894c3c017bfbdd9ddcbb468039604: Merge branch 'smack-for-3.12' of git://git.gitorious.org/smack-next/kernel into ra-next (2013-08-23 02:50:12 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/keys-x509-improvements for you to fetch changes up to 1d283e8a122f572ef0320f90b0077ce3b9aff464: KEYS: initialize root uid and session keyrings early (2013-09-04 19:51:45 +0100) (from the branch description for keys-devel local branch) clone of master X.509 key improvements and fixes David Howells (27): KEYS: Skip key state checks when checking for possession KEYS: Use bool in make_key_ref() and is_key_possessed() KEYS: key_is_dead() should take a const key pointer argument KEYS: Consolidate the concept of an 'index key' for key access KEYS: Introduce a search context structure KEYS: Search for auth-key by name rather than target key ID KEYS: Define a __key_get() wrapper to use rather than atomic_inc() KEYS: Drop the permissions argument from __keyring_search_one() Add a generic associative array implementation. KEYS: Expand the capacity of a keyring KEYS: Implement a big key type that can save to tmpfs KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches KEYS: Rename public key parameter name arrays KEYS: Move the algorithm pointer array from x509 to public_key.c KEYS: Store public key algo ID in public_key struct KEYS: Split public_key_verify_signature() and make available
