text:
Cleanup: Improve the wording in the greeting endpoint description.

Rephrased the description of the greeting endpoint to add clarity.
@rhoads-zach please take a look and merge if it looks OK to you.
resolves #298

@Ladicek I've fixed the endpoint name. Thanks for the feedback:)

LGTM, merging.

merged: https://github.com/openshiftio/appdev-documentation/commit/313b765597e327d462b1d3ca0de41635aa338b5f

source: gharchive/pull-request

repo: openshiftio/appdev-documentation

license_type: permissive

license_source: github-api


text:
How to return an output from a handler function?

Hi there,
I may just be missing something, but is there any way to return a value from a handler function once a message is received? All of the examples I saw in the documentation used the handler function simply to print a phrase.
I have code where one agent waits to receive "I'm Ready" signals from all other agents before sending a particular message. As such, I want to update a variable from inside the handler function every time a message is received. I have tried using global variables inside the handler function with no luck. Besides this, the only way I know how to get an output value from a function is to put it in this form:
output = function(input)
Since the handlers are set up inside the connection based on their topic, I don't see any way to specify this output....
Here is an example to illustrate what I'm saying:
AgentManager.connect(Agent1, handler = {'Intro': log_message, 'ImReady': tallyreadies})

Agent1 is set up to publish. AgentManager has connected to Agent1's publishing address. When receiving a message of the topic "ImReady", the AgentManager uses the following function:
def tallyreadies(agent, message):
    global ScenarioReady
    ScenarioReady = 1*int(message)

I have tested this and the ScenarioReady variable does not update outside the function. I have also tried:
def tallyreadies(agent, message):
    ScenarioReady = 1*int(message)
    return ScenarioReady

I'm probably missing something obvious, but I have been stuck on it for awhile. Does anyone have any suggestions?
Thanks so much!
Sam

Hello,
Hopefully, I'm not missing anything.
The only cases in which you would want to return (or yield) something from a handler would be when that returned object is to be sent to another agent:

After a request is received in a SYNC_PUB socket.
After a request is received in an ASYNC_REP or a REP socket.

Since in any other case we won't be sending a message back, we do not have to return anything.
If I understood correctly, I would try something like this (supposing you know the total number of agents which will be connected to AgentManager):

In the AgentManager, create an attribute of type set() (list without repeated elements).
Set the handler for the 'ImReady' topic to a function that will add the received message to the set.
From the sending agents, send their uuid along the 'ImReady' topic. You should send it periodically (with a each timer) since messages sent before the communication is stablished might be lost using the PUB/SUB pattern.
In the AgentManager, wait until the length of the set() created before reaches the number of agents.

Since we are storing only unique uuid's in AgentManager and each Agent would be sending its own uuid, when both lenghts are equal it would mean

Hi @sjanko2,
You must realize agents, by default, are system processes. When you create one, a fork occurs and the child process gets a copy of the state of the father. This means that, if you try to modify a global variable, you will be modifying the copy on the child (Unix systems implement copy-on-write). Maybe that is why you see that "unexpected" behavior (which is totally expected). :stuck_out_tongue_winking_eye:
If you want to keep state within the agent, you should use an attribute instead:
def tallyreadies(agent, message):
    # Change the value of an attribute in the agent
    agent.scenario_ready = 1 * int(message)

If you want to share state between agents, then use message passing, or take advantage of the proxies if performance is not critical.
Please, if you have other questions make sure to provide a minimal, complete and verifiable example. Many times code is easier to understand than words. :wink:

Hello,
Thank you so much for the suggestions. I apologize for not including a more complete example before.
Attached I have included an example of three agents. Agent 1 acts as the "AgentManager" previously mentioned, while Agent 2 and Agent 3 are the other agents that send the "Im Ready" message to Agent 1.
I have attempted to create an attribute of type set in Agent 1. However, I cannot figure out how to add to the set from inside the function... I think I may need more clarification on how to do that. The messages from Agent 2 and Agent 3 specify a number (Agent 2 sends "2" and Agent 3 sends "3"), so Agent 1 is waiting for a set that has 2 unique values to continue.
Please run these in order: Agent1.py, Agent2.py, then Agent3,py.
Thank you so, so much as always!! You guys are awesome. :)
Sam

Agent1.py
from osbrain import run_agent
from osbrain import run_nameserver
import osbrain
import time

osbrain.config['TRANSPORT'] = 'tcp'

def tallyreadies(agent, message):
    Agent1Proxy.ScenarioReady.add(message)

if __name__ == '__main__':

    # Start the nameserver:
    ns = '127.0.0.1:1124'
    nsP = run_nameserver(ns)

    # Run the Agent
    Agent1Proxy = run_agent('Agent1', ns)

    # Create address for Agent1's publishing
    Agent1PubAdderess = Agent1Proxy.bind('PUB', alias = 'PUBStream')

    # Create ScenarioReady attribute of type set()
    Agent1Proxy.ScenarioReady = set()
    print(type(Agent1Proxy.ScenarioReady))
    print(Agent1Proxy.ScenarioReady)

    # Have this agent wait until the other agents have registered:
    print('Waiting for all agents to arrive...')
    agentsinNS = osbrain.nameserver.NameServer.agents(nsP)

    while len(agentsinNS) < 3:
        agentsinNS = osbrain.nameserver.NameServer.agents(nsP)

    print('All agents have arrived!')
    print('The agents in the nameserver are: %s' %agentsinNS)

    # Create proxies to all agents and save publishing addresses
    Agent2Proxy = nsP.proxy(agentsinNS[1])
    Agent2PubAdderess = Agent2Proxy.bind('PUB', alias = 'PUBStream')

    Agent3Proxy = nsP.proxy(agentsinNS[2])
    Agent3PubAddress = Agent3Proxy.bind('PUB', alias = 'PUBStream')

    # Connect Agent 1 to all other agents
    Agent1Proxy.connect(Agent2PubAdderess, handler = {'ImReady': tallyreadies})
    Agent1Proxy.connect(Agent3PubAddress, handler = {'ImReady': tallyreadies})

    # Have Agent 1 wait until all agents have said they are ready
    while len(Agent1Proxy.ScenarioReady) < 3:
        print ('Agents are not ready yet.')
        time.sleep(3)

    # Send message to all saying we are ready to begin
    Agent1Proxy.send('PUBStream', 'All agents are ready! We will now begin.', topic = 'Intro')

Agent2.py
from osbrain import run_agent
from osbrain import run_nameserver
import osbrain
from osbrain.proxy import NSProxy, locate_ns
import time

osbrain.config['TRANSPORT'] = 'tcp'

def log_message(agent, message):
    agent.log_info('Received: %s' % message)

if __name__ == '__main__':

    # Get nameserver proxy
    ns = '127.0.0.1:1124'
    nsaddr = locate_ns(ns)
    nsP = NSProxy(nsaddr)

    # Run the Agent
    print('Registering Agent 2 with the server...')
    Agent2Proxy = run_agent('Agent2', nsaddr)
    print('Agent registered!')
    time.sleep(3)

    # Create proxy to Agent 1 and connect to receive Intro message
    Agent1Proxy = nsP.proxy('Agent1')

    # Wait for proxy to set up
    checkstatus = Agent1Proxy.get_attr('running')

    while checkstatus == False:
        checkstatus = Agent1Proxy.get_attr('running')

    Agent1PubAddress = Agent1Proxy.addr('PUBStream')
    Agent2Proxy.connect(Agent1PubAddress, handler = {'Intro': log_message})

    # Other stuff happens here with agent "prepping" -- in my code, it is contacting a DB and gathering info
    ################
    time.sleep(3)

    # Tell Agent 1 that Agent 2 is ready
    Agent2Proxy.each(3, Agent2Proxy.send('PUBStream', '2', topic = 'ImReady'))
    print('Im Ready message sent!')

Agent3.py
from osbrain import run_agent
from osbrain import run_nameserver
import osbrain
from osbrain.proxy import NSProxy, locate_ns
import time

osbrain.config['TRANSPORT'] = 'tcp'

def log_message(agent, message):
    agent.log_info('Received: %s' % message)

if __name__ == '__main__':
    # Get nameserver proxy
    ns = '127.0.0.1:1124'
    nsaddr = locate_ns(ns)
    nsP = NSProxy(nsaddr)

    # Run the Agent
    print('Registering Agent 3 with the server...')
    Agent3Proxy = run_agent('Agent3', nsaddr)
    print('Agent registered!')

    # Create proxy to Agent 1 and connect to receive Intro message
    Agent1Proxy = nsP.proxy('Agent1')
    Agent1PubAddress = Agent1Proxy.addr('PUBStream')
    Agent3Proxy.connect(Agent1PubAddress, handler={'Intro': log_message})

    # Other stuff happens here with agent "prepping" -- in my code, it is contacting a DB and gathering info
    ################
    time.sleep(3)

    # Tell Agent 1 that Agent 3 is ready
    Agent3Proxy.each(3, Agent3Proxy.send('PUBStream', '3', topic='ImReady'))
    print('Im Ready message sent!')

@sjanko2 A couple of comments:
Remember, read the name server documentation and:
# Do not use this
osbrain.nameserver.NameServer.agents(ns_proxy)
# But rather
ns_proxy.agents()

Also (not documented, but opened an issue for adding this, thanks :+1:):
# Instead of
nsaddr = locate_ns('127.0.0.1:1234')
nsP = NSProxy(nsaddr)
# You can simply do
nsP = NSProxy('127.0.0.1:1234')

You can currently not do this:
agent_proxy.attribute = set()

It is not documented, so I just opened an issue, thanks for reporting. :blush:
Use the set_attr method instead (it allows you to set multiple attributes at the same time):
agent_proxy.set_attr(attribute0=value0, attribute1=value1, ...)

Alternatively, if your agent is complex, you might want to go with OOP:
class AgentManager(Agent):
     def on_init(self):
          self.counter = set()
          self.size = 3
          self.bind('PUB', alias='main')

     def ready(self, name):
          self.attribute.add(value)
          if len(self.counter) < self.size:
              return
          self.send('main', 'Reached the desired count!')

agent_proxy = run_agent('alias', base=AgentManager)
# Note how we can set the `ready` method as handler using its name
agent_proxy.connect(other_address, handler='ready')

Note how, in this last example, I am not checking the moment when all agents are ready from the script (using proxies), but rather directly from the AgentManager, in the ready handler.
This is what I see at first sight. Try to play a bit and change your code to see if you can make it work with this tips. :wink:

source: gharchive/issue

repo: opensistemas-hub/osbrain

license_source: bigquery


text:
🛑 Weblate is down

In 1335e53, Weblate (https://translate.opensourcepos.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Weblate is back up in d76b077.

repo: opensourcepos/upptime

license: MIT


text:
🛑 Dev is down

In 86e3c1f, Dev (https://dev.opensourcepos.org) was down:

HTTP code: 502
Response time: 542 ms

Resolved: Dev is back up in a831a9b.


text:
added support of Immunization protocolApplied for dosageNumber

IMPORTANT: Where possible all PRs must be linked to a Github issue
Fixes https://github.com/opensrp/fhircore/pull/2790 (Sibling PR)
Engineer Checklist

[ ] I have written Unit tests for any new feature(s) and edge cases for bug fixes
[ ] I have added any strings visible on UI components to the strings.xml file
[ ] I have updated the  CHANGELOG.md file for any notable changes to the codebase
[ ] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the project's style guide
[ ] I have built and run the FHIRCore app to verify my change fixes the issue and/or does not break the app
[ ] I have checked that this PR does NOT introduce breaking changes that require an update to Content and/or Configs? If it does add a sample here or a link to exactly what changes need to be made to the content.

Code Reviewer Checklist

[ ] I have verified Unit tests have been written for any new feature(s) and edge cases
[ ] I have verified any strings visible on UI components are in the strings.xml file
[ ] I have verifed the CHANGELOG.md file has any notable changes to the codebase
[ ] I have verified the solution has been implemented in a configurable and generic way for reuseable components
[ ] I have built and run the FHIRCore app to verify the change fixes the issue and/or does not break the app

@dubdabasoduba I think we already have this implementation in place. Please check out this

@qiarie please note that I've renamed from Immunization_VaccinationProtocol to Immunization_AppliedProtocol to match what we have on FHIR docs.
cc @dubdabasoduba

authors: Lentumunai-Mark aurangzaibumer

repo: opensrp/fhircore


text:
DSA related TODO

This TODO was originally listed as part of #12982, but in #12986 @levitte asked me to open it as a separate issue.
Since this appears in a public header, do we need to take any action before beta 1?
https://github.com/openssl/openssl/blob/53c4992e0b1c79bdf5904b84e77ca7d362cc4af0/include/openssl/dsa.h#L77-L80

These do seem like candidates for deprecation, given the other infrastructure we have in place.
That said, apps/dhparam.c uses d2i_DSAparams_bio(), and providers/implementations/encode_decode/encode_key2any.c uses i2d_DSAparams_bio(), so we'd have to do the work to update those call sites before effectuating the deprecation.

Until we are completely sure that the EVP_PKEY layer can handle everything so that EVP_PKEY_get0_DSA and the other _get0_XXX's never need to be used, these all need to remain.
Topic was discussed at the OTC virtual face to face meeting (day 1) with more discussion to follow on day 2.

What is the threshold for "completely sure"?  "Just" a thorough code audit? This sounds like a recipe for never getting rid of anything -- marking something as deprecated is not a guarantee that it will be removed at any particular time, and it would help crowdsource detection of cases where the EVP_PKEY layer is insufficient.

Moving the low-level apps across to the EVP interface is how to the "sure" at a reasonable level. Right now there are major gaps at the EVP_PKEY layer that are being worked through.

Thanks for the extra detail; that sounds like a good plan to me.

There are no instances of the macros that this comment is referring to being used anywhere within current master. All of the macros were deprecated by commit f41ac0e. Therefore I think this comment should just be removed.

authors: kaduk mattcaswell t-j-h

repo: openssl/openssl


text:
.gitignore lists files in the repo

# Auto generated doc files
doc/man1/openssl-*.pod

...but....
$ ls doc/man1/openssl-*.pod
doc/man1/openssl-format-options.pod
doc/man1/openssl-namedisplay-options.pod
doc/man1/openssl-passphrase-options.pod
doc/man1/openssl-verification-options.pod

You might want to ask git what files are checked in:
$ git ls-files doc/man1
doc/man1/CA.pl.pod
doc/man1/build.info
doc/man1/openssl-asn1parse.pod.in
doc/man1/openssl-ca.pod.in
doc/man1/openssl-ciphers.pod.in
doc/man1/openssl-cmds.pod.in
doc/man1/openssl-cmp.pod.in
doc/man1/openssl-cms.pod.in
doc/man1/openssl-crl.pod.in
doc/man1/openssl-crl2pkcs7.pod.in
doc/man1/openssl-dgst.pod.in
doc/man1/openssl-dhparam.pod.in
doc/man1/openssl-dsa.pod.in
doc/man1/openssl-dsaparam.pod.in
doc/man1/openssl-ec.pod.in
doc/man1/openssl-ecparam.pod.in
doc/man1/openssl-enc.pod.in
doc/man1/openssl-engine.pod.in
doc/man1/openssl-errstr.pod.in
doc/man1/openssl-fipsinstall.pod.in
doc/man1/openssl-format-options.pod
doc/man1/openssl-gendsa.pod.in
doc/man1/openssl-genpkey.pod.in
doc/man1/openssl-genrsa.pod.in
doc/man1/openssl-info.pod.in
doc/man1/openssl-kdf.pod.in
doc/man1/openssl-list.pod.in
doc/man1/openssl-mac.pod.in
doc/man1/openssl-namedisplay-options.pod
doc/man1/openssl-nseq.pod.in
doc/man1/openssl-ocsp.pod.in
doc/man1/openssl-passphrase-options.pod
doc/man1/openssl-passwd.pod.in
doc/man1/openssl-pkcs12.pod.in
doc/man1/openssl-pkcs7.pod.in
doc/man1/openssl-pkcs8.pod.in
doc/man1/openssl-pkey.pod.in
doc/man1/openssl-pkeyparam.pod.in
doc/man1/openssl-pkeyutl.pod.in
doc/man1/openssl-prime.pod.in
doc/man1/openssl-rand.pod.in
doc/man1/openssl-rehash.pod.in
doc/man1/openssl-req.pod.in
doc/man1/openssl-rsa.pod.in
doc/man1/openssl-rsautl.pod.in
doc/man1/openssl-s_client.pod.in
doc/man1/openssl-s_server.pod.in
doc/man1/openssl-s_time.pod.in
doc/man1/openssl-sess_id.pod.in
doc/man1/openssl-smime.pod.in
doc/man1/openssl-speed.pod.in
doc/man1/openssl-spkac.pod.in
doc/man1/openssl-srp.pod.in
doc/man1/openssl-storeutl.pod.in
doc/man1/openssl-ts.pod.in
doc/man1/openssl-verification-options.pod
doc/man1/openssl-verify.pod.in
doc/man1/openssl-version.pod.in
doc/man1/openssl-x509.pod.in
doc/man1/openssl.pod
doc/man1/tsget.pod

See the difference?

So I don't really know what happened.  I just remember that at some point I had to modify the .gitignore file or else after some combination of building, cleaning, git clean -xdf, etc., etc, the build system would complain about missing doc/man1/openssl-format-options.pod   . Modifying the section in .gitignore made this problem go away but it was more of a hack than anything else.

It seems to me that the .gitignore is a bit too enthusiastic to ignore things. doc/man1/openssl-*.pod matches some files that should not in fact be ignored.

authors: anhu levitte mattcaswell


text:
SSL_read() failed (SSL: error:0A000126:SSL routines::unexpected eof while reading)

Hello, 2-3 weeks ago i started getting errors from my website based on laravel:

I can't find any reasons or solution of this error.
OS:
Ubuntu 22.04 LTS
php -v:
PHP 8.1.2 (cli) (built: Jun 13 2022 13:52:54) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.2, Copyright (c) Zend Technologies
with Zend OPcache v8.1.2, Copyright (c), by Zend Technologies
openssl version -a:
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
nginx -v:
nginx version: nginx/1.18.0 (Ubuntu)
SSL certificate from Let's encrypt via certbot

Supposedly the nginx used does not set the new option where it should do so.

Hi,
Updating nginx resolve the problem for me.
Ubuntu default nginx version 1.18 is old. The newest version is 1.22.
https://askubuntu.com/questions/1389719/install-nginx-1-20-2-on-ubuntu-20-04
http://nginx.org/en/CHANGES-1.22
Hope this may help you.

i cant update to new version nginx 1.22 becasue passenger not support
how i can solve it manualy

My public facing site is bombarded by these messages in the nginx error.log.
A quick 'dig -x' shows hostnames that are not consistent with our target audience.
Also, one host causes the messages for way longer then typical for our site usage.
Is it possible these messages are caused by some probes looking to break into SSL sessions?

i cant update to new version nginx 1.22 becasue passenger not support how i can solve it manualy

I have the same issue with Passenger holding me back and getting this massive stream of errors, a lot are from the same IP's again and again, so I think its bots hunting around. My site seems fine to access from all devices I can test it on and on https://globalsign.ssllabs.com/

Any update ?!

I got theys errors with Apache2  ..
[Sun Sep 04 13:44:07.303103 2022] [ssl:info] [pid 86541] (70014)End of file found: [client 213.216.205.177:60718] AH02008: SSL library error 1 in handshake (server thesite.fi:443)
[Sun Sep 04 13:44:07.303116 2022] [ssl:info] [pid 86541] SSL Library Error: error:0A000126:SSL routines::unexpected eof while reading
openssl version -a
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
built on: Mon Jul  4 11:20:23 2022 UTC
platform: debian-amd64
options:  bn(64,64)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-Q8dQt3/openssl-3.0.2=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-3"
MODULESDIR: "/usr/lib/x86_64-linux-gnu/ossl-modules"
Seeding source: os-specific
CPUINFO: OPENSSL_ia32cap=0x7ffaf3bfffebffff:0x29c67af
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04 LTS
Release:        22.04
Codename:       jammy
apache2 -V
Server version: Apache/2.4.52 (Ubuntu)
Server built:   2022-06-14T12:30:21
Server's Module Magic Number: 20120211:121
Server loaded:  APR 1.7.0, APR-UTIL 1.6.1
Compiled using: APR 1.7.0, APR-UTIL 1.6.1
Architecture:   64-bit
Server MPM:
Server compiled with....
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_PROC_PTHREAD_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=256
-D HTTPD_ROOT="/etc/apache2"
-D SUEXEC_BIN="/usr/lib/apache2/suexec"
-D DEFAULT_PIDLOG="/var/run/apache2.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="mime.types"
-D SERVER_CONFIG_FILE="apache2.conf"

We've updated to ubuntu 22.04 and we get the same issue while doing HTTP requests to Canvas LMS
The requests return 200 - OK but this error happens
Any solution for apache users?

We've updated to ubuntu 22.04 and we get the same issue while doing HTTP requests to Canvas LMS The requests return 200 - OK but this error happens
Any solution for apache users?

There really isn't a solution, these are spammers/scammers/hackers trying to infiltrate your server by sending malformed connections. You need to look at a WAF / Web Application Firewall to filter and block these from even getting to your web server

There really isn't a solution, these are spammers/scammers/hackers trying to infiltrate your server by sending malformed connections. You need to look at a WAF / Web Application Firewall to filter and block these from even getting to your web server

I don't follow,  i mean we get this error when sending requests, not when receiving or something

There really isn't a solution, these are spammers/scammers/hackers trying to infiltrate your server by sending malformed connections. You need to look at a WAF / Web Application Firewall to filter and block these from even getting to your web server

I don't follow,  i mean we get this error when sending requests, not when receiving or something

These warnings are normally from hackers trying to infiltrate your web server. They send incorrectly formed ssl connection requests. If you are the one initiating the connections then it's a confit option. Are both ends using http/2 with correct certificates? Try https://hstspreload.org/ and https://globalsign.ssllabs.com/analyze.html

These warnings are normally from hackers trying to infiltrate your web server. They send incorrectly formed ssl connection requests. If you are the one initiating the connections then it's a config problem. Are both ends using http/2 with correct certificates? Try https://hstspreload.org/ and https://globalsign.ssllabs.com/analyze.html

Certificates are correct but not sure how to see if both servers provide http/2, i mostly see http/1.1
Both servers also have "no" next to SSL 2 and SSL 3 under protocols
Which config would be the trigger? The server we send request from, or the server we send request to?

My Scene:

I use openssl ciphers -v | awk '{print $2}' | sort | uniq fetch openssl ciphers for shown
Information:
Trans Server:
Os : RockyLinux 9
openssl version:  OpenSSL 3.0.1 14 Dec 2021 (Library: OpenSSL 3.0.1 14 Dec 2021)
nginx version: nginx/1.22.1
Kernel :Linux fa-xx 5.14.0-70.22.1.el9_0.x86_64 #1 SMP PREEMPT Tue Aug 9 19:45:51 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
openssl ciphers: SSLv3 TLSv1 TLSv1.2 TLSv1.3

Business Server
Os : Centos 7
openssl version:  OpenSSL 1.0.2k-fips  26 Jan 2017
nginx version: nginx/1.20.2
Kernel :Linux business-xx 3.10.0-1160.36.2.el7.x86_64 #1 SMP Wed Jul 21 11:57:15 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
openssl ciphers: SSLv3  TLSv1.2

Hopes to refound this question.

I faced the same unexpected eof issue on a Rocky 9.1.
I've tested with the native openssl version then build 3.0.7 and also compile the 3.1 release.
I've got alwas the following message :
OpenSSL 3.1.0-beta1 21 Dec 2022 (Library: OpenSSL 3.1.0-beta1 21 Dec 2022)
[root@rundeck bin]# ./openssl s_client -debug -connect ansible-galaxy.s3.amazonaws.com:443
CONNECTED(00000003)
write to 0x24e32b0 [0x24f6ba0] (333 bytes => 333 (0x14D))
0000 - 16 03 01 01 48 01 00 01-44 03 03 15 5c fb b1 45   ....H...D...\..E
0010 - a8 74 1c bd 0a b0 19 29-48 ba 36 0a 18 c7 0d 62   .t.....)H.6....b
0020 - 3e dd db 89 36 c8 f6 ff-85 7c 14 20 da e8 c1 e0   >...6....|. ....
0030 - bf 8e af db b3 72 61 e3-c2 be fb 73 4a 1e 01 b8   .....ra....sJ...
0040 - 4c 38 67 fd ce 6f fe da-16 89 e6 0e 00 3e 13 02   L8g..o.......>..
0050 - 13 03 13 01 c0 2c c0 30-00 9f cc a9 cc a8 cc aa   .....,.0........
0060 - c0 2b c0 2f 00 9e c0 24-c0 28 00 6b c0 23 c0 27   .+./...$.(.k.#.'
0070 - 00 67 c0 0a c0 14 00 39-c0 09 c0 13 00 33 00 9d   .g.....9.....3..
0080 - 00 9c 00 3d 00 3c 00 35-00 2f 00 ff 01 00 00 bd   ...=.<.5./......
0090 - 00 00 00 24 00 22 00 00-1f 61 6e 73 69 62 6c 65   ...$."...ansible
00a0 - 2d 67 61 6c 61 78 79 2e-73 33 2e 61 6d 61 7a 6f   -galaxy.s3.amazo
00b0 - 6e 61 77 73 2e 63 6f 6d-00 0b 00 04 03 00 01 02   naws.com........
00c0 - 00 0a 00 16 00 14 00 1d-00 17 00 1e 00 19 00 18   ................
00d0 - 01 00 01 01 01 02 01 03-01 04 00 23 00 00 00 16   ...........#....
00e0 - 00 00 00 17 00 00 00 0d-00 2a 00 28 04 03 05 03   .........*.(....
00f0 - 06 03 08 07 08 08 08 09-08 0a 08 0b 08 04 08 05   ................
0100 - 08 06 04 01 05 01 06 01-03 03 03 01 03 02 04 02   ................
0110 - 05 02 06 02 00 2b 00 05-04 03 04 03 03 00 2d 00   .....+........-.
0120 - 02 01 01 00 33 00 26 00-24 00 1d 00 20 4e 0c bd   ....3.&.$... N..
0130 - 21 d4 5a 11 b3 0d de 4a-fc ac 25 7c 4c a3 bd b4   !.Z....J..%|L...
0140 - 8e ea 65 df 8f 5f f4 15-21 a9 8c 38 66            ..e.._..!..8f
read from 0x24e32b0 [0x24ed983] (5 bytes => 0)
write to 0x24e32b0 [0x24f6ba0] (7 bytes => 7 (0x7))
0000 - 15 03 01 00 02 02 32                              ......2
805B9E32657F0000:error:0A000126:SSL routines:ssl3_read_n:unexpected eof while reading:ssl/record/rec_layer_s3.c:321:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 340 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
read from 0x24e32b0 [0x249e970] (8192 bytes => 0)

hope it coule help

I am getting this error with Postfix. The latest version of Postfix 3.7.4 that got released yesterday has implemented this >

Workaround: with OpenSSL 3 and later always turn on SSL_OP_IGNORE_UNEXPECTED_EOF, to avoid warning messages and missed opportunities for TLS session reuse. This is safe because the SMTP protocol implements application-level framing, and is therefore not affected by TLS truncation attacks. Fix by Viktor Dukhovni.

On Arch Linux, only Postfix 3.7.3 is available.
https://archlinux.org/packages/extra/x86_64/postfix/
So I will update the PKGBUILD manually.

nginx version: nginx/1.18.0 (Ubuntu)

Try to use nginx/1.22.0 , Rockylinux + nginx/1.22 solved my issue.

I have the same error message in apache2 error log. No nginx in place.
Ubuntu 22.04.3 LTS
openssl version -a
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
built on: Wed May 24 17:12:55 2023 UTC
platform: debian-amd64
options:  bn(64,64)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-Z1YLmC/openssl-3.0.2=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-3"
MODULESDIR: "/usr/lib/x86_64-linux-gnu/ossl-modules"
Seeding source: os-specific
CPUINFO: OPENSSL_ia32cap=0xbeb82221479bfffd:0x0

apache2 -V
[Tue Oct 10 05:49:56.930942 2023] [core:warn] [pid 78819] AH00111: Config variable ${APACHE_RUN_DIR} is not defined
apache2: Syntax error on line 80 of /etc/apache2/apache2.conf: DefaultRuntimeDir must be a valid directory, absolute or relative to ServerRoot
Server version: Apache/2.4.52 (Ubuntu)
Server built:   2023-05-03T20:02:51
Server's Module Magic Number: 20120211:126
Server loaded:  APR 1.7.0, APR-UTIL 1.6.1
Compiled using: APR 1.7.0, APR-UTIL 1.6.1
Architecture:   64-bit
Server MPM:
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_PROC_PTHREAD_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/etc/apache2"
 -D SUEXEC_BIN="/usr/lib/apache2/suexec"
 -D DEFAULT_PIDLOG="/var/run/apache2.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="mime.types"
 -D SERVER_CONFIG_FILE="apache2.conf"

The server has been setup from scratch. So there was not upgrade of Ubuntu or Apache ....

Closing since this is marked as resolved.

authors: HLFH Janvanoorschot MichaelBelgium MiesSuomesta ashrafalzyoud averlon flotho imvkmark mattcaswell seanwmitchell shinoaq t8m wakango


text:
Bringing package scripts into the fold

I've been building the semi-official binary releases of OpenSSL for Windows for many years.  Had a good chat with Tam, Anton, and Hugo this morning and want to start the process of getting the scripts I currently use cleaned up and imported "somewhere" under the formal purview of the main OpenSSL project.  This issue exists to make sure the process is done with positive public input and transparency.
Currently, I use a hodgepodge of technologies to produce the binaries in 3 to 4 phases (depending on how you want to view the process), including one old Borland C++ binary from some ancient version of that compiler.  There are a number of hardcoded paths, which will make it a bit difficult to replicate the setup I use in other environments.  So I believe a progressive approach will be best rather than trying to do everything that needs to be done all at once.
The first thing to do will be to decide where various things need to live.  Should the scripts for Windows live off of the 'ms' subdirectory or live in its own repo or something else entirely different?  A separate repo seems like the best option to me to afford less confusion and those with package script access aren't necessarily the same people as those with main repo access.  If a repo is the preferred route, let's get that setup as well as whatever relevant access, if any - a pull request/merge approach is fine with me as well.  This whole process will likely take a while, so I don't think there's a rush to get this done in time for the next version tag as long as it happens and active progress is made.
I'm happy to do the work involved and look forward to feedback on this endeavor.

Are the scripts version specific? i.e. do you have 3.0 scripts and separate 1.1.1 scripts? Or do the same scripts cover multiple versions?

Some of both.  The InnoSetup/Wix installer scripts themselves are version specific.  That is partly due to changes to OpenSSL that happen over time but also maintaining the same version of Visual Studio across version releases.  For example, 1.1.1 is built against VS 2017 while 3.0 and 3.1 are built against VS 2019.  (3.1 is still VS 2019 because when I went to install VS 2022, the installer for VS failed to install several important components.  I wasn't confident on the stability of that install, so I ended up going back to VS 2019.)
There are several scripts I use that are more generic-ish and not necessarily version specific.  I still end up tweaking those a little here and there to deal with new release issues but they are largely stable.

I would put the packaging stuff in a separate repository, for now.  It's possible that we can integrate it into the main source alter on, but I believe that will take some scrutiny.

Sounds good to me.  I've already begun work on this project.  I'm taking what I've currently got and I'm reworking it to:  Clean up folder structures, eliminate hardcoded paths, and make a simplified, unified tool that will hopefully be more generic and repeatable.  Fewer things that can go wrong is generally better for everyone.
It'll be a few more days before I have anything ready.  I'll start posting some updates once I get the first working build.

We discussed this and the feeling is we should create a repository called openssl/installer with a subdirectory for Windows (could contain non-Windows installers in future, but just Windows for now).
We'll get this repo created and then you can raise a PR against it. And again, thanks for the effort.

I've got the first set of installers building successfully.  The unified script can only build OpenSSL 3.1 for x86 (VC-WIN32) at the moment but expanding that to other base versions and architectures should happen soon.
For now I'm just aiming for parity/equivalence to what the existing scripts do with a few minor tweaks/improvements here and there (e.g. reducing 8 builds to 6).

Okay, over the past few days, I got all architectures building for 1.1.1 (x86 and x64), 3.0 (x86, x64, and arm64), and 3.1 (x86, x64, and arm64).  I also added ZIP file generation for two portable edition flavors.
Since I don't see an openssl/installer repository, I went ahead and created a temporary repo:
https://github.com/slproweb/openssl-packagers/tree/main/ms-windows
Addressing the elephant in the room up front:  Why is the unified build tool written in PHP?  Mostly because I know PHP and also because the existing scripts are/were written in PHP (and .bat files).  It was faster (it only took one week) and easier to simply port all of the existing code over into the new tool and clean up the code than to try to rewrite it all at the same time in a language I don't know and would have to go find a beginner's tutorial for (i.e. I'm not all that familiar with Perl beyond running it for the Configure step).  PHP also happens to run just fine on the command line.  At any rate, getting something working first was more important.
With that out of the way, feel free to analyze the code and templates, provide feedback, ask questions, etc.  I tried to comment and document everything fairly liberally and organized the code and resources to hopefully make it easier to follow along with and understand.
The 'deps' and 'profiles' portions, the base version JSON files, and some of the automation bits are, more or less, the only brand new code and resources.  Everything else is largely untouched and just reworked slightly to fit into the unified tool.  I did notice that 3.0 and 3.1 have virtually identical Inno Setup and Wix toolset scripts and JSON after transforming them into templated variants, which means there could be a way to simplify those even further.

Looks very nice!
I've read through the README and scanned through various of the template files to get a feel for it.
I don't think PHP is a big concern. It wouldn't be acceptable for the main source repo because that code has to be able to run everywhere and on all sorts of platforms and environments. But for this code we only need it to run in certain well defined environments and its not a big deal to add additional build-time dependencies for that.
I am a noob as far as windows installers are concerned so I can only provide limited feedback - but I spotted some interesting things in templates/3.1/info.json:
				"configure_target": "VC-WIN32",
				"configure_extra": "-D_USE_32BIT_TIME_T -D_WINSOCK_DEPRECATED_NO_WARNINGS -D_WIN32_WINNT=0x0501",

and
				"configure_target": "VC-WIN64A",
				"configure_extra": "-D_WINSOCK_DEPRECATED_NO_WARNINGS -D_WIN32_WINNT=0x0502",

0x0501 corresponds to Windows XP I think, and 0x0502 is Windows Server 2003. I wonder whether those are the correct versions to be targeting. OpenSSL itself is supposed to be able to support anything from Windows XP onwards - but whether we want to support that far back in a binary is another question. IIRC there are various optimisations in the code if we are allowed to assume a later version.
I'm also interested in why the other defines are needed.
Anyway, it looks very good so far. It will be easier to review once we have a repository set up and we can create PRs against it.

Here's the full build section from the JSON:
			"build": {
				"configure_target": "VC-WIN32",
				"configure_extra": "-D_USE_32BIT_TIME_T -D_WINSOCK_DEPRECATED_NO_WARNINGS -D_WIN32_WINNT=0x0501",
				"patches": {
					"/Zi ": "/Z7 ",
					"/subsystem:console ": "/subsystem:console,5.01 ",
					"CNF_LDFLAGS=": "CNF_LDFLAGS=/subsystem:console,5.01 "
				}

Above was extracted from:
https://github.com/slproweb/openssl-packagers/blob/main/ms-windows/templates/3.1/info.json
The defines were pulled from the existing build scripts.  They are various tweaks I made to the Makefile over the years to address various concerns that came up.  Some of those concerns may or may not still be valid but I'll try to address them here from what I recall:
The _USE_32BIT_TIME_T define originally came from:  http://groups.google.com/group/mailing.openssl.users/browse_thread/thread/006b8e8b8c8463d0/447180a3a6c167bf?lnk=raot
The _WINSOCK_DEPRECATED_NO_WARNINGS define has been in there basically forever.  I think at one point the deprecated Winsock warnings triggered a build failure.  Adding the define made the problem go away.
The _WIN32_WINNT version define is used by the Windows SDK to prevent newer APIs from being used.  It doesn't guarantee that won't happen though.  0x0502 is the first version of Windows with a 64-bit build of the OS.  I'm pretty sure that was Windows XP Professional, x64 edition, which never really saw broad deployment, but it did exist.
The /Zi to /Z7 patch deals with linker issues when mixing versions of the Visual C++ compiler/linker.  The generated libraries may work with one version of the compiler/linker but not others.  I don't recall the exact problem but someone suggested that as the fix, I researched the options to make sure it seemed sane, and it seemed to work because the problems vanished.
The two /subsystem:console,5.01 patch lines force the final linked EXEs/DLLs to declare themselves to be Windows XP compatible.  That doesn't mean the executable itself will load and run (e.g. DLL loader failures) but at least it won't be due to an artificial limitation within the EXE itself.
Just to point out that this is a nearly 1:1 port of my existing code - weird build warts and all - with some tweaks to cater better to the project's needs.  You don't have to use those patches or you could backport some or all of the patches into the mainline or do something entirely different.  This was a first pass to get everything into one place as it currently exists.
			// Nothing is perfect.  Patch the makefile.
			$data = file_get_contents($pathmap["[[SOURCE_TEMP_DIR]]"] . "/makefile");

			foreach ($archinfo["build"]["patches"] as $key => $val)
			{
				$data = str_replace($key, $val, $data);
			}

			// The 'no-shared' build should only generate statically linked libraries and executables.
			if (strpos($configuretype, "no-shared") !== false)
			{
				$data = str_replace("MODULES=providers\\legacy.dll", "MODULES=", $data);
				$data = str_replace("MODULEPDBS=providers\\legacy.pdb", "MODULEPDBS=", $data);
			}

			// Fix the build type.
			$data = str_replace(" /MTd ", " " . $buildtype . " ", $data);
			$data = str_replace(" /MTd\r\n", " " . $buildtype . "\r\n", $data);
			$data = str_replace(" /MT ", " " . $buildtype . " ", $data);
			$data = str_replace(" /MT\r\n", " " . $buildtype . "\r\n", $data);

			$data = str_replace(" /MDd ", " " . $buildtype . " ", $data);
			$data = str_replace(" /MDd\r\n", " " . $buildtype . "\r\n", $data);
			$data = str_replace(" /MD ", " " . $buildtype . " ", $data);
			$data = str_replace(" /MD\r\n", " " . $buildtype . "\r\n", $data);

			file_put_contents($pathmap["[[SOURCE_TEMP_DIR]]"] . "/makefile", $data);

Above was extracted from:
https://github.com/slproweb/openssl-packagers/blob/main/ms-windows/build-tools.php#L1209
The makefile itself is patched to replace the build type with the desired build type.  Those linking their applications need support for all four main build types (MD, MDd, MT, MTd) to avoid linker errors.  shared vs. no-shared mostly gets there but there's no way to directly declare the build type.  There are some problems with software built with MT and MTd but some people want and use them anyway.  Since the DLLs export C library functions, there's not a whole lot of concern over mixing MD linked DLLs against MT/MTd libraries, especially when using DLL local resources like the memory isolated BIO API.  Mixing VC++ runtimes is not great but multiple runtimes can be loaded just fine in memory in the same process space as long as one runtime doesn't try to free another runtime's allocated memory or resources.
As a side effect of the monkey patching that happens, the legacy provider DLL fails to build altogether in the no-shared builds for whatever reason.  That's why no-shared builds neutralize those two lines in the makefile patching above.  I don't think that the failure to build nor successfully building the legacy provider DLL matters here because the intent was to produce two statically linked variants of the main openssl.exe and the legacy provider DLL is successfully compiled and linked in other builds.  Fully statically linked OpenSSL is a bit different than dynamically linked anyway.
The ability to post-patch the makefile can also make it possible to apply fixes for release level bugs where something unexpected crops up at the last minute for a specific architecture.  3.0.8 had that issue with Windows ARM64 builds, albeit that was a source code problem rather than a makefile problem, but you get the idea.

Er...  looking into the support subdirectory.  Who is CubicleSoft?

That's also me.  Second business entity.  Those libraries are open source:
https://github.com/cubiclesoft/php-misc
https://github.com/cubiclesoft/ultimate-web-scraper

openssl/installer now exists, feel free to submit your stuff as a PR.

Unless I am missing something, I don't think submitting a PR against the new repository is currently possible.  Specifically, the GitHub web interface isn't letting me fork the repo:  "Cannot fork because repository is empty."
Based on some searching Google/Stack Overflow, I'm pretty sure there has to be at least one branch on a git repo to be able to fork and submit PRs.

Argh.  I always forget that bit.
I've pushed an embryo for a .gitignore file, so now there is a main branch.

Marking as inactive.  will be closed at the end of 3.4 dev cycle

Is there still going to be a pre-built Windows binary available from the project?

I believe that will be the case.  It looks like Neil has taken over the installer and simplified it quite a bit.  I just left a note on the unfinished pull request that I had originally opened:
https://github.com/openssl/installer/pull/2#issuecomment-2153724731

@paulidale @slproweb yes, our intent is to provide binary installers.  Currently the plan is to do this in two parts:

Create the binary installer and make openssl compatible with it, tracked here: https://github.com/openssl/project/issues/643

That epic tracks the creation of the installer, and the updates needed to make openssl compatible with it (most notably the creation of registry keys to allow what were previously build time constants (like OPENSSLDIR) to be install time selectable on a per-installation basis.  This is a 3.4 deliverable

Obtain a signing certificate from a vendor to sign the installer, create a process to build and sign the installer as part of our release process, and add the installer binary as a release artifact.  The build process (minus the signing) is available in 3.4 as a manually triggered ci workflow in the installer repo now, but the rest of this will be a 3.5 deliverable.

authors: hlandau levitte mattcaswell nhorman paulidale slproweb


text:
XMSS & LMS

OpenSSL should consider providing APIs to do LMS and XMSS.
Refer to the standard: SP 800-208 for details.
Refer also to RFC 8391 and RFC 8554.

I have had a bit of a look at this previously, and the implementation may get quite complex if it needs to be fast.
There is a implementation here that sets up some ACVP test vectors https://github.com/cisco/hash-sigs.
bouncycastle (BC) also has an implementation.
The 'stateful' nature of one time use private keys is a bit different to other signature schemes.. The reuse of any OTS key is very bad. BC also has an API to reserve a block of the private keys.

Also see https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF

IMO it is a bad idea for software modules to implement signing with stateful signature schemes.
We should consider implementing just the verification part.

Agree with this approach.
It seems that the format of the data is also not standardized as part of the RFC, so that part may need to sit outside openssl somehow.

See discussion in #22357


text:
PHP Startup: Unable to load dynamic library php_curl.dll ' - Das angegebene Modul wurde nicht gefunden.  in Unknown on line 0.

When updating to SSL 1.0.2g i get PHP Startup: Unable to load dynamic library php_curl.dll - Das angegebene Modul wurde nicht gefunden. in Unknown on line 0.
I use PHP 5.2.17 VC6 TS x86

Looks like a CURL issue, not an openssl issue.  But I could be wrong.

Sure - i can recompile PHP 5.2.17 but i'm not able to do. So please keep openSSL compatible to older PHP versions as 1.0.2f works fine so far !

We try to keep things binary-compatible across letter update releases.
Please explain what broke and we'll try to fix it.

I'm only a simple user but using the new 1.0.2g libraries (libeay32.dll and ssleay.dll) cause my php to avoid loading the php_curl.dll which uses ssl functions. For me it looks like there is something wrong in environment / config of openssl ? Some users on apachelounge report mixing CRT version or additional configuration options which are needed to keep the symbols. I still use PHP 5.2.17 and cannot upgrade due to VC6 which is needed for my old webserver i use.

With dependencywalker i get the following error:
Error: At least one module (SSLEAY32.DLL) has an unresolved import due to a missing export function in an implicitly dependent module.

Referring to http://abi-laboratory.pro/tracker/compat_report/openssl/1.0.2f/1.0.2g/2ccb1/abi_compat_report.html#Removed
...you should return NULL instead of removing the SSLv2_client_method functions completely to stay binary comapatible imho ?

That's been fixed in git. If you recompile OpenSSL using "enable-ssl2" during config then you should get the missing symbols back. We made other changes in the latest 1.0.2 to ensure SSL2 isn't used by default even when you have explicitly enabled it at compile time so this should still be safe (unless applications explicitly ask for SSL2).

authors: mattcaswell petesky richsalz


text:
Building OpenSSL 1.1.1b on Sparc Solaris 11.1: libcrypto.so: "read-only segment has dynamic relocations"

Building OpenSSL 1.1.1b from source on Sparc Solaris 11.1 w/ gcc 4.8.2 and binutils 2.23.2 configured to use GNU ld (full config output at the bottom FWIW).
The following error occurs while linking libcrypto.so:
.../bin/ld: read-only segment has dynamic relocations.
collect2: error: ld returned 1 exit status

The error disappears if crypto/ec/ecp_nistz256-sparcv9.o is excluded from the ld arguments; looking at the problematic .o:
$ objdump -r .../openssl-1.1.1b/crypto/ec/ecp_nistz256-sparcv9.o

.../openssl-1.1.1b/crypto/ec/ecp_nistz256-sparcv9.o:     file format elf64-sparc-sol2

RELOCATION RECORDS FOR [.text]:
OFFSET           TYPE              VALUE
0000000000025da4 R_SPARC_PC22      _GLOBAL_OFFSET_TABLE_-0x0000000000000004
0000000000025dac R_SPARC_PC10      _GLOBAL_OFFSET_TABLE_+0x0000000000000004
0000000000025db0 R_SPARC_GOT22     OPENSSL_sparcv9cap_P
0000000000025db4 R_SPARC_GOT10     OPENSSL_sparcv9cap_P
0000000000025f24 R_SPARC_PC22      _GLOBAL_OFFSET_TABLE_-0x0000000000000004
0000000000025f2c R_SPARC_PC10      _GLOBAL_OFFSET_TABLE_+0x0000000000000004
0000000000025f30 R_SPARC_GOT22     OPENSSL_sparcv9cap_P
0000000000025f34 R_SPARC_GOT10     OPENSSL_sparcv9cap_P
0000000000025f4c R_SPARC_WDISP22   ecp_nistz256_point_add_vis3
0000000000026484 R_SPARC_PC22      _GLOBAL_OFFSET_TABLE_-0x0000000000000004
000000000002648c R_SPARC_PC10      _GLOBAL_OFFSET_TABLE_+0x0000000000000004
0000000000026490 R_SPARC_GOT22     OPENSSL_sparcv9cap_P
0000000000026494 R_SPARC_GOT10     OPENSSL_sparcv9cap_P

Looking at crypto/ec/asm/ecp_nistz256-sparcv9.pl, it appears that the problem might be with ecp_nistz256_point_add_vis3 being .globl as well as referenced in a branch instruction.  The following change appears to fix the problem:
--- openssl-1.1.1b.orig/crypto/ec/asm/ecp_nistz256-sparcv9.pl   2019-02-26 09:15:30.000000000 -0400
+++ openssl-1.1.1b/crypto/ec/asm/ecp_nistz256-sparcv9.pl        2019-05-16 00:31:36.000000000 -0400
@@ -2301,7 +2301,6 @@
 # !in1infty, !in2infty and result of check for zero.

 $code.=<<___;
-.globl ecp_nistz256_point_add_vis3
 .align 32
 ecp_nistz256_point_add_vis3:
        save    %sp,-STACK64_FRAME-32*18-32,%sp

$ perl .../openssl-1.1.1b/configdata.pm --dump

Command line (with current working directory = .../openssl-1.1.1b):

    .../perl64-5.10.1/bin/perl ./Configure --prefix=.../openssl enable-shared enable-threads enable-ssl3 enable-ssl3-method enable-weak-ssl-ciphers enable-ssl-trace solaris64-sparcv9-gcc -Wl,-rpath,\$$ORIGIN/../lib/sparcv9

Perl information:

    perl
    5.10.1 for sun4-solaris-64

Enabled features:

    aria
    asm
    async
    autoalginit
    autoerrinit
    autoload-config
    bf
    blake2
    camellia
    capieng
    cast
    chacha
    cmac
    cms
    comp
    ct
    deprecated
    des
    dgram
    dh
    dsa
    dso
    dtls
    dynamic-engine
    ec
    ec2m
    ecdh
    ecdsa
    engine
    err
    filenames
    gost
    hw(-.+)?
    idea
    makedepend
    md4
    mdc2
    multiblock
    nextprotoneg
    pinshared
    ocb
    ocsp
    pic
    poly1305
    posix-io
    psk
    rc2
    rc4
    rdrand
    rfc3779
    rmd160
    scrypt
    seed
    shared
    siphash
    sm2
    sm3
    sm4
    sock
    srp
    srtp
    sse2
    ssl
    ssl-trace
    static-engine
    stdio
    tests
    threads
    tls
    ts
    ui-console
    whirlpool
    weak-ssl-ciphers
    ssl3
    ssl3-method
    tls1
    tls1-method
    tls1_1
    tls1_1-method
    tls1_2
    tls1_2-method
    tls1_3
    dtls1
    dtls1-method
    dtls1_2
    dtls1_2-method

Disabled features:

    afalgeng                [not-linux]
    asan                    [default]   OPENSSL_NO_ASAN
    crypto-mdebug           [default]   OPENSSL_NO_CRYPTO_MDEBUG
    crypto-mdebug-backtrace [default]   OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
    devcryptoeng            [default]   OPENSSL_NO_DEVCRYPTOENG
    ec_nistp_64_gcc_128     [default]   OPENSSL_NO_EC_NISTP_64_GCC_128
    egd                     [default]   OPENSSL_NO_EGD
    external-tests          [default]   OPENSSL_NO_EXTERNAL_TESTS
    fuzz-libfuzzer          [default]   OPENSSL_NO_FUZZ_LIBFUZZER
    fuzz-afl                [default]   OPENSSL_NO_FUZZ_AFL
    heartbeats              [default]   OPENSSL_NO_HEARTBEATS
    md2                     [default]   OPENSSL_NO_MD2 (skip crypto/md2)
    msan                    [default]   OPENSSL_NO_MSAN
    rc5                     [default]   OPENSSL_NO_RC5 (skip crypto/rc5)
    sctp                    [default]   OPENSSL_NO_SCTP
    ubsan                   [default]   OPENSSL_NO_UBSAN
    unit-test               [default]   OPENSSL_NO_UNIT_TEST
    zlib                    [default]
    zlib-dynamic            [default]

Config target attributes:

    AR => "ar",
    ARFLAGS => "r",
    CC => "gcc",
    CFLAGS => "-Wall -O3",
    HASHBANGPERL => "/usr/bin/env perl",
    RANLIB => "ranlib",
    RC => "windres",
    aes_asm_src => "aes_core.c aes_cbc.c aes-sparcv9.S aest4-sparcv9.S aesfx-sparcv9.S",
    aes_obj => "aes_core.o aes_cbc.o aes-sparcv9.o aest4-sparcv9.o aesfx-sparcv9.o",
    apps_aux_src => "",
    apps_init_src => "",
    apps_obj => "",
    bf_asm_src => "bf_enc.c",
    bf_obj => "bf_enc.o",
    bn_asm_src => "asm/sparcv8plus.S sparcv9-mont.S sparcv9a-mont.S vis3-mont.S sparct4-mont.S sparcv9-gf2m.S",
    bn_obj => "asm/sparcv8plus.o sparcv9-mont.o sparcv9a-mont.o vis3-mont.o sparct4-mont.o sparcv9-gf2m.o",
    bn_ops => "BN_LLONG RC4_CHAR",
    build_file => "Makefile",
    build_scheme => [ "unified", "unix" ],
    cast_asm_src => "c_enc.c",
    cast_obj => "c_enc.o",
    cflags => "-m64 -mcpu=ultrasparc -pthread",
    chacha_asm_src => "chacha_enc.c",
    chacha_obj => "chacha_enc.o",
    cmll_asm_src => "camellia.c cmll_misc.c cmll_cbc.c cmllt4-sparcv9.S",
    cmll_obj => "camellia.o cmll_misc.o cmll_cbc.o cmllt4-sparcv9.o",
    cppflags => "",
    cpuid_asm_src => "sparcv9cap.c sparccpuid.S",
    cpuid_obj => "sparcv9cap.o sparccpuid.o",
    defines => [  ],
    des_asm_src => "des_enc-sparc.S fcrypt_b.c dest4-sparcv9.S",
    des_obj => "des_enc-sparc.o fcrypt_b.o dest4-sparcv9.o",
    disable => [  ],
    dso_extension => ".so",
    dso_scheme => "dlfcn",
    ec_asm_src => "ecp_nistz256.c ecp_nistz256-sparcv9.S",
    ec_obj => "ecp_nistz256.o ecp_nistz256-sparcv9.o",
    enable => [  ],
    ex_libs => "-lsocket -lnsl -ldl -pthread",
    exe_extension => "",
    includes => [  ],
    keccak1600_asm_src => "keccak1600.c",
    keccak1600_obj => "keccak1600.o",
    lflags => "",
    lib_cflags => "",
    lib_cppflags => "-DFILIO_H -DB_ENDIAN -DBN_DIV2W",
    lib_defines => [  ],
    md5_asm_src => "md5-sparcv9.S",
    md5_obj => "md5-sparcv9.o",
    modes_asm_src => "ghash-sparcv9.S",
    modes_obj => "ghash-sparcv9.o",
    module_cflags => "-fPIC",
    module_cxxflags => "",
    module_ldflags => "-shared",
    multilib => "/64",
    padlock_asm_src => "",
    padlock_obj => "",
    perlasm_scheme => "void",
    poly1305_asm_src => "poly1305-sparcv9.S",
    poly1305_obj => "poly1305-sparcv9.o",
    rc4_asm_src => "rc4_enc.c rc4_skey.c",
    rc4_obj => "rc4_enc.o rc4_skey.o",
    rc5_asm_src => "rc5_enc.c",
    rc5_obj => "rc5_enc.o",
    rmd160_asm_src => "",
    rmd160_obj => "",
    sha1_asm_src => "sha1-sparcv9.S sha256-sparcv9.S sha512-sparcv9.S",
    sha1_obj => "sha1-sparcv9.o sha256-sparcv9.o sha512-sparcv9.o",
    shared_cflag => "-fPIC",
    shared_defines => [  ],
    shared_extension => ".so",
    shared_extension_simple => ".so",
    shared_ldflag => "-shared",
    shared_rcflag => "",
    shared_target => "solaris-gcc",
    thread_defines => [  ],
    thread_scheme => "pthreads",
    unistd => "<unistd.h>",
    uplink_aux_src => "",
    uplink_obj => "",
    wp_asm_src => "wp_block.c",
    wp_obj => "wp_block.o",

Recorded environment:

    AR =
    BUILDFILE =
    CC = .../bin/gcc -m64
    CROSS_COMPILE =
    CXX = .../bin/g++ -m64
    HASHBANGPERL =
    OPENSSL_LOCAL_CONFIG_DIR =
    PERL = .../perl64-5.10.1/bin/perl
    RANLIB =
    RC =
    WINDRES =
    __CNF_CFLAGS =
    __CNF_CPPDEFINES =
    __CNF_CPPFLAGS =
    __CNF_CPPINCLUDES =
    __CNF_CXXFLAGS =
    __CNF_LDFLAGS =
    __CNF_LDLIBS =

Makevars:

    AR              = ar
    ARFLAGS         = r
    CC              = .../bin/gcc -m64
    CFLAGS          = -Wall -O3
    CPPDEFINES      =
    CPPFLAGS        =
    CPPINCLUDES     =
    CXX             = .../bin/g++ -m64
    CXXFLAGS        =
    HASHBANGPERL    = .../perl64-5.10.1/bin/perl
    LDFLAGS         = -Wl,-rpath,\$$ORIGIN/../lib/sparcv9
    LDLIBS          =
    PERL            = .../perl64-5.10.1/bin/perl
    RANLIB          = ranlib
    RC              = windres

NOTE: These variables only represent the configuration view.  The build file
template may have processed these variables further, please have a look at the
build file for more exact data:
    .../openssl-1.1.1b/Makefile

build file:

    .../openssl-1.1.1b/Makefile

build file templates:

    .../openssl-1.1.1b/Configurations/common0.tmpl
    .../openssl-1.1.1b/Configurations/unix-Makefile.tmpl
    .../openssl-1.1.1b/Configurations/common.tmpl

@levitte , @richsalz the code mentioned above was added in commit 5557d5f2e27ae8265d0b76227c78f2879d7f80a6, any thoughts?

I have no ideas, sorry.

Working on upgrade of OpenSSL to 1.1 in Solaris 11.4, I encountered the same problem. Compiling with Oracle Developer studio 12.5 and Solaris link editor. The ld is smart enough to give the cause right away:
cc -KPIC  -Xa -DSOLARIS_OPENSSL -Qoption cg -xregs=no%appl -xO5 -xstrconst -xdepend -m64 -xspace -L. -G -dy -z text -zdefs -Bdirect -zignore -M/usr/lib/ld/map.noexstk -M/usr/lib/ld/map.pagealign  \
        -o libcrypto.so.1.1 crypto/aes/aes-sparcv9.o ... (lots of objects elided)
                 -lsocket -lnsl -ldl -lc
Text relocation remains                         referenced
    against symbol                  offset      in file
ecp_nistz256_point_add_vis3         0x25f4c     crypto/ec/ecp_nistz256-sparcv9.o
ld: fatal: relocations remain against allocatable but non-writable sections
gmake[1]: *** [Makefile:730: libcrypto.so] Error 2

I can confirm the problem stems from ecp_nistz256_point_add_vis3 being global symbol, combined with the fact that the linker is instructed with -z text to (quoting from ld(1) man page):

force a fatal error if any relocations against non-writable, allocatable sections remain

The majority of relocations for the object file in question are GOT/PLT:
$ elfdump -r crypto/ec/ecp_nistz256-sparcv9.o

Relocation Section:  .rela.text
  index  type              offset value             addend  section symbol
    [0]  R_SPARC_PC22     0x25da4     0 0xfffffffffffffffc  .text   _GLOBAL_OFFSET_TABLE_
    [1]  R_SPARC_PC10     0x25dac     0                0x4  .text   _GLOBAL_OFFSET_TABLE_
    [2]  R_SPARC_GOT22    0x25db0     0                  0  .text   OPENSSL_sparcv9cap_P
    [3]  R_SPARC_GOT10    0x25db4     0                  0  .text   OPENSSL_sparcv9cap_P
    [4]  R_SPARC_PC22     0x25f24     0 0xfffffffffffffffc  .text   _GLOBAL_OFFSET_TABLE_
    [5]  R_SPARC_PC10     0x25f2c     0                0x4  .text   _GLOBAL_OFFSET_TABLE_
    [6]  R_SPARC_GOT22    0x25f30     0                  0  .text   OPENSSL_sparcv9cap_P
    [7]  R_SPARC_GOT10    0x25f34     0                  0  .text   OPENSSL_sparcv9cap_P
    [8]  R_SPARC_WDISP22  0x25f4c     0                  0  .text   ecp_nistz256_point_add_vis3
    [9]  R_SPARC_PC22     0x26484     0 0xfffffffffffffffc  .text   _GLOBAL_OFFSET_TABLE_
   [10]  R_SPARC_PC10     0x2648c     0                0x4  .text   _GLOBAL_OFFSET_TABLE_
   [11]  R_SPARC_GOT22    0x26490     0                  0  .text   OPENSSL_sparcv9cap_P
   [12]  R_SPARC_GOT10    0x26494     0                  0  .text   OPENSSL_sparcv9cap_P
$ elfdump -s crypto/ec/ecp_nistz256-sparcv9.o

Symbol Table Section:  .symtab
  index    value    size  type bind oth ver shndx name
    [0]        0       0  NOTY LOCL  D    0 UNDEF
    [1]  0x259e0    0x28  FUNC LOCL  D    0 .text __ecp_nistz256_mul_by_2
    [2]  0x25a60    0x94  FUNC LOCL  D    0 .text __ecp_nistz256_mul_by_3
    [3]  0x26d20    0xc4  FUNC LOCL  D    0 .text __ecp_nistz256_sub_morf_vis3
    [4]  0x25100   0x79c  FUNC LOCL  D    0 .text __ecp_nistz256_mul_mont
    [5]        0       0  SECT LOCL  D    0 .text
    [6]  0x25b80    0x8c  FUNC LOCL  D    0 .text __ecp_nistz256_sub_from
    [7]  0x26c00    0x18  FUNC LOCL  D    0 .text __ecp_nistz256_mul_by_2_vis3
    [8]  0x26e00    0x78  FUNC LOCL  D    0 .text __ecp_nistz256_div_by_2_vis3
    [9]  0x26c80    0x8c  FUNC LOCL  D    0 .text __ecp_nistz256_sub_from_vis3
   [10]  0x26e80   0x1b0  FUNC LOCL  D    0 .text __ecp_nistz256_mul_mont_vis3
   [11]  0x26c30       0  NOTY LOCL  D    0 .text __ecp_nistz256_add_noload_vis3
   [12]  0x26c20    0x5c  FUNC LOCL  D    0 .text __ecp_nistz256_add_vis3
   [13]  0x25cc0    0xb0  FUNC LOCL  D    0 .text __ecp_nistz256_div_by_2
   [14]  0x25c20    0x48  FUNC LOCL  D    0 .text __ecp_nistz256_sub_morf
   [15]  0x27040   0x180  FUNC LOCL  D    0 .text __ecp_nistz256_sqr_mont_vis3
   [16]  0x27bc0   0x500  FUNC LOCL  D    0 .text ecp_nistz256_point_add_affine_vis3
   [17]  0x258e0    0xb0  FUNC LOCL  D    0 .text __ecp_nistz256_add
   [18]  0x271c0   0x348  FUNC LOCL  D    0 .text ecp_nistz256_point_double_vis3
   [19]  0x27520   0x698  FUNC GLOB  D    0 .text ecp_nistz256_point_add_vis3
   [20]  0x25b00    0x30  FUNC GLOB  D    0 .text ecp_nistz256_sub
   [21]  0x25b40    0x34  FUNC GLOB  D    0 .text ecp_nistz256_neg
   [22]  0x25080    0x20  FUNC GLOB  D    0 .text ecp_nistz256_to_mont
   [23]        0 0x25000  OBJT GLOB  D    0 .text ecp_nistz256_precomputed
   [24]  0x268c0    0xe4  FUNC GLOB  D    0 .text ecp_nistz256_scatter_w5
   [25]  0x26b20    0x48  FUNC GLOB  D    0 .text ecp_nistz256_scatter_w7
   [26]        0       0  NOTY GLOB  D    0 UNDEF OPENSSL_sparcv9cap_P
   [27]  0x25c80    0x30  FUNC GLOB  D    0 .text ecp_nistz256_div_by_2
   [28]  0x250a0    0x20  FUNC GLOB  D    0 .text ecp_nistz256_from_mont
   [29]  0x258a0    0x30  FUNC GLOB  D    0 .text ecp_nistz256_add
   [30]  0x269c0   0x150  FUNC GLOB  D    0 .text ecp_nistz256_gather_w5
   [31]  0x26b80    0x70  FUNC GLOB  D    0 .text ecp_nistz256_gather_w7
   [32]  0x25da0   0x16c  FUNC GLOB  D    0 .text ecp_nistz256_point_double
   [33]  0x26480   0x440  FUNC GLOB  D    0 .text ecp_nistz256_point_add_affine
   [34]  0x259a0    0x30  FUNC GLOB  D    0 .text ecp_nistz256_mul_by_2
   [35]  0x25a20    0x30  FUNC GLOB  D    0 .text ecp_nistz256_mul_by_3
   [36]  0x250e0    0x18  FUNC GLOB  D    0 .text ecp_nistz256_sqr_mont
   [37]  0x25f20   0x55c  FUNC GLOB  D    0 .text ecp_nistz256_point_add
   [38]  0x250c0    0x18  FUNC GLOB  D    0 .text ecp_nistz256_mul_mont
   [39]        0       0  NOTY GLOB  D    0 UNDEF _GLOBAL_OFFSET_TABLE_
   [40]   REG_G2       0  REGI GLOB  D    0 UNDEF
   [41]   REG_G3       0  REGI GLOB  D    0 UNDEF

The offset 0x25f4c of the relocation entry for ecp_nistz256_point_add_vis3 falls into the definition of ecp_nistz256_point_add:
$ dis -n -F ecp_nistz256_point_add crypto/ec/ecp_nistz256-sparcv9.o |head -20
disassembly for crypto/ec/ecp_nistz256-sparcv9.o

ecp_nistz256_point_add()
    0x25f20:                8a 10 00 0f  mov       %o7, %g5
    0x25f24:                03 00 00 00  sethi     %hi(0x0), %g1
    0x25f28:                7f ff ff 96  call      -0x1a8        <0x25d80>
    0x25f2c:                82 10 60 00  or        %g1, 0x0, %g1
    0x25f30:                1f 00 00 00  sethi     %hi(0x0), %o7
    0x25f34:                9e 13 e0 00  or        %o7, 0x0, %o7
    0x25f38:                c2 58 40 0f  ldx       [%g1 + %o7], %g1
    0x25f3c:                9e 10 00 05  mov       %g5, %o7
    0x25f40:                c2 00 40 00  ld        [%g1], %g1
    0x25f44:                82 08 61 40  and       %g1, 0x140, %g1
    0x25f48:                80 a0 61 40  cmp       %g1, 0x140
    0x25f4c:                02 80 00 00  be        +0x0          <0x25f4c> <<<<< HERE
    0x25f50:                01 00 00 00  nop
    0x25f54:                9d e3 bd a0  save      %sp, -0x260, %sp
    0x25f58:                f0 77 a7 f7  stx       %i0, [%fp + 0x7f7]
    0x25f5c:                86 10 00 19  mov       %i1, %g3
    0x25f60:                84 10 00 1a  mov       %i2, %g2

which matches the expanded source code:
.globl  ecp_nistz256_point_add
.align  32
ecp_nistz256_point_add:
        SPARC_LOAD_ADDRESS_LEAF(OPENSSL_sparcv9cap_P,%g1,%g5)
        ld      [%g1],%g1               ! OPENSSL_sparcv9cap_P[0]
        and     %g1,(SPARCV9_VIS3|SPARCV9_64BIT_STACK),%g1
        cmp     %g1,(SPARCV9_VIS3|SPARCV9_64BIT_STACK)
        be      ecp_nistz256_point_add_vis3
        nop

        save    %sp,-STACK_FRAME-32*12-32,%sp

        stx     %i0,[%fp+STACK_BIAS-8]  ! off-load %i0
        mov     %i1,%g3
        mov     %i2,%g2
...

I.e. precisely at the branch instruction for ecp_nistz256_point_add_vis3. The function is not called from any other object file therefore can be local.
Also, the function should also be prefixed with __. Same for ecp_nistz256_point_add_affine_vis3 and ecp_nistz256_point_double_vis3 - these are also local (and jumped into using the branch instruction).

authors: richsalz vladak vladr


text:
Fix a return value bug in apps/speed.c

Those functions returns less than and equal to 0 to indicate an error
occured.

I found this one should also be back ported to 1.1.1.
Besides, I found other mis-check of the EVP_KEY_xxxx return values in apps/speed.c, will fix them after this one is merged.

Pushed to master and 1.1.1 as 94bd168a9e and 312674e. Closing...


text:
Add SM2 signature algorithm to default provider

Addressing #10357
This is still in a very early stage but the skeleton is almost done. I have several unclear things that need answers from the team:

~how to pass values associated with the EVP_PKEY_CTX to the provider? (the SM2 identifier)~
~how to turn the OID into DER format for the algorithm identifiers?~
I assume that the EC key management can be reused in SM2 case, or should I create a new SM2 keymgmt?

Checklist

[ ] documentation is added or updated
[ ] tests are added or updated

Perhaps I should skip CIs at current stage...

Note that CIFuzz found a bug in this pull request. Please check the logs for details.

Note that CIFuzz found a bug in this Pull request. It was not reported because CIfuzz was in dry_mode.

Note that CIFuzz found a bug in this Pull request. It was not reported because CIfuzz was in dry_mode.

Thanks and this PR is still not finished let's see if that exist after more commits are pushed.

how to pass values associated with the EVP_PKEY_CTX to the provider? (the SM2 identifier)

Since PR #11302 has been merged so I don't think this is a problem anymore

@InfoHunter said this in https://github.com/openssl/openssl/pull/11302#issuecomment-599492733:

Since PR #11302 has been merged so I don't think this is a problem anymore

I had a re-thought on this. It seems current design doesn't allow passing the dist-ID into a provider, so the user can only set the dist-ID in advance and then the calculation of the dist-ID is computed in the update process inside a provider. Is this what you originally intended? @levitte

Not sure I understand the issue.  The SM2 ID is set with EVP_PKEY_CTX_set1_id(), and can be used after EVP_DigestSignInit() since #11302 was merged in.  That's the intention.  It mist still, however, be used before EVP_DigestSignUpdate() and EVP_DigestSignFinal() is called.  Does that make sense?  Have you found a place where this doesn't quite work out?

Well, the calling sequence you mentioned requires the caller to set the ID by using EVP_PKEY_CTX_set1_id(), and currently if the ID is not set then the call will fail. I was wondering if some implementations (provided by providers) of SM2 would like to handle the ID set by the user inside the provider - for instance to adjust the value of the ID. I am not pretty sure about this use case, but just found that the ID is transparent to the provider since it's calculated outside.  Should this calculation be part of a provider implementation? It seems there is no way to intercept the EVP_PKEY_ctrl or custom_digest stuffs in a provider, right?

You're right that EVP_PKEY_CTX_set1_id() currently only works with legacy implementations.  To work with providers, it needs to be rewritten in the same way that, for example, EVP_PKEY_CTX_set_ecdh_cofactor_mode() was rewritten.
The location for the EC control reimplementations is crypto/ec/ec_evp_lib.c

Actually I have some new ideas about the use case of handling the ID stuffs. It might be possible that some day in the future the compliance requirement changes to some new policies, say, the ID is required to less than 4 bytes..., so one can implement a 4-byte-ID-SM2 provider to comply with it... ;-)

But this is low priority - need to get this PR done first

Travis-CI failure is not relevant (timeout), considering to remove the WIP prologue

@mattcaswell , for the SM3 considerations, I found in the legacy part there is not such limit, so do we need to limit that in default provider or should we just make it compatible with what legacy part does (OpenSSL 1.1.1)

The WIP is removed from this PR.

Ping?

What is the arrangement for this PR? Any dependencies yet?

Ping @openssl/otc

Should this be included in any alpha version? maybe the next alpha-2?

This ought to be included at some point.  It isn't essential for the alpha releases but it should be done before the first beta.
I do not expect that any of the core team will have time to do this, we're relying on you or a Chinese compatriot to convert it into a provider based solution.  The conversion isn't difficult, but it could be a bit tedious.

@InfoHunter can you rebase this on latest master? A lot of things changed since the last push (sorry I did not find the time to review this sooner) so it would be better to test this against latest master.

I believe it doesn't make much sense to include this without the corresponding keymgmt part

Okay, no problem, I would probably find some time later next week to handle this.

I assume that the EC key management can be reused in SM2 case, or should I create a new SM2 keymgmt?

Kinda sorta.  We're treating SM2 as a separate key type, even though the underlying structure is the same.  You should be able to use most of the same functions for both, just make sure you keep track of what key type you're handling at all times, and there should be a separate OSSL_DISPATCH for SM2.
I've done that same sort of work, for separating plain RSA and RSA-PSS keys.  See #11751

@mattcaswell , for the SM3 considerations, I found in the legacy part there is not such limit, so do we need to limit that in default provider or should we just make it compatible with what legacy part does (OpenSSL 1.1.1)

I have personally no issues with that.  There's still the concept of the default digest type, which is up to the keymgmt to specify.

Have any of you encountered the duplicated symbol issue when building master?
duplicate symbol '_der_oid_id_shake128_len' in:
    providers/libnonfips.a(libnonfips-lib-der_digests.o)
    providers/libnonfips.a(libnonfips-lib-der_rsa.o)

Hmmm, I'll look into that.  Thosse two may need a little bit of reorganization.

I've done that same sort of work, for separating plain RSA and RSA-PSS keys. See #11751

It seems the PR number is not quite right?

It seems the PR number is not quite right?

#11710

Thanks

Refactoring of provider side DER stuff in #11868

Unfortunately, after the symbol conflicts are resolved, it seems there is still building problem with master.
Undefined symbols for architecture x86_64:
  "_BIO_get_data", referenced from:
      _bio_core_write_ex in libcommon.a(libcommon-lib-bio_prov.o)
      _bio_core_read_ex in libcommon.a(libcommon-lib-bio_prov.o)
  "_BIO_meth_free", referenced from:
      _bio_prov_init_bio_method in libcommon.a(libcommon-lib-bio_prov.o)
  "_BIO_meth_new", referenced from:
      _bio_prov_init_bio_method in libcommon.a(libcommon-lib-bio_prov.o)
  "_BIO_meth_set_create", referenced from:
      _bio_prov_init_bio_method in libcommon.a(libcommon-lib-bio_prov.o)
  "_BIO_meth_set_ctrl", referenced from:
      _bio_prov_init_bio_method in libcommon.a(libcommon-lib-bio_prov.o)
  "_BIO_meth_set_destroy", referenced from:
      _bio_prov_init_bio_method in libcommon.a(libcommon-lib-bio_prov.o)
  "_BIO_meth_set_gets", referenced from:
      _bio_prov_init_bio_method in libcommon.a(libcommon-lib-bio_prov.o)
  "_BIO_meth_set_puts", referenced from:
      _bio_prov_init_bio_method in libcommon.a(libcommon-lib-bio_prov.o)
  "_BIO_meth_set_read_ex", referenced from:
      _bio_prov_init_bio_method in libcommon.a(libcommon-lib-bio_prov.o)
  "_BIO_meth_set_write_ex", referenced from:
      _bio_prov_init_bio_method in libcommon.a(libcommon-lib-bio_prov.o)
  "_BIO_new", referenced from:
      _bio_new_from_core_bio in libcommon.a(libcommon-lib-bio_prov.o)
  "_BIO_set_data", referenced from:
      _bio_new_from_core_bio in libcommon.a(libcommon-lib-bio_prov.o)
  "_BIO_set_init", referenced from:
      _bio_core_new in libcommon.a(libcommon-lib-bio_prov.o)
      _bio_core_free in libcommon.a(libcommon-lib-bio_prov.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

@InfoHunter, would you mind telling me how you configured?

@InfoHunter, would you mind telling me how you configured?

On MacOS (with clang), the config is: config --prefix=/to/some/place enable-asan --strict-warnings

Anyway, despite of that ld failure, I updated the SM2 signature algorithm provider code a bit.

... and rebased to master as well

I believe it doesn't make much sense to include this without the corresponding keymgmt part

@romen , I looked a bit in the ec_kmgmt.c, and I think it's possible just to wrap sm2_kmgmt around ec_kmgmt - with some minor modifications, like fixing the curve to SM2 curve...

I believe it doesn't make much sense to include this without the corresponding keymgmt part

@romen , I looked a bit in the ec_kmgmt.c, and I think it's possible just to wrap sm2_kmgmt around ec_kmgmt - with some minor modifications, like fixing the curve to SM2 curve...

@InfoHunter I left some notes regarding SM2 in the description of #10631 (which also references some important comments): maybe they are still useful?
I still think sm2_keymgmt needs to be distinct, yet most of it is going to be basically a duplicate of the ec_kmgmt with minor adjustments (e.g., as you say, maybe there is no need to include a curve name).
As a side note, I will leave it to your interpretation of it as you definitely have more insight on it, but regarding removing the flexibility of choosing this or that curve underneath SM2, looking at the standards before, I had the impression it is not unlikely that in the future one or more different curves could be used and recommended under the SM2 cryptosystem.
For example, considering PQC is coming to industry and it is not limited anymore to academic debate, I can see how there might be a push in the near future to recommend a >512 bit curve as the preferred one!

I left some notes regarding SM2 in the description of #10631 (which also references some important comments): maybe they are still useful?

I reviewed the comments in #10631 and I finally recall something discussed then... Will try to resolve this SM2 key management stuff.

For example, considering PQC is coming to industry and it is not limited anymore to academic debate, I can see how there might be a push in the near future to recommend a >512 bit curve as the preferred one!

I found this is reasonable and interesting as well!

Squashed and rebased to master - Although I still can't build the final binaries on my local machine but at least I am sure the compilation is OK ;-)

@romen , would you like to show me some examples on how ec_kmgmt is used?

Hmmm, I'm actually ambivalent about having a distinct SM2 key type, as there's really nothing (apart from the default curve being SM2) that makes it distinct from an EC key.
The SM2 operation (signature), on the other hand, is distinct.
In legacy implementations, the operation type an the key type are strongly associated (which is the main reason why an EVP_PKEY_set_alias_type() call was needed, while they are less so with provider implementations.  I'm pondering if we can take advantage of that in a sane way.

SM2 keygen is different (different ranges)
it should be possible to run ECDH/DSA over the so-called SM2 curve
it should be possible to rune SM2DH/SM2DSA over any curve

I believe there is no way around having 2 separate keymgmt given these conditions!

Their serialization looks the same: that is true, and it's basically standardization debacle that generates all the confusion and the weirdness around set_alias and friends.

@romen , would you like to show me some examples on how ec_kmgmt is used?

@InfoHunter You mean how the provider interface calls into it? I think @levitte can be more helpful with that!

SM2 keygen is different (different ranges)
Right. Current SM2 key generation follows this calling sequence:

        EC_KEY *eckey = EC_KEY_new();
        EC_KEY_set_group(eckey, group);
        EC_KEY_generate_key(eckey);

I remember there was a discussion that current OpenSSL SM2 key generation does not exactly follow the SM2 specification?

it should be possible to run ECDH/DSA over the so-called SM2 curve
it should be possible to rune SM2DH/SM2DSA over any curve

For 3, we can provide that flexibility. But for 2, I am not sure if SM2 curve is actually necessary to be used with ECDSA. (ECDH may have the use case)

You mean how the provider interface calls into it?

Yes, exactly! I found some in the EVP code, but if there are more high level descriptions, that would be better.

SM2 keygen is different (different ranges)

It seems there is no special treatment on the SM2 keygen in OpenSSL 1.1.1. It should just follow the standard EC_GFp_mont_method->keygen procedures.
Are you suggesting that we should fix this in provider implementation of SM2?

SM2 keygen is different (different ranges)

Okie, that's an argument.

it should be possible to run ECDH/DSA over the so-called SM2 curve
it should be possible to rune SM2DH/SM2DSA over any curve

Sure, but those signature operations, not keymgmt.

I believe there is no way around having 2 separate keymgmt given these conditions!

Only the keygen concern seems relevant for having a separate SM2 key type.

It seems there is no special treatment on the SM2 keygen in OpenSSL 1.1.1. It should just follow the standard EC_GFp_mont_method->keygen procedures.
Are you suggesting that we should fix this in provider implementation of SM2?

Note that the legacy code for SM2 has changed in master, to avoid the dumber quirks that are still present in 1.1.1

SM2 keygen is different (different ranges)

Okie, that's an argument.

it should be possible to run ECDH/DSA over the so-called SM2 curve
it should be possible to rune SM2DH/SM2DSA over any curve

Sure, but those signature operations, not keymgmt.

I believe there is no way around having 2 separate keymgmt given these conditions!

Only the keygen concern seems relevant for having a separate SM2 key type.

@levitte they are still valid arguments because of this
https://github.com/openssl/openssl/blob/93f99b681ab5a1cf7062053323e09b0cad5ff854/providers/implementations/keymgmt/ec_kmgmt.c#L54-L64
The keymgmt says what are the operations names, so SM2 cannot reuse the EC keymgmt and then USE different operations!

SM2 keygen is different (different ranges)

It seems there is no special treatment on the SM2 keygen in OpenSSL 1.1.1. It should just follow the standard EC_GFp_mont_method->keygen procedures.
Are you suggesting that we should fix this in provider implementation of SM2?

We have an open issue regarding the defect in the 1.1.1 implementation: https://github.com/openssl/openssl/issues/8435#issuecomment-481540010
The reason why it wasn't fixed yet is exactly because of how much in 1.1.1 SM2 and ec have been tied together due to the internal architecture and serialization/deserialization issues.
In 3.0.0 we should aim for a saner implementation where the 2 cryptosystems are handled distinctly and code duplication is avoided in smarter ways!

The keymgmt says what are the operations names, so SM2 cannot reuse the EC keymgmt and then USE different operations!

We might have to re-think the returned value, for example make that a NULL-terminated array of string pointers instead of just one string.  That would allow us to return { "ECDSA", "SM2", NULL } for possible signature operations.  To be checked against a fetch EVP_SIGNATURE with EVP_SIGNATURE_is_a...  something like that.

In 3.0.0 we should aim for a saner implementation where the 2 cryptosystems are handled distinctly and code duplication is avoided in smarter ways!

We can only do so much!  If the keys in PKCS#8 form don't have any indication other than the SM2 curve, we only have an educated guess, and in doing so, we would remove any possibility to run ECDSA with the SM2 curve or SM2 signatures with other curves.

Deserialization is an issue bacuase the standardization of SM2 made them indistinguishable, true.
Somewhere in the deserialization step we probably will need to keep defaulting to "create an SM2 key if this is serialized as an EC key over the so-called-SM2-curve".
Yet it should be possible from an application that can sidestep or implement its own deserialization stage, to ask a provider to generate an EC key on the SM2 curve, and viceversa to generate an SM2 key on this nist curve.
I don't see huge benefits in unifying again the SM2 and ec keymgmt, adding the complexity of multiple alternative options for the operations that a given key object supports.

Yet it should be possible from an application that can sidestep or implement its own deserialization stage, to ask a provider to generate an EC key on the SM2 curve, and viceversa to generate an SM2 key on this nist curve.

... and then it gets saved to file, and the next time it's read from that same file, it's suddenly potentially a different key type.  If that isn't a source of confusion, I don't know what is.

Yet it should be possible from an application that can sidestep or implement its own deserialization stage, to ask a provider to generate an EC key on the SM2 curve, and viceversa to generate an SM2 key on this nist curve.

... and then it gets saved to file, and the next time it's read from that same file, it's suddenly potentially a different key type. If that isn't a source of confusion, I don't know what is.

Well, I don't think the library can solve a confusion that is embedded in the result of the standardization process.
Even having a single keymgmt for SM2 and EC will cause confusion if a user checks out the saved file: it is indistinguishable from an EC key on the SM2 curve.
Looking from this perspective, it is already confusing for a user in 1.1.1 to see that a key that looks like an EC key on disk does not compute ECDH or ECDSA when used for derive/sign!

This is my personal opinion (and I am biased because it's my proposal), but I think that:

an EC keymgmt, with its own keygen, that is associated with ECDH/ECDSA operations
a distinct SM2 keymgmt, with its own different keygen, that is associated with SM2DH/SM2DSA operations
an EC deserializer, that defaults to calling the EC keymgmt, unless the so-called-SM2-curve OID is detected for which SM2 keymgmt is used instead

is going to be cleaner than

a single keymgmt that does

EC keygen or SM2 keygen (*)
ECDH or SM2DH (*)
ECDSA or SM2DSA (*)

an EC deserializer, that sets the internal flags that choose among EC operations or SM2 operations depending on detecting the so-called-SM2-curve OID.

(*): depending on something internal and difficult to reach or override
Yes, in both cases there will still be the issue of the confusion caused by the indistinguishability of the serialized format, but we can't really escape it until the SM2 spec is revised (and probably not even then, to retain compatibility with 1.1.1), but at least we avoid creating an overloaded key object standing for 2 different cryptosystems (keys are generated in different ways, they are associated with different operations) that only share (unluckily) the serialization format.

Maybe @bbbrumley can share his thoughts about this as well, given that he has been struggling with trying to fix #8435 in 1.1.1 and can have even more insights on what could be done better at this time.

I don't see huge benefits in unifying again the SM2 and ec keymgmt, adding the complexity of multiple alternative options for the operations that a given key object supports.

One the advantages could be less code duplication. According to the discussions above, It seems the only difference we need to take care is the key generation process in the keymgmt scope.

One the advantages could be less code duplication. According to the discussions above, It seems the only difference we need to take care is the key generation process in the keymgmt scope.

Why do you need to duplicate code?  You could set a flag of some sort in the keydata (like we now do for the RSA sub-types), all that's needed then is a different constructor, and then pay attention to that flag in the few places where that's needed.  The only thing that would be duplicated is the OSSL_DISPATCH array.  I would much rather than a lot of code copying.

This is just my opinion as some random guy on the Internet.

We might have to re-think the returned value, for example make that a NULL-terminated array of string pointers instead of just one string. That would allow us to return { "ECDSA", "SM2", NULL } for possible signature operations

@levitte I feel like this is similar to the line of thinking that led to the 111 mess with SM2. "Well let's just piggy back off this -- it's similar enough" and turns out it wasn't, right?

and then it gets saved to file, and the next time it's read from that same file, it's suddenly potentially a different key type. If that isn't a source of confusion, I don't know what is.

I agree! And what you're doing in master is much better than the 111 state.

This is my personal opinion (and I am biased because it's my proposal), but I think that

@romen I agree with this proposal.
Even if it means duplicate code here and there, keep them as separate as possible.
The way I look at it is this: what if SM2 had it's own OID that wasn't under the legacy EC hierarchy? Yes that is a standardization mistake, but put that aside. Step into fantasy land for a minute.

Would you still be trying to tie in SM2 to the EC module at any level?
Including key management?
Does OpenSSL do that for ed25519? I can write that curve as a legacy curve, too ...

Ignore the standards mistake, and ask yourself these questions. I think you'll find the right decision for OpenSSL then.

This is just my opinion as some random guy on the Internet.

Thanks for the chuckle in these trying times!

I just pushed a new commit containing the separated SM2 key management skeleton (and it's only a skeleton so please consider this as WIP at current stage). The current implementation is just a copy of the EC key management. According to what Nicola proposed in the emails during the weekend, I need to replace the content with SM2 implementation. We can have a discussion on this on the upcoming online meeting on Tuesday ;-)

We could house the SM2 keymgmt in providers/implementations/keymgmt/ec_kmgmt.c and do something similar to the RSA and RSA-PSS keymgmt:
https://github.com/openssl/openssl/blob/7e4f01d8ba9983b37758eb8842c64500ee0b29ca/providers/implementations/keymgmt/rsa_kmgmt.c#L584-L626
Most pointers in the dispatch table are identical, and only the ones that need to differ are actually different. This way we minimize duplication.
At a first examination, I think the SM2 keymgmt should differ from the EC one in the following:

OSSL_FUNC_KEYMGMT_GEN (it should be a separate function, very similar to the EC one, but internally instead of EC_KEY_generate_key(ec); we should call a new internal function that behaves like it, but uses the proper range for picking the secret scalar)
OSSL_FUNC_KEYMGMT_QUERY_OPERATION_NAME (pointing to the SM2 specific operations like you have in the current version of this PR)
OSSL_FUNC_KEYMGMT_GET_PARAMS

OSSL_PKEY_PARAM_SECURITY_BITS might be defined differently for the SM2 curve?
https://github.com/openssl/openssl/blob/7e4f01d8ba9983b37758eb8842c64500ee0b29ca/providers/implementations/keymgmt/ec_kmgmt.c#L484-L520

OSSL_PKEY_PARAM_USE_COFACTOR_ECDH, OSSL_PKEY_PARAM_TLS_ENCODED_PT shouldn't be supported

OSSL_FUNC_KEYMGMT_GETTABLE_PARAMS, OSSL_FUNC_KEYMGMT_SET_PARAMS, OSSL_FUNC_KEYMGMT_SETTABLE_PARAMS should be similarly revised (seems like maybe there are no settable params leftover, but maybe there is the opportunity to add the SM2-specific USER_ID personalization string as a parameter here!)
OSSL_FUNC_KEYMGMT_IMPORT, this could probably point to a wrapper around the existing internal ec_import function. It's only goal would be to filter import calls, so that the SM2 keymgmt only accepts keys/params that are on the so-called "SM2 curve" and fail otherwise.

I am going to draw back the latest commits containing the keymgmt code in this PR and open a new PR to address this.

At a first examination, I think the SM2 keymgmt should differ from the EC one in the following:
OSSL_FUNC_KEYMGMT_GEN (it should be a separate function, very similar to the EC one, but internally instead of EC_KEY_generate_key(ec); we should call a new internal function that behaves like it, but uses the proper range for picking the secret scalar)

And SM2 needn't to provide the ability of specifying curves, did we have a consensus on this yesterday?

@InfoHunter

And SM2 needn't to provide the ability of specifying curves, did we have a consensus on this yesterday?

Regarding this I think the best course of action (and minimal work) is to leave the EC flexibility underneath, but filter so that if the curve id does not match import fails.
That way when another supported curve is added to part 5 of the SM2 standards we just have to add one more entry to the allowlist and now we don't need to refractor extra code in the keymgmt.

but maybe there is the opportunity to add the SM2-specific USER_ID personalization string as a parameter here!

The SM2 user ID seems not a param with the key itself, this ID is involved in the SM2 signature computation progress which has been addressed by @levitte months ago IIRC. So it seems we don't need to consider supporting this in the key management part of SM2

As per https://github.com/openssl/openssl/pull/12536#issuecomment-672997935 and https://github.com/openssl/openssl/pull/12536#issuecomment-673010582
This PR is going to moved into PR #12536 , so this one can be closed now.

authors: InfoHunter Leo-Neat bbbrumley levitte mattcaswell paulidale richsalz romen


text:
Build: add a make target to build the openssl application [1.1.1]

This commit adds a build_the_app make target, which essentially
builds apps/openssl, respecting all dependencies.
This target is mainly intended to be used by developers in order
to speed up compilation time.
Fixes #11932
(Backport of #11946)

I dislike this as much here as in #11946...  however, because the alternative I proposed there depends on new building features, the alternative I proposed there can't be applied in 1.1.1.
Also, considering that 1.1.1 isn't in development in the same manner as master, I don't see much value in this backport.

Ok. The motivation was consistency, so people wouldn't have to remember which targets are valid on which branch. But I get your point.

authors: levitte mspncp


text:
Add User-Agent in HTTP header / Fixing alignment for --helptext.

Pretty self-explanatory stuff.
Adding a header and fixing helptext.

The -header command can add any header.  And in 1.1 the options are auto-aligned.
Thanks!

Awesomesauce!

authors: patchon richsalz


text:
test/ec_internal_test: link with libapps.a too

Whenever the source from $target{apps_init_src} is added to the source
of a test program, it needs to be linked with libapps.a as well.  Some
init sources depend on that.
Without this, builds break on VMS because of the unresolved symbol
'app_malloc'.
On platforms that do not need anything from libapps.a, adding it is a
no-op.
This is for OpenSSL 1.1.1 only.  OpenSSL 3.0 and beyond have a
different solution.

This pull request is ready to merge

Merged
ed96022218e71efcf50c69cd6997ed85a2c37ffe test/ec_internal_test: link with libapps.a too

authors: levitte openssl-machine


text:
Correct FIPS breakage on NonStop where locale_t is not defined.

Fixes: #18232
Signed-off-by: Randall S. Becker randall.becker@nexbridge.ca

All tests passed, including FIPS on NonStop x86 for this PR. It should be applied to the openssl-3.0 branch, and master at some point. I can create another one for master if requested.

Still approved from my perspective.

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set.  Please review the updates and set the label manually.

authors: openssl-machine rsbeckerca t-j-h


text:
fips: Use salt >= 16 bytes in PBKDF2 selftest

NIST SP 800-132 [1] section 5.1 says "[t]he length of the randomly-generated portion of the salt shall be at least 128 bits", which implies that the salt for PBKDF2 must be at least 16 bytes long (see also Appendix A.2.1).
The FIPS 140-3 IG [2] section 10.3.A requires that "the lengths and the properties of the Password and Salt parameters, as well as the desired length of the Master Key used in a CAST shall be among those supported by the module in the approved mode."
As a consequence, the salt length in the self test must be at least 16 bytes long for FIPS 140-3 compliance. Switch the self test to use the only test vector from RFC 6070 that uses salt that is long enough to fulfil this requirement. Since RFC 6070 does not provide expected results for PBKDF2 with HMAC-SHA256, use the output from [3], which was generated with python cryptography, which was tested against the RFC 6070 vectors with HMAC-SHA1.
Checklist

[ ] ~documentation is added or updated~
[x] tests are added or updated

pycrypto uses OpenSSL underneath doesn't it?
What about repurposing one of the test vectors from test/recipes/30-test_evp_data/evpkdf_pbkdf2.txt?

pycrypto uses OpenSSL underneath doesn't it?
What about repurposing one of the test vectors from test/recipes/30-test_evp_data/evpkdf_pbkdf2.txt?

Any reason why those would be more trustworthy?
In fact, I'm using exactly the vector that's in that file at line 95, except with truncated output: https://github.com/openssl/openssl/blob/master/test/recipes/30-test_evp_data/evpkdf_pbkdf2.txt#L95-L100

I'm not sure of their provenance but if they weren't generated using OpenSSL, I'd consider them a better test than using vectors generated by the code under test.

3.0 also?

This isn't required for 3.0 but should be harmless to include (famous last words).

@paulidale @beldmit the comment formatting was fixed, please reapprove.
I assume there is no need to restart the 24 h wait for this style nit fix.

I confirm reapproval

Merged to master and 3.1 branches. Thank you for your contribution.

authors: beldmit neverpanic paulidale slontis t8m


text:
Enable access to group name

Adds two functions tls1_group_id2name which returns the tlsname for a given group_id and SSL_get0_group_name which surfaces that name to the "user"
This is a follow up to my previously rejected PR #20318 and the resulting discussion. It is related to #20594 but I am unsure if it addresses that issue at its core.
Since I am new to this project I would appreciate direction on if I went about surfacing the tlsname the correct way here, how I should document this new functionality, and how/where to test it.
I am aware I will need to submit a ICLA and a CCLA (If IBM hasn't submitted one already) before this can be merged.
Checklist

[x] documentation is added or updated
[x] tests are added or updated

A few updates:

I've address the style issues after reviewing https://www.openssl.org/policies/technical/coding-style.html
I've added a doc file based on reading doc files for similar surrounding functions.
I will submit my ICLA on Friday (I will have access to a printer/scanner Thursday night)
I've confirmed that IBM has previously submitted a CCLA
I am in the process of figuring out where/how to test this. I will be adding/updating a test in test/sslapitest.c

I've added some test updates, but am not confident I added enough. Feedback on my tests would be appreciated.
Also as an FYI, I emailed in my ICLA today.

CI failures are relevant

I believe I've addressed the CI failures, there was one windows build failure I was not sure about though.
If you could re-trigger the CI for me (since I'm not whitelisted)

Please rebase the PR against fresh master branch and drop the merge commit. Merge commits are not allowed.

Please rebase the PR against fresh master branch and drop the merge commit. Merge commits are not allowed.

Since most of my commits were just wip something I decided to just patch the diff and force push it.
Everything should be fine now, though I'm unsure why my CCLA situation is still unresolved (my ICLA was accepted over a week ago).

Closed and reopened to grab my CLA

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set.  Please review the updates and set the label manually.

@hlandau @paulidale please reconfirm

FYI I saw a merge conflict message so I rebased on latest master and force pushed it

'''
SSL_get_curve_name                      ?	3_2_0	EXIST::FUNCTION:
'''
should be removed from util/libssl.num

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set.  Please review the updates and set the label manually.

Needs the fix up before merge.  Approved anew once that's done.

just pushed the requested fix

This pull request is ready to merge

Squashed commits and merged to master branch. Thank you for your contribution.

Follow up Question:
Is there any way to know when this will be part of a release? From my research it would assume it needs to wait for 3.2, which doesn't seem to have an estimate yet afaik.
I'm working on some upstream usage of the new function and would prefer to have a timeline

No release date for 3.2 has been set at this stage.
I'd expect late this year, but not promises.

authors: Tarnum-tst ajbozarth openssl-machine paulidale t8m


text:
Gather controller-0 logs in nested virt molecule

As a pull request owner and reviewers, I checked that:

[x] Appropriate testing is done and actually running

/test pre-commit

/test pre-commit

/approve
/lgtm

authors: cjeanner pablintino