text:
Added Distiguished Name API

Description
Added Distiguished Name API.
Issues Resolved
[#106 ]
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

I'm not sure why I can't get successfully through "DCO" check,
I used '-s' flag in my last commit.

@aabeshov Looks like maybe you'd missed pushing some changes as many of the earlier requested changes were marked as resolved but had not been made, so I've "unresolved" those requests for now.

@aabeshov Let's close this PR and create a new one since this one is too old. We have had so many merged since you first created this one. Remember to rebase onto upstream/main daily and right before you push up a change to make sure that there are no conflicts.

authors: Xtansia aabeshov nhtruong


text:
Operator 2.6.0 Memory Leak

What is the bug?
Over time, the operator container consumes more memory until it fails and is recreated. This issue was present in 2.5.0 and 2.5.1 as well. We reverted all clusters to use 2.4.0 and the problem went away.
How can one reproduce the bug?
Setup the 2.6.0 operator and deploy a small OS cluster with it. Monitor it over the next day or two and you'll see the memory consumption of the operator manager pod continually increases. Higher activity clusters grow faster and fail more often. A slow memory creep can be observed within less than an hour.
What is the expected behavior?
Our clusters that use 2.4.0 Operator have garbage collection that runs regularly and memory consumption is very regulated between 20MB and 50MB. Stable for months.
What is your host/environment?
We are running Opensearch 2.6.0 with Operator 2.6.0 (now reverted to 2.4.0) on AKS (Also observed on docker-desktop and Rancher).
Do you have any screenshots?
#700 There are plenty of screenshots on this ticket referencing 2.5.1 (which also had this leak). That ticket is for 2.4.0 but we haven't observed any issues with 2.4.0.
Do you have any additional context?
I've tested this with a small cluster without any additional plugins or even indexes on them to rule out some plugin causing the leak. This appears to be something in the Operator itself. A development cluster started at 110MB and overnight is now at 241MB and climbing. I kept the limit of 500 the same and it crashes when it hits the limit. Increasing the limit doesn't help, just delays how long before it crashes and wastes resources.
Any help appreciated!

I think pprof could be useful in determining root cause here. We are unable to upgrade past 2.4.0 until memory leaks are resolved. There is a prioritized issue for pprof here: pprof

[Triage] Thanks @mrvdcsg for reporting the bug, as you noticed there is already an open issue for this bug. Can we club both the issues under one umbrella? Thanks Adding @swoehrl-mw @salyh @bbarani

I agree that this can be included in issue 700. That ticket reported a memory leak in 2.4.0 and I wanted to create visibility to it existing in 2.5.1 and 2.6.0. I will close this ticket and allow it to be tracked on the other open issue.

source: gharchive/issue

license_type: permissive

license_source: github-api


text:
Remove cert usage from CI

Remove added certs from upstream (https://github.com/opensearch-project/opensearch-py/tree/main/.ci/certs). This will be added as support to security plugin
Remove references like https://github.com/opensearch-project/opensearch-py/blob/main/opensearchpy/helpers/test.py#L47
Remove references from upstream https://github.com/opensearch-project/opensearch-py/blob/main/opensearchpy/helpers/test.py#L40

The pull request has been merged!

authors: Shivamdhar VijayanB

repo: opensearch-project/opensearch-py


text:
[BUG] Client/Core Engine Compatibility Matrix Wrong/Outdated

What is the bug?

The compatibility matrix [1] indicates that I need client v1.1 to talk to OS 1.2.0, but client v1.0 to talk to OS 1.2.1.  This is confusing and almost certainly not intended.
Additionally, the compatibility matrix gives no indication on compatibility with the many newer versions of the core engine (2.1, 2.2, 2.3, 2.4).  It would be helpful to indicate whether the newest version of the client (2.0) should be considered compatible or not, or at least whether that's currently unknown/untested.  Right now, readers are left with no idea whatsoever, especially since the matrix is almost certainly wrong about compatibility with OS 1.X versions.

[1] https://github.com/opensearch-project/opensearch-py/blob/main/COMPATIBILITY.md
How can one reproduce the bug?
Read the compatibility file :-)
What is the expected behavior?
N/A
What is your host/environment?
N/A
Do you have any screenshots?
N/A
Do you have any additional context?
N/A

Thanks for the updated documentation!


text:
OUI-Codepipeline CDK

Create CDK to deploy codepipeline , which we will use to deploy oui doc-site to s3.

Update:

CDK is ready & Deployed over opensearch-infra.
Ticket is pending for creating new repo to deploy CDK
Pipeline is ready
Doc Site is Up & Running Site

Are we going to eventually have a nicer human-readable URL?

Will update CDK to handle staging + prod.

Repo is live!

authors: BSFishy joshuarrrr kaddy645

repo: opensearch-project/oui


text:
Coralogix partner page

Description
Extended partner page for Coralogix.
Issues Resolved
https://github.com/opensearch-project/project-website/issues/1935#issuecomment-1696589576
Check List

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the BSD-3-Clause License.

@astephanus - got an odd error running locally:
"             Error: YAML Exception reading /OpenSearch/temp-astephanus-coralogix-partner-page-project-website/_exhibitors/coralogix.md: (): found unexpected end of stream while scanning a quoted scalar at line 4 column 7"

@astephanus - got an odd error running locally:
" Error: YAML Exception reading /OpenSearch/temp-astephanus-coralogix-partner-page-project-website/_exhibitors/coralogix.md: (): found unexpected end of stream while scanning a quoted scalar at line 4 column 7"

Thanks @krisfreedain. I'm not entirely sure how that slipped through the cracks. Nevertheless, it is resolved.

Closing because of Github confusion about "merge-base change" message. Redone in PR https://github.com/opensearch-project/project-website/pull/1946

source: gharchive/pull-request

authors: astephanus krisfreedain

repo: opensearch-project/project-website


text:
Adds new author KakaInnocent

Description
[Describe what this change achieves]
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the BSD-3-Clause License.

Sorry for the delay

Hey, please move this file to _authors/osci_2023/ and then we should be good to complete!

Hey already done it maybe now we can check and proceed. Thank you


text:
Remove usage of legacy url API .query

We should switch to .search which is part of the node api, see https://nodejs.org/docs/latest-v14.x/api/url.html which has more details.
Impacted code
https://github.com/opensearch-project/security-dashboards-plugin/blob/fc7b8cc994046c830d950dc57742e6f1ac542b7b/server/auth/types/basic/routes.ts#L173-L174

[Triage] We should also look into url.path that is used right above this location in the file.

Removing the label for 2.0.0 as the PR hasn't been ready yet.


text:
[RFC] Dashboards object sharing (replace Dashboards tenants)

Background
OpenSearch users have adopted the security plugin to manage the data permissions of users across various teams within their organization. In addition to providing fine grained access control for actions on the data and the cluster, various authentication mechanisms including basic and SAML, the security plugin also provides the ability to isolate OpenSearch Dashboards objects using a concept of tenants. An OpenSearch cluster is often shared across different teams or customers using services of a common vendor. In such scenarios we need to provide admins with the necessary tools to easily isolate data sets as well as any derived Dashboards objects including visualizations, dashboards, reports etc.
Problem statement
OpenSearch users want to share and collaborate on Dashboard objects with one or more users/teams in a simple and easy workflow, while having the ability to see and filter through private or shared objects in the same view. In addition, users want a simple way to isolate the data and Dashboard objects in a scoped view so only users of that role can access the data and associated Dashboards objects (eg: visualizations, saved queries, reports, dashboards etc) to generate valuable insights and support in making business decisions.
Existing solution for sharing Dashboards objects
Tenants in Dashboards is a popular feature that provides the ability to end users to create shared collaboration spaces for saving Dashboards objects such as visualizations, dashboards, reports, saved searches, default index patterns. This is the only solution that helps admins to configure their clusters to provide a clear and isolated view to multiple teams in their organization or to multiple clients that may be hosted on the same cluster. This customized view helps make business decisions faster by providing relevant insights to specific sets of users.
Tenants are configured by the admin who is responsible for all the security configuration and permissions mapping for users in the organization. Tenants are most commonly used in the following ways

to share or collaborate with users or similar role/team/project
to create a clear data separation of indices and visuals on the data in such indices. Roles and tenants have a many to many relationship, making it much harder to manage these mappings.

Shortcomings of the existing solution
While tenants help in separating Dashboards objects, they are often misunderstood to also provide a traditional multi-tenant architecture that provides data separation and/or infrastructure isolation (hardware, power etc). This is simply untrue as tenancy is designed as a Dashboards concept and should not be mixed with the separate role to permissions mapping needed for the data indices stored in OpenSearch.
Following is a comprehensive list of shortcomings of tenants as a mechanism to share and collaborate

Tenants are misinterpreted to provide data separation, but they are really only designed for Dashboards objects separation
Users cannot share objects with other users who are not part of the same tenant (Eg: index patterns, visualizations etc)
Users cannot change the access scope of an object (Eg: moving index patterns, visualizations etc from one tenant to another)
Users don’t have a simple way to list all objects that they have the permissions to. They are required to switch between tenants to see a list of objects belonging to that tenant (which takes several seconds as Dashboards is reloaded every-time there is a change in tenant). Also users need to remember the tenant where they created each object
Complete Dashboards experience is anchored around the current tenant that the user has selected instead of being anchored around the user and their permissions
Currently on first session login, Dashboards defaults to “private” tenant. This is confusing for customers as those who are just assigned one tenant (eg: “global") and dont need to know the concept of tenants, are now required to understand the concept of tenants and make a selection at login
Roles need to be carefully mapped to individual tenants with the right level of permissions (read or read and write). This is a many to many relationship
Many roles can be assigned to the same tenant. One role can have access to many tenants. Different users logging in with different data permissions may need different default index patterns, which is not possible with current implementation, leading to a degraded experience where users may see missing or empty objects (eg: visualizations)
Users with inadequate permissions to certain objects (eg: visualizations) do not know what permissions they are missing and there is a significant back and forth that needs to happen with the admin, who needs to re-verify their data permissions
In order to share objects, users need a way to define the scope of the object and permissions for other users or roles
There are multiple different workflows for sharing objects using tenants, plugin permissions, cluster and data permissions resulting in different experiences and adding confusion
Number of private tenant indices can become a performance bottleneck for organizations with hundreds or thousands of users

This has resulted in a sub-par experience for OpenSearch users who often ask to disable tenancy entirely.
Proposed solution
OpenSearch users have made us aware of many of the shortcomings of the current solution that is difficult to use, while lacking some critical features. This is an opportunity to rethink the approach to enabling sharing with OpenSearch Dashboards.
The shortcomings highlighted in the above section have led us to rethinking the approach to sharing Dashboards objects.
As we have seen above, the current mechanism doesnt meet users requirements of sharing and collaborating on Dashboards objects in a simple and easy way. This is an opportunity to redesign and simplify the core workflows and functionality that is currently partially fulfilled by tenancy,  to create a simpler user sharing experience. Following is a list of recommended features

Users can share individual Dashboards objects with other users, roles or external identities (also knows as backend roles), given they have the permissions to shareRole mapping workflow should allow turning on default sharing with users of the same role
Users can see a list of all Dashboards objects in one place. Eg: If the user is viewing a list of visualizations, they must be able to view all the visualizations that were created by them or shared with them, in one place. Similarly for other objects including dashboards, index patterns etc
By default, new user created objects are shared with the users of the same role. They can be easily marked as private or shared with additional users, before saving the object
New user created objects are shared with the role by default and can be easily changed to be shared with one or more users or made private
Index patterns should be tied to a user. Index patterns are the primary anchor for all searches including discover, visualizations, dashboards etc. This configuration should be specific to a user as every user may have a unique combination of roles and data permissions. Every user may want to search on a different index pattern, that should be remembered across logins
Advanced settings (such as settings for search, visualization, timeline, notifications, allowing leading wildcards, dark mode etc) that are currently in scope of a tenant, will instead be in scope of a user so they can customize their views and preferences
The security sub-section in Dashboards will now also include a pending/approved permission requests tab. This will show user requests with permissions to specific data sets. Admins will have the option to approve or deny such requests
Users should be able to “Request access” with one click on any data being visualized across Dashboards . This request automatically shows up in the admin or security manager dashboard, for approval or rejection
Simplify the role mapping workflows to unify data, plugin and sharing permissions in a unified workflow that is anchored around a user or role

New concepts
As we work on rethinking how we enable OpenSearch users to share and collaborate, we can preserve some core concepts, while introducing new ones. Following are concepts that need to be introduced for a seamless sharing experience.
User profile
Currently we support very limited user specific settings that are remembered on login, but only from that specific browser (eg: last used tenant). We don't have any mechanisms in place that remember user preferences across logins. Also some experiences need to evolve from being tied to tenants, instead to be part of a user profile. For eg: index pattern is currently tied to a tenant or advanced settings (such as settings for search, visualization, timeline, notifications, allowing leading wildcards, dark mode etc) are per tenant. Every user can have a unique data permissions, preferences and should be able to select an index pattern or Dashboards settings that are relevant to the queries they run. This will also eliminate the issue of users with different roles logging into the same tenant and at least one of them not being able to see any data visualized due to the default index pattern not matching their data permissions or being forced to use the advanced settings of the specific tenant. User profile will also be helpful if we decouple Dashboards from OpenSearch, as it will help narrow down the specific query in the context of that user.
Sharing and permissions
Sharing will replace the core functionality that tenancy provides today, by allowing a mechanism to collaborate with other users and roles. Each Dashboard object can be individually shared with different permissions (read, read/write) with other users or roles. Each user will have the ability to share the Dashboard object that they create, but admin can limit users from sharing altogether (eg: for read only roles).
Dashboards objects ownership
Currently Dashboards objects are owned by the tenant that creates them. One or more users may be assigned to that role and direct ownership of the object isn't saved. As we introduce the concept of sharing, it is critical to have ownership of individual Dashboard objects. By default any newly created object will be owned by the user creating it.
Aggregate object views
Currently if a user has access to multiple tenants, they need to switch between tenants, in order to see the relevant Dashboard objects of that tenant. We will introduce a new concept of aggregate views wherein the user can see the full list of all Dashboard object categories including objects that they created and objects that are shared with them. We will provide powerful filtering mechanisms that would allow users to easily find the objects they are looking for. Eg: On the dashboards page, users can see a list of all the dashboards that they created as well as dashboards that were shared with them by other users. Similarly for different categories of Dashboard objects including visualizations, saved searches etc, each of these objects will provide a simplified listing of all objects of that type. The user will not have to leave the page and jump between tenants to find the objects they are looking for. Aggregate object views will provide a single pane of glass for Dashboards objects.
As a result of the sharing mechanism, we will also do away with the inability of moving dashboard objects from one tenant to other. Now there is no need to do that as the user can see all the objects in a single unified pane.
Administrator or security manager dashboard
One of the other problematic areas that goes hand in hand with tenancy is data isolation. While tenancy wasn't designed for data permissions, we are proposing a simpler design that would allow to make this experience easier. When a user views a shared dashboard object that they don't have data permissions to visualize, there would be a mechanism for the user to “Request permission”. Such requests will show up in a admin/security manager panel where they can be approved or denied with the click of a button. We will also provide mechanisms to group actions for easier management. Once approved, the requesting user can see the data that they need to see. In the background, the system will add the data permissions (with explicit approval from the admin) needed by the user to view the requested data.
Tagging
As clusters scale, there will be several users and continuous stream of Dashboards objects creation activity. In order to simplify viewing, filtering, sharing and grouping, we will introduce the mechanism of tagging objects. This will allow users to share various categories of Dashboards objects in one flow. Tagging is also useful to take bulk actions such as deleting objects, group tagging, sharing etc. Eg: If a user wants to share all relevant objects related to “incident-april-5-2022”, they can do so by simply filtering for objects with a specific tag and share them in one workflow. Note that since tags are relevant to the specific user, when objects are shared, the associated tags are not. Every user can tag and group objects how they see fit for their usecase without being overwhelmed with tags associated by object creators.
Simplifying role permissions
Currently roles are assigned access to tenants with either a read or read/write permissions. This creates confusion between boundaries of data permissions and dashboard object permissions, leaving admins often struggling to find the perfect combination of data, plugin, cluster and tenant permissions. In addition some roles are exclusively defined for plugins making it time consuming and difficult to arrive at the perfect combination of permissions for a given user or role. We will aggregate all permissions within one workflow so admins can decide the right cluster, index, plugin and sharing permissions in the same role mapping workflow. Admins can turn on “Sharing by default” in any role, so any user who has assumed that role, can automatically share their newly created Dashboard objects with other users of the same role meeting the needs of users who want data isolation but also share Dashboard objects within the same role. This will give admins a comprehensive view of the role permissions across data, cluster, plugins and sharing.
Migration of existing tenants and dependent plugins
While we introduce new, powerful and simplified concepts, we need to find a proper migration path for clusters currently enabled with tenancy. We need to do this without changing the scope of the permissions and without requiring significant overhead on the administrator for any reconfiguration. There are some plugins that also use the concept of tenancy (eg: Reporting). We need to provide a clean migration path for such plugins.
Index patterns are being migrated from being associated with a role to being associated with a user. This is a significant shift in usage behavior and we need to ensure that post migration the scope of permissions stays the same while each user also has access to index patterns previously associated with the tenants that their roles had access to.
Requirements
Attached requirements highlight how we wish to integrate the core concepts of sharing into existing workflows while carefully introducing new concepts to meet the users requirements (See attached spreadsheet)
Sharing with Dashboards GitHub v1.xlsx
Ask
We are requesting the community to evaluate this RFC, share their feedback, comments and proposals.

We love the concepts of tenants, however I am slightly worried about this proposal to replace them on my understanding of what I've read.  There's a lot written above so I may be misinterpreting some of it -  if this is the case please help me understand better the proposal!
We use tenants to organise data from various products into verticals where each tenant (product) is compartmentalised and separate from each other one.  This means that we can set up visualisations, dashboards and index patterns for one product are completely separate from another.  This seems to be use-case 2 raised in the proposal above: "to create a clear data separation of indices and visuals on the data in such indices"
The shortcomings listed above state that the "Complete Dashboards experience is anchored around the current tenant that the user has selected instead of being anchored around the user and their permissions", however this is exactly how we use tenants and do not wish to move away from this model.  If a user has access to all tenants we still want to be able to show only data for the current product as conceptually they are completely separate from other products.  I don't want to see dashboards and visualisations for Product 2 when I am looking at Product 1.

Users can share individual Dashboards objects with other users, roles or external identities (also knows as backend roles), given they have the permissions to shareRole mapping workflow should allow turning on default sharing with users of the same role

This sounds good

Users can see a list of all Dashboards objects in one place. Eg: If the user is viewing a list of visualizations, they must be able to view all the visualizations that were created by them or shared with them, in one place. Similarly for other objects including dashboards, index patterns etc

A good idea, but only if not the default.  I'd like to see and focus on the data I am interested in for the product I am looking at without having to search through hundreds of other visualisations.

By default, new user created objects are shared with the users of the same role. They can be easily marked as private or shared with additional users, before saving the object
New user created objects are marked as private by default and can be easily changed to be shared with one or more users

Not sure I understand, these seem to contradict each other.   Would new user created objects shared or private by default?
If new user objects are shared with users of the same role then how will this work when a user has multiple roles?

Index patterns should be tied to a user. Index patterns are the primary anchor for all searches including discover, visualizations, dashboards etc. This configuration should be specific to a user as every user may have a unique combination of roles and data permissions. Every user may want to search on a different index pattern, that should be remembered across logins

How will index patterns be assigned to users when using an external auth eg. LDAP?  We don't want to have to define index patterns for hundreds of users individually.  Our users don't understand index patterns, nor do they wish to know about index patterns.  Most just want to view a dashboard and see pretty graphs.

Advanced settings (such as settings for search, visualization, timeline, notifications, allowing leading wildcards, dark mode etc) that are currently in scope of a tenant, will instead be in scope of a user so they can customize their views and preferences

Sounds good, as long as defaults can be set.

The security sub-section in Dashboards will now also include a pending/approved permission requests tab. This will show user requests with permissions to specific data sets. Admins will have the option to approve or deny such requests
Users should be able to “Request access” with one click on any data being visualized across Dashboards . This request automatically shows up in the admin or security manager dashboard, for approval or rejection

Sounds like a notification system would also be required here to notify admins that they have pending requests

Simplify the role mapping workflows to unify data, plugin and sharing permissions in a unified workflow that is anchored around a user or role

As long as there is the ability to select a specific role and view and explore data through the lens of that role this seems fine.
All in all, I feel it may just become for more difficult to administrate for more than a handful of users.  I also feel that it will raise the barrier for entry with users having to understand more about permissions and therefore make the software harder to use.  Don't fall into the same trap that Elastic seems to have fallen into in wanting every end user to understand how Kibana/Dashboards works.
Thanks for putting together the proposal.  I'm really glad of this discussion but I'm not sure I quite see how the proposal as it stands can satisfy use-case 2 raised above: "to create a clear data separation of indices and visuals on the data in such indices".
Would love to hear feedback on the above.

Will have to keep this brief, so sorry for the stream of consciousness response...
As for the notion of "tenancies" being misinterpreted as providing data separation, fair enough - but we use it in the manner suggested, to provide compartmentalization of dashboards and visualizations.  Like @jgough above, we don't wish to lose that aspect of the tenancy nomenclature.
However, having a means to place certain indices in specific storage spaces in order to provide data separation would be desirable.  But that seems beyond the scope of your proposal.
One of my frustrations is in changing visualizations and dashboards where the index pattern name has changed, resulting in a different UUID, which requires a fairly manual process to update the underlying visualizations - I can't say how the proposed idea of tying index patterns to the user may help with this - I'll just note that changing an index pattern (uuid) shouldn't invalidate all of the dashboards and visualizations that were based on the previous iteration.
We use doc-level security to provide fine-grained access control, and would be nice if the security plugin permitted a "self-service" role request mechanism - that is, a user can request a role, and the admin role can approve it.  I like this.
The way we use Opensearch is to drop it into a client's site, and more often than not, the client doesn't provide us access to their SSO service, so we use the security plugin.  So, like self-service role requests, it would be nice to have a self-service sign-up so users can enter their own account info (subject to admin approval) - or at least, allow a "change password at next login" and password aging/complexity rules - it's kind of awkward to generate a password for a user account, find a way to transmit it to them securely, but with no assurance they'll ever change it, or will change it to something dumb, like "password".  As noted above, some kind of notification system that there are outstanding requests would be necessary (that is, some kind of external notification system - i.e. slack or email.)
Tagging - The notion of "tagging" sounds like something I've been thinking about, but am unsure how it would be implemented in practice - seems to me the current design of dashboards / visualizations are great at providing filtering of events - but they're read-only, and don't provide a convenient mechanism for updating fields, for example:

A document comes in, and needs to be manually categorized - for example, call it a "firewall" event - the ability of someone with appropriate authority to add/update a category field value via a visualization that corresponds to a DLS / role field so that once updated, only those with the "firewall" role can see that/those documents.
A simple control tag on a document like "Open/Closed" or "View/Hide" would be great as part of a workflow.  For example, a document comes in that forms a case record and its initial value is open or null (displayed.)  Would like to be able to incorporate a state change workflow, such that a user can change the tag - "In progress", "Closed", etc, with a notes field can be entered, together with an audit stamp - "user jdoe updated this field to 'Closed' at dd:mmm:yyyy hh:mm".   This would require read/write access to certain designated fields, while all others could remain read-only.

Using the console or query workbench isn't really appropriate for this type of operation.
Thanks for the detailed proposal, there are some interesting ideas in there.  At the same time, I'll have to echo @jgough's concerns above - the goals are great, but if it raises the administrative complexity and overhead for simple use cases, it could be counter-productive in driving adoption.

@squiddy-gh and @jgough - I'm hearing the need for some kind of either workspace, or other organizational concept that would allow users to easily share objects together without having to look through and parse through a bunch of additional "noise" to get to what they are looking for. This makes me wonder if either a hierarchichal organization structure could be added as an option (perhaps folders that users can save objects into, so that all objects in the same folder can have shared permissions, visibility, sharing), or even the notion of a workspace. My concern with workspaces, is that this makes sharing objects between spaces more challenging, and it tends to give people the incorrect assumption that workspaces provide data isolation (true multitenancy), when in reality it usually results simply in dashboard objects isolation.
As we continue to evolve the concept of tenancy, I want to ensure we don't throw out useful concepts, so I really appreciate the additional perspective here.

Are there many forum posts around this issue and the problems people are having?  I had a quick search but couldn't find anything.  I'd really like to understand if I'm an outlier in liking the existing tenant system.

This is an interesting topic. I share the opinion that the current multi-tenant mechanism leaves a lot to be desired. So, I strongly appreciate your initiative. Still, the topic has lots of different facets, dimensions and external constraints, which makes it hard to find a solution which suits all needs.
First of all, it would be nice if the feature would be designed in such a way that  3rd party security plugins like Search Guard would remain inter-operable with Dashboards.
Now to the actual proposal. For now, I just have a random list of observations and thoughts. I think there are a couple of issues/challenges. But life would be boring without challenges, wouldn't it? :-)
You are writing in the "Shortcomings" section:

Many roles can be assigned to the same tenant. One role can have access to many tenants.

IMHO, the m:n relationship between roles and tenants is desirable. This is a standard behavior that also holds for indices and other permissions: Roles can give access to many indices and one index can be accessed by many indices.
Only this gives administrators great flexibility in modeling their organizational structure (which can be amazingly complex). A very simple example for roles which leverage the m:n relationship are roles like all_access (which is actually a built-in standard role in OpenSearch). This gives privileges to access all tenants by specifying the tenant pattern *. Thus, if you want to have all_access like roles, an m:n relationship is essential.
This m:n relationship between roles and granted privileges can be found in most software secured by role-based access control. Thus, I would not consider it too hard to understand to the experienced administrator.
In a similar context:

Users can share individual Dashboards objects with other users, roles or external identities (also knows as backend roles)

I would not recommend to let users share objects to roles or backend roles. Right now, roles and backend roles are a concept that is totally invisible to users. Roles and backend roles are only visible to administrators. Thus, the names of roles are designed to suit the needs of administrators, not the needs of users.
Also, roles are not necessarily modeled after organizational structures. There are the pre-defined standard roles all_access and kibana_user (sic). For both roles, it does not make sense to share objects with.
Going further in the "Shortcomings" section:

Different users logging in with different data permissions may need different default index patterns, which is not possible with current implementation, leading to a degraded experience where users may see missing or empty objects (eg: visualizations)

And in the "Proposed solution" section:

Index patterns should be tied to a user. Index patterns are the primary anchor for all searches including discover, visualizations, dashboards etc. This configuration should be specific to a user as every user may have a unique combination of roles and data permissions. Every user may want to search on a different index pattern, that should be remembered across logins

The change of index pattern association should be not necessary if OpenSearch security is running with the enabled do_not_fail_on_forbidden setting (in config.yml). In this case, OpenSearch security takes care that the currently logged in user is only able to "see" the indices that they are authorized to access.
Consider the following example:
Cluster has indices:

a_1
a_2
a_x

User is only allowed to access a_1 and a_2.
With do_not_fail_on_forbidden disabled, the user would be indeed not able to view visualizations with the index pattern a_*, as this also matches a_x.
However, if the user has enabled do_not_fail_on_forbidden, they would be able to view the visualizations. The visualizations would just not include the index a_x.
Thus, with do_not_fail_on_forbidden enabled, it is not really necessary to move index patterns to a user scope.

Users with inadequate permissions to certain objects (eg: visualizations) do not know what permissions they are missing and there is a significant back and forth that needs to happen with the admin, who needs to re-verify their data permissions

Going to a general level: Of course, it is challenging to manage complex privilege configurations, especially when these include many dimensions and when the organization is large. However, IMHO, this is an inherent property of complex organizations, which never can be completely avoided. Also, it is not exclusive to Dashboards, but to any application that accesses OpenSearch indices. Thus, the "significant back and forth" you described above will be always present to a certain extent. I believe that better diagnostic information would be better suited to improve this than user-level index patterns.

Users can share individual Dashboards objects [...]

Saved objects in Dashboards are extensively interconnected. For example, a dashboard contains several visualizations; all these entities are individual saved objects. I think we need some definition what is supposed to happen when a user tries to share an object which includes other objects the user does not share.

Users can share [...] objects with other users

In many security configurations - especially for clusters with SSO-based authentication like SAML or OIDC - it is either difficult or even impossible to get information about users other than the currently logged in user.
Consider the following example:

Cluster is configured to use SAML authentication using an external IdP
A new user is created in the IdP
An existing user wants to share an object with the new user

Dashboards is now unable to provide any guidance with the sharing process, as it does not have any information on the new user. It is impossible to implement a user search functionality that would be able to search for the new user. If you allow entering the bare user name, Dashboards would be unable to verify whether the user exists or not.
A workaround would be that Dashboards would keep a list of users which have logged in before. Thus, the new user would need to login at least once until they can receive shared objects.
Then, however, the opposite case would be an issue: If a user is deleted in the IdP, Dashboards would get no information about this. Thus, other users could still share objects with that user, even though that user would never be able to see these.

Currently Dashboards objects are owned by the role that creates them. One or more users may be assigned to that role and direct ownership of the object isn't saved. As we introduce the concept of sharing, it is critical to have ownership of individual Dashboard objects. By default any newly created object will be owned by the user creating it.

Minor, non-relevant nit-pick: currently, Dashboards objects are owned by the tenant that creates them.
If you want to move the ownership to users, we need a more precise definition what ownership means.
Also, it should be clarified whether and how ownership can be transferred, for example for the case that a user leaves an organization.

@nibix Thanks so much for taking the time to evaluate and share your feedback on this proposal.
That is a fair point that a role like all_access will need to have access to multiple tenants. But the flip side of that is often users log in to a tenant where the default index pattern is different from what their role allows access to. This means that every role who logs in to the same tenant, needs to keep changing the pattern based on their role permissions. Also, as you correctly highlighted, generally users dont know the details of the role mapping, so sometimes they won't even know which index pattern to select.
Eg: Lets take RoleA and RoleB and TenantT.
RoleA has permissions to index A*
RoleB has permissions to index B*
TenantT has default index pattern of A*
When RoleB logs in to TenantT, the default index pattern is different (A*) from what it has access to. Now RoleB needs to change the index pattern to query. If RoleB changes the default index pattern, then when RoleA logs backing, they will have the same problem as the default index pattern (B*) is different from what their role is mapped to (A*)
The change of index pattern association is because currently tenants own Dashboards objects (thanks for pointing it out, fixed it main issue) and one cannot share an object without first asking the admin to also include the said user in the same tenant. The requirement of including a user/role in a tenant just so another user can share a Dashboard object (eg: visualization) is confusing. Many customers have pointed this out as an issue that inhibits easy sharing of Dashboard objects. I wasn't referring to the do_not_fail_on_forbidden setting which allows the user to choose between all_or_none results vs excluding the index pattern matched indices that the user doesn't have access to. Apologies if i wasn't completely clear about that.
You have a valid point on adding diagnostics to make the mapping and access easier. I can see that complex organizations will have some level of this back and forth, but we need to find the right balance and mechanisms to simplify the interactions.
Regarding nested objects sharing - the idea is when a dashboard is shared, the nested objects within the same, will also be shared as a part of it. With tenants, this is easy. But if we consider a different model without tenants, then we need to account for this.
Thank you for sharing your thoughts on the user discoverability. That is an excellent point that raises the questions, who are you sharing the object with and how does one identify/lookup such a user/role. This one needs some more thinking and discussion.
Again, thanks for sharing your thoughts and moving the discussion along. This is the type of feedback that would help refine this proposal to create an experience that is broadly applicable to users of OpenSearch.

Thank you @jgough and @squiddy-gh on sharing your thoughts regarding the benefits of compartmentalization and how it is suitable for your usecases. While many users have requested to disable tenants entirely or make the experience simpler, i understand that usecases like yours still benefit from the current design. I will need to think a little bit more about this and how we can keep the benefits of the current design while simplifying its use for all users. So definitely agree that we dont want to change it and make it complex to use and manage. Ill share more on this.
@squiddy-gh regarding the UUID issue, while not directly a part of the security plugin, is important and im tagging @ahopp who may have ideas around this.
The idea for a self service basic auth user signup is fantastic. I like your suggestion about adding password policies related to aging, length/strength, force users to change the default password etc. While not in the scope of this proposal, it will enhance the user experience. I will track it separately. (Also, feel free to open a feature request issue here in GitHub)
Thanks again for sharing your ideas and reviewing this proposal.

@jimishs

When RoleB logs in to TenantT, the default index pattern is different (A*) from what it has access to. Now RoleB needs to change the index pattern to query.

I don't really understand this scenario. In the status quo, there are three cases:

RoleB has all necessary permissions, thus it sees the same as RoleA
RoleB gets either an error message (for do_not_fail_on_forbidden: false)
RoleB sees a (possibly empty) subset of the visualisation (for  do_not_fail_on_forbidden: true).

If you change the index pattern to be user-specific, would RoleA  see the contents of A* in the visualization, while RoleB sees the contents of B*  in the same visualization - which was shared with them?  If yes, RoleB might see something completely different - not just an error message or a subset. Would RoleA expect that the visualization they are sharing might display something completely different for RoleB?

authors: jgough jimishs kgcreative nibix squiddy-gh

repo: opensearch-project/security


text:
Change 2.0-alpha1 to 2.0-rc1.

Following https://github.com/opensearch-project/opensearch-build/pull/1863, change 2.0-alpha1 to 2.0-rc1.

@dblock This is a chicken v. egg build problem.  The security plugin uses the OpenSearch min tar to make sure it can be installed.  Until we've got a rc1 version of OpenSearch min our CI check won't pass.
Option 1) remove security plugin from the manifest.  Cleanest approach for build safety with the tradeoff of consuming a lot of time during this transition phase.
Option 2) bypass the CI check and cross fingers that the new build doesn't have any unexpected issues.
My preference is towards option 1 with the understanding it will slow down the whole rollout.  This will ensure only correctly building plugins are included in the build, avoiding an utterly broken build.
Note; These problems are magnified in security-dashboards-plugin as it depends on a full distribution build for its CI checks.

Codecov Report

Merging #1764 (7434ebc) into main (e213e9c) will decrease coverage by 0.04%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##               main    #1764      +/-   ##
============================================
- Coverage     60.79%   60.75%   -0.05%
+ Complexity     3186     3185       -1
============================================
  Files           253      253
  Lines         17931    17930       -1
  Branches       3204     3204
============================================
- Hits          10902    10894       -8
- Misses         5453     5460       +7
  Partials       1576     1576

Impacted Files
Coverage Δ

...org/opensearch/security/rest/TenantInfoAction.java
77.94% <0.00%> (-10.30%)
:arrow_down:

...security/auditlog/sink/ExternalOpenSearchSink.java
59.25% <0.00%> (-2.47%)
:arrow_down:

...ecurity/ssl/rest/SecuritySSLReloadCertsAction.java
84.78% <0.00%> (-0.33%)
:arrow_down:

...a/org/opensearch/security/tools/SecurityAdmin.java
37.74% <0.00%> (+0.24%)
:arrow_up:

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 e213e9c...7434ebc. Read the comment docs.

@dblock This is a chicken v. egg build problem. The security plugin uses the OpenSearch min tar to make sure it can be installed. Until we've got a rc1 version of OpenSearch min our CI check won't pass.
Option 1) remove security plugin from the manifest. Cleanest approach for build safety with the tradeoff of consuming a lot of time during this transition phase.
Option 2) bypass the CI check and cross fingers that the new build doesn't have any unexpected issues.
My preference is towards option 1 with the understanding it will slow down the whole rollout. This will ensure only correctly building plugins are included in the build, avoiding an utterly broken build.
Note; These problems are magnified in security-dashboards-plugin as it depends on a full distribution build for its CI checks.

I have created a PR to address option 1. https://github.com/opensearch-project/opensearch-build/pull/1977

Once there's a successful distribution rc1 build CI will turn green here, let's retry later today.

Thank you @dblock !

authors: DarshitChanpura codecov-commenter dblock peternied


text:
Avg and Max Envoy Update Time metrics are incorrect

Bug description:
@eduser25 found that avg and max are showing 300/600s for update time, but the histogram doesn't show any update more than 0.1s

Affected area (please mark with X where applicable):

Install                    [ ]
SMI Traffic Access Policy  [ ]
SMI Traffic Specs Policy   [ ]
SMI Traffic Split Policy   [ ]
Permissive Traffic Policy  [ ]
Ingress                    [ ]
Egress                     [ ]
Envoy Control Plane        [ ]
CLI Tool                   [ ]
Metrics                    [ x]
Certificate Management     [ ]
Sidecar Injection          [ ]
Logging                    [ ]
Debugging                  [ ]
Tests                      [ ]
Demo                       [ ]
CI System                  [ ]

Max update time can't be calculated using Prometheus
https://groups.google.com/g/prometheus-users/c/4V3A0t6u9ME

@shalier Thanks for pointing this out. How is update time being calculated today?

authors: michelleN shalier

repo: openservicemesh/osm


text:
ran 'osm install --mesh-name "test-osm"' but got error "Error: EOF"

may be related to #961

Have you been able to repro this? Can we close this issue?

No I haven't been able to reproduce. Closing for now. Thnx

authors: ksubrmnn michelleN


text:
TRT-1560: Make namespaces last resort owners

We have an example of where we want ns/console-operator tests to go to the Router component because it's far more likely to be the cause. This makes namespaces last resort owners instead of superseding all matchers.
There's two commits here, you may want to view them separately.  One is just fixing a lint problem.

/lgtm

authors: dgoodwin stbenjam

repo: openshift-eng/ci-test-mapping


text:
Update Serving CI config for 1.16

Similar to https://github.com/openshift-knative/hack/pull/192
4.12 is EOL Jan/17/2025 so keeping it for now with 1.12.
We don't have a 4.17 cluster-pool, probably we should?

/hold for cutting net-kourier and net-istio 1.16

/unhold

@ReToCode could you stamp again?

/lgtm
/approve

authors: ReToCode skonto

repo: openshift-knative/hack


text:
Upgrade to adopt readonly support

fixed: https://issues.redhat.com/browse/ACM-11739

/assign @qiujian16

repo: openshift-online/maestro


text:
Update incoming webhook for github apps

If GithubApp is installed on the cluster then no need to provide git_provider spec because for GithubApps we detect the secret and use it
Signed-off-by: Savita Ashture sashture@redhat.com

Changes

Submitter Checklist

[ ] ♽  Run make test lint before submitting a PR (ie: with pre-commit, no need to waste CPU cycle on CI
[ ] 📖 If you are adding a user facing feature or make a change of the behavior, please verify that you have documented it
[ ] 🧪 100% coverage is not a target but most of the time we would rather have a unit test if you make a code change.
[ ] 🎁 If that's something that is possible to do please ensure to check if we can add a e2e test.
[ ] 🔎 If there is a flakiness in the CI tests then don't necessary ignore it, better get the flakyness fixed before merging or if that's not possible there is a good reason to bypass it. (token rate limitation may be a good reason to skip).

/retest

/retes

/retest

/retest

some reviews, and we really need e2e test to cover this, a gitlab and a github app one

@chmouel we have e2e test for Gitlab here https://github.com/openshift-pipelines/pipelines-as-code/blob/main/test/gitlab_incoming_webhook_test.go
So added e2e test for GithubApp now for Incoming

Codecov Report

Merging #1090 (70db476) into main (1d39fbd) will decrease coverage by 0.09%.
The diff coverage is 57.74%.

@@            Coverage Diff             @@
##             main    #1090      +/-   ##
==========================================
- Coverage   62.97%   62.88%   -0.10%
==========================================
  Files         106      106
  Lines        6358     6471     +113
==========================================
+ Hits         4004     4069      +65
- Misses       1970     2010      +40
- Partials      384      392       +8

Impacted Files
Coverage Δ

pkg/kubeinteraction/labels.go
65.62% <ø> (ø)

pkg/provider/bitbucketcloud/bitbucket.go
74.84% <0.00%> (-0.96%)
:arrow_down:

pkg/provider/bitbucketserver/bitbucketserver.go
81.33% <0.00%> (-1.10%)
:arrow_down:

pkg/provider/gitea/gitea.go
7.45% <0.00%> (-0.10%)
:arrow_down:

pkg/provider/github/github.go
68.32% <0.00%> (-3.58%)
:arrow_down:

pkg/provider/gitlab/gitlab.go
70.23% <0.00%> (-0.85%)
:arrow_down:

pkg/reconciler/reconciler.go
20.72% <12.50%> (+0.35%)
:arrow_up:

pkg/adapter/incoming.go
75.00% <63.82%> (-18.75%)
:arrow_down:

pkg/pipelineascode/secret.go
74.54% <100.00%> (ø)

pkg/provider/github/parse_payload.go
90.95% <100.00%> (+0.24%)
:arrow_up:

... and 5 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

lmk when you finish added the e2e and i'll do a new review

lmk when you finish added the e2e and i'll do a new review

https://github.com/openshift-pipelines/pipelines-as-code/pull/1090#issuecomment-1377404192 I have added e2e already

The e2e test not failing locally :thinking:

/retest

/test

/retest

glad we have pac running :-p  unitlint is broken...

you are right @jkandasa about t.Setenv, i think we will then need a refactoring of all our test using gotest.tools env to move to t.Setenv

/retest

authors: chmouel codecov-commenter savitaashture sm43

repo: openshift-pipelines/pipelines-as-code


text:
Add "managed" annotation to CSIDriver

The csi.openshift.io/managed annotation will be used to distinguish if a CSI driver is installed + managed by OCP (= the annotation is present) or by some 3rd party script / helm chart / operator.
Eventually, CSO should not start CSI driver operator when it sees CSIDriver without this annotation - it's a signal that the driver was installed by someone else.
@openshift/storage

/lgtm

authors: huffmanca jsafrane


text:
[release-4.14] OCPBUGS-33295: Update opentelemetry to mitigate CVE-2023-47108

Bumps (primarily):
go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc to v0.46.0 [OCPBUGS-33295]
go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp to v0.44.0 [OCPBUGS-33296]
& related go.opentelemetry.io dependencies

/assign @sayan-biswas @adambkaplan

/retest
Build test suite should pass now

/retitle [release-4.14] OCPBUGS-33295: Update opentelemetry to mitigate CVE-2023-47108

/assign @sayan-biswas
I'm not approver on this branch :cry:.
Failure of the build test needs to be triaged.

The context directory set for the affected test is 2.7/test/puma-test-app, which is no longer supported & removed from the source

/test openshift-e2e-aws-builds-techpreview

@sayan-biswas I believe, these test-failures will continue unless we get https://github.com/openshift/origin/pull/28840 merged & backported.

/retest

/retest

/approve
/lgtm

/label backport-risk-assessed

/label cherry-pick-approved

/retest

/cherrypick release-4.13

authors: adambkaplan apoorvajagtap sayan-biswas


text:
[WIP] Boilerplate update and migrate the v1beta1 CRDs to v1

https://issues.redhat.com/browse/OSD-7595
This PR does the needed boilerplate updates and generates to update the current v1beta1 CRD to a v1 CRD. This is currently blocked until the v3 hives are decommissioned, hence the WIP tag.

Codecov Report

Merging #115 (58d3c60) into master (33ade6e) will increase coverage by 1.82%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #115      +/-   ##
==========================================
+ Coverage   38.12%   39.94%   +1.82%
==========================================
  Files          14       14
  Lines         703      791      +88
==========================================
+ Hits          268      316      +48
- Misses        402      442      +40
  Partials       33       33

Impacted Files
Coverage Δ

pkg/localmetrics/localmetrics.go
30.30% <0.00%> (-2.46%)
:arrow_down:

pkg/apis/apis.go
100.00% <0.00%> (ø)

cmd/manager/main.go
0.00% <0.00%> (ø)

pkg/utils/clientwrapper.go
0.00% <0.00%> (ø)

pkg/controller/controller.go
0.00% <0.00%> (ø)

pkg/apis/addtoscheme_deadmanssnitch_v1alpha1.go
100.00% <0.00%> (ø)

pkg/controller/add_deadmanssnitchintegration.go
100.00% <0.00%> (ø)

...snitch/v1alpha1/deadmanssnitchintegration_types.go
100.00% <0.00%> (ø)

pkg/dmsclient/dmsclient.go
4.87% <0.00%> (+0.33%)
:arrow_up:

pkg/dmsclient/mock/mock_dmsclient.go
64.70% <0.00%> (+1.24%)
:arrow_up:

... and 4 more

authors: codecov-commenter fahlmant

repo: openshift/deadmanssnitch-operator


text:
[ART-4877] add check function is_cve_in_summary

if a bug was backported to Jira, it might miss CVE-related labels but it has CVE feature in its summary and described in its description, so this check is to raise concern if we find CVE in summary

Thanks for creating the story and this PR, taking a look today

ut test failed should be fixed by https://github.com/openshift/elliott/pull/441

@Ximinhan Request to include the jira story link, and the commands affected and how to test them in the PR description - this make PR reviews much easier!

/lgtm

authors: Ximinhan thegreyd

repo: openshift/elliott


text:
WIP: DO_NOT_MERGE: debug ci test operator-e2e

Let's check if operator-e2e succeeds on pure repo.

This PR proves that ci/prow/operator-e2e is perma failing. Closing.


text:
Bug 1988373: Rebase v1.3.1 for OCP 4.9

Among other, this fixes mounting XFS volumes / BZ 1988373.
Diff to upstream v1.3.1:
https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver/compare/v1.3.1...jsafrane:rebase-v1.3.1
Notice that golang.org/x/oauth2 changes are due to https://github.com/openshift/gcp-pd-csi-driver/pull/15.
@openshift/storage

/bugzilla refresh

repo: openshift/gcp-pd-csi-driver


text:
Bump appsre image tag from 7 to 10c

We hit a case where the first 7c of the commit sha was ambiguous, so our appsre build script helpfully used 8c instead. Unfortunately, the tooling on the appsre saas deploy side doesn't have the ability to do this same disambiguation, so it tried the 7c prefix and the deploy failed.
Increase the prefix length to 10c to greatly reduce (but not eliminate, sad-face) the probability of future collisions.
HIVE-2194

/assign @dlom

/lgtm

Fast merging, as no source files were touched.

repo: openshift/hive


text:
Add hypershiftlogforwarder controller hosted cluster clients

Why
Adding hosted cluster clients to controller

/lgtm

authors: bmeng samanthajayasinghe

repo: openshift/hypershift-logging-operator


text:
HOSTEDCP-1976: Nodepool controller cleanup

What this PR does / why we need it:

Move platform specific logic into their own files
Rearrange validations

Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #
Checklist

[ ] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

lgtm overall. The commits should have a description added per 5) https://hypershift-docs.netlify.app/contribute/#prior-to-submitting-a-pull-request no?

/lgtm

/lgtm

/test images

authors: bryan-cox enxebre

repo: openshift/hypershift


text:
updated SL for Bad SCC Priority with docs link

This PR updates the bad SCC Priority SL and adds the correct documentation link for the same

/lgtm

/lgtm

/approve

authors: MitaliBhalla cattias devppratik

repo: openshift/managed-notifications


text:
must-gather: noobaa obc list command not working

added a workaround which fixes the issue where noobaa obc list command was not working. This is just a workaround and might be updated in the later releases.
Signed-off-by: RAJAT SINGH rajasing@redhat.com

I tried various ways like moving the entire for a loop at a different place but I could not really think of anything else in the end and this worked. While this is not the best solution, but at the moment, this worked for me while others don't.
If you have any suggestions, please let me know.

It worked
[must-gather-nwh5g] POD -----------collecting dump of status
[must-gather-nwh5g] POD -----------collecting dump of obc list
[must-gather-nwh5g] POD collecting dump of noobaa

/test ocs-operator-bundle-e2e-aws

/cherry-pick release-4.8

authors: agarwal-mudit jarrpa rajatsing

repo: openshift/ocs-operator


text:
Bug 1979155: [release-4.7] must-gather: remove the standard pod template

Had to resolve a conflict, couldn't automate the cherry-pick of #1255 1255

/retest

/bugzilla refresh

/retest


text:
Recurring failure of "create with now flag should pass" tests

The "create with now flag" tests are failing recurrently. It's also ranked 2 on the test statistics dashboard. Here's the log from one of the failures:
 [odo] I0527 08:04:29.128749    9537 utils.go:141] Updating container runtime env with run command
[odo] I0527 08:04:29.128756    9537 utils.go:150] Updating container runtime env with run command's workdir
[odo] I0527 08:04:29.128777    9537 utils.go:102] Found component "dockerimage" with alias "runtime"
[odo] I0527 08:04:29.128810    9537 adapter.go:224] Creating deployment xgegme
[odo] I0527 08:04:29.128827    9537 adapter.go:225] The component name is xgegme
[odo]  ✗  Failed to start component with name xgegme.
[odo] Error: Failed to create the component: unable to create or update component: unable to create Deployment xgegme: deployments.apps "xgegme" is forbidden: unable to create new content in namespace uqlvomcmsa because it is being terminated
Deleting project: wzmyhsfrka
Running odo with args [odo project delete wzmyhsfrka -f]
[odo] I0527 08:04:29.703908    9561 application.go:49] Unable to list Service Catalog instances: unable to list ServiceInstances: serviceinstances.servicecatalog.k8s.io is forbidden: User "developer" cannot list resource "serviceinstances" in API group "servicecatalog.k8s.io" in the namespace "wzmyhsfrka"
[odo]  ✓  Deleted project : wzmyhsfrka
[odo]  ⚠  Warning! Projects are deleted from the cluster asynchronously. Odo does its best to delete the project. Due to multi-tenant clusters, the project may still exist on a different node.
[odo] I0527 08:04:29.764376    9561 odo.go:72] Could not get the latest release information in time. Never mind, exiting gracefully :)
Setting current dir to: /go/src/github.com/openshift/odo/tests/integration/devfile
Deleting dir: /tmp/811695040
• Failure [4.731 seconds]
odo devfile url command tests
/go/src/github.com/openshift/odo/tests/integration/devfile/cmd_devfile_url_test.go:16
  Creating urls
  /go/src/github.com/openshift/odo/tests/integration/devfile/cmd_devfile_url_test.go:105
    create with now flag should pass [It]
    /go/src/github.com/openshift/odo/tests/integration/devfile/cmd_devfile_url_test.go:129
    No future change is possible.  Bailing out early after 0.509s.

    Running odo with args [odo url create iqvrn --port 3000 --host gbxko.com --now --ingress --devfile devfile.yaml]
    Expected
        <int>: 1
    to match exit code:
        <int>: 0
    /go/src/github.com/openshift/odo/tests/helper/helper_run.go:34

More logs can be found by referring to the odo test statistics dashboard.
/priority high
/kind failing-test
/area testing

@mohammedzee1000 can you PTAL?

This is duplicate of #3122
Please refer the original issue for details.

@amitkrout The issue you've mentioned is about namespace deletion happening before the URL could get created. But I'm seeing following log for failure in PR #3252:
 [odo] Creating Kubernetes resources for component hohnkv
[odo] I0529 04:24:07.925272    2752 adapter.go:269] Successfully created component hohnkv
[odo] I0529 04:24:07.976385    2752 adapter.go:278] Successfully created Service for component hohnkv
[odo] I0529 04:24:07.976416    2752 deployments.go:47] Waiting for hohnkv deployment rollout
[odo]  •  Waiting for component to start  ...
[odo] I0529 04:24:07.996731    2752 deployments.go:81] Waiting for deployment "hohnkv" rollout to finish: 0 of 1 updated replicas are available...
[odo] I0529 04:24:07.996758    2752 deployments.go:88] Waiting for deployment spec update to be observed...
[odo] I0529 04:24:38.674941    2752 deployments.go:81] Waiting for deployment "hohnkv" rollout to finish: 0 of 1 updated replicas are available...
[odo] I0529 04:24:38.674973    2752 deployments.go:88] Waiting for deployment spec update to be observed...
[odo]  ✗  Waiting for component to start [5m]
[odo]  ✗  Failed to start component with name hohnkv.
[odo] Error: Failed to create the component: error while waiting for deployment rollout: timeout while waiting for hohnkv deployment roll out
Deleting project: ptumssntcg
Running odo with args [odo project delete ptumssntcg -f]
[odo] I0529 04:29:08.335923    4989 application.go:49] Unable to list Service Catalog instances: unable to list ServiceInstances: serviceinstances.servicecatalog.k8s.io is forbidden: User "developer" cannot list resource "serviceinstances" in API group "servicecatalog.k8s.io" in the namespace "ptumssntcg"
[odo]  ⚠  Warning! Projects are deleted from the cluster asynchronously. Odo does its best to delete the project. Due to multi-tenant clusters, the project may still exist on a different node.
[odo] I0529 04:29:08.370493    4989 odo.go:72] Could not get the latest release information in time. Never mind, exiting gracefully :)
[odo]  ✓  Deleted project : ptumssntcg
Setting current dir to: /go/src/github.com/openshift/odo/tests/integration/devfile
Deleting dir: /tmp/221082326
• Failure [307.575 seconds]
odo devfile url command tests
/go/src/github.com/openshift/odo/tests/integration/devfile/cmd_devfile_url_test.go:16
  Creating urls
  /go/src/github.com/openshift/odo/tests/integration/devfile/cmd_devfile_url_test.go:105
    create with now flag should pass [It]
[Fail] odo devfile url command tests Creating urls [It] create with now flag should pass
/go/src/github.com/openshift/odo/tests/helper/helper_run.go:34
Ran 59 of 59 Specs in 597.385 seconds
FAIL! -- 58 Passed | 1 Failed | 0 Pending | 0 Skipped

From these logs it doesn't look like namespace is getting deleted beforehand. There's a timeout happening:
[odo]  ✗  Waiting for component to start [5m]
[odo]  ✗  Failed to start component with name hohnkv.
[odo] Error: Failed to create the component: error while waiting for deployment rollout: timeout while waiting for hohnkv deployment roll out

Link to the logs.

authors: amitkrout dharmit

repo: openshift/odo


text:
ci-firewall --setupscript and --runscript should take script parameter arg

/kind bug

What versions of software are you using?
Operating System:
All supported
Output of odo version:
master
How did you run odo exactly?
Executing ci-firewall request with argument in --setupscript  and --runscript doesn't accept the arg
./ci-firewall request --sendqueue amqp.ci.queue.minikube.send --sendtopic amqp.ci.topic.minikube.send --setupscript scripts/minikube-minishift-setup-env.sh minikube --runscript scripts/minikube-minishift-all-tests.sh minikube --timeout 2h15m
Following jenkins build 486
[ssh:Fedora 32] !!!running tests on node Fedora 32 via ssh!!!
[ssh:Fedora 32] Executing command [rm -rf amqp_ci_rcv_odo-minikube-pr-build_PR_4521]
[ssh:Fedora 32] Executing command [mkdir -p amqp_ci_rcv_odo-minikube-pr-build_PR_4521/repo]
[ssh:Fedora 32] Executing command [git clone https://github.com/openshift/odo amqp_ci_rcv_odo-minikube-pr-build_PR_4521/repo]
[ssh:Fedora 32] Cloning into 'amqp_ci_rcv_odo-minikube-pr-build_PR_4521/repo'...
[ssh:Fedora 32] Executing command [git fetch origin pull/4521/head:pr4521]
[ssh:Fedora 32] From https://github.com/openshift/odo
[ssh:Fedora 32]  * [new ref]             refs/pull/4521/head -> pr4521
[ssh:Fedora 32] Executing command [git checkout master]
[ssh:Fedora 32] Your branch is up to date with 'origin/master'.
[ssh:Fedora 32] Already on 'master'
[ssh:Fedora 32] Executing command [git merge pr4521 --no-edit]
[ssh:Fedora 32] Updating e04d99e86..25f8e7f78
[ssh:Fedora 32] Fast-forward
[ssh:Fedora 32]  Makefile                                           |  46 ----
[ssh:Fedora 32]  tests/helper/helper_cli.go                         |   2 +-
[ssh:Fedora 32]  tests/helper/helper_docker.go                      | 270 -------------------
[ssh:Fedora 32]  .../docker/cmd_docker_devfile_catalog_test.go      |  72 -----
[ssh:Fedora 32]  .../docker/cmd_docker_devfile_delete_test.go       | 168 ------------
[ssh:Fedora 32]  .../devfile/docker/cmd_docker_devfile_exec_test.go |  66 -----
[ssh:Fedora 32]  .../devfile/docker/cmd_docker_devfile_push_test.go | 290 --------------------
[ssh:Fedora 32]  .../docker/cmd_docker_devfile_status_test.go       | 299 ---------------------
[ssh:Fedora 32]  .../devfile/docker/cmd_docker_devfile_test_test.go | 181 -------------
[ssh:Fedora 32]  .../cmd_docker_devfile_url_pushtarget_test.go      |  82 ------
[ssh:Fedora 32]  .../devfile/docker/cmd_docker_devfile_url_test.go  | 160 -----------
[ssh:Fedora 32]  .../docker/cmd_docker_devfile_watch_test.go        |  86 ------
[ssh:Fedora 32]  .../devfile/docker/docker_suite_test.go            |  14 -
[ssh:Fedora 32]  tests/integration/devfile/utils/utils.go           |   5 -
[ssh:Fedora 32]  14 files changed, 1 insertion(+), 1740 deletions(-)
[ssh:Fedora 32]  delete mode 100644 tests/helper/helper_docker.go
[ssh:Fedora 32]  delete mode 100644 tests/integration/devfile/docker/cmd_docker_devfile_catalog_test.go
[ssh:Fedora 32]  delete mode 100644 tests/integration/devfile/docker/cmd_docker_devfile_delete_test.go
[ssh:Fedora 32]  delete mode 100644 tests/integration/devfile/docker/cmd_docker_devfile_exec_test.go
[ssh:Fedora 32]  delete mode 100644 tests/integration/devfile/docker/cmd_docker_devfile_push_test.go
[ssh:Fedora 32]  delete mode 100644 tests/integration/devfile/docker/cmd_docker_devfile_status_test.go
[ssh:Fedora 32]  delete mode 100644 tests/integration/devfile/docker/cmd_docker_devfile_test_test.go
[ssh:Fedora 32]  delete mode 100644 tests/integration/devfile/docker/cmd_docker_devfile_url_pushtarget_test.go
[ssh:Fedora 32]  delete mode 100644 tests/integration/devfile/docker/cmd_docker_devfile_url_test.go
[ssh:Fedora 32]  delete mode 100644 tests/integration/devfile/docker/cmd_docker_devfile_watch_test.go
[ssh:Fedora 32]  delete mode 100644 tests/integration/devfile/docker/docker_suite_test.go
[ssh:Fedora 32] Executing command [sh -c ". ./scripts/minikube-minishift-setup-env.sh; . ./scripts/minikube-minishift-all-tests.sh"]

Actual behavior
Expected behavior
ci-firewall should run the script with parameter.
Any logs, error output, etc?
Log details: https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/openshift_odo/4521/pull-ci-openshift-odo-master-psi-kubernetes-integration-e2e/1372151833438457856#1:build-log.txt%3A85

@mohammedzee1000 what do you think we need to do here? This looks like something that needs to be fixed on ci-firewall side. Correct me if I am wrong.

https://gist.github.com/mohammedzee1000/c8aa9264e6d09852239418eb45d5df9c looks like the problem may not be on co-firewall side after all. @prietyc123 can you verify, so we know if we need to close this or investigate a different angle


text:
Updating vendoring o-a to 3.10.0-0.29.0

#3497

/cherry-pick int

repo: openshift/openshift-tools


text:
OSD-25873: Removing unused endpoints from egress lists

What does this PR do? / Related Issues / Jira
Addresses OSD-25873 by removing unused endpoints

Checklist

[ ] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[ ] I have made corresponding change to the default configuration files
[ ] I have added tests that prove my fix is effective or that my feature works
[x] I have tested the functionality against gcp / aws, it doesn't cause any regression
[ ] I have added execution results to the PR's readme

Reviewer's Checklist

[ ] (This needs to be done after technical review) I've run the branch on my local, verified that the functionality is ok

How to test this PR locally / Special Instructions
Standard testing process for network verifier. No special instructions.

Logs
N/A

/label configuration

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 25.83%. Comparing base (35e0ea3) to head (25710e4).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #274   +/-   ##
=======================================
  Coverage   25.83%   25.83%
=======================================
  Files          25       25
  Lines        1835     1835
=======================================
  Hits          474      474
  Misses       1333     1333
  Partials       28       28

authors: codecov-commenter michaelryanmcneill

repo: openshift/osd-network-verifier


text:
[SDA-6965] Add validation to path ocm/user roles

Related issue: https://issues.redhat.com/browse/SDA-6965
What
A validation to the path was done to acc roles, but not for ocm/user roles
Why
Making sure client knows what is happening if he inputs a wrong path

lgtm

/lgtm

authors: andreadecorte gdbranco pvasant

repo: openshift/rosa


text:
add runbook for NodeWithoutOVNKubeNodePodRunning and V4SubnetAllocati…

…onThresholdExceeded
cc @martinkennelly @npinaeva

Thanks Bo! Looking forward to your replies. I am on PTO until next Tuesday.

/assign @jan--f

Thanks, the runbooks lgtm!
Can you please add an OWNERS file to alerts/cluster-network-operator? See https://github.com/openshift/runbooks/blob/master/alerts/cluster-etcd-operator/OWNERS for an example.

@jan--f The owners file is in this PR: https://github.com/openshift/runbooks/pull/40/files
Thank you.

@bmeng Can you add the PR to update CNO alerts to consume this runbook? Thank you.

authors: bmeng martinkennelly

repo: openshift/runbooks


text:
disable buttons on validation + finish separate 'url'

possible fix for issue #46

d332658143a8d8e7287551756c0e0c2dbf38b29a

authors: ALRubinger edewit

repo: openshiftio/launchpad-frontend


text:
Some documentation docstrings are messed up

Some functions, despite being one liners which make it clear what they do when looking at the code, are missing a docstring. Others, simply have the Parameters and Returns field in their docstring (with no description of what it does).
When looking at the generated API, this might not look good:

Therefore I think we should document every single method/function regardless of its complexity. Also, for very simple functions such as Agent.list_timers(), I think we could get rid of the Parameters and Returns fields to save some space. What do you think @Peque ?

Yeah, maybe in some cases it is cleaner to just have a little description. Anyway, for now, I would not remove any already-added parameters/returns in the docstrings.
100% agree that we should make sure all docstrings have at least a one-liner description to avoid those ugly results in the generated documentation.

repo: opensistemas-hub/osbrain

license_source: bigquery


text:
新特性请求：类似springboot中的注解处理器

在springboot中，支持以下注解别名化处理

希望solon也提供该特性，或提供该特性实现的途径。

这个 sa-token 在 v1.39 自己处理了。

authors: blackknifes noear

repo: opensolon/solon


text:
🛑 Demo is down

In 5e52c8a, Demo (https://demo.opensourcepos.org) was down:

HTTP code: 502
Response time: 535 ms

Resolved: Demo is back up in c36000c after 19 minutes.

repo: opensourcepos/upptime

license: MIT


text:
Should have a highlight color to distinguish the linked address

ref #363

authors: hyifeng qiyisi

repo: opensquare-network/dotreasury


text:
[Tech Debt] Update the placement of the display and system keys on the user assignment meta.tags

Name of feature to enhance

We tag all the app-generated resources with the user assignments.
The meta.tag is a FHIR Code which contains the following keys system, code & display.
We don't expect the display & system keys to change but we still want to make it easy for engineers to change them if they wanted to.
This means either declaring them on the build.grable or the strings.xml
This issue is to facilitate the discussion and get the placement agreed upon.
The configuration is not user-facing. It's just for the engineering teams' benefit.

Description of feature

[ ] Declare the system & display keys of the meta.tag codes in a configurable way for engineers to easily change if need to. This can be on the build.gradle or string.xml.

@ellykits @FikriMilano I have moved the pending discussion here allowing merging of this PR https://github.com/opensrp/fhircore/pull/1576

@ellykits @dubdabasoduba
What do you think of using build.gradle?
Actually I prefer this way, because:

We can avoid the ApplicationUtil
strings.xml should only for string that is displayed into the app, that's why they are translatable

@FikriMilano I am okay with that. The only question is what happens in case they are removed. Do we stop the app from building?

@dubdabasoduba
Had a discussion w @ellykits , let's do the strings.xml.
It's easier to do the flavoring, will be getting the context from config service, strings.xml can also be marked as non translatable.

@ellykits @FikriMilano should we close this after the tagging PR?

@dubdabasoduba yeah

authors: FikriMilano dubdabasoduba

repo: opensrp/fhircore


text:
App configuration docusaurus

IMPORTANT: Where possible all PRs must be linked to a Github issue
Fixes #[issue number]
Checklist

[ ] I have written Unit tests for any new feature(s) and edge cases for bug fixes
[ ] I have added any strings visible on UI components to the strings.xml file
[ ] I have updated the  CHANGELOG.md file for any notable changes to the codebase
[ ] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the project's style guide
[ ] I have built and run the fhircore app to verify my change fixes the issue and/or does not break the app

@ellykits ,
I only edited files on the branch app-configuration-docusaurus . The main branch has untouched files. You can use this as the back-up

@ellykits I created a tag to use it as a back-up. Here's the tag https://github.com/opensrp/fhircore/releases/tag/docs_before_docusaurus

@SebaMutuku Can you tag the issue this PR is fixing.

@dubdabasoduba the files generated needs to be edited one by one. So as not to lose the them, I created a tag up there a a back up

authors: SebaMutuku ellykits


text:
Ignore compose preview functions from codecov

IMPORTANT: Where possible all PRs must be linked to a Github issue
Fixes #1929
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
[x] 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

Could we override the @Compose decorator to do this, instead of adding an additional decorator?

not really sure, but it's worth trying

awesome, it works.
so I created a custom annotation, that includes both Preview and Exclude codecov annotation.
the naming must include Generated so the exclude functionality can work.
now we just need to use 1 annotation to preview and exclude :D
thx for the idea @pld

will update the rest on next week CHT

LGTM. Have you updated every Preview annotation in the codebase?

Yeah, all of them

authors: FikriMilano pld


text:
Added SessionBuilder::user_known_hosts_file

Signed-off-by: Jiahao XU Jiahao_XU@outlook.com

This change is

authors: NobodyXu jonhoo

repo: openssh-rust/openssh


text:
OSSL_PARAM_REAL type

The documentation says:
       OSSL_PARAM_REAL
           The parameter data is a floating point value in native form.

It seems that the code has switches all over checking sizeof(double). I think double is the only thing we support. It's probably more clear that we say double there instead of "floating point".

Why? Both float and double are floating point types, just of different sizes.

But we don't actually support either float or long double.

So?

If we have no intention to support anything other that double, I
think it should be clear that when we say OSSL_PARAM_REAL that
it's a double, and not any of the other floating point types. Or
everywhere that OSSL_PARAM_REAL is used, it should mention
only double is supported.

Key word here is currently. I see no reason to lock that data type to one specific C type.
And the point is that any size is perfectly possible for the OSSL_PARAM structure itself, even though the OSSL_PARAM functions currently only support double.

I had float in the parameter code originally but it was decided to defer this until later.  Putting it back would be straightforward.
I'm less sure about long double though.  I have seen compilers where command line options change the size of this one which could cause problems with providers built differently to libcrypto.  A can of worms best left closed until we need it.

Right. And we can with no changes to the OSSL_PARAM data types.

#11183 ??

authors: kroeckx levitte paulidale

repo: openssl/openssl


text:
Building faild on cygwin

In file included from providers/implementations/storemgmt/winstore_store.c:27:
/usr/include/w32api/wincrypt.h:20:11: error: unknown type name ‘LONG’
   20 |   typedef LONG HRESULT;
      |           ^~~~
In file included from providers/implementations/storemgmt/winstore_store.c:27:
/usr/include/w32api/wincrypt.h:283:11: error: unknown type name ‘ULONG_PTR’
  283 |   typedef ULONG_PTR HCRYPTHASH;
      |           ^~~~~~~~~
/usr/include/w32api/wincrypt.h:284:11: error: unknown type name ‘ULONG_PTR’
  284 |   typedef ULONG_PTR HCRYPTKEY;
      |           ^~~~~~~~~
/usr/include/w32api/wincrypt.h:285:11: error: unknown type name ‘ULONG_PTR’
  285 |   typedef ULONG_PTR HCRYPTPROV;
      |           ^~~~~~~~~
/usr/include/w32api/wincrypt.h:628:5: error: unknown type name ‘DWORD’
  628 |     DWORD dwVersion;
      |     ^~~~~
/usr/include/w32api/wincrypt.h:630:5: error: unknown type name ‘BYTE’
  630 |     BYTE *pbOID;
      |     ^~~~
/usr/include/w32api/wincrypt.h:631:5: error: unknown type name ‘DWORD’
  631 |     DWORD cbOID;
      |     ^~~~~
/usr/include/w32api/wincrypt.h:636:5: error: unknown type name ‘BYTE’
  636 |     BYTE *pbInnerString;
      |     ^~~~
/usr/include/w32api/wincrypt.h:637:5: error: unknown type name ‘DWORD’
  637 |     DWORD cbInnerString;
      |     ^~~~~
/usr/include/w32api/wincrypt.h:638:5: error: unknown type name ‘BYTE’
  638 |     BYTE *pbOuterString;
      |     ^~~~
/usr/include/w32api/wincrypt.h:639:5: error: unknown type name ‘DWORD’
  639 |     DWORD cbOuterString;
      |     ^~~~~
/usr/include/w32api/wincrypt.h:643:5: error: unknown type name ‘DWORD’
  643 |     DWORD dwUse;
      |     ^~~~~
/usr/include/w32api/wincrypt.h:645:5: error: unknown type name ‘DWORD’
  645 |     DWORD cBits;
      |     ^~~~~
/usr/include/w32api/wincrypt.h:646:5: error: unknown type name ‘DWORD’
  646 |     DWORD dwFlags;
      |     ^~~~~
/usr/include/w32api/wincrypt.h:647:5: error: unknown type name ‘DWORD’
  647 |     DWORD dwReserved;
      |     ^~~~~
/usr/include/w32api/wincrypt.h:656:5: error: unknown type name ‘DWORD’
  656 |     DWORD dwBitLen;
      |     ^~~~~
/usr/include/w32api/wincrypt.h:657:5: error: unknown type name ‘DWORD’
  657 |     DWORD dwNameLen;
      |     ^~~~~
/usr/include/w32api/wincrypt.h:658:5: error: unknown type name ‘CHAR’
  658 |     CHAR szName[20];
      |     ^~~~
/usr/include/w32api/wincrypt.h:663:5: error: unknown type name ‘DWORD’
  663 |     DWORD dwDefaultLen;
      |     ^~~~~
/usr/include/w32api/wincrypt.h:664:5: error: unknown type name ‘DWORD’
  664 |     DWORD dwMinLen;
      |     ^~~~~
/usr/include/w32api/wincrypt.h:665:5: error: unknown type name ‘DWORD’
  665 |     DWORD dwMaxLen;
      |     ^~~~~
/usr/include/w32api/wincrypt.h:666:5: error: unknown type name ‘DWORD’
  666 |     DWORD dwProtocols;
      |     ^~~~~
/usr/include/w32api/wincrypt.h:667:5: error: unknown type name ‘DWORD’
  667 |     DWORD dwNameLen;
      |     ^~~~~
/usr/include/w32api/wincrypt.h:668:5: error: unknown type name ‘CHAR’
......

Command build below
cd openssl
./config
make -j8

I just add
#ifdef __CYGWIN__
#include <Windows.h>
#endif

at  providers/implementations/storemgmt/winstroe_stroe.c at line 26
after, I faced link error
Add Configurations10-main.conf
1563|         ex_libs          => add("-lcrypt32"),

then I Succeed build openssl.exe at cygwin terminal

Hope you can fix. Thanks !

@affggh
where did you add this line,
1563|         ex_libs          => add("-lcrypt32"),

@affggh
where did you add this line, I am still facing problem in CYGWIN
1563| ex_libs => add("-lcrypt32"),

Its in Configurations/Configurations10-main.conf
at line 1563

@affggh  Thanks for Reply.
But I already see that at Line number 1573,

After doing above changes to config file..
I am still receiving errors as attached.

@affggh Thanks for Reply.
But I already see that at Line number 1573,

this mingw target is not working on cygwin

After doing above changes to config file..
I am still receiving errors as attached.

did you add -lctypt32 on cygwin target

Yes,
I did add that line.. see below screenshot.

Yes,
I did add that line.. see below screenshot. Line Number : 1563

you should insert it at cygwin target，not mingw

Thanks Buddy!!
It working now..


text:
test/recipes/04-test_bioprint.t fails when enable-crypto-mdebug enabled

When compiled with -enable-crypto-mdebug, make test fails on test_bioprint due to a memory leak.
> cd test; VERBOSE=1 SRCTOP=.. BLDTOP=..  ./run_tests.pl test_bioprint | grep -E '(address|leaked|Result)'
[14:48:28]     2 file=crypto/err/err.c, line=692, thread=2147483704, number=392, address=0x80010c60
392 bytes leaked in 1 chunks
Result: FAIL

> OPENSSL_DEBUG_MEMORY=0 VERBOSE=1 SRCTOP=.. BLDTOP=..  ./run_tests.pl test_bioprint | grep -E '(address|leaked|Result)'
Result: PASS

Can you do this and give the full output?
make 'TESTS=test_bioprint' 'V=1'

We have an mdebug build in travis, and I run it regularly, so it's curious that you are seeing a failure.

The command you gave did not run any tests. I guest you meant make 'TESTS=test_bioprint' test 'V=1' which yields (apart from likely uninteresting lines I filtered out above) the same as before:
make depend && make _tests
make[1]: Entering directory '/cygdrive/p/PKI/openssl'
make[1]: Leaving directory '/cygdrive/p/PKI/openssl'
make[1]: Entering directory '/cygdrive/p/PKI/openssl'
( cd test; \
  SRCTOP=../. \
  BLDTOP=../. \
  PERL="/usr/bin/perl" \
  EXE_EXT=.exe \
  OPENSSL_ENGINES=.././engines \
  OPENSSL_DEBUG_MEMORY=on \
    /usr/bin/perl .././test/run_tests.pl test_bioprint )
../test/recipes/04-test_bioprint.t ..
1..1
    # Subtest: ./bioprinttest
    1..4
    ok 1 - test_big
        # Subtest: test_fp
        1..7
        ok 1 - iteration 1
        ok 2 - iteration 2
        ok 3 - iteration 3
        ok 4 - iteration 4
        ok 5 - iteration 5
        ok 6 - iteration 6
        ok 7 - iteration 7
    ok 2 - test_fp
        # Subtest: test_zu
        1..4
        ok 1 - iteration 1
        ok 2 - iteration 2
        ok 3 - iteration 3
        ok 4 - iteration 4
    ok 3 - test_zu
        # Subtest: test_j
        1..4
        ok 1 - iteration 1
        ok 2 - iteration 2
        ok 3 - iteration 3
        ok 4 - iteration 4
    ok 4 - test_j
[16:08:21]     2 file=crypto/err/err.c, line=692, thread=2147483704, number=392, address=0x80038ca0
392 bytes leaked in 1 chunks
../util/shlib_wrap.sh ./bioprinttest.exe => 1
not ok 1 - running bioprinttest
#   Failed test 'running bioprinttest'
#   at ../test/testlib/OpenSSL/Test/Simple.pm line 77.
# Looks like you failed 1 test of 1.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests

Test Summary Report
-------------------
../test/recipes/04-test_bioprint.t (Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
Files=1, Tests=1,  1 wallclock secs ( 0.08 usr  0.19 sys +  0.12 cusr  0.60 csys =  0.99 CPU)
Result: FAIL
make[1]: *** [Makefile:168: _tests] Error 1
make[1]: Leaving directory '/cygdrive/p/PKI/openssl'
make: *** [Makefile:165: tests] Error 2

Thanks.  This is cygwin?  It's the only test that fails?  If so, let's make another one also fail.  Edit test/recipes/30-test_evp_data/evpdigest.txt and flip the "69" to "96" in the Output line.

I had already started writing: Maybe the issue only arises under Cygwin (which is my default build environment).
I have only one other test that fails, namely the final three parts (192-194) of test_store fail (at least for me), because apps/openssl storeutl test/certs tries to access test/certs as a file although it is a directory.
As far as still relevant, after editing that file, make "TESTS=test_evp" test does fail as expected:
../test/recipes/30-test_evp.t .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/7 subtests

Test Summary Report
-------------------
../test/recipes/30-test_evp.t (Wstat: 256 Tests: 7 Failed: 1)
  Failed test:  2
  Non-zero exit status: 1
Files=1, Tests=7, 10 wallclock secs ( 0.08 usr  0.19 sys +  6.78 cusr  1.82 csys =  8.87 CPU)
Result: FAIL
make[1]: *** [Makefile:168: _tests] Error 1
make[1]: Leaving directory '/cygdrive/p/PKI/openssl'
make: *** [Makefile:165: tests] Error 2

Can you open another issue for store and the test/file stuff, that's a bug.
Just to make it clear: the test_evp failure doesn't report a memleak?  Even when it fails?

That's right, no mem leak reported in that case for me though sub-test 2 fails.
Yep, I'll open an issue for test_store...

At the time of reporting, this must have been around commit 1a9f5cf0d5, i.e., already version 1.1.1-dev.
I cannot reproduce the issue with Cygwin and the current master (still 1.1.1-dev).

Ok - closing. Assumed to be fixed.

authors: DDvO mattcaswell richsalz


text:
Internal IP exposed

Internal IP exposed after running a openssl (version 1.1.0j) connect command:
openssl s_client -connect 103.XX.XXX.XX:10443 -quiet

Where 103.XX.XXX.XX is a Public IP. And after it shows the certificates, typed the following:
GET /images HTTP/1.0

And hit enter twice, the following gets displayed:
HTTP/1.0 301 Moved Permanently
Date: Mon, 25 Mar 2019 00:10:13 GMT
Server: xxxxxxxx-xxxxx
Location: https://10.240.123.1:10443/images/
Connection: close
Content-Type: text/html; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=28800

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<TITLE>301 Moved Permanently</TITLE>

Moved Permanently

The document has moved here.

read:errno=0

The 10.240.123.1 is an internal IP and it is exposed by this little method. Although not shown when using curl -kv -O command.
Is there a way to cover up the "Location" or at least the internal IP from being exposed? Thanks.

Found out that this is not an OpenSSL issue but more on the firewall/server side configuration to mask the IP address.


text:
"Unrecognized character escape sequence" when OPENSSLDIR contains an '@'

This was observed on Windows with OpenSSL 1.1.1. Configure with
perl .\Configure --prefix=C:\weird@path --openssldir=C:\weird@path
The makefile then sets LIB_CPPFLAGS to contain the preprocessor definition
-D"OPENSSLDIR=\"C:\\weird\@path\""
Note the superfluous backslash before the '@'.
Building with nmake results in a warning (promoted to an error due to the /WX flag):
crypto\cversion.c(32): warning C4129: "@": unrecognized character escape sequence

Marking as inactive, to be closed at the end of 3.4 dev barring further input

authors: bkloster-sma nhorman


text:
Add a GitHub issue template for questions and documentation issues

Actually, we would rather see general questions posted to the
openssl-users mailing list. But habits have changed and more and
more users ask questions on GitHub. Many of them are currently tagged
as bug reports or feature requests, because there is no appropriate
template for questions. This commit adds the missing template.

See https://github.com/openssl/openssl/issues/9783#issuecomment-536311318 and this thread on openssl-project.

Ping: reviews not addressed

Ping: reviews not addressed

This is next on my todo list. I'll add issue templates for issue: question and issue: documentation.

Done. I did not put too much effort into the 'help comments', because my plan is to move the help for creating issues into a separate SUPPORT.md markdown file.

ping @openssl/omc. It would be nice if this change could go in soon.

Ok, thanks.

I'll push a fixup, since we need for the grace period anyway.

Do you really think anyone will read all this?
OpenSSL gets PR's and people don't bother to remove the two simple checkboxes!

No, I don't believe anybody will read this. That's why I half-heartedly copied and modified the text from the existing templates.
The main reason why I want to get this pull request merged is because I want to get the missing GitHub issue templates added. Because otherwise people continue asking questions with the 'issue: bug report' label added.
My vision for the near future is that the templates will only show a short text like:

<!--
Thank you for your bug report. If this is your first one, please take the time
to follow the 'Support' link to the right of this edit field, where you will find
a lot of useful information to get you started.

Please take the time to read it before creating your bug report.

Thank you in advance,

The OpenSSL Team
-->

On the F2F I committed myself to revamp the online GitHub support by adding a lot of fancy markup documentation. The starting point will be the SUPPORT.md and CONTRIBUTING.md documents, which are officially supported by GitHub, see the screenshot. The first document already exists but is neglected, the other one does not exist yet.

If @levitte insists that I should reword the text, I will do it. But I agree with @richsalz that nobody will read it anyway.

Done:

authors: levitte mspncp


text:
EVP: Adapt EVP_PKEY checking, comparing and copying for provider keys

This affects the following function, which can now deal with provider
side domain parameters and keys:

EVP_PKEY_copy_parameters()
EVP_PKEY_missing_parameters()
EVP_PKEY_cmp_parameters()
EVP_PKEY_cmp()

This also adds the necessary EVP_KEYMGMT interfaces to support those functions, and the implementations for RSA, DSA and DH.

There was a small fixup needed, but other than that, at least my personal tests go through.  Final review?

Travis failures also look relevant.

After all the excellent remarks from @mattcaswell, I've had the time to rethink this PR, and have refactored it quite a bit.
Also, this is now pending #10837.

#11006 is the new KEYMGMT design.  I'll work that one into this one.

Killing this in favor of #11025

authors: levitte mattcaswell


text:
Remove unneeded switch statement to fix warning

https://github.com/openssl/openssl/issues/10958
This is a trivial change which has no functional impact, just to fix a couple of warnings.

This pull request is ready to merge

Merged to master.   Thanks for checking the early change.

authors: 4cad openssl-machine paulidale


text:
Fix wrong numbers being passed as string lengths

This resolves https://github.com/openssl/openssl/issues/43 and one more similar problem outlined in http://www.viva64.com/en/b/0250/

Applied.

authors: Dmitry-Me levitte


text:
Fix typo in OPENSSL_malloc.pod

Checklist

[x] documentation is added or updated

@mattcaswell Updated commit message, thanks!

This pull request is ready to merge

Merged
74c8dd1c516c7017477a205fd1f5f975cfa86722 Fix typo in OPENSSL_malloc.pod

... and to 1.1.1 as well:
5daa28ad7041a0def79e14a0e845f407e6f04f7e Fix typo in OPENSSL_malloc.pod

authors: NanXiao levitte openssl-machine


text:
test: fix thread test config file problem

Force the thread test to use the configuration file via a command line arg.
Use the test library support for libctx creation.
Fixes #15243

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

Agree that it is an urgent fix.

Merged, thanks.

@levitte @mattcaswell, any idea why setting OPENSSL_CONF didn't work?

authors: paulidale slontis


text:
DOCS: Don't mention internal functions in public documentation

This time noticed in OSSL_trace_set_channel.pod, and it turned out to
be easy to mention the public functions affected instead.

Thank you @richsalz for getting my attention on this detail.  (#15419)

This pull request is ready to merge

Merged.

authors: levitte openssl-machine paulidale


text:
Fix broken links in crypto manpage

CLA: trivial

I thought I was fixing broken links due to them looking out of place, but the corresponding pages do not exists. Closing this issue.

I found out that the link name should have been different. I fixed that as well and reopened the pull request.

24 hours has passed since 'approval: done' was set, but this PR has failing CI tests.  Once the tests pass it will get moved to 'approval: ready to merge' automatically, alternatively please review and set the label manually.

Merged, thanks for the fixes.

authors: Lipovlan openssl-machine paulidale


text:
Add -Wundef to --strict-warnings options

Add -Wundef to --strict-warnings options.
This PR is against master

@richsalz Yes I did add the -Wundef to both, but I have only tested with gcc so far.

i tested -wundef on clang.

thanks!

See https://github.com/openssl/openssl/pull/2713

Ok, then I assume I should do a rebase.

i need the following added (and a rebase to catch the apps/rehash.c)
diff --git a/include/internal/refcount.h b/include/internal/refcount.h
index c8ebd5a..c70d95e 100644
--- a/include/internal/refcount.h
+++ b/include/internal/refcount.h
@@ -15,7 +15,8 @@
 # define HAVE_C11_ATOMICS
 # endif

-# if defined(HAVE_C11_ATOMICS) && ATOMIC_INT_LOCK_FREE > 0
+# if defined(HAVE_C11_ATOMICS) && defined(ATOMIC_INT_LOCK_FREE) \
+    && ATOMIC_INT_LOCK_FREE > 0

 # define HAVE_ATOMICS 1

@richsalz

i need the following added (and a rebase to catch the apps/rehash.c)

done, and split up in smaller commits, as @dot-asm suggested.

well since we already merged your PR for 1.1.0, the split is just an academic exercise :)
@dot-asm, please reconfirm and I will merge/squash.

squashed again as an exercise ;)

Reconfirmed.
"Side note" means that no action is expected, this is likely something to consider for future.

merged, thank you!

authors: bernd-edlinger dot-asm richsalz


text:
Fix no-blake2 for Windows classic build

Fix no-blake2 for Windows classic build

@levitte: Care to look at this?

Other than that comment, it looks fine to me

done, thanks!

authors: kroeckx levitte matbech richsalz