Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1540991 > unrolled thread

Re: Revised add_key(2) man page for review

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Revised add_key(2) man page for review David Howells <dhowells@redhat.com> - 2016-12-13 12:00 +0100
    Re: Revised add_key(2) man page for review "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-12-13 12:30 +0100
      Re: Revised add_key(2) man page for review David Howells <dhowells@redhat.com> - 2016-12-13 12:40 +0100
        Re: Revised add_key(2) man page for review "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-12-13 13:00 +0100
          Re: Revised add_key(2) man page for review Eugene Syromyatnikov <evgsyr@gmail.com> - 2016-12-13 13:10 +0100
            Re: Revised add_key(2) man page for review "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> - 2016-12-13 14:00 +0100

#1540991 — Re: Revised add_key(2) man page for review

Michael Kerrisk (man-pages) <mtk.manpages@gmail.com> wrote:

>        The destination keyring serial number may be that  of  a  valid
>        keyring for which the caller has write permission, or it may be
>        one of the following special keyring IDs:

No comma before "or".

>        "user" This is a general purpose key type whose payload may  be
> ...
>       "keyring"

It probably makes sense to put keyring either first or last.

>        "keyring"
>               Keyrings are special key types that may contain links to
>               sequences  of other keys of any type.  If this interface
>               is used to create a keyring, then a NULL payload  should
>               be specified, and plen should be zero.

I think "then payload should be NULL and plen should be zero." sounds better.

>        "logon" (since Linux 3.3)
>               This  key type is essentially the same as "user", but it
>               does not provide reading.

"permit the key to be read" rather than "provide reading", I think.

>        "big_key" (since Linux 3.13)
>               This  key type is similar to "user", but may hold a pay‐
>               load of up to 1 MiB.  If the key payload is large,  then
>               it  may  be stored in swap space rather than kernel mem‐
>               ory.

"stored encrypted in swap space".

>            printf("Key ID is %lx\n", (long) key);

key_serial_t is an int.  It doesn't really need casting to long.

David

[toc] | [next] | [standalone]

#1541010

Hello David

Thanks for the review!

On 12/13/2016 11:58 AM, David Howells wrote:
> Michael Kerrisk (man-pages) <mtk.manpages@gmail.com> wrote:
> 
>>        The destination keyring serial number may be that  of  a  valid
>>        keyring for which the caller has write permission, or it may be
>>        one of the following special keyring IDs:
> 
> No comma before "or".

Actually, I think its okay with the comma. But I decided anyway to 
reword this into two sentences.

>>        "user" This is a general purpose key type whose payload may  be
>> ...
>>       "keyring"
> 
> It probably makes sense to put keyring either first or last.

Done.

> 
>>        "keyring"
>>               Keyrings are special key types that may contain links to
>>               sequences  of other keys of any type.  If this interface
>>               is used to create a keyring, then a NULL payload  should
>>               be specified, and plen should be zero.
> 
> I think "then payload should be NULL and plen should be zero." sounds better.

Agreed. Fixed.

>>        "logon" (since Linux 3.3)
>>               This  key type is essentially the same as "user", but it
>>               does not provide reading.
> 
> "permit the key to be read" rather than "provide reading", I think.

Fixed.

>>        "big_key" (since Linux 3.13)
>>               This  key type is similar to "user", but may hold a pay‐
>>               load of up to 1 MiB.  If the key payload is large,  then
>>               it  may  be stored in swap space rather than kernel mem‐
>>               ory.
> 
> "stored encrypted in swap space".

Fixed.

>>            printf("Key ID is %lx\n", (long) key);
> 
> key_serial_t is an int.  It doesn't really need casting to long.

Well, this is a common way of dealing with opaque integer system data
types, so that one does not encode a representational dependency into
printf(). (Relies on the assumption that the underlying type is no
bigger than long. The alternative these days is a cast to (intmax_t) 
plus %jd.) [So, for the moment, I'll leave the text as is.]

Cheers,

Micael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

[toc] | [prev] | [next] | [standalone]

#1541013

Michael Kerrisk (man-pages) <mtk.manpages@gmail.com> wrote:

> > "stored encrypted in swap space".
> 
> Fixed.

Since 4.8, that is.

David

[toc] | [prev] | [next] | [standalone]

#1541021

On 13 December 2016 at 12:37, David Howells <dhowells@redhat.com> wrote:
> Michael Kerrisk (man-pages) <mtk.manpages@gmail.com> wrote:
>
>> > "stored encrypted in swap space".
>>
>> Fixed.
>
> Since 4.8, that is.

Which commit was that? I could not find it?


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

[toc] | [prev] | [next] | [standalone]

#1541025

On Tue, Dec 13, 2016 at 11:49 AM, Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com> wrote:
> On 13 December 2016 at 12:37, David Howells <dhowells@redhat.com> wrote:
>> Michael Kerrisk (man-pages) <mtk.manpages@gmail.com> wrote:
>>
>>> > "stored encrypted in swap space".
>>>
>>> Fixed.
>>
>> Since 4.8, that is.
>
> Which commit was that? I could not find it?
13100a72f40f5748a04017e0ab3df4cf27c809ef, v4.7-rc1~124^2~2^2~2^2~1

>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/



-- 
Eugene Syromyatnikov
mailto:evgsyr@gmail.com
xmpp:esyr@jabber.{ru|org}

[toc] | [prev] | [next] | [standalone]

#1541048

Hi Eugene,

On 13 December 2016 at 13:06, Eugene Syromyatnikov <evgsyr@gmail.com> wrote:
> On Tue, Dec 13, 2016 at 11:49 AM, Michael Kerrisk (man-pages)
> <mtk.manpages@gmail.com> wrote:
>> On 13 December 2016 at 12:37, David Howells <dhowells@redhat.com> wrote:
>>> Michael Kerrisk (man-pages) <mtk.manpages@gmail.com> wrote:
>>>
>>>> > "stored encrypted in swap space".
>>>>
>>>> Fixed.
>>>
>>> Since 4.8, that is.
>>
>> Which commit was that? I could not find it?
> 13100a72f40f5748a04017e0ab3df4cf27c809ef, v4.7-rc1~124^2~2^2~2^2~1

Thanks! See my reply  (in a moment) on the keyrings(7) page.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web