Inline demo contains "```html"

As you can see at https://beta.webcomponents.org/element/Juicy/juicy-ace-editor

Inline demo contains "```html"
The markdown looks like follows:
3. Start using it!
<!--
 ```
<custom-element-demo>
  <template>
    <link rel="import" href="juicy-ace-editor.html">
    <next-code-block></next-code-block>
  </template>
</custom-element-demo>
```
-->
    ```html
    <juicy-ace-editor>Editable code here</juicy-ace-editor>
    ```

I suppose indentation is the problem, but I'd like to keep it to get formatting right in regular markdown result.

@tomalec: the markdown formatting doesn't look correct on GitHub.

Ref: https://github.com/Juicy/juicy-ace-editor
You may need an extra newline before the commented section. For the README files, the site uses GitHub to render it, so this issue might be fixed once it looks correct on GitHub. Can you try that? You can use preview instead of publishing a new version.

Thanks @samuelli, I have just fixed formattin so it looks good in github, but at beta.webcomponents.org I still have the same problem
The corrected markdown looks like:
3. Start using it!

   <!--
   ```
   <custom-element-demo>
     <template>
       <script src="../webcomponentsjs/webcomponents.js"></script>
       <link rel="import" href="juicy-ace-editor.html">
       <next-code-block></next-code-block>
     </template>
   </custom-element-demo>
   ```
   -->

  ```html
  <juicy-ace-editor theme="ace/theme/monokai">Type your code here...</juicy-ace-editor>
  ```

BTW, Can I refresh the beta.wc.org page without releasing a new version?

@tomalec: this is fixed now!
https://beta.webcomponents.org/element/Juicy/juicy-ace-editor

Great! thanks


Couch settings

@wpride this'll add the appropriate couch settings for formplayer
cc: @gcapalbo

(ignore first commit, it's part of another PR that'll be merged soon)

(hold off on merge need to adjust when we're connecting to cloudant)

good to merge


Fails to compile in Alpine

Hi there,
Exile is failing to compile in Alpine (3.17 and 3.18 tried) via docker.io/hexpm/elixir:1.14.2-erlang-25.1.2-alpine-3.18.0 at the moment. Here is the stacktrace:
#22 61.28 ==> exile
#22 61.28 mkdir -p priv
#22 61.28 cc -I/usr/local/lib/erlang/usr/include -fPIC -shared -Wall -Werror -Wno-unused-parameter -pedantic -std=c99 -O2 -fsanitize=undefined -D_POSIX_C_SOURCE=200809L c_src/exile.c -o priv/exile.so
#22 61.42 /usr/lib/gcc/aarch64-alpine-linux-musl/12.2.1/../../../../aarch64-alpine-linux-musl/bin/ld: cannot find -lubsan: No such file or directory
#22 61.42 collect2: error: ld returned 1 exit status
#22 61.42 make: *** [Makefile:21: priv/exile.so] Error 1
#22 61.43 could not compile dependency :exile, "mix compile" failed. Errors may have been logged above. You can recompile this dependency with "mix deps.compile exile", update it with "mix deps.update exile" or clean it with "mix deps.clean exile"
#22 61.43 ==> conduit
#22 61.43 ** (Mix) Could not compile with "make" (exit status: 2).
#22 61.43 You need to have gcc and make installed. If you are using
#22 61.43 Ubuntu or any other Debian-based system, install the packages
#22 61.43 "build-essential". Also install "erlang-dev" package if not
#22 61.43 included in your Erlang/OTP version. If you're on Fedora, run
#22 61.43 "dnf group install 'Development Tools'".
#22 61.43

The build is including alpine-sdk (functional equivalent to build-essential).
Thanks

Hi @nsweeting, thanks for reporting the issue.
I created a fix, can you try dev branch to see if works?
{:exile, github: "akash-akya/exile", branch: "dev"}

Hi @akash-akya - thanks for the quick followup. I was able to compile in an alpine based build successfully from your dev branch 👍

@nsweeting released v0.7.0 with the fix 🎉


DBZ-4494 Document reason/description for user grants w/Oracle

https://issues.redhat.com/browse/DBZ-4494

@Naros This is super useful docs, thanks!


pycsw endpoint must be public

Currently, pycsw endpoint (for example http://hh.worldmap.harvard.edu/registry/hypermap/csw?service=CSW&version=2.0.2&request=GetCapabilities) seems available only when authenticated.
We should have it public as default

@tomkralidis this happens because the views behind that url uses the @logged_in_or_basicauth decorator: https://github.com/cga-harvard/HHypermap/blob/master/hypermap/search/views.py#L21
Is it safe to have that view accessible to anyone? Or is it responsible also for transactions? In the latter case we will need to filter out on request types

sorry, this is the view: https://github.com/cga-harvard/HHypermap/blob/master/hypermap/search/views.py#L79

thanks @capooti.  Suggested update/fix:

remove logged_in_or_basicauth() decorator from https://github.com/cga-harvard/HHypermap/blob/master/hypermap/search/views.py#L79 and https://github.com/cga-harvard/HHypermap/blob/master/hypermap/search/views.py#L21
update logic in https://github.com/cga-harvard/HHypermap/blob/master/hypermap/search/views.py#L22 as follows:

if logged in or basic auth: set CSW-T manager (transactions) to true, else false

This way, CSW-T only gets enabled at runtime when the client/user is logged in / authenticated / authorized.  Makes sense?

thanks, will do it!


optimize: send async response

Ⅰ. Describe what this PR did
Optimize code and error message for clarity.
Ⅱ. Does this pull request fix one issue?

https://github.com/apache/incubator-seata/issues/6515

cc. @funky-eyes @slievrly

LGTM

Thanks for the review 🙇🏼

LGTM

If there are any issue that i could help with just let me know anytime.
I am currently working full time job, so maybe solving issue not so fast but i could help and contriubte somthing this project
Thanks 😄

Is there any issue to merge it??

我将在2.2版本上合并这个pr，当前2.1版本的里程碑已经完成接近于发版，暂时不进行合并pr I will merge this pr on version 2.2. The milestone of the current version 2.1 has been completed and is close to the release. I will not merge pr for the time being.

I understand it. Thank you for the kind description.


Verify make will assert binary sizes

It will probably be better to make a tool around make configure

The latest commit contains simple FS, thus removes the troublesome requirements for keeping track of where user binaries are stored in the image.
Commit 825e43fd (please ignore the type there :)), deprecated make configure itself.


Fix broken backend nodes for TOPCONS2

Some of the backend nodes for TOPCONS2 are down. Figure out the problem and fix them.

DONE


[Proposal] Resource Permissions and Sharing

Resource Sharing
Status Quo
Currently, there is no mechanism provided by the security plugin for plugins to utilize to provide fine-grained access control to own resources created by each plugin. Some plugins have addressed this by implementing their own custom authorization mechanism, however it is not sustainable for each plugin to handle resource-level FGAC using their own custom implementation. For example, in anomaly detection, granting permissions to delete detectors requires the user to be granted cluster:admin/opendistro/ad/detector/delete, which allows the user to delete all detectors in the cluster. Anomaly Detection has implemented their own authz mechanism.To address this, we are introducing a new concept of Resource Sharing. This feature introduces a new way of authorization in addition to existing RBAC authorization model.
Abstract:
With Resource Sharing, the high-level idea is that a resource owner determines how a resource can be shared with others. A user should be able to control access to the resources created by them. A cluster admin will not be able to control access  unless they are defined as REST or TLS admins.
This will enable a collaborative usage of OpenSearch like never before. Quip is one of the well known tools around for document sharing and collaboration. With quip you can define documents private to you, or you can grant access to a group of people, or you can mark the document as public. Resource Sharing is following a similar approach where different access control scopes and levels can be defined to permission resources.
Motivation:
Due to the absence of any mechanism for resource access control, many plugins have resorted to implement custom authorization schemes to curb access to resources defined by such plugins. Here is one such example of a known public documentation for ML-Commons plugin (link) to control access to model groups.
ML Commons implements a robust authorization model that categorizes access to model groups into three distinct modes: public, private, and restricted. These modes provide flexible control over who can view and interact with model groups:

Public: All users have access to the model group. However, this does not grant full control over the resource. Access is further governed by the permissions model. For instance, users with ml_read_access will only be able to list and view model groups, but not modify them. Only users with ml_full_access will have complete control over public models.
Private : Only the resource owner has access to the model group.
Restricted: The resource owner has shared access with specific trusted users or parties.

This approach is inspired by the ML Commons architecture and aims to provide a reusable mechanism for any plugin to leverage the Security plugin for resource sharing. By centralizing authorization within the Security plugin, plugin development is simplified, while ensuring that access control remains robust and scalable. This model also provides a clear pathway for migrating existing access control mechanisms from plugins to the Security framework.
Feature Implementation:
Components:
There are 3 major components to this design:

resource_sharing index: This index will be stored centrally and will contain information about how a particular resource is shared.
ResourcePlugin : The contract class defined in OpenSearch to be utilized by the plugins who choose to utilize the resource access control framework provided by Security plugin.
Resource Access Control Framework: This framework is at the heart of this design and involves defining concrete implementation of access control methods defined in the contract above. It also involves implementing index action listener to ensure the resource sharing information remains consistent across the nodes in the cluster.

Assumptions:
A Resource is a document stored within a plugin’s system index, containing metadata about that resource. Examples of resources include Model Groups in ML Commons, Anomaly Detectors in anomaly-detection, and Detectors in alerting plugins.
The .resource-sharing index will always maintain a compound key that references the location of the original resource. This compound key consists of two components:

source_idx: The system index where the original resource is stored, as defined by the plugin.
resource_id: The DocID corresponding to the resource document within the system index source_idx.

This structure ensures a clear and direct link between the shared resource and its original location.
Index design:
The resource_sharing index document has following entries:

source_idx : The system index which resource metadata. This is usually the plugin’s system index.
resource_id : The id of the resource document defined in the source_idx .
created_by : Defined the user or a backend_role that created this resource.
shared_with : Defines access scope for this resource. It contains users, roles and backend_roles this resource is shared with. Access scope is defined in 3 ways:

public: A shared_with  entry exists, and contains users  entry mapped to * .
restricted: A shared_with  entry exists, and contains users  entry not mapped to * .
private: A shared_with  entry is empty or doesn’t exist.

In addition each shared_with will also contain the level of access that each user, role or backend_role may have. These are two scopes at present read_only and read_write.

Note: The relationship between entries in this index and the resource metadata stored in plugin’s index is many-to-one.
Here are 3 examples of entries in resource_sharing index, one for each scope.

Private:

{
   "source_idx": ".plugins-ml-model-group",
   "resource_id": "<doc_id_of_model_group>",
   "created_by": {
      "user": "darshit",
      "backend_role": "",
   }
}

Restricted:

{
   "source_idx": ".plugins-ml-model-group",
   "resource_id": "<doc_id_of_model_group>",
   "created_by": {
      "user": "darshit",
      "backend_role": "",
   },
   "share_with": {
      "read_only": {
         "users": [
            "derek"
         ],
         "roles": [],
         "backend_roles": []
      },
      "read_write": {
         "users": [
            "craig"
         ],
         "roles": [],
         "backend_roles": []
      }
   }
}

Public:

{
   "source_idx": ".plugins-ml-model-group",
   "resource_id": "<doc_id_of_model_group>",
   "created_by": {
      "user": "darshit",
      "backend_role": "",
   },
   "share_with": {
      "read_only": {
         "users": ["*"],
         "roles": ["*"],
         "backend_roles": ["*"]
      },
      "read_write": {
         "users": [
            "*"
         ],
         "roles": ["*"],
         "backend_roles": ["*"]
      }
   }
}

NOTE: Each user, role and backend_role must be individually added as there is no pattern matching at present by design.
Code Implementation:
A new plugin type ResourcePlugin  will be defined in OpenSearch. This is an extensible contract and will define core Java APIs to be used by plugins to check access:

updateSharingInformation (ResourceSharing resourceSharing)

This method creates or updates the entry in .resource-sharing to define how a resource is shared.

Example where AD creates a detector with a detectorUser: https://github.com/opensearch-project/anomaly-detection/blob/main/src/main/java/org/opensearch/ad/transport/IndexAnomalyDetectorTransportAction.java#L175-L203

listAccessibleResourcesForUser()

This method can be used when a plugin is listing resources to obtain a list of resources accessible by current user (information retrieved from thread context). It will check for a match in created_by and shared_with entries.

Example of how list works in AD: https://github.com/opensearch-project/anomaly-detection/blob/main/src/main/java/org/opensearch/timeseries/util/ParseUtils.java#L583-L640

hasPermission(Resource resource, ResourcePermissionScope scope)

Determines if the current user has access to the target resource with the given scope. There are two main scopes: "read_only" and "read_write".

Example of how AD implements this: https://github.com/opensearch-project/anomaly-detection/blob/main/src/main/java/org/opensearch/timeseries/util/ParseUtils.java#L654-L674

Security will add a concrete implementation to these APIs to determine access to a particular resource, and plugins will call these APIs to verify a user’s access to requested resource.
Flow Diagram:
sequenceDiagram
    participant Plugins
    participant ResourcePlugin as ResourcePlugin
Defines Core APIs
    participant Security as Security
Concrete Implementation of APIs

    Plugins ->> ResourcePlugin: Call updateSharingInformation
    ResourcePlugin ->> Security: Forward to Security Plugin
    Security -->> ResourcePlugin: Return result
    ResourcePlugin -->> Plugins: Return result

    Plugins ->> ResourcePlugin: Call listAccessibleResourcesForUser
    ResourcePlugin ->> Security: Forward to Security Plugin
    Security -->> ResourcePlugin: Return accessible resources
    ResourcePlugin -->> Plugins: Return accessible resources

    Plugins ->> ResourcePlugin: Call hasPermission
    ResourcePlugin ->> Security: Forward to Security Plugin
    Security -->> ResourcePlugin: Return permission status
    ResourcePlugin -->> Plugins: Return permission status

Pros & Cons:

Pros

A highly scalable approach where the resource owner is empowered to determine how the resource is shared
Provides a clear migration path for plugins like ML Commons

Cons

No code re-use
Not all unknowns are identified
Introduces a new authorization model in addition to and different from Role Based Access Control

Test Plan

Add local tests in the security plugin.
Add mixed cluster tests. (To evaluate requests coming in during rolling-upgrade scenario)
Add tests in anomaly detection or other plugins that could leverage this feature.

Will the feature require a security review?
This feature will require a security review to confirm that it correctly evaluates the scope of the requested resource.
Documentation
The documentation should be added for this feature detailing how users can utilize this feature.
--
Next Steps

[ ] Open a META issue that tracks this feature

[ ] Add a task to add ResourcePlugin definition in core
[ ] Open a task to add this feature in Security Plugin by extending the APIs offered (preferred if done via feature branch)
[ ] Open a follow-up issue to add tests for this feature
[ ] Open a PoC PR in anomaly detector plugin to demonstrate this feature

 Expand to see old design:
## _High-Level Design_

### Status Quo

Currently, there is no mechanism provided by the security plugin for plugins to utilize to provide fine-grained access control to own resources created by each plugin. Some plugins have addressed this by implementing their own custom authorization mechanism, however it is not sustainable for each plugin to handle resource-level FGAC using their own custom implementation. For example, in [anomaly detection](https://opensearch.org/docs/latest/observing-your-data/ad/security/), granting permissions to delete detectors requires the user to be granted `cluster:admin/opendistro/ad/detector/delete`, which allows the user to delete all detectors in the cluster.  To avoid this the Security plugin should be the only place where authorization happens. To address this, we are introducing a new concept of Resource Permissions. This feature adds an additional step to the authorization evaluation, allowing plugins to define resource-specific permissions.

### **Feature Implementation**

Once plugins define the resource permissions associated with resources, cluster admins can assign the relevant resource permissions to roles, which will then be evaluated within the Security plugin. Resource permissions can be defined in two ways:

1. Starts with `resource:<plugin-identifier>/<permission>`  **(proposed)**
2. Starts with `<plugin-identifier>:<permission>`

The main difference is the presence of the standard prefix `resource:`, **which simplifies validation [here](https://github.com/opensearch-project/OpenSearch/blob/2069bd805804dd93bd69695a4c6521cc6f2b9bb6/server/src/main/java/org/opensearch/transport/TransportService.java#L1097)**. The structure would look like:

Allows users to use all Anomaly Detection functionality on selected resources, i.e., detectors
anomaly_full_access:
reserved: true
cluster_permissions:
- 'cluster_monitor'
- 'cluster:admin/opendistro/ad/'
index_permissions:
- index_patterns:
- ''
allowed_actions:
- 'indices_monitor'
- 'indices:admin/aliases/get'
- 'indices:admin/mappings/get'
resource_permissions:
- identifier_pattern:
- 'detector1'
- 'detector2'
allowed_actions:
- 'resource:ad/detectors/read'

**This allows admins to add a layer of control, restricting access to selected detectors instead of all detectors. Plugins like [alerting](https://opensearch.org/docs/latest/observing-your-data/alerting/security/), [ml-commons](https://quip-amazon.com/CBKNACJHvnRY/ML-Commons-Security-model-access-control), and flow-framework can similarly benefit by defining permissions at the resource level.**

### **Evaluation Flow Diagram**

* ResourceAccessEvaluator.java
```mermaid
flowchart TD
    A[Resource Access Evaluator.evaluate]
    A --> B{Does request have resources defined?}
    B -->|No| C[Return response as incomplete]
    B -->|Yes| D{Do roles have resource_permissions defined?}
    D -->|No| E[Return response as denied and mark complete]
    D -->|Yes| F[Evaluate resource_permissions for all roles]
    F --> G{Do resource_permissions match with supplied resource names?}
    G -->|Yes| H[Return response as allowed and mark complete]
    G -->|No| E
    H --> J[Return presponse]
    E --> J
    C --> J

PrivilegesEvaluator.java’s evaluate() method with resource permissions check:

flowchart TD
    A[PrivilegesEvaluator.evaluate]
    A --> B[Resolve roles]
    B --> C{Is bulk request for default tenant?}
    C -->|Yes| D[Evaluate and return presponse]
    C -->|No| E[Resolve all indices in the request]
    E --> F[Evaluate snapshot restore request]
    F -->|Complete| G[Return response]
    F -->|Incomplete| H[Evaluate security index access request]
    H -->|Complete| I[Return response]
    H -->|Incomplete| J[Evaluate protected index access request]
    J -->|Complete| K[Return response]
    J -->|Incomplete| L[Evaluate Resource Access request]
    L -->|Complete| M[Return response]
    L -->|Incomplete| N[Evaluate PIT request]
    N -->|Complete| O[Return response]
    N -->|Incomplete| P{Is cluster permission request?}
    P -->|Yes| Q[Evaluate cluster-level permissions and return response]
    P -->|No| R[Evaluater terms aggregation request]
    R -->|Complete| S[Return response]
    R -->|Incomplete| T[Perform DNFOF evaluation if enabled]
    T --> U[Return result]
    style L fill:green,stroke:#333,stroke-width:4px

Low-Level Design
Design Questions

Are we allowing a mix of roles with and without resource permissions?

If yes, what is the default behavior when none of the roles resolved for a user contain a resource permission?
Should the user be allowed permission to that resource?

If yes, there won’t be backward compatibility issues, but it is not ideal as the feature can be circumvented by not adding any resource permissions.
(Proposed) If no, there might be backward compatibility issues, especially in mixed cluster requests, which need thorough testing.

Should we allow *  (match_all) patterns for accessing resources? OR should they be individually listed under the role?

Note: detector_c*  can still be allowed but the question here is, should  *  be prohibited as a resource_name pattern.

Should ressource_permissions be hidden behind feature flag?

No, the primary purpose of introducing this feature is to move the authorization logic, implemented by individual plugins with resources, to Security plugin.

File Changes

ActionRequest.java

This base class is extended by every plugin’s implementation of transport request calls. Hence, the proposal is to add a standard class property List<String> resources . This should then be implemented by plugins to populate this property when handling an actionRequest after which SecurityFilter.java will intercept this call to perform privilege evaluation. (It is important to note this change when creating a documentation to onboard plugin developers to this change)

Note: this is done for standardization purposes, however this can be skipped and left on the plugin developers to add this property to each request class. (Not recommended)

TransportService.java

Add resource:  as a valid transport action prefix here.

RoleV7.java

This class will now define a new type of class: Resource (Use the class Index as reference)
Add this newly defined class as a property to the parent

ResourceAccessEvaluator.java (new file)

A new class that defines the evaluator method to verify the resource permissions.
This method should assume the resource names are passed in the request (the string list defined above).
If no resources are present in the list, it should assume that the plugin has not opted into this feature and so should bypass this authorization check to return a success response.

PrivilegeEvaluator.java

Modify evaluate() method to add a check that calls the evaluator defined above.

Thanks for the proposal @DarshitChanpura ! This looks interesting! High-level comments-
From what I understand, this proposal is targeting current roles and adding new resource_permissions to the existing RBAC system. What are your thoughts about treating resources as entities and allowing admins/users to tie up ACLs with a resource? For example, treating detector as a resource and access control will be defined on this resource (i.e. close to the entity being evaluated).
This proposal talks in depth about plugins, can you add an example if such a resource is added by core. This could also pave the way for treating indices as resources and tying down an ACL with them.

Adding few more comments on each design question-

Are we allowing a mix of roles with and without resource permissions?
If yes, what is the default behavior when none of the roles resolved for a user contain a resource permission?
Should the user be allowed permission to that resource?
If yes, there won’t be backward compatibility issues, but it is not ideal as the feature can be circumvented by not adding any resource permissions.
(Proposed) If no, there might be backward compatibility issues, especially in mixed cluster requests, which need thorough testing.

For backwards compatibility, I think this should be introduced with default behavior of treating * as a resource on a role that doesn't have any explicit definitions of resource_permissions. I agree that this might not be the best security behavior, however, it allows for smoother upgrades and easier migration path for customers. To negate circumventing of the feature, for any roles being created, resource_permissions must be explicitly added. Thoughts?
For example, an existing role without resource permissions specified would be treated as equal to the following-
# Allow users to read Anomaly Detection detectors and results
anomaly_read_access:
  reserved: true
  cluster_permissions:
    - 'cluster:admin/opendistro/ad/detector/info'
    - 'cluster:admin/opendistro/ad/detector/search'
    - 'cluster:admin/opendistro/ad/detector/validate'
    - 'cluster:admin/opendistro/ad/detectors/get'
    - 'cluster:admin/opendistro/ad/result/search'
    - 'cluster:admin/opendistro/ad/result/topAnomalies'
    - 'cluster:admin/opendistro/ad/tasks/search'
  resource_permissions:
    - '*'

This would allow users upgrading to newer versions of OpenSearch where these permissions are introduced while letting users/admins define more granular access control methods.

Should we allow * (match_all) patterns for accessing resources? OR should they be individually listed under the role?
Note: detector_c* can still be allowed but the question here is, should * be prohibited as a resource_name pattern.

For the reasons mentioned in previous comment, I think * needs to be allowed.

Should ressource_permissions be hidden behind feature flag?
No, the primary purpose of introducing this feature is to move the authorization logic, implemented by individual plugins with resources, to Security plugin.

I agree with the requirement, however, this could also break existing customers. If we can cover migrations/upgrades with enough tests, it should be okay to use a feature flag to enable it. However, I would prefer a flag to turn this functionality on/off smoothly for initial release as this could be a breaking change.

File Changes

For file change, kindly consider the changes being brought in by https://github.com/opensearch-project/security/issues/3870 and ensure changes are compatible with the RFC.

RoleV7.java

Since this introduces a new class in existing model, do you know if contents of this class are sent over transport channel with requests? If so, this could cause issues during ugprades in a mixed-version cluster.

[Triage] Hi @DarshitChanpura, thanks for filing this issue. This proposal/rfc is for the resource permissions you are working on. I will go ahead and mark it as triaged.

@shikharj05 Thank you for your comments.

What are your thoughts about treating resources as entities and allowing admins/users to tie up ACLs with a resource? For example, treating detector as a resource and access control will be defined on this resource (i.e. close to the entity being evaluated).

Not sure if i completely understand what an ACL is. However, this proposal introduces 1 more layer which is closer to the resource being evaluated.

As this is introducing a new field/permission model, should this be a new config_version ? Also, there's another RFC to retire V6 https://github.com/opensearch-project/security/issues/4493 , I think we can use this opportunity to define how new permissions models/config_version changes should be added and older ones removed. Thoughts @DarshitChanpura @cwperks ?

We can consider this as a new config version, however the scope of #4493 might not overlap with this as that RFC discusses retiring v6 and this RFC talks about introducing a new property to a role. Having said that this should be be tested in mixed cluster scenario.

For backwards compatibility, I think this should be introduced with default behavior of treating * as a resource on a role that doesn't have any explicit definitions of resource_permissions. I agree that this might not be the best security behavior, however, it allows for smoother upgrades and easier migration path for customers. To negate circumventing of the feature, for any new roles being created, resource_permissions must be explicitly added (maybe, we can add similar requirement for updates to existing roles). Thoughts?

Proposed path for roles with no resource_permissions is to skip Resource Permissions evaluation entirely which essentially mimics * behavior. "If no resources are present in the list, it should assume that the plugin has not opted into this feature and so should bypass this authorization check to return a success response." If plugin has opted in to resource permissions, we should not allow * access to all resources as this would essentially by-pass resource permissions evaluation.

I would prefer a flag to turn this functionality on/off smoothly for initial release as this could be a breaking change.

Agreed.

File Changes
For file change, kindly consider the changes being brought in by https://github.com/opensearch-project/security/issues/3870 and ensure changes are compatible with the RFC.
RoleV7.java

Since that is still in draft state I have not considered those changes here.

Since this introduces a new class in existing model, do you know if contents of this class are sent over transport channel with requests? If so, this could cause issues during ugprades in a mixed-version cluster.

Agreed. This will have to be tested. Can you elaborate on what contents will be sent over transport channel?

@nibix would love your inputs on this.

Resource permissions can be defined in two ways:

Starts with <plugin-identifier>:<permission>

@DarshitChanpura I think a good aim for action naming is to make them as succinct as possible to help cluster admins understand what they do based off of this short name. We could have the prefix of the action name be the resource type and allow plugins to specify what the type of resource is.
i.e. In Anomaly-Detection the resource type could be anomalydetector and for ML-Commons it could be modelgroup. Think of indices as a type of resource and resource permissions as a generalization on index permissions.
anomalydetector:admin/create is more succinct then resource:ad/admin/create, but I could see how the resource: prefix could also be helpful for consistency.

@DarshitChanpura
Interesting proposal! That moves OpenSearch quite a bit into the direction of a whole application platform.
Configuration structure

Resource permissions can be defined in two ways:

Starts with resource:<plugin-identifier>/<permission> (proposed)
Starts with <plugin-identifier>:<permission>

I can understand the motivation for both. Both have pros and cons. The pro about <plugin-identifier>:<permission> is that the plugin is easy to recognize for the user. The pro about resource:<plugin-identifier>/<permission> is that the validation in TransportService and also the logic routing in PrivilegesEvaluator is more easy. However, it might be confusing that the first component after the resource: prefix is actually not the resource, but a string requiring the plugin? How about using the format plugin:<plugin-identifier>/<resource>/<permission> instead?
However, I would like to take one step back first. Do I see it correctly that we have these dimensions?

Plugin: Like Anomaly detection, or alerting, ...
Plugin-specific resource type: Plugins might be managing more than one resource types, especially alerting seems to have quite a few
Individual instances of one resource type.

While I am pretty sure that these dimensions can be modeled with the proposed resource_permissions structure, I am wondering whether it still will be easy to grasp when there are several plugins with several resource types in the game.
Generally, to verify the real-world suitability of a new config format, I like to recommend to actually create some complete real-world examples, which incorporate several features for several different cases.
Backwards compatibility considerations
I have read the discussions about backwards compat. Just some random thoughts about this:

Are there considerations in which version these permissions shall be introduced? In a major release one might be more liberal about breaking changes than in a minor release.
As some of the plugins might have implemented their own authz mechanisms now, these also need to be considered in the migration process. As soon as the security plugin gets responsible for authz, the plugins authz mechanisms should be no longer in effect.
One way around this would be to require the plugins to introduce new APIs which are then protected by the new scheme, while the old APIs are protected by the old scheme and can be removed eventually. But that might also introduce further and bigger issues :thinking:
I would strongly recommend not to assume that roles without resource permissions indicate full permissions in order to stay backwards compat. That would be very counter-intuitive. If such a strong backwards compatibility is required, I'd go with a feature flag instead.

Code infrastructure: Extending ActionRequest
I can think about two different way of extending ActionRequest. I am wondering about what way you were thinking.
Approach a): Add an empty method that can be overridden:
public abstract class ActionRequest extends TransportRequest {

    public ActionRequest() {
        super();
    }

    public ActionRequest(StreamInput in) throws IOException {
        super(in);
    }

    /**
      * NEW NEW NEW
      */
    public List<String> getResources() {
    }

    public abstract ActionRequestValidationException validate();

    public boolean getShouldStoreResult() {
        return false;
    }

    @Override
    public void writeTo(StreamOutput out) throws IOException {
        super.writeTo(out);
    }
}

Approach b): Include the actual resource information here.
public abstract class ActionRequest extends TransportRequest {

    private final List<String> resources;

    public ActionRequest() {
        super();
        this.resources = Collections.emptyList();
    }

    public ActionRequest(List<String> resources) {
        super();
        this.resources = resources;
    }

    public ActionRequest(StreamInput in) throws IOException {
        super(in);
        if (in comes from resource aware node) {
           this.resources = in.readList();
        }
    }

    public List<String> getResources() {
       return this.resources;
    }

    @Override
    public void writeTo(StreamOutput out) throws IOException {
        super.writeTo(out);

        if (out is resource aware node) {
           out.writeList(this.resources);
        }
    }
}

One advantage of apporach b) would make it very easy for plugins to gradually enhance their existing actions.

One disadvantage of approach b) would be that such requests likely already carry the resource information - yet there is no standardized way to access and retrieve it. In approach b) it would need to be stored redundantly - which would create the risk of inconsistencies.

Yet, both approaches would be a slight deviation from the present quite strict segmentation of action and request types by interfaces and super-classes (compare IndicesRequest, AliasesRequest, BroadcastRequest, ...). If ActionRequest is extended, it gets very easy to also add resource priv requirements to IndicesRequests. The question would be whether that makes sense.

One thing that needs to be clarified is: Shall such requests support resource wildcards (*)  and resource name patterns (my_resource_*)? For indices requests, it is standard that wildcards and patterns are supported, so it would be intuitive if resource requests would be supporting these as well. However, resource requests can only carry the patterns. They are most likely lacking the dependencies to resolve these patterns to concrete resource names. This probably can be only done by a central component in the plugin, possibly the TransportAction instance which is responsible for processing the requests. Possibly, one needs to have a further interface which TransportActions need to implement in order to extract concrete resource names from requests.

Code infrastructure: Privilege meta data
I am deviating from the proposal a bit to make a related observation: In core OpenSearch, there is also no standardized interface to deduce required privileges from action requests. Instead, the security plugin has a quite involved logic to deduce required privileges from requests. See for example:
https://github.com/opensearch-project/security/blob/2b5a811de599f7c7fc2ca2b9246e57fd6cfaf33b/src/main/java/org/opensearch/security/privileges/PrivilegesEvaluator.java#L601
https://github.com/opensearch-project/security/blob/main/src/main/java/org/opensearch/security/resolver/IndexResolverReplacer.java (especially this one is pure horror)
Could it make sense to extend the proposal to enhance ActionRequests and TransportActions to provide their required privileges - independently whether these are plugin resources or core indices, core aliases or core data streams?
New config version
So far the proposal for the new configuration is a pure super-set of the previous configuration. Thus, the new properties can be considered as a "progressive enhancement", which does not make a new config version necessary.
I guess that introducing new config versions introduces significant pains (migration processes, tools, etc), which should be avoided if possible.

New config version

So far the proposal for the new configuration is a pure super-set of the previous configuration. Thus, the new properties can be considered as a "progressive enhancement", which does not make a new config version necessary.

I guess that introducing new config versions introduces significant pains (migration processes, tools, etc), which should be avoided if possible.

This would be ideal. I also don't believe a new config version is necessary.

I agree with succinct naming, however the prefixes for transport actions are statically defined here. If we were to define plugin names as prefixes instead of resource: it becomes impossible to validate the prefix and without this validation the transport action flow fails here. Hence, I think we should have a common prefix: resource:.

That data structure can be treated as a registry and an extension point could be introduced for plugins to register resource types. I see "views" is in that list and that could be considered a resource type. Since the new section of the role would be called resource_permissions: there would be some redundancy with all action names prefixed with resource: but we can iterate to determine the ideal path forward. As @nibix mentioned, it would be useful in the action name to both has the plugin identifier (or commonly-used shortname) + resource type to allow plugins to create more than one resource type.

One way around this would be to require the plugins to introduce new APIs which are then protected by the new scheme, while the old APIs are protected by the old scheme and can be removed eventually. But that might also introduce further and bigger issues 🤔

+1, while this offers easier migration path, however this will make authorization decisions complicated with custom authZ. @DarshitChanpura - can you help list plugins performing custom authZ within the opensearch-project? I think this proposal can cover migrating these plugins away from custom authZ.

I would strongly recommend not to assume that roles without resource permissions indicate full permissions in order to stay backwards compat. That would be very counter-intuitive. If such a strong backwards compatibility is required, I'd go with a feature flag instead.

I think it should be okay to introduce this feature with a flag. i.e. fail-open with * as resource_permissions or fail-close in case of missing resource_permissions. We can also offer something like a migration period/dual-mode flag like plugins.security_config.ssl_dual_mode_enabled

Not sure if i completely understand what an ACL is. However, this proposal introduces 1 more layer which is closer to the resource being evaluated.

For example, consider Linux OS. Permissions on a file can be defined for file owner, group owner & others. i.e. resource permissions are dictated by ACL defined on the file.
As an example, for OpenSearch, this could possibly translate to a Super Admin user being able to create a detector in AD plugin and adding an ACL to it that looks like - CRUD for super admin users & RU for users with anomaly_full_access role and R for others.
For an incoming request, security plugin would first evaluate permissions based on the identity (caller of the request); next, request would be evaluated against resource(in this case a detector) ACL.
Thoughts?

@nibix

Are there considerations in which version these permissions shall be introduced? In a major release one might be more liberal about breaking changes than in a minor release.
As some of the plugins might have implemented their own authz mechanisms now, these also need to be considered in the migration process. As soon as the security plugin gets responsible for authz, the plugins authz mechanisms should be no longer in effect.
One way around this would be to require the plugins to introduce new APIs which are then protected by the new scheme, while the old APIs are protected by the old scheme and can be removed eventually. But that might also introduce further and bigger issues 🤔
I would strongly recommend not to assume that roles without resource permissions indicate full permissions in order to stay backwards compat. That would be very counter-intuitive. If such a strong backwards compatibility is required, I'd go with a feature flag instead.

These are great thoughts/suggestions. This feature would require end to end testing to understand the migration path for plugins with custom authz schemes. However, the idea is to enforce those plugins to use security plugin as the standard for any authorization which would be considered breaking change for plugins but the end user experience remains the same (except now they have to have resource permissions, of course).
I agree with not assuming no permission as full permissions and hence suggested an alternative to use feature flag. However, the issue with feature flag is that when it is enabled all plugins must have been onboarded to this new authz scheme, else we'll have to maintain a list of plugins which have onboarded, as a custom setting, and then only evaluate requests pertaining to those plugins, which is a whole new set of problems.  I'm strongly in favor of nudging plugins to introduce new APIs that can be hidden behind feature flag until we finally deprecate the current APIs.

Code infrastructure: Extending ActionRequest

I'm leaning towards approach a which makes the implementation simpler and easy to extend, but with a twist. If we are nudging plugins to introduce new APIs, we can extend ActionRequest to a new class ResourceActionRequest and have the plugins using custom authz extend this class instead.

One thing that needs to be clarified is: Shall such requests support resource wildcards () and resource name patterns (my_resource_)? For indices requests, it is standard that wildcards and patterns are supported, so it would be intuitive if resource requests would be supporting these as well. However, resource requests can only carry the patterns. They are most likely lacking the dependencies to resolve these patterns to concrete resource names. This probably can be only done by a central component in the plugin, possibly the TransportAction instance which is responsible for processing the requests. Possibly, one needs to have a further interface which TransportActions need to implement in order to extract concrete resource names from requests.

My understanding is that resource names would be extracted from the API request as is before forwarding those to transport action calls. I'm not entirely sure if we need to expand and resolve resource names similar to index-pattern. If we do then, we will have to develop an API to fetch all resources and resolve them based on the pattern supplied, similar to IndexResolverReplacer. This might need a deeper look.
@cwperks

That data structure can be treated as a registry and an extension point could be introduced for plugins to register resource types. I see "views" is in that list and that could be considered a resource type. Since the new section of the role would be called resource_permissions: there would be some redundancy with all action names prefixed with resource: but we can iterate to determine the ideal path forward. As @nibix mentioned, it would be useful in the action name to both has the plugin identifier (or commonly-used shortname) + resource type to allow plugins to create more than one resource type.

This sounds like a good approach. However it also relies to plugins registering the resource types. If we are to move with this path then we would have to highlight that all plugins that will be utilizing this new authz scheme should register the resource types. AFAIK, keeping a consistent prefix avoids a lot of problems around validation and we already have redundancy in cluster_permissions and index_permissions.
@shikharj05

@DarshitChanpura - can you help list plugins performing custom authZ within the opensearch-project? I think this proposal can cover migrating these plugins away from custom authZ

From my knowledge and talking with @cwperks, these plugins currently perform custom authZ: alerting, anomaly-detection, ml-commons and flow-framework.

For an incoming request, security plugin would first evaluate permissions based on the identity (caller of the request); next, request would be evaluated against resource(in this case a detector) ACL.
Thoughts?

I'm not sure if we have a concept of ACL today, but wouldn't it be similar to creating roles like admin, developer, regular-user and then mapping users to these roles as required to grant them access?

@DarshitChanpura I had some more recent thoughts on Resource Permissions and wanted to run them by you. I think Resource Permissions are fundamentally about sharing a resource created by some user.
I was thinking about what it would take to create a Searchable Photo Album plugin (Hackathon idea) where users of the plugin can share their photo albums with others to add photos, add captions, etc.
Each resource should have a resource user, the user that creates the resource. The resource user, should have the ability to allow others to interact with their resources (either explicitly adding someone by username or perhaps someone that shares a role/backend role)
I'm starting to think about the Job-Scheduler SPI model where the security plugin can listen to index operation on resource indexes and then store the resource user centrally along with the docId of the resource, the resource index and the resource user and what level of access (allowed_actions) in a .resource_sharing index.
Also I'm now thinking that resources should not have unique names. i.e. You and I can both have photo albums called Tulum 2024, but I should be able to add you to my album to add photos.
Let's say user1 is trying to upload a photo to user2's photo album, how would the authz work?

PUT /_plugins/photoalbum/{albumId}/upload <- Assume the resource user with {albumId} belongs to user2

When authorizing the request, the security plugin can use the permissions stored in the .resource-sharing index to determine if the user trying to interact with the resource has access.

For a user's own resource, they can continue to be authorized using the cluster_permissions section of a role definition.
I'm still thinking through this idea some and I will reply back with another comment once its more complete.

@cwperks I think your idea also aligns with Resource ACLs. ACLs would allow a user to create a resource and define an ACL on it. i.e. permissions will be tied to the resource and not the user requesting access.

+1 to @shikharj05's comment. I like this idea, however we are moving towards a more ACL approach where the resource "owner/creator" has the right to define ACL's to the resource.
At present, the "owner" of these resources is admin or someone who has access to manage roles, and these admins can then define access levels to individual resources or resource patterns. Allowing the ability to share resources is an administerial task. For what you are suggesting, the idea of a cluster admin might change to allow a regular user more control over their own resources. I personally am in favor of adding such a feature however this might be a v2 of this or a separate feature overall.

Outstanding Questions:

How are we planning to roll-out this feature?

To allow for smoother upgrades, and maintain backwards compatibility, this feature will initially be launched with three modes (settings) : disabled, fail-open and enabled.

plugins.security.resource_permissions.enabled: false - resource permission evaluation is completely disabled.
plugins.security.resource_permissions.fail_open: true - resource permissions will be evaluated and all failures and successes will be logged, and eventually authorization will be deemed successful. Requires enabled to be set to true.
plugins.security.resource_permissions.enabled: true - resource permissions evaluation will be enforced and any failures will cause the request to fail.

To accommodate these flags, plugins will initially be launched with a code flag that switches between in-house authorization and centralized security plugin authorization based on plugins.security.resource_permissions.enabled is set to false or true.

This is prevent us from taking a step backwards where we have on-boarded all plugins onto the new authz scheme, but then have the feature flag disabled, thus allowing all requests to pass through.

Please let me know your thoughts and any questions.

@shikharj05 @nibix @cwperks I have updated the design to follow a new approach that is more scalable. Please review it and add comments. If you would prefer to review via google doc, lmk.
(Thanks @cwperks for helping me draft this).

This feature will be release under @experimental flag until a PoC is complete.

Nice job @DarshitChanpura specifically taking all the feedback in stride and reworking the design to fit the comments and concerns :)

@shikharj05 @nibix @willyborankin @cwperks @derek-ho I have update the design slightly to include scopes for individual or group access to a resource. Please review whenever you get a chance and let me know if there are any comments/concerns.

In addition each shared_with will also contain the level of access that each user, role or backend_role may have. These are two scopes at present read_only and read_write.

@DarshitChanpura From an implementation perspective how will security differentiate between read operation and write operation? Would it be done in the hasPermission(Resource resource) call? i.e. A plugin utilizing these methods has to pass what type of operation it is?

hasPermission will be tweaked to hasPermission(resource, scope) where scope will default to read_only.
Plugin owners are responsible for calling with correct scope. Let me know if you have a different approach in mind

Great work on the design updates!
Some comments-

A new plugin type ResourcePlugin will be defined in OpenSearch.

What are your thoughts about adding a more generic AuthZ plugin interface in core OpenSearch? ResourcePlugin can be an implementation in SecurityPlugin with other existing methods. This would align with vision proposed in https://github.com/opensearch-project/OpenSearch/issues/5834 and pave the way to make AuthZ more extensible as proposed in https://github.com/opensearch-project/security/issues/4702

What are your thoughts about adding a more generic AuthZ plugin interface in core OpenSearch? ResourcePlugin can be an implementation in SecurityPlugin with other existing methods. This would align with vision proposed in https://github.com/opensearch-project/OpenSearch/issues/5834 and pave the way to make AuthZ more extensible as proposed in https://github.com/opensearch-project/security/issues/4702

ResourcePlugin should be defined in core as it defines a new type of plugin that declares resources that are shareable. I can add another scaffolding for declaring AuthZ contracts, which ResourcePlugin can then extend. However, ResourcePlugin should not be moved to security.
There are two main types of plugins introduced with this feature. ResourePlugin and ResourceAccessControl plugin. ResourcePlugin would be inherited by plugin like AD, alerting, ml-commons, etc. ResourceAccessControl would be inherited by Sec Plugin which defines access control to the resources declared by ResourcePlugins.

Can we layout what it would look like to add support for patterns?

This would require reading all users, roles and backend_roles from configuration (or config cache) then resolving them to concrete entity names. And this would need to happen every-time access is checked for the resource which might become memory intensive. Hence, it is not included by design.

In https://github.com/cwperks/security/pull/26, I explored making the security plugin an ExtensiblePlugin and spiked on creating a SPI approach for this RFC. In general I think its a good approach to the problem in this RFC or for making authz pluggable.
If used for this RFC, there would need to be a change in core to relax the rule on extended plugins to make them optional instead of required. Example PR: https://github.com/cwperks/OpenSearch/pull/209
^ One advantage of the SPI approach (at least in the context of this RFC) is testability. It would allow us to maximize changes in the Security plugin (minimize core changes) and provides good testability where it doesn't rely on changes merged into core for testing.

SPI approach is good, however it creates a dependency on Security Plugin to be declared for plugins like AD to utilize the APIs similar . With this approach there is a clear definition of different types of plugins and doesn't declare any requirements on Security Plugin.

SPI approach is good, however it creates a dependency on Security Plugin to be declared for plugins like AD to utilize the APIs similar . With this approach there is a clear definition of different types of plugins and doesn't declare any requirements on Security Plugin.

With a small change in core like https://github.com/cwperks/OpenSearch/pull/209, it removes the requirement. Not sure if there is appetite for a change like that, but it would remove the restriction that extended plugins are required.
i.e. if changed, then AD can be installed even if JS is not installed in the cluster. Currently it makes sense because any instance of extendedPlugin is required, but I think there's a case to be made for this use-case from security. i.e. If you have a plugin that implements the SPI and security is installed on the cluster then you get the resource sharing feature. If security is not installed on the cluster, you can still install the dependent plugin but rely on noop implementation where there is no resource authorization. In noop, all users have full access created to resources created by any user.

In the current design drafted here (https://github.com/opensearch-project/OpenSearch/pull/16030), I've introduced ResourceAccessControl Plugin type which, for now, can either be No-op or Sec plugin. The implementing plugins are not aware of the underlying implementation and do not need to declare dependency on Security. Instead they simply use the APIs provided by ResourceAccessControlPlugin.java class and get a response back.
This allows for future modifications of the implementations by making minimal to no changes in core without requiring explicit dependency declarations.


Model classes based API

Current coverage is 24.85%

Merging #11 into master will decrease coverage by -36.21% as of 2e7c907

@@            master     #11   diff @@
======================================
  Files           28      43    +15
  Stmts          131     354   +223
  Branches         2       5     +3
  Methods          0       0
======================================
+ Hit             80      88     +8
  Partial          0       0
- Missed          51     266   +215

Review entire Coverage Diff as of 2e7c907

Powered by Codecov. Updated on successful CI builds.


Selection style

selection style for vscode
https://github.com/unocss/unocss/discussions/1834

sorry, i forgot the test, may i exec : pnpm run test:ci, thanks.

sorry, i forgot the test, may i exec : pnpm run test:ci, thanks.
@antfu

Hi，you can chekout this contribute guide of antfu‘s https://github.com/antfu/contribute

Looking forward to it

i fixed the type check.

sorry, i forgot the test, may i exec : pnpm run test:ci, thanks.
@antfu

Hi，you can chekout this contribute guide of antfu‘s https://github.com/antfu/contribute

thank you

@antfu
hi，i found some bugs with media:
expacted:

actually:

i am pushing...


chore(master): release 1.1.3

:robot: I have created a release beep boop
1.1.3 (2024-02-25)
Bug Fixes

mongo-config: configurable auth database (ee35cd4)

Reverts

.github/workflows/docker.yml (f1fceb7)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/Blvckleg/BingusBoingus/releases/tag/v1.1.3 :sunflower:


Port code from CygwinCCompiler to UnixCCompiler

https://github.com/python-pillow/Pillow/issues/7158#issuecomment-1546746716 and
https://github.com/pypa/setuptools/blob/e76db4408e40a5c0a218ef6f652454f69c5aca59/setuptools/_distutils/ccompiler.py#L1055-L1058
suggest that Cygwin uses UnixCCompiler rather than CygwinCCompiler by default, so UnixCCompiler would also need to know how to find shared libraries, import libraries, and static libraries on Cygwin.
Port of #139 to UnixCCompiler

UnixCCompiler.find_library_file now returns library names that are likely to occur on Cygwin, rather than those likely on Linux, which causes the doctest to fail.  Should I fix that with # doctest: ELLIPSIS or something like
>>> result = compiler.find_library_file(dirs, 'abc').replace('\\', '/')
>>> if sys.platform == "cygwin":
...     print(result == "/foo/bar/existing/cygabc.dll")
... else:
...     print(result == "/foo/bar/existing/libabc.dylib")
True

Given Cygwin seems to use UnixCCompiler rather than CygwinCCompiler, should we also drop cygwinccompiler.py?

Given Cygwin seems to use UnixCCompiler rather than CygwinCCompiler, should we also drop cygwinccompiler.py?

#185 similarly feels CygwinCCompiler isn't used, although thinks it should be.

The odd doctests suggest having CygwinCCompiler be a thin wrapper around UnixCCompiler might be the way to go: the only thing I can think to change would be the doctests in this PR, as everything else seems fine.

Oh, heck. Tests on cygwin are currently disabled because ruff fails to install there.

There's some progress on rust-lang/rust#79854; I'm somewhat curious how well the work done to cross-compile from Linux would carry over to cross-compiling from Windows.

I'm somewhat curious how well the work done to cross-compile from Linux would carry over to cross-compiling from Windows.

there wasn't any existing cygwin cross compiler available on mingw or msys, but there is one on fedora linux
i also tried to get a cygwin cross compiler on archlinux: arch-cygwin (unofficial), it uses PKGBUILD (which is the same as what MSYS2 is using), might be useful if someone want to build them and package on msys2

How should I be fixing the doctests to not fail with working code on Cygwin?

I don't see any problem with the doctests. Perhaps they've been resolved.
The only failing test now is the failing coverage test, which is spurious and only there because the coverage is only checked on one platform, so it's ignorable.

How should I be fixing the doctests to not fail with working code on Cygwin?

I don't see any problem with the doctests. Perhaps they've been resolved.

It was a failure on the Cygwin doctests, which I think got disabled because there's no Rust compiler for Cygwin

How should I be fixing the doctests to not fail with working code on Cygwin?

I don't see any problem with the doctests. Perhaps they've been resolved.

It was a failure on the Cygwin doctests, which I think got disabled because there's no Rust compiler for Cygwin

the problem is usually path conversion
https://github.com/thepowersgang/mrustc

you can kinda get rust here on cygwin, but there are many problems with path conversion and cygwin not being linux


Parse files that end without a newline or semicolon

See #166
Unfortunately, it doesn't look straightforward to include this example in the tests.
$ echo -n "print(3)" > nonewline.swift
$ npx tree-sitter parse nonewline.swift # No parse error

Yeah, the test format is probably why I don’t notice something so basic for so long. Thank you for fixing this! Glad the fix was this straightforward.

Yeah, the test format is probably why I don’t notice something so basic for so long. Thank you for fixing this! Glad the fix was this straightforward.


Fix labels unit tests + root displayed as '..

Iteration on #12040
Unit tests should work for MacOS. Couldn't verify it though.
Also root path is displayed as '.'

@hun1ahpu not a good fix, please keep using nativeSep, otherwise you end up with slashes on windows as part separator which is not correct, it should be "". I suggest to fix your tests by using nativeSep in the tests too.

@hun1ahpu did you get my message?

@bpasero Yes, i agree it's a bad fix. Will send a new iteration today-tomorrow.
Thanks.

@hun1ahpu great 👍

@bpasero decided to create 2 separate unit tests. it's not easy to read when using nativeSep.

@hun1ahpu looks good, thanks.


Specific Tools for Jobs

So my idea would be to make it so you can specify which tool is needed to break a certain block or even kill certain mobs. So for example, I could require people to break melon blocks with a wooden hoe.
You could take this even further, by giving different rewards depending on the tool used to kill/break the block. So for example, if a person breaks a block of stone with a wooden pickaxe, they'll get 5 money/points/exp, but if they break a block of stone with a diamond pickaxe, they'll get 15 money/points/exp.
An example of the job config (this example is from the default digger.yml, with the proposed additions):
  Break:
    red_sand:
      tool: "diamond_pickaxe"
      income: 1
      points: 1
      experience: 1

Another config example (this would be an addition to the generalConfig.yml):
  ToolMulti:
    wood:
      MONEY: 0.0
      EXP: 0.0
      POINTS: 0.0
   iron:
      MONEY: 0.0
      EXP: 0.0
      POINTS: 0.0
   gold:
      MONEY: 0.0
      EXP: 0.0
      POINTS: 0.0
   diamond:
      MONEY: 0.0
      EXP: 0.0
      POINTS: 0.0
   netherite:
      MONEY: 0.0
      EXP: 0.0
      POINTS: 0.0

I would add this in the Economy section of the config nearby the generalMulti.
I think this change would allow for further customization within jobs and would make the plugin much better than it already is. I was thinking of adding this myself as the plugin is open-source, but I think this feature would be beneficial to all of the users of the plugin and not just myself.

This is s cool suggestion, I like it !


Vickel: Watch luv(?:[\W_]*+)?trise(?:.com|.org|.net)?

Vickel requests the watch of the watch_keyword luv(?:[\W_]*+)?trise(?:\.com|\.org|\.net)?. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

luv(?:[\W_]*+)?trise(?:\.com|\.org|\.net)? has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


Fix List operation bulk buttons on XS and SM

Fixes #3135
Alternative to #3181
I've inspected the code a little bit, and it looks like our intention was never to show the Export buttons on screens this small.
In the previous version (Backpack 3.x), we used hidden-xs to hide the export buttons on mobile entirely. And it makes sense, why would you hide/show columns when so few columns are visible. I still think that's a good idea.
So this PR:

hides the export buttons on XS
fixes a few print issues (looks like we hadn't replaced Bootstrap 3's hidden print with Bootstrap 4's d-print-none)
centers the bulk buttons on mobile, so it looks a little better
fixes the problem using helper classes in CSS, so that we can push it as a non-breaking change

Here's the end result:

@pxpm & @DanielKimmich - I'd love it if you guys could give it a go, and let me know if you discover something I've missed. Anybody else is welcome to test too, of course. I think I've covered all use cases, but maybe I'm wrong:

test by doing  composer require backpack/crud:"dev-fix-operation-display-on-print-xs-and-sm" and a hard refresh;
go back to normal with composer require backpack/crud:"4.1.*"

Cheers!

A new inspection was created.

The inspection completed: No new issues

I think in the end we can not make everybody happy and have to make some decision.
I personally would like those buttons on page, like you said, we probably can show 1/2 columns not more, it would be great if I can show the columns I want.
Imagine:

id
car
manufacturer
plate
status
owner

My guess is that probably id and car would be visible, but I am looking for status, I even searched by status, and my results are filtered .. if I could just see plate or owner ..
Ofcouse, I can try to turn my phone (hope it's not locked rotation), if so, I must know how to go to settings and enable screen rotation.
I am trying to put myself in some random enduser that happens to use the software that some of our community devs created.
From developer perspective removing the buttons might be a wise decision, I personally have nothing against, I happen to know that I can turn my screen and how to activate screen rotation (yes, I am one of those that has screen rotation locked, that's why that came to mind).
What I notice is that some apps that I use force landscape mode, so I am good with that.
I tried searching about this subject, from my research I found that yes, is possible, and no it's not to do it from html.
For reference:
https://stackoverflow.com/questions/14360581/force-landscape-orientation-mode
http://fuel-efficient-vehicles.org/pwsdb/?p=330
But I am not also sure that forcing landscape is the way to go.
To sum up, I will test this, I am ok removing the buttons, but I still have the concerns I pointed out.
Best,
Pedro

I understand your concerns @pxpm , thank you. Glad we had the talk. I've worked on this some more, and merged the results into https://github.com/Laravel-Backpack/CRUD/pull/3205 so let's close this in favour of that.

A new inspection was created.

Thank you for voicing your concerns @pxpm . I think you're right, it does kind of make sense to pick which columns to show, when you can only show so few columns.
So I've tried to do it. A lot. But no matter what I did, I couldn't keep the export buttons on XS and make them look decent and make it a reasonably non-breaking change (without major changes in list.css). So in the end I've decided to hide it on XS, under the reasoning that people can (and should) switch to landscape to see more functionality. I'm not 100% happy with it either, but we can change this behaviour in 4.2 when we can make more changes to list.css. Until then, it's better to hide the buttons than keep them looking odd.
In addition to the above, I've been able to squeeze into this PR quite a few more improvements to the XS, SM and print user experience. As much as it's possible without considering it a breaking change, I think:

hides the export buttons on XS;
makes the print view cleaner (no buttons or actions);
centers the bulk buttons on mobile, so it looks a little better;
fixes the problem using helper classes in CSS, so that we can push it as a non-breaking change;
changes the default priorities given to columns, so that the Actions column (the one with the Edit/Delete buttons) does NOT show up on XS and SM, since it's usually large and doesn't leave room for an identifiable column to show; by default:

the first column added is given priority 0;
the bulk action columns are given priority 0;
the action column (Edit/Delete) keeps its default priority 1 (which means it's less important than the above);

it does NOT do Laravel-Backpack/ideas#70 yet (does not hide bulk actions on mobile) because I found no reasonably way to do it; so the problem remains that when using bulkActions + responsiveTable the only column that gets shown is the freakin checkbox. I've spent >3 hours trying to fix that alone, no luck. Will try again but until then some fixes are better than no fixes;

The end result, I think, is decent, while still having problem Laravel-Backpack/ideas#70  which hopefully we can and will solve soon:

A new inspection was created.

The inspection completed: 1 new issues, 2 updated code elements


rename wrapped_type to wrapped_T

Welcome to Codecov :tada:
Once merged to your default branch, Codecov will compare your coverage reports and display the results in this comment.
Thanks for integrating Codecov - We've got you covered :open_umbrella:


Update README image with pretty output

Follow on from https://github.com/hugovk/norwegianblue/pull/116.
Use a bigger image than last time.
Put through optipng -o7 -zm1-9:
609x317 pixels, 4x8 bits/pixel, RGB+alpha
Reducing image to 3x8 bits/pixel, RGB
Input IDAT size = 53331 bytes
Input file size = 56760 bytes

Trying:
  zc = 9  zm = 9  zs = 0  f = 0		IDAT size = 34440
  zc = 7  zm = 1  zs = 0  f = 22

Selecting parameters:
  zc = 9  zm = 9  zs = 0  f = 0		IDAT size = 34440

Output IDAT size = 34440 bytes (18891 bytes decrease)
Output file size = 37833 bytes (18927 bytes = 33.35% decrease)

Resized in https://github.com/hugovk/norwegianblue/commit/a90495caded6c33ef1db2625c56445dd1f9e00c4 because, on mobile, GitHub doesn't respect the width and height so the aspect ratio is bad.

Before
	After


node: AssemblyLoadContext.Default.Unloading might not be reliable for thorough disposition

In these lines we set up Unloading events which are executed when user closes neo-cli.
https://github.com/neo-project/neo-node/blob/7aa1e1610dc5c303bde92a1fc8ea3dd8df00dae7/Neo.ConsoleService/ConsoleServiceBase.cs#L273-L279
However there might be problems in this strategy. Unless user chooses to close cli by typing "exit" command, other ways such as directly clicking "close" button will leave only no more than 2 seconds for this event. That means, if disposition actions take longer than this time period, whole process will be shut down before everything disposed gracefully.
Currently there seems nothing that must be disposed before shutting down (even DB), but still this is some vulnerability easy to be neglected.
https://docs.microsoft.com/en-us/dotnet/api/system.appdomain.processexit?f1url=https%3A%2F%2Fmsdn.microsoft.com%2Fquery%2Fdev15.query%3FappId%3DDev15IDEF1%26l%3DEN-US%26k%3Dk(System.AppDomain.ProcessExit)%3Bk(SolutionItemsProject)%3Bk(SolutionItemsProject)%3Bk(SolutionItemsProject)%3Bk(DevLang-csharp)%26rd%3Dtrue&view=net-5.0

Old, if remains, please re-open


Update to bevy 15.0

Created  based on the other pullrequest https://github.com/vladbat00/bevy_egui/pull/309
Tested with all the examples. The UI in my game looks like before moving from 14 to 15.

Seems like our commits were just 5 minutes apart 😄 Already merged #309. Thank you for your work though!


checkver.ps1 - what am I doing wrong?

I have the following manifest:
{
    "version": "0.5.2",
    "description": "The official GitHub command-line client",
    "homepage": "https://github.com/cli/cli",
    "url": "https://github.com/cli/cli/releases/download/v0.5.2/gh_0.5.2_windows_amd64.msi",
    "hash": "fd311a4b964f6dca1ae014f602e8b33816569ecb341ffb9045e63c89b3d7ffcf",
    "bin": "GitHub CLI/gh.exe",
    "checkver": "github",
    "notes": [
        "Changes in this release:",
        "Fix parsing non-GitHub remotes #266",
        "Fix pr create preview in browser flow for Windows #272",
        "Have update notifier and changelog link use the new repo name #264",
        "Minor doc updates #261"
    ]
}

when I run checkver.ps1 -dir path/to/bucket -app gh-cli -u, the output reports that there's an update:
gh-cli: 0.5.3 (scoop version is 0.5.2)

but doesn't actually update the manifest. I assume I'm doing something wrong -- any help appreciated.

"checkver": "github",

this will retrieve the latest release from the release page - https://github.com/cli/cli/releases.
but you didn't provide the autoupdate field for auto-updating.

thanks -- please add to the wiki / docs? I was following those and being well confused :/

https://github.com/lukesampson/scoop/wiki/App-Manifest-Autoupdate#adding-autoupdate-to-a-manifest

Obsolete.


chore(java): bump arrow to 18.0.0

Update arrow dependency from 15.0.0 to 18.0.0.
As Apache Arrow now requires Java 11, Apache Arrow ADBC also now requires Java 11.
Update Apache Parent pom to version 33 and take advantage of Java 9+ support.
Clean up pom.xml files to remove duplicate or conflicting plugin version definition and/or configuration
Update FlightSQL tests to use the FlightSQL Junit 5 extension.
Update build and dev scripts, and documentation

Thanks! I'll review when I get back next week

Note that it appears Java verification fails

I do see multiple errors in C++ code with the following message though:
In file included from /adbc/c/driver/framework/utility.cc:24:
/adbc/c/vendor/nanoarrow/nanoarrow.hpp:95:35: error: identifier '_asv' preceded by whitespace in a literal operator declaration is deprecated [-Werror,-Wdeprecated-literal-operator]
   95 | inline ArrowStringView operator"" _asv(const char* data, std::size_t size_bytes) {
      |                        ~~~~~~~~~~~^~~~
      |                        operator""_asv
In file included from /adbc/c/driver/framework/objects.cc:22:
/adbc/c/vendor/nanoarrow/nanoarrow.hpp:95:35: error: identifier '_asv' preceded by whitespace in a literal operator declaration is deprecated [-Werror,-Wdeprecated-literal-operator]
   95 | inline ArrowStringView operator"" _asv(const char* data, std::size_t size_bytes) {
      |                        ~~~~~~~~~~~^~~~
      |                        operator""_asv
1 error generated.

and also
/Users/runner/work/arrow-adbc/arrow-adbc/c/driver/flightsql/sqlite_flightsql_test.cc:124:15: error: 'catalog' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
  124 |   std::string catalog() const { return "main"; }
      |               ^
/Users/runner/work/arrow-adbc/arrow-adbc/c/validation/adbc_validation.h:248:23: note: overridden virtual function is here
  248 |   virtual std::string catalog() const { return ""; }
      |                       ^
1 error generated.

it may be caused by my change but the cause is unclear to me as why. I'll try to rebase my change in case
There's also one maven-assembly-plugin error probably caused by the apache parent update (will debug and fix)

The C++ errors aren't related, there are separate fixes for those

I would like to do a release soon so I may take the liberty of upgrading Arrow separately (without the parent POM change) in the meantime. Thanks for the help!

I think if you rebase, the CI errors should mostly go away!

Pushed new rebase


Health Checker - Check certificate Secure Hash Algorithm (SHA) and show a warning for SHA-1

We should check the certificate Secure Hash Algorithm (SHA) in the certificate check and highlight if SHA-1 was used (it's considered weak).

@hmsc @hmstorecenter

Implemented with v<IP_ADDRESS>5

Whos is msft


Slow Execution of 201.sql

Hello,
I'm trying to run this and when I try to execute the runStudy function the execution gets stuck trying to run 201.sql.  The code is running but it's running for 3+ hours and finally times out.  It looks like the query in some places is trying to join measurement to measurement on person_id to determine a change in value which takes a really long time.  Other Sql platforms might optimize things by filtering the joins from the where clause BigQuery, our platform, seems to do things very literally. If I edit the query text to move some of the tables into cte expressions to filter them down before the join, is that OK? Here's an example of what I mean
Original (takes hours):
insert into  omop_covid19_cohort.e5avqxzfmeasurements
  --1.2 LOINC mg/dl
select m2.person_id,
       m2.measurement_id                   as event_id,
       m2.measurement_date                as start_date,
       DATE_ADD(IF(SAFE_CAST(m2.measurement_date  AS DATE) IS NULL,PARSE_DATE('%Y%m%d', cast(m2.measurement_date  AS STRING)),SAFE_CAST(m2.measurement_date  AS DATE)), interval 1 DAY) as end_date,
       m2.measurement_concept_id          as target_concept_id,
       m2.visit_occurrence_id,
       m2.measurement_date                as sort_date
from omop_covid19.measurement m
       join omop_covid19.measurement m2
            on m.person_id = m2.person_id and DATE_DIFF(IF(SAFE_CAST(m2.measurement_date  AS DATE) IS NULL,PARSE_DATE('%Y%m%d', cast(m2.measurement_date  AS STRING)),SAFE_CAST(m2.measurement_date  AS DATE)), IF(SAFE_CAST(m.measurement_date  AS DATE) IS NULL,PARSE_DATE('%Y%m%d', cast(m.measurement_date  AS STRING)),SAFE_CAST(m.measurement_date  AS DATE)), DAY) between 0 and 2
       join omop_covid19_cohort.e5avqxzfcodesets codesets on (m.measurement_concept_id = codesets.concept_id and codesets.codeset_id = 7)
       join omop_covid19_cohort.e5avqxzfcodesets codesets2 on (m2.measurement_concept_id = codesets2.concept_id and codesets2.codeset_id = 7)
where m2.value_as_number > 0
  and m.value_as_number > 0
  and (m2.value_as_number - m.value_as_number) > 0.3

Modified (less than a minute):
insert into  omop_covid19_cohort.e5avqxzfmeasurements
  --1.2 LOINC mg/dl
with cte_measurements as (
   select * from omop_covid19.measurement m
   join omop_covid19_cohort.e5avqxzfcodesets codesets on (m.measurement_concept_id = codesets.concept_id and
   codesets.codeset_id = 7)
   where m.value_as_number > 0
)
select m2.person_id,
       m2.measurement_id                   as event_id,
       m2.measurement_date                as start_date,
       DATE_ADD(IF(SAFE_CAST(m2.measurement_date  AS DATE) IS NULL,PARSE_DATE('%Y%m%d', cast(m2.measurement_date  AS STRING)),SAFE_CAST(m2.measurement_date  AS DATE)), interval 1 DAY) as end_date,
       m2.measurement_concept_id          as target_concept_id,
       m2.visit_occurrence_id,
       m2.measurement_date                as sort_date
from cte_measurements m
       join omop_covid19.measurement m2
            on m.person_id = m2.person_id and DATE_DIFF(IF(SAFE_CAST(m2.measurement_date  AS DATE) IS NULL,PARSE_DATE('%Y%m%d', cast(m2.measurement_date  AS STRING)),SAFE_CAST(m2.measurement_date  AS DATE)), IF(SAFE_CAST(m.measurement_date  AS DATE) IS NULL,PARSE_DATE('%Y%m%d', cast(m.measurement_date  AS STRING)),SAFE_CAST(m.measurement_date  AS DATE)), DAY) between 0 and 2
       join omop_covid19_cohort.e5avqxzfcodesets codesets2 on (m2.measurement_concept_id = codesets2.concept_id and codesets2.codeset_id = 7)
where m2.value_as_number > 0
  and (m2.value_as_number - m.value_as_number) > 0.3

Hi @CartWill - generally speaking we want to keep the study code locked so users are only running the package vs. making modifications. Otherwise we run the risk of not being able to reproduce the results.
One question: does the cohort ever complete using the original code? The default behavior in this study package is to generate the cohorts 1 time and it will only generate the cohort if the SQL code changes. So, if cohort 201 did finish, it would by-pass that generation step again.

No it did not finish.  I increased the timeout in the connection string but that did not help.

@anthonysena Cohort 201 (Acute Kidney Injury) was custom SQL not an ATLAS generated cohort. I'm open to a collaborator contributed optimization.

@kmkostka - good catch on the AKI definition! @CartWill - sorry if I gave the impression that we would not welcome a contribution around optimizing this cohort.
Looking at the SQL you provided: Using a CTE with an INSERT statement will not work across DBMS platforms unfortunately. One thought: could you put the results of the CTE into a TEMP table (call it #measurement_subset) and then use that for the remaining queries? Also, looking at the code that populates the #measurement table, we might be able to further optimize this for BigQuery by using a UNION to do a single insert into #measurement vs individual inserts. Let me know what you think and happy to collaborate on the code change if helpful.

@anthonysena yeah that would probably work.  SqlRender and temp tables in BigQuery are messy so I try to avoid them if at all possible.
One thing that might work too is to just move the measurements into sub-queries where the filtering concepts are moved up into the sub query.  That's probably more compatible across partners than the cte.  Something like this:
insert into  omop_covid19_cohort.e5avqxzfmeasurements
  --1.2 LOINC mg/dl
select m2.person_id,
       m2.measurement_id                   as event_id,
       m2.measurement_date                as start_date,
       DATE_ADD(IF(SAFE_CAST(m2.measurement_date  AS DATE) IS NULL,PARSE_DATE('%Y%m%d', cast(m2.measurement_date  AS STRING)),SAFE_CAST(m2.measurement_date  AS DATE)), interval 1 DAY) as end_date,
       m2.measurement_concept_id          as target_concept_id,
       m2.visit_occurrence_id,
       m2.measurement_date                as sort_date
from
	(
	  SELECT *
	  FROM
		omop_covid19.measurement m
	  join omop_covid19_cohort.e5avqxzfcodesets codesets
		on (m.measurement_concept_id = codesets.concept_id and codesets.codeset_id = 7)
	) m
join (
	  SELECT *
	  FROM
		omop_covid19.measurement m2
	  join omop_covid19_cohort.e5avqxzfcodesets codesets2
		on (m2.measurement_concept_id = codesets2.concept_id and codesets2.codeset_id = 7)
	) m2
            on m.person_id = m2.person_id and DATE_DIFF(IF(SAFE_CAST(m2.measurement_date  AS DATE) IS NULL,PARSE_DATE('%Y%m%d', cast(m2.measurement_date  AS STRING)),SAFE_CAST(m2.measurement_date  AS DATE)), IF(SAFE_CAST(m.measurement_date  AS DATE) IS NULL,PARSE_DATE('%Y%m%d', cast(m.measurement_date  AS STRING)),SAFE_CAST(m.measurement_date  AS DATE)), DAY) between 0 and 2
where m2.value_as_number > 0
  and m.value_as_number > 0
  and (m2.value_as_number - m.value_as_number) > 0.3

@CartWill sorry this issue has aged but it appears that you were able to resolve this issue.


EditableText blocked PointerEvent after dismissed in IOS with apple pencil supported

Steps to reproduce （only on ios)
the follow has fullscreen GestureDetector, which should be able get tap wherever you touch the screen;  but with the following operation, the red are in center will stop response to tap;
reproduce step

tap red area => the area will change to green to show EditableText;
click green area to focus the EditableText, then keyboard is displayed on the screen;
input one character (Chinese character) and then fold the keyboard with  bottom-right key on keyboard
click white area again to dismiss the EditableText;
click the red area, it should change to green,  but it is still red with keyboard popup

note: in step 3, you should input Chinese character (maybe CJK character also reproduce able)
Expected results
int step 5, it should change to green;
Actual results
nothing happened
Code sample
Code sample
import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
        useMaterial3: true,
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({super.key, required this.title});
  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      resizeToAvoidBottomInset: false,
      appBar: AppBar(
        backgroundColor: Theme.of(context).colorScheme.inversePrimary,
        title: Text(widget.title),
      ),
      body:const  Center(
        child: MyWidget(),
      ),
    );
  }
}

class MyWidget extends StatefulWidget {
  const MyWidget({super.key});

  @override
  State<MyWidget> createState() => _MyWidgetState();
}

class _MyWidgetState extends State<MyWidget> {
  final TextEditingController _controller = TextEditingController();
  bool showText = false;
  @override
  Widget build(BuildContext context) {
    var text = showText
        ? ColoredBox(
            color: Colors.green,
            child: EditableText(
              maxLines: null,
              minLines: 2,
              focusNode: FocusNode(),
              controller: _controller,
              style: const TextStyle(
                fontSize: 20,
                color: Colors.black,
              ),
              cursorColor: Colors.black,
              backgroundCursorColor: Colors.black,
            ),
          )
        : null;
    return GestureDetector(
      behavior: HitTestBehavior.opaque,
      onTap: () {
        setState(() {
          showText = !showText;
        });
      },
      child: SizedBox.expand(
        child: Center(
          child: Container(
            width: 400,
            height: 400,
            color: Colors.red,
            child: text,
          ),
        ),
      ),
    );
  }
}

Screenshots or Video

Screenshots / Video demonstration
[Upload media here]

Logs
Logs
[Paste your logs here]

Flutter Doctor output
version of flutter  3.13 and 3.16 . 3.10 is ok;

it is reproducible with ipad that can use pencil but don't need to be connected;

TextFeild also have such problem with input of chinese character;

and following errors are given when tap many times
API error: <_UIKBCompatInputView: 0x143d481e0; frame = (0 0; 0 0); layer = <CALayer: 0x2809fb4c0>> returned 0 width, assuming UIViewNoIntrinsicMetric
API error: <_UIKBCompatInputView: 0x143d481e0; frame = (0 0; 0 0); layer = <CALayer: 0x2809fb4c0>> returned 0 width, assuming UIViewNoIntrinsicMetric
[LayoutConstraints] Unable to simultaneously satisfy constraints.
        Probably at least one of the constraints in the following list is one you don't want.
        Try this:
                (1) look at each constraint and try to figure out which you don't expect;
                (2) find the code that added the unwanted constraint or constraints and fix it.
(
    "<NSLayoutConstraint:0x282a81630 'assistantHeight' TUISystemInputAssistantView:0x143e51950.height == 55   (active)>",
    "<NSLayoutConstraint:0x282ab79d0 'assistantView.bottom' TUISystemInputAssistantView:0x143e51950.bottom == _UIKBCompatInputView:0x143d481e0.top   (active)>",
    "<NSLayoutConstraint:0x282ab4140 'assistantView.top' V:|-(0)-[TUISystemInputAssistantView:0x143e51950]   (active, names: '|':UIInputSetHostView:0x143d576e0 )>",
    "<NSLayoutConstraint:0x282a96300 'inputView.top' V:|-(0)-[_UIKBCompatInputView:0x143d481e0]   (active, names: '|':UIInputSetHostView:0x143d576e0 )>"
)

Will attempt to recover by breaking constraint
<NSLayoutConstraint:0x282ab79d0 'assistantView.bottom' TUISystemInputAssistantView:0x143e51950.bottom == _UIKBCompatInputView:0x143d481e0.top   (active)>

Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKitCore/UIView.h> may also be helpful.
No windows have a root view controller, cannot save application state

Hi @wanjm, what iPad are you testing on? What version of iOS is it running and what generation of apple pencil does it use?
I tested this on my iPad Air M1 running iOS 17.2 with a 2nd gen apple pencil and I can't seem to reproduce the issue.
Also, what version of flutter specifically are you using? If you could provide any more details that could help us reproduce, that would be appreciated.
Please file new issues regarding the comments I have hidden as off topic so that they can be tracked separately. Please check for duplicates before filing the issues.
Thank you

flutter 3.13.9 and 3.16.9 and master (4601341b50f22f3e840ad8a6336cf4ffa4ca9804)
iPad 15.2 (7th generation) and iPad 16.5.1(6th generation)
just use the ipad with apple pencil support, but when test , you should use you hand instead of apple pencil, and you need to use input Chinese character;  other character will not trigger such problem;

Hi @wanjm, I just tried again but still can't repro. Kindly see the video below and let me know if I'm missing anything.
Thank you
https://github.com/flutter/flutter/assets/88313112/cfcfeb4b-abe5-47a6-a13d-a6ef543226e3

you need to use "right-bottom" key on keyboard to fold the keyboard, from your mp4, it seems step 3 is different; could you please check you do as i asked;

tap red area => the area will change to green to show EditableText; (green without active EditableText)
click green area to focus the EditableText, then keyboard is displayed on the screen; (now EditableText is active and cursor is shine)
input one character (Chinese character) and then fold the keyboard with bottom-right key on keyboard, (** now you can see green area but EditableText is not active**);
click white area again to dismiss the EditableText; (change to red);
click the red area, it should change to green, but it is still red with keyboard popup;

https://github.com/flutter/flutter/assets/3118573/4824bd58-87de-434f-8125-26be280896a6
please see my video

maybe you can try https://github.com/flutter/flutter/issues/142437 @danagbemava-nc

@danagbemava-nc
please use change your input method to Simplified Chinese instead of Traditional Chinese;
I tested that Tradition Chinese can't reproduce either;

Hi @wanjm, I am using the Simplified keyboard and I am also using the button that dismissed the keyboard on the ipad (not the done button). See the recording below
https://github.com/flutter/flutter/assets/88313112/b44e1eeb-9086-41b2-826e-752c2674f6b8

@danagbemava-nc  could you please find a pad with old version;
I find another 16.6.1 also have such problem;
many of our users are using 16.6 and below. through 17 has no such issue, I still need to fix it;

@danagbemava-nc  I tested it on 17.1, there is no such problem;
could you please find ipad of 15 or 16, and try again.
thanks;

@wanjm I check this issue on a simulator (iPad Pro, 12.9 inch, 5h gen, iOS 16.4 - support Apple Pencil) but don't see the issue. My result is similar to Daniel's demo above.
This could be a device-specific issue. Could you try upgrading to the latest master channel and retry?
flutter channel master
flutter upgrade

I have tested on master, there is such problem;
I don't think this is device-specific issue, for I have found 3 pad, all have this problem;

I just checked this on a physical device (iPad Air 5) but still can't reproduce the issue. Labeling the issue for further information. If you can find any clues, please write in comments.

Labelling this as p3 due to the difficulty to reproduce and how odd this case is. Will change priority if it turns out to be more common.

I just checked this on a physical device (iPad Air 5) but still can't reproduce the issue. Labeling the issue for further information. If you can find any clues, please write in comments.

could you please record a video, so that i can have a check;

Labelling this as p3 due to the difficulty to reproduce and how odd this case is. Will change priority if it turns out to be more common.

I don't think it is difficult to reproduce as  https://github.com/flutter/flutter/issues/138395 has found this three month before;
we just need find a physical device and the right version;

could you please record a video, so that i can have a check;

https://github.com/flutter/flutter/assets/104349824/8ef4d03c-4060-47df-bcc3-b10047d9c053

could you please record a video, so that i can have a check;

RPReplay_Final1707194211.MP4
what is the version of os . it only reproduce with ios 15.x and 16.x ; 17.x has no such problem;

what is the version of os . it only reproduce with ios 15.x and 16.x ; 17.x has no such problem;

It's iPadOS 17.2 (sorry I didn't notice your question, thought it's a quote only)

or any suggestion for me how to avoid this.


GSD Request

--- GSD JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from v5.7 to before v5.10.90",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5f29458b77d51c104554575b73184c243930aa87",
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=73665165b64a8f3c5b3534009a69be55bb744f05"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "5f29458b77d51c104554575b73184c243930aa87",
      "note": "introduced"
    },
    {
      "type": "commit",
      "value": "73665165b64a8f3c5b3534009a69be55bb744f05",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "net/mlx5e: Wrap the tx reporter dump callback to extract the sq\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.10.90 by commit 73665165b64a8f3c5b3534009a69be55bb744f05, it was introduced in version v5.7 by commit 5f29458b77d51c104554575b73184c243930aa87. For more details please see the references link."
}
--- GSD JSON ---

This issue has been assigned GSD-2022-1000045


Any update plan for Spark 2.4?

Hi,
There are several API changes in Spark 2.4 which break this package. Do you have a plan for version update?
thanks,
Richard

It has been already updated to spark 2.4.0. Check the latest codes in the master branch or the corresponding release tag.

That's great! Thanks.
Would it be possible if you can document how to install the package and use it in Spark? That would help a lot for users with a different level of experience with Scala/Spark. Currently, it only includes how to import the package and call the APIs.
Thanks for your work!
Richard

That depends on what you gonna to do with this package. You can just install this package into your maven repository and use it in other projects. Or you can put the package jar into your spark class lib and call it on spark client.


Upgrade to QuickJS 2021-03-27

Closes #111

do we realy still need that stack-overflow-signed patch? that issue was caused when you called something from a lower stack point.
I had that issue when i had an init_rt method which first did a println, then another method which used the rt but did it as first action.
I'm guessing more people had issues like that and thats why fabrice added JS_UpdateStackTop() so you can "reset" the top most stack level..


Unable to use - as positional argument

Working on an app that should be able to operate on either STDIN or a file, I was trying to use - as the file name to indicate STDIN (as is the convention used in the app I'm porting, and elsewhere), but that causes an index out of bounds panic.
% ./target/debug/signing-participants -
thread '<main>' panicked at 'index out of bounds: the len is 0 but the index is 0', /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-mac/build/src/libcore/str/mod.rs:1685

So, I thought I'd try the common -- to indicate "only positional arguments follow", but that fails as well but much more gracefully.
% ./target/debug/signing-participants -- -
Argument -- isn't valid
USAGE:
	signing-participants [FLAGS] [OPTIONS] <INPUT>
For more information try --help

Ok, I think I've got an idea of how I can make this work. I was using - and -- to narrow down the searches to "flag" or "option", but I could do a check where if - or -- are the only characters in the argument, it'll parse as positional. I'll work on it tomorrow and post back with how it goes.
Thanks for the heads up!

Turned out to be an easier fix than anticipated. If it's still not fixed just let me know.
Note that -- still isn't implemented, that's on the TODO list.

0.4.4 works with - as a positional argument for me now.  Thanks for the quick response!  I'll keep an eye on #10 as that'll be nice to have, too.


Support PKCS8 for RSA keys

My software requires PKCS8 format rsa keys, but it seems this tool only can output PKCS1 format
Want a spec to choose the format

Hey @mhoshi-vm We had a discussion about this, and we are okay with the above enhancement.
Would you like to raise a PR making the change? We will prioritise a review.