openssl 1.1.1 manuals

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

openssl 1.1.1 manuals

Michael Richardson

If manual pages for 1.1.1 aren't going to be posted/generated:
   could https://www.openssl.org/docs/man1.1.1
redirect to https://www.openssl.org/docs/man1.1.0?

(I think that 1.1.1 ought to be generated)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [




--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: openssl 1.1.1 manuals

J. J. Farrell-2
man1.1.1 looks OK to me, the pages all appear to be there. What is missing is a link to 1.1.1 in the little Manpages list of links on the right hand side of the page

On 27/12/2018 16:31, Michael Richardson wrote:
If manual pages for 1.1.1 aren't going to be posted/generated:
   could https://www.openssl.org/docs/man1.1.1
redirect to https://www.openssl.org/docs/man1.1.0?

(I think that 1.1.1 ought to be generated)
-- 
J. J. Farrell
Not speaking for Oracle

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: openssl 1.1.1 manuals

OpenSSL - User mailing list
In reply to this post by Michael Richardson
They are there, but the sidenav needs to be updated.


On 12/27/18, 11:31 AM, "Michael Richardson" <[hidden email]> wrote:

   
    If manual pages for 1.1.1 aren't going to be posted/generated:
       could https://www.openssl.org/docs/man1.1.1
    redirect to https://www.openssl.org/docs/man1.1.0?
   
    (I think that 1.1.1 ought to be generated)
   
    --
    ]               Never tell me the odds!                 | ipv6 mesh networks [
    ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
    ]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [
   
   
   
   

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: openssl 1.1.1 manuals

Dennis Clarke-2
On 12/27/18 11:48 AM, Salz, Rich via openssl-users wrote:
> They are there, but the sidenav needs to be updated.
>

Generally I find everything I need in the source tarball and after the
install is done everything anyone could want is installed on the system.
As for 'sidenav' that sounds like someone actually has to go tweak stuff
manually on some website. Sadly. Anyways, the source tarballs have
everything that is for certain. A lot of symlinks to be sure.

Dennis
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: openssl 1.1.1 manuals

Dr. Matthias St. Pierre
> Generally I find everything I need in the source tarball and after the
> install is done everything anyone could want is installed on the system.
> As for 'sidenav' that sounds like someone actually has to go tweak stuff
> manually on some website. Sadly. Anyways, the source tarballs have
> everything that is for certain. A lot of symlinks to be sure.
>
> Dennis

All supported manual page versions are publicly available from this site here.
https://www.openssl.org/docs/manpages.html

The missing link in the manual side bar is an oversight, which will be
fixed shortly, see https://github.com/openssl/web/pull/100

HTH,

Matthias



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: openssl 1.1.1 manuals

Michael Richardson
In reply to this post by J. J. Farrell-2
J. J. Farrell <[hidden email]> wrote:
    > man1.1.1 looks OK to me, the pages all appear to be there. What is
    > missing is a link to 1.1.1 in the little Manpages list of links on the
    > right hand side of the page

https://www.openssl.org/docs/man1.1.0/crypto/CMS_sign.html exists, but
https://www.openssl.org/docs/man1.1.1/crypto/CMS_sign.html does not.

There are other examples which I have come across.

    > On 27/12/2018 16:31, Michael Richardson wrote:

    >     If manual pages for 1.1.1 aren't going to be posted/generated:
    > could https://www.openssl.org/docs/man1.1.1 redirect to
    > https://www.openssl.org/docs/man1.1.0?

    > (I think that 1.1.1 ought to be generated)


    > --
    > J. J. Farrell Not speaking for Oracle


    > ----------------------------------------------------
    > Alternatives:

    > ----------------------------------------------------
    > --
    > openssl-users mailing list To unsubscribe:
    > https://mta.openssl.org/mailman/listinfo/openssl-users
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: openssl 1.1.1 manuals

Blumenthal, Uri - 0553 - MITLL
The docs site is screwed up.

CMS_sign is indeed documented for 1.1.1 - but you have to go there via
https://www.openssl.org/docs/man1.1.1 -> Libraries -> CMS_sign.html, which would bring you to https://www.openssl.org/docs/man1.1.1/man3/CMS_sign.html 

On 12/27/18, 14:00, "openssl-users on behalf of Michael Richardson" <[hidden email] on behalf of [hidden email]> wrote:

    J. J. Farrell <[hidden email]> wrote:
        > man1.1.1 looks OK to me, the pages all appear to be there. What is
        > missing is a link to 1.1.1 in the little Manpages list of links on the
        > right hand side of the page
   
    https://www.openssl.org/docs/man1.1.0/crypto/CMS_sign.html exists, but
    https://www.openssl.org/docs/man1.1.1/crypto/CMS_sign.html does not.
   
    There are other examples which I have come across.
   
        > On 27/12/2018 16:31, Michael Richardson wrote:
   
        >     If manual pages for 1.1.1 aren't going to be posted/generated:
        > could https://www.openssl.org/docs/man1.1.1 redirect to
        > https://www.openssl.org/docs/man1.1.0?
   
        > (I think that 1.1.1 ought to be generated)
   
   
        > --
        > J. J. Farrell Not speaking for Oracle
   
   
        > ----------------------------------------------------
        > Alternatives:
   
        > ----------------------------------------------------
        > --
        > openssl-users mailing list To unsubscribe:
        > https://mta.openssl.org/mailman/listinfo/openssl-users
    --
    openssl-users mailing list
    To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
   

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: openssl 1.1.1 manuals

Michael Richardson
In reply to this post by Dr. Matthias St. Pierre

Dr. Matthias St. Pierre <[hidden email]> wrote:
    >> Generally I find everything I need in the source tarball and after the
    >> install is done everything anyone could want is installed on the
    >> system.  As for 'sidenav' that sounds like someone actually has to go
    >> tweak stuff manually on some website. Sadly. Anyways, the source
    >> tarballs have everything that is for certain. A lot of symlinks to be
    >> sure.
    >>
    >> Dennis

    > All supported manual page versions are publicly available from this
    > site here.  https://www.openssl.org/docs/manpages.html

The listings like:

    https://www.openssl.org/docs/man1.1.1/man3/

are basically useless for navigation.

Particularly if you don't know exactly what one is looking for...
{ There is something amiss with BIO_addr_rawaddress... it's shift right.
  I don't see a problem in the HTML source though.. }

Sure, google will find some things, but usually it's the wrong version, and
one has to guess what the URL for the most recent one is.

At which point, like Dennis Clarke suggests, might as well grep the POD files
in the source code.  This is not terribly effective to find information
about how to manipulate particular object types.

(I have started writing an index by object type for my own use, but I doubt
I'll get very far)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [





--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: openssl 1.1.1 manuals

Dr. Matthias St. Pierre
> Particularly if you don't know exactly what one is looking for...
> { There is something amiss with BIO_addr_rawaddress... it's shift right.
>   I don't see a problem in the HTML source though.. }
>
> Sure, google will find some things, but usually it's the wrong version, and
> one has to guess what the URL for the most recent one is.
>
> At which point, like Dennis Clarke suggests, might as well grep the POD files
> in the source code.  This is not terribly effective to find information
> about how to manipulate particular object types.
>
> (I have started writing an index by object type for my own use, but I doubt
> I'll get very far)

The manpages are primarily what the name says: manual pages. I.e, their
primary use is the unix/linux 'man' command.

The conversion to html is an add-on to make it available via web server.
And I agree with you that static web pages are not of much help, it could
be better, more searchable.

As for grepping the POD files: There is a much simpler solution if you are using
bash on linux: Install your manual pages locally, add them to your MANPATH, and
marvel at the power of bash's tab completion.

Disclaimer: Unless you know what you are doing, you should not replace your
distribution's copy of OpenSSL by your own, but instead install it to a separate
location. For example, I have all my openssl library versions installed locally in

  /opt/openssl-dev
  /opt/openssl-1.1.1-dev
  /opt/openssl-1.1.0-dev
  /opt/openssl-1.0.2-dev

(By configuring with --prefix=/opt/openssl-dev (etc.) and then running
'make -j 16 ; sudo make install'.)

Additionally, I have a simple script and a set of aliases 'ossl', 'ossl111'
to set the MANPATH accordingly:

  cat ~/.osslpath
  export PATH=${OSSLPATH}/bin:$ORI_PATH
  export LD_LIBRARY_PATH=${OSSLPATH}/lib:$ORI_LD_LIBRARY_PATH
  export MANPATH=${OSSLPATH}/${OSSL_MANPATH}:$ORI_MANPATH

  msp@msppc:~$ alias ossl
  alias ossl='export OSSLPATH=/opt/openssl-dev   ; OSSL_MANPATH=share/man source ~/.osslpath ; echo $OSSLPATH: $(openssl version)'

  msp@msppc:~$ alias ossl111
  alias ossl111='export OSSLPATH=/opt/openssl-1.1.1-dev ; OSSL_MANPATH=share/man source ~/.osslpath ; echo $OSSLPATH: $(openssl version)'

($ORI_PATH is initally set to $PATH in my .bashrc, and the same holds for the other $ORI_XXX)

Changing to the manual pages for the correct openssl version is now a matter of
a single command,

  msp@msppc:~$ ossl
  /opt/openssl-dev: OpenSSL 3.0.0-dev xx XXX xxxx

And voila, if your tab completion is setup correctly, help is only two <TAB>s away:
 
  msp@msppc:~$ man BIO_new <TAB> <TAB>
  BIO_new                     BIO_new_file
  BIO_new_CMS                 BIO_new_fp
  BIO_new_accept              BIO_new_mem_buf
  BIO_new_bio_pair            BIO_new_socket
  BIO_new_buffer_ssl_connect  BIO_new_ssl
  BIO_new_connect             BIO_new_ssl_connect
  BIO_new_fd


Matthias

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

setting eContentType for CMS messages without CMS_PARTIAL

Michael Richardson
In reply to this post by Michael Richardson

A major way in which PKCS7 and CMS signed artifacts differ is that
the CMS artifacts include a content-type.

RFC5652 has a decision tree to decide what version of SignedData
structure to produce.  The presence of a non-"id-data" content-type
is among the decision tree, and so I understand why it can't be set after the
signature (besides, the content-type is within the signature!).

I think it's probably too complex that the only way to set the content-type
is by doing the CMS_PARTIAL work.   I think that CMS_sign() and CMS_encrypt()
ought to take a eContentType OID: but ABI issues would mean a new call.

I had to read the source code to understand the difference between
CMS_get0_type() and CMS_get0_eContentType().

I can see how one refers to the cms->contentType, and the other refers to
the same thing "as received", in the structure (RFC5652's
EncapsulatedContentInfo).   I'm not sure if there is intended to be
functional or API contract differences between the two??

I was also mystified about get0_content(), until I realized that it did not
have the word "type" in it.  I've sent some pull requests, one of which
suggests that you can't call get0_content() until CMS_final() has been called
on outgoing objects.

CMS_get0_content() returns a pointer to a pointer, and it says down at the
bottom that it can be used to modify the content.  It's clear that a
receiver (verifier/decrypter) can mutate this content as part of it's
processing: saves memory for a buffer, a copy, and a potential buffer
overflow, I guess.

It's unclear to me of what use this is for outgoing content. Clearly
one could allocate an ASN1_OCTET_STRING big enough for constructing content,
or point it at a buffer already in use.  Clearly that's nonsense if
CMS_PARTIAL is not used, and I wonder if CMS_get0_content() should return
NULL if the signature is already done.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [






--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

setting eContentType for CMS messages without CMS_PARTIAL

Michael Richardson
In reply to this post by Michael Richardson

A major way in which PKCS7 and CMS signed artifacts differ is that
the CMS artifacts include a content-type.

RFC5652 has a decision tree to decide what version of SignedData
structure to produce.  The presence of a non-"id-data" content-type
is among the decision tree, and so I understand why it can't be set after the
signature (besides, the content-type is within the signature!).

I think it's probably too complex that the only way to set the content-type
is by doing the CMS_PARTIAL work.   I think that CMS_sign() and CMS_encrypt()
ought to take a eContentType OID: but ABI issues would mean a new call.

I had to read the source code to understand the difference between
CMS_get0_type() and CMS_get0_eContentType().

I can see how one refers to the cms->contentType, and the other refers to
the same thing "as received", in the structure (RFC5652's
EncapsulatedContentInfo).   I'm not sure if there is intended to be
functional or API contract differences between the two??

I was also mystified about get0_content(), until I realized that it did not
have the word "type" in it.  I've sent some pull requests, one of which
suggests that you can't call get0_content() until CMS_final() has been called
on outgoing objects.

CMS_get0_content() returns a pointer to a pointer, and it says down at the
bottom that it can be used to modify the content.  It's clear that a
receiver (verifier/decrypter) can mutate this content as part of it's
processing: saves memory for a buffer, a copy, and a potential buffer
overflow, I guess.

It's unclear to me of what use this is for outgoing content. Clearly
one could allocate an ASN1_OCTET_STRING big enough for constructing content,
or point it at a buffer already in use.  Clearly that's nonsense if
CMS_PARTIAL is not used, and I wonder if CMS_get0_content() should return
NULL if the signature is already done.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [






--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: openssl 1.1.1 manuals

Dr. Matthias St. Pierre
In reply to this post by Blumenthal, Uri - 0553 - MITLL
> The docs site is screwed up.

Actually, it is screwed up for the older versions, not for 1.1.1:
In OpenSSL 1.1.0 and before, the pod files (the manual page sources)
would be located in <openssldir>/doc/crypto and <openssldir>/doc/ssl,
and only during the installation would be placed in the proper manX
subdirectory (X=1,3,5,7). Starting with OpenSSL 1.1.1, the pod files are
now reorganized in subdirectories doc/man1, doc/man3, doc/man5,
doc/man7, reflecting the manual section where they will finally be installed.

So the path is correct for 1.1.1 and screwed up for 1.1.0 and below.

https://www.openssl.org/docs/man1.1.1/man3/CMS_sign.html

https://www.openssl.org/docs/man1.1.0/crypto/CMS_sign.html

Matthias
 
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: openssl 1.1.1 manuals

OpenSSL - User mailing list
In reply to this post by Dr. Matthias St. Pierre
On 27/12/2018 20:39, Dr. Matthias St. Pierre wrote:

>> Particularly if you don't know exactly what one is looking for...
>> { There is something amiss with BIO_addr_rawaddress... it's shift right.
>>    I don't see a problem in the HTML source though.. }
>>
>> Sure, google will find some things, but usually it's the wrong version, and
>> one has to guess what the URL for the most recent one is.
>>
>> At which point, like Dennis Clarke suggests, might as well grep the POD files
>> in the source code.  This is not terribly effective to find information
>> about how to manipulate particular object types.
>>
>> (I have started writing an index by object type for my own use, but I doubt
>> I'll get very far)
> The manpages are primarily what the name says: manual pages. I.e, their
> primary use is the unix/linux 'man' command.
>
> The conversion to html is an add-on to make it available via web server.
> And I agree with you that static web pages are not of much help, it could
> be better, more searchable.
Consider at least including the one-line manpage summaries on the index
pages (the ones displayed by the apropos command on POSIX systems).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: openssl 1.1.1 manuals

OpenSSL - User mailing list
Great idea; https://github.com/openssl/web/issues/101


On 12/28/18, 12:39 AM, "Jakob Bohm via openssl-users" <[hidden email]> wrote:

    Consider at least including the one-line manpage summaries on the index
    pages (the ones displayed by the apropos command on POSIX systems).

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users