text:
ref(k8s): remove K8sServiceToMeshServices from Controller

Description:
This change removes the K8sServiceToMeshServices method from the k8s
Controller interface. Since K8sServiceToMeshServices only relies on
the GetEndpoints method already in the interface and nothing specific
to the unexported client implementation, it has been converted to a
function that accepts a Controller.

Testing done: Ran affected unit tests locally.

Affected area:

Functional Area

New Functionality
[ ]

CI System
[ ]

CLI Tool
[ ]

Certificate Management
[ ]

Control Plane
[X]

Demo
[ ]

Documentation
[ ]

Egress
[ ]

Ingress
[ ]

Install
[ ]

Networking
[ ]

Observability
[ ]

Performance
[ ]

SMI Policy
[ ]

Security
[ ]

Sidecar Injection
[ ]

Tests
[ ]

Upgrade
[ ]

Other
[ ]

Please answer the following questions with yes/no.

Does this change contain code from or inspired by another project? No

Did you notify the maintainers and provide attribution?

Is this a breaking change? No

Codecov Report

Merging #4372 (50fd3fc) into main (5229967) will increase coverage by 0.01%.
The diff coverage is 75.00%.

@@            Coverage Diff             @@
##             main    #4372      +/-   ##
==========================================
+ Coverage   69.18%   69.20%   +0.01%
==========================================
  Files         212      212
  Lines       14458    14450       -8
==========================================
- Hits        10003    10000       -3
+ Misses       4403     4398       -5
  Partials       52       52

Flag
Coverage Δ

unittests
69.20% <75.00%> (+0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/k8s/mock_controller_generated.go
0.00% <ø> (ø)

pkg/k8s/types.go
100.00% <ø> (ø)

pkg/providers/kube/client.go
72.22% <50.00%> (ø)

pkg/envoy/registry/services.go
89.47% <100.00%> (ø)

pkg/k8s/client.go
93.01% <100.00%> (ø)

pkg/messaging/workqueue.go
89.28% <0.00%> (-10.72%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5229967...50fd3fc. Read the comment docs.

authors: codecov-commenter nojnhuh

repo: openservicemesh/osm


text:
Switch dependencies from JCenter to Maven Central

JCenter is now deprecated and will shut down at some point, should switch dependencies to Maven Central (and ensure that they all exist there). See this error for more information:
/gradlew --warning-mode all assemble

> Configure project :
The RepositoryHandler.jcenter() method has been deprecated. This is scheduled to be removed in Gradle 8.0. JFrog announced JCenter's shutdown in February 2021. Use mavenCentral() instead. Consult the upgrading guide for further information: https://docs.gradle.org/7.0.1/userguide/upgrading_version_6.html#jcenter_deprecation
        at build_e4abrzgeaxfgmy3w1s49gzh8w$_run_closure1.doCall(/home/kevin/workspace/opensha/build.gradle:12)
        (Run with --stacktrace to get the full stack trace of this deprecation warning.)

Updated to Maven Central in 06e3032, was an easy drop in replacement and all dependencies revolved without problem (both before and after I cleared the gradle cache). FYI @pmpowers-usgs @chrisbc @voj

source: gharchive/issue

repo: opensha/opensha

license_type: permissive

license_source: github-api


text:
Don't fail on repos without base_ref

In some cases (although it's not clear when), Prow job statuses may contain entries without base_ref.
Let's ignore such jobs when we're not interested in them, and show a better message if the key is required.

/ok-to-test

source: gharchive/pull-request

authors: empovit osherdp


text:
[release-v1.11] Bump to Go v1.21

Related to https://github.com/openshift-knative/serverless-operator/pull/2451

/cc @matzew @creydr

/retest

authors: creydr pierDipi

repo: openshift-knative/eventing


text:
Remove unused code

This commit removes the following vars, which were totally unused:
* defaultTimeoutSeconds
* clientHubDynamic

Signed-off-by: Daniel Mellado dmellado@redhat.com

/lgtm

/approve

authors: danielmellado irinamihai rcarrillocruz


text:
[release-4.12] remove k8s deps

targeted backport of commits from various PRs needed to be able to remove all the k8s deps from the branch 4.12
many PRs had layered/intertwined dep trees, so picking individual commits is the most practical way to go.

/lgtm

/hold cancel
tested locally with good results

authors: ffromani shajmakh

repo: openshift-kni/numaresources-operator


text:
When the controller crash, the controller should restart

It currently just crash and then we get a 502 Bad gateway from openshift router

let's reopen if we reproduce

repo: openshift-pipelines/pipelines-as-code


text:
improve get changed files

Changes
This change will add support for separating the files by the change type i.e. added, modified, deleted and renamed for a giving source control event. This provides the ability to target only added files or only renamed files. Note that this change still supports all changed files in case specifics types of changes are not needed.
In addition, this change will also allow the changed file information to be passed down using templating variables. The following templated variables have been added

{{all_changed_files}}
{{added_files}}
{{deleted_files}}
{{modified_files}}
{{renamed_files}}

/ok-to-test

lgtm

@kcloutie PR looks good
Can we have a e2e for this change?

Can we have a e2e for this change?

I have not done anything in this area as of yet. Can I get some direction on what is required

So what about some refactoring on this to get:
{{ files. changed }}
{{ files. added }}
{{ files. deleted }}
{{ files. modified }}
{{ files. renamed }}

So what about some refactoring on this to get:
{{ files. changed }} {{ files. added }} {{ files. deleted }} {{ files. modified }} {{ files. renamed }}
you can do this the same way we define body:
https://github.com/openshift-pipelines/pipelines-as-code/blob/main/pkg/cel/cel.go#L53
by defining a map[string]interface{} like we do on body https://github.com/openshift-pipelines/pipelines-as-code/blob/main/pkg/cel/cel.go#L44
the advantage is that it become a CEL expression as well which we can do some funky stuff with

@chmouel  Is the idea for this proposed change to place all the changed files under files or a seperate section or to have it as a CEL expression? My change makes it available as a CEL expression already under a standard param. It would be under pac. i.e. pac.all_changed_files pac.added_files and so on.

@chmouel Is the idea for this proposed change to place all the changed files under files or a seperate section or to have it as a CEL expression? My change makes it available as a CEL expression already under a standard param. It would be under pac. i.e. pac.all_changed_files pac.added_files and so on. Below is a code example of e2e test I wrote using cel expressions

having a CEL expression will be a side effect of doing it like this, I think this makes even easier than if you doing in another way.
We are not talking about CEL expression for filtering. I am talking about a CEL expression from the standard params

Please see https://github.com/openshift-pipelines/pipelines-as-code/pull/1524

authors: chmouel kcloutie piyush-garg savitaashture


text:
[SRVKP-6163] Removed Extra Load-Scripts Step

https://issues.redhat.com/browse/SRVKP-6163

/test osp-114-ocp-415-e2e

/test osp-115-ocp-415-e2e

authors: Aneesh-M-Bhat savitaashture

repo: openshift-pipelines/task-maven


text:
force operators to whitelist feature gates

Since features are easier to manage uniformly across the cluster, this holds feature gates for everything in a payload.  Not all features applicable to all binaries.  The operators must whitelist what can be handled.
Let's see just how far off we are.

I've realized I have to vendor this into a few examples.

repo: openshift/api


text:
Images are themselves manifests, and reference a config blob

The naming of the nested field was wrong (this known as the image "config") and we need to correct it. An OpenShift image is always a manifest.  This is naming only.
Second change: Allow the API to return info about images whose references are not resolvable
Administrators may delete an image intentionally or accidentally, and the layers API needs to be able to inform the registry that the image is referenced, but no layer data is available, so that the registry can more accurately return an error to the client.
@liggitt as discussed. The first is an error @bparees and I found when updating api.ci.  The second is our discussion about references.

@deads2k since liggitt is out - this is a must for 3.11 (since the field is new).  Jordan and I had verbal agreement on a separate map for tracking missing references, but we didn't talk naming or structure.

one question on the separate map vs additional field on existing ImageBlobReferences type. LGTM otherwise

Updated

Need to regenerate proto.  We've been encouraging https://github.com/openshift/api#pull-request-process.  I don't think this will cause problems, but something to keep in mind.
/lgtm

Ok, will do it now.  Didn't see that before.

https://github.com/openshift/origin/pull/20643

authors: deads2k liggitt smarterclayton


text:
OCPBUGS-4052: document trusted CA consumption

The operator needs a way to trust a custom CA. The cluster wide egress proxy with a "not public" certificate is one of the use cases for this. It can be achieved only by the manual intervention done by the user (cluster or namespace admin) as the operator itself makes calls to the external resources at startup (AWS endpoints to get VPC ID).
This PR adds the manual instructions which let ALBO trust a custom CA.

/jira refresh

Discussion about the mounting point for the custom CA: https://redhat-internal.slack.com/archives/C3VS0LV41/p1673598746600019.

/assign

Rebased to fix a conflict with the main branch.

Added the forth step to the proxy doc.

/lgtm
/approve

repo: openshift/aws-load-balancer-operator


text:
Clusterdeployment controller

controller that watches ClusterDeployments and creates any required CertificateRequests
test cases to cover the initial use-case of having one CertificateBundle that covers the entire ClusterDeployment

@csrwng probably worth reviewing that 2nd and 3rd commit in this PR

/lgtm

authors: csrwng joelddiaz

repo: openshift/certman-operator


text:
build_root configuration

This is to enable the CI, added build_root_image configuration used for prow CI, more info: https://docs.ci.openshift.org/docs/architecture/ci-operator/#build-root-image

/assign

/lgtm

/approve

authors: Karthik-K-N mkumatag

repo: openshift/cluster-api-provider-powervs


text:
Bug 2067805: Bump prometheus/client_golang

Bump prometheus/client_golang https://access.redhat.com/security/cve/CVE-2022-21698

/approve
/lgtm

authors: JoelSpeed alexander-demichev

repo: openshift/cluster-capi-operator


text:
UPSTREAM: : add --experimental-max-learner flag

This PR is a manual cherry-pick of https://github.com/etcd-io/etcd/pull/13377 into openshift-4.10
Signed-off-by: Sam Batschelet sbatsche@redhat.com
Please read https://github.com/etcd-io/etcd/blob/main/CONTRIBUTING.md#contribution-flow.
/hold for testing

configmap-scale is physically broken.
Collecting ripsaw-cli from git+https://github.com/cloud-bulldozer/benchmark-operator.git/#egg=ripsaw-cli&subdirectory=cli
  Cloning https://github.com/cloud-bulldozer/benchmark-operator.git/ to /tmp/pip-build-zgquwxtm/ripsaw-cli
ripsaw-cli requires Python '>=3.8' but the running Python is 3.6.8

infra fail
/retest e2e-aws

/test e2e-aws

/override ci/prow/configmap-scale
/retest

manually adding tags as these are not actually required during 4.10 dev cycle

/override ci/prow/configmap-scale

/override ci/prow/configmap-scale

/refresh

/override ci/prow/configmap-scale

authors: droslean hexfusion

repo: openshift/etcd


text:
Avoid toggling menu open state on outside menu click handler

Fixes
https://issues.redhat.com/browse/STONEBUGS-95

Description
Clicking on kebab button also ran the click event handler for outside button click, so the toggle would be changed to false before the actual toggle handler was run, this caused the toggle handler to update from an incorrect state.

Type of change

[ ] Feature
[x] Bugfix
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

Screen shots / Gifs for design review
https://user-images.githubusercontent.com/20013884/229834266-887f5674-9c50-47ad-a09d-d284bdab335d.mp4

How to test or reproduce?
Toggle any kebab menu.

Browser conformance:

[x] Chrome
[x] Firefox
[ ] Safari
[ ] Edge

Added more tests to satisfy codecov

/lgtm

repo: openshift/hac-dev


text:
delete PVs

delete PVs that match the filters provided to the uninstaller
it will fail to delete volumes attached to instances, but those volumes will be auto-deleted when the instances are deleted, so it eventually deletes PVs created by the cluster
PVs are not tagged with the tectonicClusterID tag, so you'll want to add 'kubernetes.io/cluster/CLUSTER_NAME=owned' as an additional tag to the uninstaller so that it can locate PVs

/lgtm

authors: dgoodwin joelddiaz

repo: openshift/hive


text:
Initial API support for provider agnostic control planes

Introduce a None platform type which will allow for a provider agnostic
control plane. There's more work to do (some AWS stuff like CAPI is still
deployed) but this is enough to get started.

This is extracted from the Kind experiment (https://github.com/openshift/hypershift/pull/189)

Overall this is more of a POC than anything since there are some AWS assumptions still embedded throughout the codebase, but it seems useful for iterating

/test e2e-aws

/lgtm

authors: ironcladlou sjenning

repo: openshift/hypershift


text:
HOSTEDCP-336: Hypershift API separation

Hypershift API separation. This will help to consume it more easily without need of all the dependecies of the project.
Signed-off-by: Juan Manuel Parrilla Madrid jparrill@redhat.com
Which issue(s) this PR fixes:
Fixes #HOSTEDCP-336

Please change the commit message to use imperative mood convention https://hypershift-docs.netlify.app/contribute/
Also can you please elaborate in PR/Commit desc about "This will help to consume it more easily without need of all the dependecies of the project." Can you detail an example of how would it be different to consume the API externally and locally for the project before and after this PR, which deps are brought in each case and why the "after" is better?

This is looking pretty good :)

/retest

/test e2e-kubevirt-aws-ovn

@jparrill Reviewed! Just a couple comments from me:

With this change, go imports for HyperShift API package will change from:
github.com/openshift/hypershift vx.y.z --> github.com/openshift/hypershift/api vx.y.z?
Seems like api/certificates/ should be included inapi/types/ as well.

Also just FYI, looks like our IBM CI tests are failing due to expired kubeconfigs. We'll get that updated!

Hey @hasueki!

With this change, go imports for HyperShift API package will change from:
github.com/openshift/hypershift vx.y.z --> github.com/openshift/hypershift/api vx.y.z?

Seems like api/certificates/ should be included in api/types/ as well.
Also just FYI, looks like our IBM CI tests are failing due to expired kubeconfigs. We'll get that updated!

That's correct in both cases :), I was waiting until stevekuznetsov finishes their PR until continue the separation.
Thanks for the review!

/test e2e-ibmcloud-iks
/test e2e-ibmcloud-roks

Hey @hasueki I will retest the IBM tests once we put the extracted runtime-controller in the code (we're making lighter the API pkgs). Thanks :)

/test e2e-ibmcloud-iks
/test e2e-ibmcloud-roks

/test e2e-ibmcloud-iks
/test e2e-ibmcloud-roks

/retest

/test e2e-ibmcloud-iks
/test e2e-ibmcloud-roks

/lgtm

/hold cancel

/retest

/test verify

/retest

/lgtm

/retest

/retest

/retest

/retest

/retest

/override Red Hat Trusted App Pipeline

/override Red Hat Konflux / Red Hat Trusted App Pipeline

/override "Red Hat Trusted App Pipeline"

/override "Red Hat Trusted App Pipeline"

authors: bryan-cox csrwng enxebre hasueki imain jparrill


text:
move authentication content to login plugin readme

@bparees ptal

this one lgtm but i'm going to let you merge it in case you decide you want to make some tweaks after my feedback on the other one.

update based on return of some content previously moved the login plugin readme pushed

lgtm

[merge]

Looks like there was a network hiccup attempting to mark the merge's test as successful:
+ test_pull_requests --mark_test_success --repo jenkins --config /var/lib/jenkins/.test_pull_requests_jenkins.json
  Marking SUCCESS for pull request #--repo in repo ''
/usr/share/ruby/net/http/response.rb:119:in `error!': 404 "Not Found" (Net::HTTPServerException)
	from /bin/test_pull_requests:543:in `block in get_comments'
	from /bin/test_pull_requests:535:in `each'
	from /bin/test_pull_requests:535:in `get_comments'
	from /bin/test_pull_requests:1074:in `get_comment_matching_regex'
	from /bin/test_pull_requests:1090:in `get_comment_with_prefix'
	from /bin/test_pull_requests:779:in `mark_test_success'
	from /bin/test_pull_requests:2358:in `<main>'
Build step 'Execute shell' marked build as failure

@stevekuznetsov - does it make sense to add some delay / retry for this command?  Or can you tell from the output above whether an attempt was made to an invalid address?
I'll try merging again in the interim.
[merge]

well ... we can't seem to add the label "kind/test-flake" to bugs in this repo
opened a general bug ... let's see what happens:  flake https://github.com/openshift/jenkins/issues/294
[merge]

[merge]

It doesn't look like "${JENKINS_PULL_ID}" was set for that command for some reason. re[test][merge] can we reproduce it?

Accidentally deleted my comment -- it looks like "${JENKINS_PULL_ID}"` didn't get threaded through the job for that command. Added some debugging re[merge]

I guess you could call that progress...
+ test_pull_requests --mark_test_success 293 --repo jenkins --config /var/lib/jenkins/.test_pull_requests_jenkins.json
  Marking SUCCESS for pull request #293 in repo 'jenkins'
/bin/test_pull_requests:780:in `mark_test_success': undefined method `[]' for nil:NilClass (NoMethodError)
	from /bin/test_pull_requests:2358:in `<main>'

Ah, this is an issue because Rosie is trying to mark this pull request successful for tests when no test tag has been placed. That's an error my end on configuration, let me fix that.

[merge]

authors: bparees gabemontero stevekuznetsov

repo: openshift/jenkins


text:
adjust jenkins e2e img env var name to new convention

this is going to need the openshift/release PR I'm about to submit
/hold

/hold cancel

/retest

/retest

/retest

/retest

Some old fashion debug was telling ... the /usr/libexec/origin directory does not exist, only /usr/libexec ... our copy of the script landed as such:
-rwxrwxr-x. 1 root root 2736 Dec  4 19:43 /usr/libexec/origin

will attempt to add a mkdir -p

Progress!!!
Out tagging script is there now:
Pulling image docker-registry.default.svc:5000/ci-op-4w5fb000/pipeline@sha256:ac849188de640d93d51381afc638666069104b1766ecb749c2007e78b3b09e76 ...
--> FROM docker-registry.default.svc:5000/ci-op-4w5fb000/pipeline@sha256:ac849188de640d93d51381afc638666069104b1766ecb749c2007e78b3b09e76 as 0
--> RUN mkdir -p /usr/libexec/origin
--> COPY tag-in-image.sh /usr/libexec/origin
--> RUN echo "Copied tag-in-image.sh to /usr/libexec/origin"
Copied tag-in-image.sh to /usr/libexec/origin
--> RUN echo "looking into /usr/libexec/origin"
looking into /usr/libexec/origin
--> RUN ls -la /usr/libexec/origin
total 4
drwxr-xr-x. 2 root root   29 Dec  4 19:57 .
drwxr-xr-x. 1 root root   20 Dec  4 19:57 ..
-rwxrwxr-x. 1 root root 2736 Dec  4 19:56 tag-in-image.sh
--> ENV "OPENSHIFT_BUILD_NAME"="tests" "OPENSHIFT_BUILD_NAMESPACE"="ci-op-4w5fb000"
--> LABEL "io.openshift.build.name"="tests" "io.openshift.build.namespace"="ci-op-4w5fb000" "io.openshift.build.commit.ref"="" "io.openshift.build.commit.author"="" "io.openshift.build.commit.date"="" "io.openshift.build.source-location"="" "vcs-type"="" "vcs-ref"="" "io.openshift.build.name"="" "io.openshift.build.commit.message"="" "io.openshift.build.source-context-dir"="" "vcs-url"="" "io.openshift.build.namespace"="" "io.openshift.build.commit.id"=""
--> Committing changes to temp.builder.openshift.io/ci-op-4w5fb000/tests:055c3dcd ...
--> Done

Pushing image docker-registry.default.svc:5000/ci-op-4w5fb000/pipeline:tests ...
Pushed 6/6 layers, 100% complete
Push successful

And our prepare step worked:
Found shared kubeconfig
Tag openshift/jenkins:2 set to registry.svc.ci.openshift.org/ci-op-4w5fb000/stable:2-centos.
Tag openshift/jenkins:latest set to registry.svc.ci.openshift.org/ci-op-4w5fb000/stable:2-centos.

But our actual test failed with
Found shared kubeconfig
Preparation job deemed completed
/usr/bin/openshift-tests
which: no extended.test in (/usr/libexec/origin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)
must provide TEST_SUITE variable

Back to comparing the templates in openshift/release

So https://github.com/openshift/release/pull/2303 has merged
And waiting on https://github.com/openshift/origin/pull/21616
Then will test this again

Some more progress ... the openshift/release PR was validated.  The openshift-tests command was called, but it does not yet have the version from the origin PR that just merged:
Error: suite "openshift/jenkins-e2e" does not exist

I'll try again tomorrow ... presumably the openshift/origin updates will propagate to the openshift ansible installer by then.

/retest

The https://openshift-gce-devel.appspot.com/build/origin-ci-test/logs/branch-ci-openshift-origin-master-images/255 post-submit job should have our openshift-tests change.

so the test failure was that our non-trivial, use the actual sample, maven build did not complete in 10 minutes
looking at the dump of the build log ... yeah, the image push etc. was super slow ... I think I timed one image interaction at 7 minutes
of  course there are known perf issues with pushing images with builds right now
and this is one of the tests that we moved out of e2e-gcp-builds because of said slowness
I say we green button this PR @bparees and go onto the other jenkins PRs and see how persistent this type of failure is ... maybe we increase the build time outs in these jenkins e2e specific tests if we consistently see stuff like this


text:
Remove all uses of dumb-init

/assign @waveywaves

/lgtm

authors: akram waveywaves


text:
bug 1953798: stop doing live gets for optional cert syncer files that don't exist on disk yet

/assign @ihcsim
This addresses the biggest burn budget offender.

proved in https://github.com/openshift/cluster-kube-apiserver-operator/pull/1120

/bugzilla refresh

/bugzilla refresh

/lgtm

/cherry-pick 4.7

/cherry-pick release-4.7

repo: openshift/library-go


text:
Rewords unsupported workload notification

Reword unsupported workload notificaton.
Signed-off-by: Christopher Collins collins.christopher@gmail.com

/lgtm
/approve

authors: c-e-brumm clcollins

repo: openshift/managed-notifications


text:
OSD-12077 - Add short description to few scripts and update descripti…

Resolves OSD-12077
Added Short Descriptions where long descriptions were not clear when trimmed
Updated some long descriptions to keep them consistent with the rest of the script descriptions and shortened where possible

/lgtm
/approve

repo: openshift/managed-scripts


text:
CNV-46603: select projects with multitypeahead

For user is difficult to use matchLabels. Use Project selection with matchExpressions
use matchExpressions also to add projects to a ClusterUDN in the project creation modal
Before

After
https://github.com/user-attachments/assets/d58414ef-750c-470f-91d4-b77b43fdfda5
https://github.com/user-attachments/assets/b35306e5-e03c-459b-91d2-d0a516968815

/lgtm

authors: metalice upalatucci

repo: openshift/networking-console-plugin


text:
V0.19.3 merge

Steps:

Create new local branch v0.19.3-merge from downstream/master
git fetch upstream && git merge v0.19.3
a. Solve conflicts. In this case it was just some go.mod lines.
Run go mod vendor
This PR

@fabianvf do we run update-collections.sh on z-stream releases, or (my guess) would that just be for X any Y stream?

@asmacdo I think we can probably skip updating the collections, tbh I don't know if we've done a z-stream release since collections were a thing

/lgtm

authors: asmacdo fabianvf jmrodri

repo: openshift/ocp-release-operator-sdk


text:
new workflow:  odo component commands

Each odo component command has optional --context argument.
That defines what is the component that the action shoudl be performed on.
By default context is ./
odo component * according to new workflow
create
creates component config (definition) in the context directory
delete
flags : --force --context
deletes component from the cluster (undeploy), configuration in intacted
describe
flags:  --context : Describe the given component
show all information about the current component, including information if it is deployed or not
link
flags:  --app --project --wait --context
Link current component to a service or component
do live change, storing in config file will depend on whether service is stored in the config or not
TODO: --app and --project
unlink
flags:  --app --port --project --context
Unlink current component from a service or component
TODO: --app and --project
list
flags:  --app --project --all --context
List all components in the current application  (the same application as the current component is)
--application flag can be specified to list components in the different application  (if not specified defaults to the application defined in the context)
--project flag can be specified to list components in the different project (if not specified defaults to the project defined in the context)
if we have following config
kind: LocalConfig
apiversion: odo.openshift.io/v1alpha1
ComponentSettings:
  Application: testing
  Project: myproj
  Name: php

odo component list - list all components in testing app in myproj
odo component list --application  myapp - list all components in myapp app in myproj
odo component list --project  secondproj - list all components in testing app in secondproj
odo component list --application  myapp --project  secondproj- list all components in myapp app in secondproj. This command is only odo component list that be run outside of the directory  with .odo o
All the above commands can be run with --context to use config file in different directory than the current one (expect the last one)
log|logs
Retrieve the log for the given component
flags:   --app --follow --project --context
--project and --app  have the same behavior like in list command
push
Push source code to a component
flags:  --show-log --context
show-log implementation in #1082
watch
Watch for changes, update component on change
flags:  --delay --ignore --show-log --context
update
TODO:

I personally think context resolution should happen in context.go. With commands not having to worry about it. They should instead complain if they dont have enough information.
For eg, If user has specified a context with no active component then context does is set but without active component and when user tries to perform any op that needs component while not providing --component flag. Then it complains asking user to set/create a component first

Then it complains asking user to set/create a component first or provide --component

there shouldn't be a --component flag anymore. This is controlled by --context

For eg, If user has specified a context with no active component then context is set but without active component and when user tries to perform any op that needs component while not providing --component flag. Then it complains asking user to set/create a component first or provide --component

No there is no active component or app or project now in odo everything that was previously called active is now only the ones in config so if component name or app name is not passed, a default is generated in config and if project is not passed, currently we use active project in component config but not sure if that's a bug though targeted for sometime in future

For eg, If user has specified a context with no active component then context is set but without active component and when user tries to perform any op that needs component while not providing --component flag. Then it complains asking user to set/create a component first or provide --component

No there is no active component or app or project now in odo everything that was previously called active is now only the ones in config so if component name or app name is not passed, a default is generated in config and if project is not passed, currently we use active project in component config but not sure if that's a bug though targeted for sometime in future. Only the contents of the component config is the single source of truth

Brilliant this should simplify stuff a lot :)

Ideally --context would be a global flag... but we'll get there eventually.
Should we split up this issue into separate parts so multiple engineers can work on it @mohammedzee1000 ?

@cdrage yes agreed. https://github.com/openshift/odo/pull/1532 is already heading in that direction. I hope i have not missed any commands here. Basically, I am letting through any command that does not rely on context at all, creates it, or has a possible flag to override missing context file. This should help in that direction. I hope i have not missed anything
Yes i think splitting would help :)

@cdrage it seems to be like it already is as far as context.go is concerned. What is important is shifting to making use of it

Create already just sets up the config information while push is the one that actually creates the said object

Working on this already. I have the base information I needed. Will ask if i need more

odo component list --all and odo watch --show-logs can be addressed in another issue and PR

created https://github.com/openshift/odo/issues/1584 and https://github.com/openshift/odo/issues/1589 is there something else that is missing?

--delay in watch i think

covered --delay in https://github.com/openshift/odo/issues/1592 for tracking

authors: anmolbabu cdrage girishramnani kadel mohammedzee1000

repo: openshift/odo


text:
Updated metrics role

Run-once is applied at role level.
Since serial cannot effectively be used with run_once, service restarts and config change was moved to a separate task.

Approved in PR #2091

repo: openshift/openshift-tools


text:
Boilerplate update with common appsre pipeline

Automated update to latest boilerplate
Fixups to accommodate bolierplated appsre pipeline scripts

See the individual commit messages for details.
OSD-6851

/lgtm

repo: openshift/osd-metrics-exporter


text:
OCM-10754 | fix: validate int32 for user input in autoscaler attributes

https://issues.redhat.com/browse/OCM-10754

/lgtm
/approve

repo: openshift/rosa


text:
Use unix-style path separators when creating tar files

When tarring windows paths, we store the windows-style path separators in the tar. If the tar is extracted on a unix system, the separators are not interpreted correctly. However, extracting a tar on a windows machine always works correctly with unix-style path separators.

@bparees ptal

lgtm [merge]

authors: bparees csrwng

repo: openshift/source-to-image


text:
Removes unwanted CI configuration

Current CI config has unwanted things which create
some confusions.
This patch removes wanted step make build  target
(OLM manifest generation) and drops extra docrerfiles.

closing this PR, I guess we need it in case of nightly.

repo: openshift/tektoncd-pipeline-operator


text:
old end-to-end jobs removed

@aditya-konarde do you want to fix Zabbix dashboard first or can we delete old jobs?
@ldimaggi @pmacik do you need any of removed credentials for booster tests?
@jmelis please do not merge until Aditya responds

@jmelis @riuvshin @kbsingh please review

Okay to delete the old jobs, note that we'll lose the historical data as its auto-discovered.

@ppitonak going to remove jobs on CI before merge.

[test]

@riuvshin  do not merge yet, let me verify something about the credentials

It looks like all of these credentials are not being used anymore after this PR:

59d1d5c5-1367-4b3e-a5cc-26846a1ea80b
60ae2fd0-5ab0-4a12-bf75-6a81ab1b915f
807b706e-c54f-48d5-be93-56525cf499f0
9d2a233c-4350-49ab-983d-5b8d0de95f44
a75af77c-1137-4ea2-9690-968848b0334e
de0940f2-f31f-4186-85e2-37d42bddcf5b
e9a32e1e-0a38-4a96-896f-a266e1428cf9

@ppitonak can you confirm that you are no longer in need of the following creds and that they can be removed from centos-ci?

credential-id: 9d2a233c-4350-49ab-983d-5b8d0de95f44
username: EE_TEST_USERNAME
password: EE_TEST_PASSWORD
oso_token_creds: 60ae2fd0-5ab0-4a12-bf75-6a81ab1b915f
oso_token_creds: de0940f2-f31f-4186-85e2-37d42bddcf5b
kc_refresh_token_creds: a75af77c-1137-4ea2-9690-968848b0334e
kc_refresh_token_creds: 807b706e-c54f-48d5-be93-56525cf499f0
osio_creds: e9a32e1e-0a38-4a96-896f-a266e1428cf9

We don't need these credentials anymore.

@ppitonak it seems job-template name: 'devtools-test-end-to-end-{test_url}-{test_suite}' is never used can you please update your pr with removing it.

@riuvshin you are right that it's not being used but it's not related to this PR. Wouldn't it be better to do it in a new PR?

updated

code updated, feel free to remove these creds:
oso_token_creds: 205e34c8-3b2f-4c1d-8110-1381f9289148
kc_refresh_token_creds: cca45759-9346-45cc-ad9c-39140eddbc58
credential-id: f32f6ca9-5fbc-4391-b03b-20ce9f6cb575

[test]

authors: aditya-konarde jmelis ppitonak riuvshin

repo: openshiftio/openshiftio-cico-jobs


text:
Added .configure() method

Should fix #206
I'm not really sure about the warning in the docstrings. I think it's an important thing to note, but I don't  know if you will like how it looks.

Closed PR with commit: 1f5ffb0ed36d0bb6d3f78a3a2c191e03963b5b62

repo: opensistemas-hub/osbrain

license_source: bigquery


text:
推荐嘉宾 - [林旅强 Richard]（个人成长系列）

栏目
个人成长系列
嘉宾名称
林旅强 Richard
GitHub
legist
公司/组织/岗位
No response
Twitter
richardllin
博客地址
No response
推荐理由（着重考虑开源爱好者能收获什么）
Richard 林旅强，在开源之夏、开源社等相关的活动中都有不少的参与。其朴实、深刻的开源认识、观点对 @LinuxSuRen 了解、参与开源有着很深的影响。@LinuxSuRen 特别希望他对开源的热情可以传递给《开源面对面》的朋友们。
推荐人
@linuxsuren
note

[ ] 建议嘉宾 订阅《开源面对面》的邮件列表（发送邮件被视为订阅），方便后续发送录制的会议邀请。
[ ] 可参考 播客录音指南 准备好录音设备与环境。

相关分享
【开源之夏2023专家寄语——Richard 林旅强】 https://www.bilibili.com/video/BV1u8411S7G7/?share_source=copy_web&vd_source=1e8d9e70686a4845fa44f8d3f5ff7925
【暑期2020“大咖说开源”| 庄表伟、林旅强：说说你人生经历中的开源故事】 https://www.bilibili.com/video/BV1Ni4y1x7LY/?share_source=copy_web&vd_source=1e8d9e70686a4845fa44f8d3f5ff7925
【【开源社】开源小故事 庄表伟&林旅强】 https://www.bilibili.com/video/BV1Sg4y1v7EX/?share_source=copy_web&vd_source=1e8d9e70686a4845fa44f8d3f5ff7925
【OpenTEKr｜大话开源精华版｜林旅强：开源之于创新 有时无招胜有招】 https://www.bilibili.com/video/BV1bf4y1g7qp/?share_source=copy_web&vd_source=1e8d9e70686a4845fa44f8d3f5ff7925

欢迎强哥！录的时候我要来参加：）

暂定本周六（Apache Con）下午三点录制，以下是参考话题
【腾讯文档】开源面对面&Richard
https://docs.qq.com/doc/DYWxuSWtjQlpCTXpn

@shinyzhu 有预计大概什么时候会剪辑出来吗？另外，在发布之前，需要找相关人确认下。感谢提供后期支持！

大概这周末（27号前）完成，剪辑完成我先更新到各位确认：）

@LinuxSuRen @legist @MikeyWei @wjsvec
剪辑基本完成。
文档：https://w703h2pk3f.feishu.cn/docx/IbglduwrJo1nsgxV1RScL0Uqnhf?from=from_copylink
音频：https://w703h2pk3f.feishu.cn/file/SuRSbszKzoFkGvxnw8ycqpZ9n1e

@LinuxSuRen @legist @MikeyWei @wjsvec 剪辑基本完成。 文档：https://w703h2pk3f.feishu.cn/docx/IbglduwrJo1nsgxV1RScL0Uqnhf?from=from_copylink 音频：https://w703h2pk3f.feishu.cn/file/SuRSbszKzoFkGvxnw8ycqpZ9n1e

👍！

片尾音乐非常赞！到时候可以在 shownote 中把使用的工具以及片尾英语都做一下说明。
我 review 过了，部分我的声音听起来比较低（例如：45:02 处）以外，整体都非常好。

片尾音乐非常赞！到时候可以在 shownote 中把使用的工具以及片尾英语都做一下说明。 我 review 过了，部分我的声音听起来比较低（例如：45:02 处）以外，整体都非常好。

抱歉。有几个时间点音轨没有切换。修复版本音频文件在这里：https://w703h2pk3f.feishu.cn/file/OT8dbiFMtoU0fvxyIaQcMItDnJc?from=from_copylink

片尾音乐非常赞！到时候可以在 shownote 中把使用的工具以及片尾英语都做一下说明。 我 review 过了，部分我的声音听起来比较低（例如：45:02 处）以外，整体都非常好。

抱歉。有几个时间点音轨没有切换。修复版本音频文件在这里：https://w703h2pk3f.feishu.cn/file/OT8dbiFMtoU0fvxyIaQcMItDnJc?from=from_copylink

片尾音乐非常赞！到时候可以在 shownote 中把使用的工具以及片尾英语都做一下说明。 我 review 过了，部分我的声音听起来比较低（例如：45:02 处）以外，整体都非常好。

抱歉。有几个时间点音轨没有切换。修复版本音频文件在这里：https://w703h2pk3f.feishu.cn/file/OT8dbiFMtoU0fvxyIaQcMItDnJc?from=from_copylink

对应的 Twitter 链接
https://twitter.com/osf2f/status/1689166651772878848

authors: LinuxSuRen shinyzhu wey-gu


text:
error: invalid path 'presentations/Open Source Design 2019 updated for ApacheCon and 16:9.odp'

When I clone this repo, it is giving me an error that there is something wrong with the path to these 2 files:

presentations/Open Source Design 2019 updated for ApacheCon and 16:9.odp
presentations/Open Source Design 2019 updated for ApacheCon and 16:9.pdf

And, as per the solution given below if you apply git restore --source=HEAD :/, all of the files get untracked and the above 2 files are removed.
Can anyone put light upon this?

if you view windows add in terminal git config --global core.protectNTFS false
https://github.community/t/windows-git-clone-error-error-filename-in-tree-entry-contains-backslash-32-mib-s/2935/4


text:
Testing performance of the re-produced model

Thanks for your great codes!
Can you provide the re-produced results such as Conformer, Transducer? I suppose this is important for users to measure the quality of the codes.

I tested conformer-with-ctc architecture.
This architecture record 2.66 CER in LibriSpeech dataset. (Greedy Search, No Language Model, No Data Augmentation)
Thank you.

It looks like pretty good results! How about the WER (word error rate) at the test-clean dataset?

I'm afraid I've heard from one of the contributors, so I don't have any more information.

authors: Jxu-Thu sooftware

repo: openspeech-team/openspeech

license: MIT


text:
Update configurable views and app JSON configurations

IMPORTANT: Where possible all PRs must be linked to a Github issue
Fixes #1761 & #1788
Checklist

[x] I have written Unit tests for any new feature(s) and edge cases for bug fixes
[x] 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
[x] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the project's style guide
[x] I have built and run the fhircore app to verify my change fixes the issue and/or does not break the app

Refactored the ViewRenderer in this PR to fix the following and add these extra features:

Fixed rendering views on ROWs and COLUMNs (Rows and Columns were not rendering)
Include weight attribute to assist with positioning of views in parent layout. The view size will be generated as a percentage of the the available screen size.
Split ViewGroupProperties into ColumnProperties and RowProperties the both have different attributes
Fixed ActionableButton  background color
Fixed ServiceButton border color
Fixed icons not showing on Fabs and Drawer menu Item (Other clients option)
Add border radius to all Properties as well as other common attributes
Introduce a disable property for views to mark them as disabled

@FikriMilano can you check to see if the changes you requested have been addressed? thank you!

@ellykits What is remaining here? I would like to merge this to main then we can create issues for the tests and minor bugs.
@pld @f-odhiambo

authors: dubdabasoduba ellykits pld

repo: opensrp/fhircore


text:
“openssl cms” with EdDSA does not work

After creating an Ed25519 self-signed certificate with
openssl req -x509 -subj "/CN=A" -newkey ed25519 -nodes -keyout - > signer

I tried to sign a file with
openssl cms -in file -sign -signer signer -noattr

but it failed with
4622915008:error:2E066080:CMS routines:CMS_add1_signer:no default digest:crypto/cms/cms_sd.c:295:

My understanding is the pureEdDSA does not need a message digest at all.

What OpenSSL version?

My understanding is the pureEdDSA does not need a message digest at all.

True.  @DDvO, do you know some more about this?  Is OpenSSL's CMS up to date with RFC 8419?

It's 1.1.1g installed by brew on macOS.

My understanding is the pureEdDSA does not need a message digest at all.

True. @DDvO, do you know some more about this? Is OpenSSL's CMS up to date with RFC 8419?

I don't have particular knowledge of CMS and EdDSA, but will have a look.
Trying to follow @wangweij's steps I've just come across a further issue:
With OpenSSL 1.1.1,
openssl req -x509 -subj "/CN=A" -newkey ed25519 -nodes -keyout - > signer.pem

outputs both the key and the cert to signer.pem,
but with the current master the cert is not included!
Yet when I replace ed25519 by RSA:1024:
apps/openssl req -x509 -subj "/CN=A" -newkey RSA:1024 -nodes -keyout - > signer.pem

it works as expected.

I did tried to download/master the master to see if this issue was fixed and noticed that problem. I can confirm that even with the key and cert created from 1.1.1g, the current master shows the same problem at cms -sign.

the current master shows the same problem at cms -sign.

I found this, too.
It looks like openssl cms -sign simply does not support pureEdDSA yet.
EVP_PKEY_get_default_digest_nid() correctly returns NID_undef in this case,
and the CMS app reports this as an error rather than getting along without a digest algorithm.

I tried use -md sha512 but also not accepted.

It looks like openssl cms -sign simply does not support pureEdDSA yet

It  does not. Nor does dgst.  I don't think anything does, except calling the low-level EVP routines directly.

I'm getting the same error with OpenSSL 3.0.0-beta1-dev  (Library: OpenSSL 3.0.0-beta1-dev ). Apparently, this issue hasn't been fixed.

Ping @openssl/committers

This should be solved as specified in https://datatracker.ietf.org/doc/html/rfc8419#section-2.3:

When the signer includes signed attributes, a message digest
algorithm is used to compute the message digest on the eContent
value.  When signing with Ed25519, the message digest algorithm MUST
be SHA-512 [FIPS180].  Additional information on SHA-512 is available
in [RFC6234].  When signing with Ed448, the message digest algorithm
MUST be SHAKE256 [FIPS202] with a 512-bit output value.

There are clearly bugs here.
Already loading the key and cert supplied via the -signer option produces the above error message.
If the key and cert are provided separately, the error is not shown.
In both cases then the process continues but no signature is produced, failing without giving an error.
I am analyzing further and will provide a fix.

There are clearly bugs here.

But we might simply say - supporting EdDSA properly in CMS is a feature. And the bug would be at most that we do not reject EdDSA outright but instead fail in weird ways.
It really depends on the size and nature of the fixes that need to be done for the EdDSA support.

It also isn't a regression from 1.1.1 so even if regarded as bugs it could be postponed Post 3.0.

I tend to agree that this is really a new feature and could be documented as not currently supported.

So I'm going to split the solution into bug fixes (to be included into 3.0 as far as possble)
and a feature extension (post 3.0).

Due to a request/report yesterday on openssl-users, I got reminded of this issue, which also holds for PKCS7 (e.g, openssl smime).
This issue is much harder to fix than for CMP, due to ugly legacy code in the CMS and PKCS7 implementations.
I tried again today, but sorry to say: fixing this is beyond my OpenSSL expertise.

BTW, for the use case given above in the OP, meanwhile for some reason no error queue output is given at all.
In cms_sd.c, after
if (EVP_PKEY_get_default_digest_nid(pk, &def_nid) <= 0)
a call
    ERR_raise(ERR_LIB_CMS, CMS_R_NO_DEFAULT_DIGEST);
is missing.

BTW, for the use case given above in the OP, meanwhile for some reason
no error queue output is given at all.

Yes, just an exit error code of "3" with no stderr output.

In "cms_sd.c", after
if (EVP_PKEY_get_default_digest_nid(pk, &def_nid) <= 0)

a call
 ERR_raise(ERR_LIB_CMS, CMS_R_NO_DEFAULT_DIGEST);

is missing.

A succinct PR to add an error message would be productive.

I investigated somewhat further, and it looks like there is a relatively elegant solution at least for Ed25519 with CMS,
yet some several CMS cases fail so far and there seems to be an underlying inconsistency on the signature size.
And before being able to use Ed448, apparently there is some underlying bug that needs to be fixed

Two questions on the OpenSSL SHAKE256 implemenation:
When using Ed448 with CMS, the related digest algorithm is SHAKE256, and 512 bits output MUST be used. Which output length does one get when using just NID_shake256, i.e., which is the default output length? If it is not 512, how to select/force 512 bits?

The default output length for SHAKE256 and SHAKE128 is not what one might desire, per #18622 -- you'd need to specifically set xoflen to get the 512-bit SHAKE256 output.

Which output length does one get when using just NID_shake256, i.e., which is the default output length? If it is not 512, how to select/force 512 bits?

SHAKE256 has a variable length output, producing in a sense a "key stream".  So you can truncate it to any length of your choice. There is no default output length: SHAKE256(M, d) is a digest of message M having length d.
Looking at the docs, suggests that the digest length is specified via EVP_DigestFinalXOF(), i.e. not up-front when fetching the algorithm or creating a digest context, but during digest extraction.

Thanks for the quick answers.
Any chance to use SHAKE(_, 512)  with the nice high-level function ASN1_item_sign_ex(),
somehow using EVP_DigestFinalXOF() or the like?
How to state the output length inside X509_ALGOR as a parameter?

I'd look into avoiding parameters, and treat SHAKE256(_, 512) as a black-box non-parametrised algorithm, whose output length is 512. This could involve registering a dedicated digest algorithm, whose ordinary EVP_DigestFinal() runs EVP_DigestFinalXOF() under the covers.
Isn't the X509_ALGOR just Ed25519 or Ed448 in any case? There should be nothing there about the digest algorithm, since it is a fixed internal detail.  The real issue is to prepare the digest context correctly and extract the right "XOF" length, when either of these signature algorithms are in use. Knowledge of the 512-bit length is an internal fixture, not a parameter.

Because the defaults are broken for SHAKE256 and SHAKE128 introducing new algorithm names that do the right thing might be even more confusing.
LMS supports truncated digests including SHAKE256-192..
We could then just use SHAKE256-256, SHAKE256-192 and SHAKE256-512 as names.. These would then just work with the normal DigestFinal..

Currently you would have to use EVP_MD_is_a() and then set the XOFLEN..

Fix is in work: draft PR #22391

authors: DDvO henning-krause kaduk levitte richsalz slontis t8m vdukhovni wangweij

repo: openssl/openssl


text:
Add constant buffer guarantee to BIO read/write interface

See https://github.com/chriskohlhoff/asio/issues/453 for the full context.
But basically currently there isn't a good way to make openSSL work with a library that wants to do the I/O in the proactor style of Boost::ASIO/C++ Networking TS (or Windows' IOCP or Linux io_uring) where the "write" (and read()) method is something like void please_write_this_later_when_you_can(buffer_to_write, callback_to_call_on_completion). The BIO write/read methods expect something that either writes/reads the data before returning or signals that it has tried but there was no space/data available in that moment, it's not designed for an interface that will not even try to transfer the data before returning from BIO_write/BIO_read.
As the explanation/code sample in the ASIO issue explains I would like openSSL to make a promise: that if my BIO write/read method returns "I couldn't do it right now, try later" the next BIO write/read will be called with the exact same parameters. That the buffer given to read/write in the first call will be valid until the second call.
Look for THE GUARANTEE I WANT in the source code if it's not clear.
a) I am right in thinking openSSL already does that?
b) If so, could this guarantee be documented as part of the interface so ASIO can rely on it?

I'm not 100% I've interpreted your request correctly. Let me put it in my own words: You would like it that if libssl calls BIO_read() or BIO_write() and passes a buffer/buffer size then, if we get a retry response, then the buffer/buffer size will remain valid until such time as it is retried - at which point you want the exact same buffer and buffer size to be passed in the repeated BIO_read() or BIO_write() call. This is presumably so that you can asynchronously read/write to the buffer in the intervening time? Am I correct?

a) I am right in thinking openSSL already does that?

By "OpenSSL" here, I think you really mean libssl - right? BIOs are used in other parts of OpenSSL outside of libssl.
The main scenario I can think of off the top of my head where this isn't true is if the user has set SSL_MODE_RELEASE_BUFFERS. In that case read buffers may be released between an initial and subsequent attempt to read. Writes would still buffer until the complete buffer is written and would then be released.
There could be some corner cases if "read_ahead" is in use - but I'm not sure.
Of course it is not uncommon for libssl users to insert custom BIO filters into the BIO chain, and who knows what they might do.
I can't definitively state outside of the above scenarios that the buffers never move. We'd probably have to do some kind of code audit, or write some kind of test to confirm this. But I can't think of a scenario where they would.

b) If so, could this guarantee be documented as part of the interface so ASIO can rely on it?

Conceivably we could do that, although I wouldn't want to do that without a test confirming that we adhere to it. I'd be open to a PR contributing such a test. It also wouldn't happen in stable branches, and is unlikely to be merged in time for the 3.0 feature freeze - so you're looking at 3.1/4.0 at the earliest.
However, I wonder if there is an alternative way to achieve want you want. If I have interpreted the requirement correctly and this is about asynchronous IO then you could use the existing async capabilities to achieve this. That has the advantage that it works today in released versions of OpenSSL. This requires the user to have set SSL connections to use SSL_MODE_ASYNC. When a new connection is attempted we create a new stack for the SSL object to work in. Your custom BIO can then call ASYNC_pause_job() to suspend that connection and return control back to the user. The user must then recall SSL_connect()/SSL_read()/whatever - and then execution will resume where it left off, i.e. the ASYNC_pause_job() function call will return.
On reading your linked asio issue I see that one of your motivations is to optimise the RAM usage, so perhaps this approach may not work for you. The async capabilities work by creating an entirely separate stack....which of course consumes memory.

I'm not 100% I've interpreted your request correctly. Let me put it in my own words: You would like it that if libssl calls BIO_read() or BIO_write() and passes a buffer/buffer size then, if we get a retry response, then the buffer/buffer size will remain valid until such time as it is retried - at which point you want the exact same buffer and buffer size to be passed in the repeated BIO_read() or BIO_write() call. This is presumably so that you can asynchronously read/write to the buffer in the intervening time? Am I correct?

Yes, exactly.

a) I am right in thinking openSSL already does that?

By "OpenSSL" here, I think you really mean libssl - right? BIOs are used in other parts of OpenSSL outside of libssl.

I guess I mean while using SSL_write_ex(), SSL_read_ex(), SSL_connect(), SSL_accept() and SSL_shutdown(). Those are the only interfaces ASIO uses..

The main scenario I can think of off the top of my head where this isn't true is if the user has set SSL_MODE_RELEASE_BUFFERS. In that case read buffers may be released between an initial and subsequent attempt to read. Writes would still buffer until the complete buffer is written and would then be released.

I could live with that. ASIO just needs to avoid using SSL_MODE_RELEASE_BUFFERS. As it is currently it's having to live with the buffers from the BIO pair that are not released anyway.
If somebody needed the extra memory I guess potentially SSL_MODE_RELEASE_BUFFERS could be modified, or a new flag added, that would release the buffers only if it doesn't get the retry response.

Of course it is not uncommon for libssl users to insert custom BIO filters into the BIO chain, and who knows what they might do.

In the user case I'm considering ASIO is in control of the chain, so this would not be an issue.

b) If so, could this guarantee be documented as part of the interface so ASIO can rely on it?

Conceivably we could do that, although I wouldn't want to do that without a test confirming that we adhere to it. I'd be open to a PR contributing such a test.

How would such a test look like? I can test whether it's fine in simple cases (I did for the SSL_connect() case in the code sample from the ASIO issue), but I would not even know what corner cases to consider.

However, I wonder if there is an alternative way to achieve want you want. If I have interpreted the requirement correctly and this is about asynchronous IO then you could use the existing async capabilities to achieve this. That has the advantage that it works today in released versions of OpenSSL. This requires the user to have set SSL connections to use SSL_MODE_ASYNC. When a new connection is attempted we create a new stack for the SSL object to work in. Your custom BIO can then call ASYNC_pause_job() to suspend that connection and return control back to the user. The user must then recall SSL_connect()/SSL_read()/whatever - and then execution will resume where it left off, i.e. the ASYNC_pause_job() function call will return.
On reading your linked asio issue I see that one of your motivations is to optimise the RAM usage, so perhaps this approach may not work for you. The async capabilities work by creating an entirely separate stack....which of course consumes memory.

I was not aware of that. From what I understand it's some kind of stackful coroutine? I did consider using a coroutine library in my BIO_write/BIO_read implementation, but I would certainly prefer to avoid that. I don't think I could get something like that merged into ASIO either. That part of the code tries to be very general, not taking any decision for the user, and using a expensive/memory consuming operation would not go nicely with the "zero cost abstractions" C++ users.

OK, so I guess I will at least start with a test that:

Creates a client and server SSL objects
Does a handshake
Sends data from client to server
Sends data from server to client
Shutdowns the connection

It will do all this with a BIO that needs two calls to read/write to actually get the read/write done, the first attempt will always say retry. And I will be able to check if the data passed in the second call is always the same than the one passed in the first call.
For compatibility with both Linux and Windows I can't use file descriptors for the communication. From what I can see most tests use a BIO_mem. I don't want to reimplement a whole BIO_mem that also does the retry thing, so I would want to reuse a BIO_mem and add the retry thing on top of it.
I can do something like
static int mem_read_control_retry(BIO *b, char *out, int outl)
{
    if(get_should_retry(b)) {
        set_should_retry(b, 0);
        BIO_clear_retry_flags(b);
        BIO_set_retry_read(b);
        return 0;
    }

    set_should_retry(b, 1);
    int (*bread)(BIO *, char *, int) = BIO_meth_get_read(BIO_s_mem());
    return bread(b, out, outl);
}

static int mem_write_control_retry(BIO *b, const char *in, int inl)
{
    if(get_should_retry(b)) {
        set_should_retry(b, 0);
        BIO_clear_retry_flags(b);
        BIO_set_retry_read(b);
        return 0;
    }

    set_should_retry(b, 1);
    int (*bwrite)(BIO *, const char *, int) = BIO_meth_get_write(BIO_s_mem());
    return bwrite(b, in, inl);
}

static BIO_METHOD *meth_mem_control_retry = NULL;

static const BIO_METHOD *bio_s_mem_control_retry(void)
{
    const BIO_METHOD *mem_bio = BIO_s_mem();

    if (meth_mem_control_retry == NULL) {
        if (!TEST_ptr(meth_mem_control_retry = BIO_meth_new(BIO_get_new_index()|BIO_TYPE_SOURCE_SINK,
                                              "memory buffer with retry control"))
            || !TEST_true(BIO_meth_set_write(meth_mem_control_retry, mem_write_control_retry))
            || !TEST_true(BIO_meth_set_read(meth_mem_control_retry, mem_read_control_retry))
            || !TEST_true(BIO_meth_set_ctrl(meth_mem_control_retry, BIO_meth_get_ctrl(mem_bio)))
            || !TEST_true(BIO_meth_set_create(meth_mem_control_retry, BIO_meth_get_create(mem_bio)))
            || !TEST_true(BIO_meth_set_destroy(meth_mem_control_retry, BIO_meth_get_destroy(mem_bio))))
            return NULL;
    }
    return meth_mem_control_retry;
}

But the BIO_get_data() pointer is already used by BIO_mem. So where can I store my state?
Being a BIO used only for testing my idea was to use some associative data structure where to store a <BIO pointer address> -> <private BIO structure>. I couldn't find any in openSSL, I am not good looking for it or it really doesn't exist?
Any other ideas?

OK, so I guess I will at least start with a test that:

Creates a client and server SSL objects
Does a handshake
Sends data from client to server
Sends data from server to client
Shutdowns the connection

This seems like a reasonable starting point.

int (*bread)(BIO *, char *, int) = BIO_meth_get_read(BIO_s_mem());

You are over complicating it here. BIOs support the concept of a chain of BIOs. So you can just call BIO_next() to get the next BIO in the chain, and then call BIO_read() directly.
You use BIO_push() to join BIO together into a chain.
For example see bio_f_async_filter in test/asynciotest.c for an instance of a "filter" BIO that sits in front of another one, and create_ssl_objects in test/ssltestlib.c for an example of where we join BIOs together into a chain.

But the BIO_get_data() pointer is already used by BIO_mem. So where can I store my state?

If you create a chain of BIOs then BIO_get_data() will give you the data for the "current" BIO in the chain, so this isn't a problem.

Any other ideas?

You might what to look at test_extra_tickets() in sslapitest.c
This uses an alternative approach. This uses a custom BIO bio_s_always_retry(), which basically always responds with "retry". We then swap in and out the "real" BIO or the "always retry" BIO as required for what we want to achieve in the test.

But the BIO_get_data() pointer is already used by BIO_mem. So where can I store my state?

If you create a chain of BIOs then BIO_get_data() will give you the data for the "current" BIO in the chain, so this isn't a problem.

It also seems like the BIO_get_data() pointer is something of a historical aberration; the BIO_get_ex_data() APIs are the more typical OpenSSL way to attach application data to an object.  This is especially so because the BIO_get_data() pointer is only usable by applications for BIO types that do not use the field internally -- some of the OpenSSL BIOs do, and some don't.

It also seems like the BIO_get_data() pointer is something of a historical aberration; the BIO_get_ex_data() APIs are the more typical OpenSSL way to attach application data to an object. This is especially so because the BIO_get_data() pointer is only usable by applications for BIO types that do not use the field internally -- some of the OpenSSL BIOs do, and some don't.

BIO_get_data() is intended to be used by the BIO implementation itself - not by applications using the BIO. That's what we're talking about here - a new BIO implementation.

BIO_get_data() is intended to be used by the BIO implementation itself - not by applications using the BIO. That's what we're talking about here - a new BIO implementation.

Ah, I see now -- thanks!

I have created https://github.com/openssl/openssl/pull/12664. I'm testing the handshake, read, write, shutdown with and without SSL_CTX_set_read_ahead.
What should be changed / added?

submitted PR closed due to lack of CLA,
Marking as inactive, to be closed at the end of 3.4 dev barring further input


text:
Configure VC-WIN64A fails using MSVC 2022 on Windows with OpenSSL 3.1.0

I've run the config step successfully:
SET VS_ENVIRONMENT="C:/Program Files/Microsoft Visual Studio/2022/Community/Common7/Tools/VsDevCmd.bat"
SET CERT_DIR="C:\Certs"
SET SRC_DIR="D:\X\OpenSSL3\openssl-3.1.0"
SET BUILD_DIR="D:\X\OpenSSL3\openssl-3.1.0-bin"

call %VS_ENVIRONMENT%
cd %SRC_DIR%
perl Configure VC-WIN64A shared --prefix=%BUILD_DIR% --openssldir=%CERT_DIR%
perl configdata.pm --dump > ../OUT-CONFIG.txt 2>&1
nmake
nmake test
nmake install

However during the build step I encounter the following error:
crypto\bn\rsa_sup_mul.c(139): fatal error C1189: #error:  Only x64, ARM64 and IA64 supported.
Please, see attached config and build outputs from terminal.
OUT-BUILD.txt
OUT-CONFIG.txt

Are you sure you set your environment so the 64 bit build environment is used?

From NOTES-windows.md:  run cmd and execute vcvarsall.bat with one of the options x86, x86_amd64, x86_arm, x86_arm64, amd64, amd64_x86, amd64_arm, or amd64_arm64 - did you do that - in your case concretely vcvarsall.bat amd64

Deleting the source folder and starting from clean did solve it. Apparently, some temp files inside the source folder were the culprit. Thanks for assistance, @t8m


text:
OpenSSL 3.0: --with-rand-seed without effect

I'm compiling OpenSSL with https://github.com/jart/cosmopolitan and configure openssl-3.0 as follows:
./config --with-rand-seed=getrandom no-asm no-shared no-dso no-engine -DPURIFY CC=/opt/cosmo/tool/scripts/cosmocc

Configure obviously recognizes this option and outputs:
Configuring OpenSSL version 3.0.11-dev for target linux-x86_64
Created configdata.pm
Running configdata.pm
Created Makefile.in
Created Makefile

**********************************************************************
***                                                                ***
***   OpenSSL has been successfully configured                     ***
***                                                                ***
***   If you encounter a problem while building, please open an    ***
***   issue on GitHub <https://github.com/openssl/openssl/issues>  ***
***   and include the output from the following command:           ***
***                                                                ***
***       perl configdata.pm --dump                                ***
***                                                                ***
***   (If you are new to OpenSSL, you might want to consult the    ***
***   'Troubleshooting' section in the INSTALL.md file first)      ***
***                                                                ***
**********************************************************************

However, running make does compile syscall_random without the following https://github.com/openssl/openssl/blob/a24eaa828354ea71f9f09a6f565b9228012aecaf/providers/implementations/rands/seeding/rand_unix.c#L400
This can be reproduced by simply adding an #error before that line.
Despite my configuration, it seems that the code is compiled so that it first tries to call getentropy()
https://github.com/openssl/openssl/blob/a24eaa828354ea71f9f09a6f565b9228012aecaf/providers/implementations/rands/seeding/rand_unix.c#L363-L368
and then it errors here:
https://github.com/openssl/openssl/blob/a24eaa828354ea71f9f09a6f565b9228012aecaf/providers/implementations/rands/seeding/rand_unix.c#L402-L403
Currently I changed the source code to delegate seeding to getrandom(), which works as expected. What is the correct way to specify the entropy source?

We don't distinguish getrandom and getentropy from a configuration viewpoint.  If you enable getrandom, we'll always check for getentropy first (if the function exists).  In your case it looks like the function is found but is returning ENOSYS or it isn't found.  In both cases it should fall through to the getrandom code later but isn't.  This looks like a bug in the #ifdef spaghetti.
What operating system and libc are using using?

As said above, I added #error test right before the call to getrandom() to see that it doesn't get compiled. I'm using cosmopolitain libc on Ubuntu 20.04. The exact steps for compiling are as follows:
git clone https://github.com/jart/cosmopolitan /opt/cosmo
cd /opt/cosmo
make toolchain
mkdir -p /opt/cosmos/bin
cd -
git clone --depth=1 https://github.com/openssl/openssl.git -b openssl-3.0 openssl
cd openssl
./config --with-rand-seed=getrandom no-asm no-shared no-dso no-engine no-dynamic-engine -DPURIFY CC=/opt/cosmo/tool/scripts/cosmocc
make

The test for the presence of the getrandom syscal on linux is here:
https://github.com/openssl/openssl/blob/2d79662b5febe565d39861338a5d9067a2df641f/providers/implementations/rands/seeding/rand_unix.c#L393-L395
This is clearly not working for your compiler/platform. We have no explicit support for the cosmopolitan libc and its associated compiler, so my assumption is that it is not defining the expected macros in order to successfully detect getrandom support (i.e. __linux or __NR_getrandom).

authors: frankmorgner mattcaswell paulidale


text:
build fails if older OpenSSL pre-installed on system [master branch]

When trying to build OpenSSL "master" from Git (on x64_64 = amd64 Ubuntu 16.04 LTS), the configuration succeeds, but the build fails because the compiler grabs incompatible system includes for OpenSSL, when it should prefer the new includes in the Git checkout.
Workaround:
./config -I$(pwd)/include
(where $(pwd) means: expand the results of pwd here, formerly `pwd`)
Please make the equivalent of this "prefer local includes over system includes" part of all relevant branches.

I'm not sure I understand...  if you do make, all compile commands already have at least one -I option.  Why does that one make a difference?

It does make a difference because it makes sure that the local include files from the new source hierarchy (Git checkout, for instance) get preference over the older stuff in /usr/[local/]include. Try building OpenSSL master while you have 1.0.2 includes in /usr/include, it will break. Making sure that the compiler prefers /path/to/checkout/include over the old droppings in the system permits you to build a bleeding-edge OpenSSL even if old stuff remains installed.
The underlying issue remains invisible though in continuous-integration, chroot or jail or other clean-room builds.

That's an operation I do every day on my laptop, and here's a random command line picked now:
clang  -I. -Iinclude -I../master -I../master/include -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -Wall -O0 -g -pthread -m64 -DL_ENDIAN -Wextra -Qunused-arguments  -DDEBUG_UNUSED -Wswitch -DPEDANTIC -pedantic -Wno-long-long -Wall -Wsign-compare -Wmissing-prototypes -Wshadow -Wformat -Wtype-limits -Wno-parentheses-equality -Werror -Qunused-arguments -Wextra -Wswitch-default -Wno-unused-parameter -Wno-missing-field-initializers -Wno-language-extension-token -Wno-extended-offsetof -Wconditional-uninitialized -Wincompatible-pointer-types-discards-qualifiers -Wmissing-variable-declarations -fPIC -DOPENSSL_USE_NODELETE -MMD -MF ssl/d1_msg.d.tmp -MT ssl/d1_msg.o -c -o ssl/d1_msg.o ../master/ssl/d1_msg.c

That's from a build of current master, and there's nothing special at all with this, I configured like this: ../master/config -d --strict-warnings
In that line, I see this: -I. -Iinclude -I../master -I../master/include
That gives the build paths to all the include files it needs.  Specifically, the last one corresponds exactly to the additional -I you suggest.
This is standard, this is how things are supposed to work, so I'm asking for a somewhat deeper analysis of why it's not working for you specifically.

Understood. I've tried to reproduce this in several ways, but failed.

authors: levitte mandree


text:
OSSL_CRYPTO_ALLOC attribute introduction proposal.

Giving hint to the compiler the returned pointer is not aliased
(so realloc-like api is de facto excluded).

This pull request is ready to merge

Merged, thanks for the contribution.

authors: devnexen openssl-machine paulidale


text:
test/recipes/01-test_symbol_presence.t: check for duplicate symbols in static libs

This checks that all symbols are unique across all public static libraries.
This includes a bit of refacftoring to avoid repeating code too much.

This is an alternative for #20308

Ping!  I personally favor this over #20308

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.

Merged.

authors: levitte openssl-machine paulidale


text:
Add function and reason checking to evp_test

Checklist

[x] tests are added or updated
[x] CLA is signed

Description of change

Add options to check the function and reason code matches expected values.

I like at first sight. Have a look at the appveyor failures, though...

There's something strange going on. The relevant errror message is:

line 3699: unexpected keyword PeerKey
evp_test.exe ....\test\evptests.txt => 1

But evptests.txt doesn't have "PeerKey" on line 3699.

Ah, that.
The line count isn't quite right, and it's possible that this is a bio issue (see the pull request that avoids eating up '\n')
Also, I have observed some issues with BIO_seek / BIO_tell on some platforms. Not sure that plays in here and currently not in a position to investigate further...

Just tried a WIN64 no-asm build (which seems to be what appveyor is having problems with). Can't reproduce it here.

The "error" originated with the previous evp_test enhancement but oddly is only triggered by the master branch and not 1.1.0.

The "error" originated with the previous evp_test enhancement

And it seems to be gone now with another evptests.txt modification, unrelated to evp_test modification...

And it seems to be gone now with another evptests.txt modification

I mean that same error was flagged in current master and now it's gone. In current master. And it probably should be noted that there is PeerKey at line 3699 in current master. It's as if appveyor used evptests.txt from master. And for some reason got angry with itself. As for line numbers being off, it wasn't a problem on Windows so far. And at least if you corrupt evptests.txt yourself, for example by replacing PeerKey with PeerKeyy, it tells the story right...

Rebased against master, let's see what that does.

It is OK now. Any further comments?

authors: dot-asm levitte snhenson


text:
cygwin buildfix

Implements the cygwin-specific build remediation documented in https://github.com/openssl/openssl/issues/19531. Without this, "master" fails to build on cygwin.

Could you please amend the commit message to add Fixes #19531 ?

Could you please amend the commit message to add Fixes #19531 ?

Done.

Thanks for the explanation. Will do my best to remember for next PR commit. Or rather, may it be an idea to update https://github.com/openssl/openssl/blob/master/.github/PULL_REQUEST_TEMPLATE.md with more definite reminders for all contributor's benefit (what to check & do for a PR)?
I also understand that I won't have to do anything on this PR any more: Please correct me if I'm wrong.

Just found this problem when doing an oqsprovider CI job for cygwin... Would a PR be welcome adding github-action-based cygwin testing to this project as well? Or even add it to this PR?

Adding it to this PR would be OK.

Adding it to this PR would be OK.

So done in https://github.com/openssl/openssl/commit/f09f774fbb35f03866f0e463a815032c1b7d7375.

CI now passes (and fails without the code changes), so asking for a new review @t8m @tmshort

The new CI is failing...

The new CI is failing... Issues with isspace() that weren't fixed in #21127

Just saw that: Would need to get me a cygwin machine to go through all these issues. Alternatively disable strict checking in this PR again: Is it an issue/goal of relevance to the OpenSSL team to.pass 'strict' build on cygwin?

The new CI is failing... Issues with isspace() that weren't fixed in #21127

Can re-enable strict checks here after #21151 has landed.

Instead of adding another .yml for the test, could you add the cygwin job to the Windows Github CI .yml?

Instead of adding another .yml for the test, could you add the cygwin job to the Windows Github CI .yml?

Sure. Will do after #21151 has landed to test all together. Please let me know whether you're OK that we're not running "make test" as part of this CI: quic, symbols and simpletest (timer) fail under cygwin. Otherwise, I'll need to create a few separate issues as all those failures puzzle me (and I don't know QUIC, the OSSL-specific use of nm and the timer precision mechanisms under cygwin sufficiently well, respectively).

The new CI is failing... Issues with isspace() that weren't fixed in #21127

@tmshort: Now fixed. strict checks now passing.

Instead of adding another .yml for the test, could you add the cygwin job to the Windows Github CI .yml?

@t8m: Now added to windows.yml. cygwin tests passing.
Please let me know if you'd still expect me to do anything on this PR.

This pull request is ready to merge

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

authors: baentsch openssl-machine t8m tmshort


text:
Fix some memory issues

Fix two memory issues detected by #21668.

Are these master branch only problems?

Yes

This pull request is ready to merge

Merged to master. Thank you.

authors: hlandau mattcaswell openssl-machine


text:
FIPS: enforce KMAC length limits for FIPS 140-3

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

The CI failure is https://github.com/openssl/project/issues/226

Feedback addressed apart from the assert question.

ping for review please @openssl/committers

If you move the assert one line higher (above the construct_end) then the stack will not have been smashed, but the assert will still catch the problem.

Which would leave a user in an impossible situation -- the function simply couldn't ever work.  Same end result IMO.

IMO this is a bad approach.  The FIPS parameters would be better done per standard rather than per feature.  It will reduce the number we end up supporting.
E.g. SP_800_131Ar2 would be best here IMO.


text:
util/mkinstallvars.pl: replace List::Util::pairs with our own

Unfortunately, List::Util::pairs didn't appear in perl core modules
before 5.19.3, and our minimum requirement is 5.10.
Fortunately, we already have a replacement implementation, and can
re-apply it in this script.
Fixes #25366

@friesoft, @alexdotgov2, please try out this patch

Looks good to me on RHEL 7, builds for RHEL 8 + 9 are still running

Works for me on RHEL 7 + 8 + 9 :) Thanks for the lightning fast fix :)
Will this be released as a 3.3.2.1?

Works for me on RHEL 7 + 8 + 9 :) Thanks for the lightning fast fix :) Will this be released as a 3.3.2.1?

As there is a clear workaround by installing the perl module, I do not think this warrants a 3.3.2.1 release.

How does failing to build with your listed minimum dependencies not warrant a point release? This release does not build for a bunch of platforms, and telling those users to upgrade their version of perl or some perl module may be a non-starter for them.

Small detail: the next patch (point) release will be 3.3.3, regardless of when or how much goes into it.

LGTM, the patch fixes 3.3.2 builds for SLES 11 + 12, RHEL 6 + 7 .
Thanks a bunch for still supporting very basic (outdated) perl installations!

@t8m, @beldmit, re-approve, please?

I confirm my approval

This also fixes #24840.

@mattcaswell @nhorman @t-j-h
Should this issue trigger a new release?
If it was intentional (which it was clearly not), I would imagine requiring a new minimum version of Perl seems like something that should only be done on major release versions.

I'm not sure, do we have any documentation for  guidance here?  It's not something we should do of course, but I'm not sure it's so serious to warrant a new release.
Regardless however, it probably does speak to the want if a ci job that builds with our minimum build tool requirements to catch this in the future

More than a few people seem to have been stung by this and the release did address a moderate CVE so folks will want to upgrade.

The discussion on minimum requirements should be held in a discussion rather than in this PR. There are ramifications to explore.

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.

Merged to the master and 3.3 branches. Thank you.

Merged to the master and 3.3 branches. Thank you.

Is this 3.3.2.1 release or other? thanks

Merged to the master and 3.3 branches. Thank you.

Is this 3.3.2.1 release or other? thanks

No new release is going to be done for this. The patch needs to be applied on top of the 3.3.2 tarball. Please see https://github.com/openssl/openssl/discussions/25394

Merged to the master and 3.3 branches. Thank you.

Is this 3.3.2.1 release or other? thanks

No new release is going to be done for this. The patch needs to be applied on top of the 3.3.2 tarball. Please see #25394

It is very disappointing. This means that a large number of CI scripts need to be revised for this, and it is very difficult. Because many Rust components involve OpenSSL and are automatically compiled by default. To improve compatibility, the commonly used base environment is manylinux2014.

@t8m why isn't a patch release being made? This would make many folks their work easier to resolve this

A patch release means a forced update for many users of OpenSSL so it creates additional work for many people. There is of course also some work required from the OpenSSL release managers to create the release but that is not so important for the decision.
So doing a new patch release should not be taken lightly and only fairly serious regressions should trigger such release.

I will be raising this issue in the next OTC meeting (next Tuesday).

Not building on supported platforms is a serious regression, and honestly, this regression should have been caught by automation prior to release.

Merged to the master and 3.3 branches. Thank you.

Is this 3.3.2.1 release or other? thanks

No new release is going to be done for this. The patch needs to be applied on top of the 3.3.2 tarball. Please see #25394

It is very disappointing. This means that a large number of CI scripts need to be revised for this, and it is very difficult. Because many Rust components involve OpenSSL and are automatically compiled by default. To improve compatibility, the commonly used base environment is manylinux2014. In this case, the patch tarball does not work. However, revising the basic environment may conflict with compatibility specifications and cannot be executed. :(

Sorry to jump in here, but I've been facing the same issue with a manylinux: auto config and a Rust+Python project (https://github.com/nyx-space/anise/actions/runs/10748687666/job/29812702558?pr=311). Is there a workaround we can use, or are we condemned to not build our libs until the next release of openssl? I admit that the crux of the issue is that the manylinux build just uses an old version of rhel here, but I don't know of a workaround to change that.
Thanks
P.S.: Openssl dev team, you're a core tenet of all software out there, so I'll take this opportunity to thank you for all of the hard work you've put into this lib over the decades.

Is there a workaround we can use, or are we condemned to not build our libs until the next release of openssl?

Yes there is.  You can take the patch that came out of this PR (commit 40c8ebe5d2781339709554d166adb006aa495ec8).
BTW, we created a discussion category Release addendums a couple of days ago, and you'll find Release 3.3.2 errata there.

If you found your way here because you are building on manylinux via Rust, I found that cargo update openssl-src --precise 300.3.1+3.3.1 was the command I needed to roll back.

If you found your way here because you are building on manylinux via Rust, I found that cargo update openssl-src --precise 300.3.1+3.3.1 was the command I needed to roll back.

The only way is to force a rollback to 300.3.1+3.3.1 and wait for the new version to be released. That patch has no effect on this case.

Yes, that's what my command does — I'm just noting that this took me a while to figure out as a non-Cargo-expert (and it seems like I'm not the only person on this thread running into this via a manylinux build of Rust software) and that perhaps others might appreciate the explicit command.

Works for me on amazon-linux2

If you found your way here because you are building on manylinux via Rust, I found that cargo update openssl-src --precise 300.3.1+3.3.1 was the command I needed to roll back.

Adding onto this, if you don't have a Cargo.lock, simply add glasser's command as a build step before the "build wheel" step: https://github.com/nyx-space/anise/pull/313/commits/02599b3217704504813202369718dfcb73d708a2 .

authors: ChristopherRabotin NehaShrivastava2022 asedeno beldmit friesoft glasser ion-elgreco levitte metercai nhorman openssl-machine paulidale rainerjung slontis t8m


text:
rand: make public/private chaining to primary configurable

Add runtime configuration [random] chain = <bool> and build-time
configuration -DOPENSSL_RAND_CHAIN=int to control if public/private
DRBGs are chained to primary, or not. Defaults to chain, current v3+
behaviour.
This is useful for NIST ESV certification, as currently chained and
unchained entropy sources are considered to be distinct. Thus
operating without chaining, may allow reuse of an existing ESV
certificate for Linux kernel, or Jitter Entropy library without need
to re-submit a separate ESV certificate for linux+OpenSSL or
jitter+OpenSSL, as per current guidance.
Also note, future developments in Linux kernel may make un-chained
mode of operation particularly attractive with inclusion of getrandom
in vDSO in upcomming Linux kernel v6.11, potentially being quicker
than chaining with locks to a syscall. Thus there is performance
optimisations to this as well.
Note current chaining behaviour is preserved, and it is considered to
be behave better on low entropy systems.
Note 3.5+ FIPS module self-unchains. Thus this unchaining is for
default provider and to support 3.4 and earlier FIPS modules.
Also see lots of review & design choices in:

Merged https://github.com/openssl/openssl/pull/25415
Draft 2 https://github.com/openssl/openssl/pull/25275
Draft 1 https://github.com/openssl/openssl/pull/25168

This PR is in a state where it requires action by @openssl/committers but the last update was 30 days ago

authors: openssl-machine xnox


text:
Restricted include of poll.h to UNIX but not NonStop (not supported).

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

waiving style, indentation for changes look right to me

This PR is in a state where it requires action by @openssl/committers but the last update was 30 days ago

authors: nhorman openssl-machine rsbeckerca


text:
Improve the usability of the ca app using EdDSA

Previously you had to supply "null" as the digest to use EdDSA. This changes
things so that any digest is ignored.

I guess this is perfectly fine for now.
I only want to raise the issue of thinking about a future when instead of only PureEdDSA OpenSSL might support also HashEdDSA: would this change have an unintended impact on configuration patterns or command line arguments that might be difficult to break in future versions?
I honestly don't know the answer, nor if such issues would concern the guarantees in minor or major releases.

I only want to raise the issue of thinking about a future when instead of only PureEdDSA OpenSSL might support also HashEdDSA: would this change have an unintended impact on configuration patterns or command line arguments that might be difficult to break in future versions?

I did consider this, but I don't think it is an issue. The way it has been implemented the ca app asks the EVP_PKEY object what its default hash is. Only if the default hash is undefined is it allowed to not have a hash specified. If we later implement hash EdDSA then the EVP_PKEY will return with a sensible, defined, hash.

Thanks for clarifying it @mattcaswell!

It seems to me that req.c be fixed the similar way to ca.c.

I'm not sure that code should ignore configuration settings. Correction for #6201 , i.e. null digest is fine with me.

I'm not sure that code should ignore configuration settings. Correction for #6201 , i.e. null digest is fine with me

The current solution is causing some significant usability problems, so it doesn't seem to be viable:
https://mta.openssl.org/pipermail/openssl-users/2018-August/008473.html

I added a new commit to make an equivalent change in the req app. Interestingly, while updating the documentation for that I discovered that we already ignore the digest configuration setting in req in some situations so this approach seems consistent with that.

@richsalz please reconfirm

reconfirm.  good catch, @petrovr !

I think the catch was @beldmit...!

mattcaswell wrote:

I think the catch was @beldmit...!
Perhaps  @beldmit is reporter.

My point is that program code can not ignore invalid values:

null is valid value,
missing digest could mean use default , i.e. null
other values, for instance sha1, should break processing .

Regards,
Roumen Petrov

My point is that program code can not ignore invalid values:

null is valid value,
missing digest could mean use default , i.e. null
other values, for instance sha1, should break processing

I disagree. It is perfectly reasonable to want to set a default digest of (say) sha256 for most stuff, but not use it when doing EdDSA.

mattcaswell wrote:

My point is that program code can not ignore invalid values:

null is valid value,
missing digest could mean use default , i.e. null
other values, for instance sha1, should break processing

I disagree. It is perfectly reasonable to want to set a default digest of (say) sha256 for most stuff, but not use it when doing EdDSA.

Digest depends from algorithm.
I would like to have more consistent behaviour. For instance if I set
md5 for dsa processing is  blocked by error  ..."dsa
routines:pkey_dsa_ctrl:invalid digest type:crypto/dsa/dsa_pmeth.c:142:"
This is reason to ask for consistency with existing functionality.
Roumen

I have the required approval for this, and I still think this is the correct approach, but given @petrovr's objection I invite any other comment from @openssl/committers.

I don't see the parameter as forcing a digest value conceptually.
I think defining default_digest to mean the digest for algorithms that allow a settable digest is a reasonable approach (and the documentation should be updated to make that clear that this is the definition of the configuration parameter - not that some algorithms ignore it - that it only applies to algorithms that allow settable values). That way it is clearer what is going on here and looks less like a workaround.
Basically more clarity in the docs wording - but I agree with @mattcaswell in terms of the approach.

It is about how to change existing code :
...
if (md == NULL && (md = lookup_conf(conf, section, ENV_DEFAULT_MD)) == NULL)
goto end;
...
, i.e. parameter "default_md" has to be specified either on command line or in configuration section.
Above could be split as follow:
...
if (md == null) md = lookup_conf(...)
if (md == null) {
if md is required : goto end
else md = "default"
}
...
I expect above code to allow user to use default_md=default and with proposed modifications (correction in existing function and addition of new one) for ASN1_PKEY_CTRL_DEFAULT_MD_NID "null" digest to be used.
Also think about "default" to be set unconditionally in above code snippet.

I don't like to stop progress on this issue, i.e. approvals.
For protocol I did tests with following code snipped from apps/ca.c
if (md == NULL)
    md = lookup_conf(conf, section, ENV_DEFAULT_MD);

if (md == NULL)
    md = "default";

if (strcmp(md, "null") == 0) {
    dgst = EVP_md_null();
} else {
    if (strcmp(md, "default") == 0) {
        int def_nid;
        if (EVP_PKEY_get_default_digest_nid(pkey, &def_nid) <= 0) {
            BIO_puts(bio_err, "no default digest\n");
            goto end;
        }
        /* NID_undef if signing algorithm requires there to be no digest */
        dgst = (def_nid == NID_undef)
            ? EVP_md_null()
            : EVP_get_digestbynid(def_nid);
    }
}
if (dgst == NULL) {
    if (!opt_md(md, &dgst))
        goto end;
}

This was my idea. Let me know if someone found above generic approach useful. Is so I open an enhancement request.
In all cases go ahead with current status.

BTW, why not to specify a separate NID, not NID_undef for md_null? It can save us from separate processing NID_undef as dgst_nid here and may be in some other places of code.

BTW, why not to specify a separate NID, not NID_undef for md_null? It can save us from separate processing NID_undef as dgst_nid here and may be in some other places of code.

One could perhaps argue that the "Intrinsic" TLS HashAlgorithm defined by RFC 8422 (section 5.1.3) would argue for having such a dedicated new NID, but if we do add such a thing, we'd need to assign it some semantics for all the other places it could be used, and it's unclear that we really want to do that.

For reasons I don't entirely understand (or agree with), this PR seems to have been more controversial than I expected. However I still believe this is the correct approach, and it has all the relevant approvals and support from an OMC member, with no "-1" from any committer, so I have pushed. If people want to they can follow up with further PRs as appropriate.

authors: beldmit kaduk mattcaswell petrovr richsalz romen t-j-h


text:
Change a bit how we manage RHOL/CRC

The logic was a bit broken and overly complicated for nothing.
Now, it's simple:

we detect if the VM exists
if so, we check if we can either re-use it or if we want a cleanup
if we want to clean it up, well, go that path, clean and boostrap it
if we can re-use it, stop there (but add the crc kubeconfig if wanted)
if VM does not exist, bootstrap it

That way, we should cover most of the potential cases, such as:

pre-provisioned CRC on a node (case for Zuul CI)
operator iterating on a specific deploy, not wanting to crash CRC and
wait for it to re-start on each iteration
brandh new env without anything

/lgtm

authors: adrianfusco cjeanner


text:
Use common memcached.GetMemcachedServerListWithInetString()

Use common func to retrieve the memcached server list for a memcached instance.

/test cinder-operator-build-deploy-kuttl


text:
Update horizon to use service override

Removes creation of routes. Those get done in the openstack-operator. Via service overrides the openstack-operator customize the services for the endpoints to the desired state specified in the ctlplane CR using externalEndpoints or the service override in the service template.
Jira: OSP-26690
Depends-On: https://github.com/openstack-k8s-operators/lib-common/pull/313

/hold

closing in favor of #212