Zen mode bugs?

VSCode Version: 1.8
OS Version: linux Mint

Hello,
Was just glad about the new zen mode when noticed 2 possible bugs.
First bug: file focus is reset
Steps to reproduce:

open some files from project
open key unofficial file (such as Preferences->User settings, or something similar)
focus on the settings.json
zen mode triggered
2x Esc
the focus jumps to another file

Note, I noticed that after some time (or maybe after I have done something), this couldn't be reproduce anymore until restarted.
Edited: Same goes for toggle sidebar (the problem is probably from here). If I focus on the settings.json and then hit toggle sidebar ... :boom:,  jumps to the first non settings.json tab
Second bug: stuck in zen :D
Steps to reproduce:

i set the shortcut for zen as F11
hold F11 - yeah... took like 30s and got stuck in something like full screen (no window or menu bar, just sidebar and editor

First thing is already covered in https://github.com/Microsoft/vscode/issues/16616

...and #16616 is fixed 💥

Any news regarding the second bug? If possible, can I take this task and fix it?

@dfroze we frist have to try to reproduce that issue - let me do that right now
If you are looking for tasks to help with a good idea is to go through our open issues and search for a tag 'help wanted' - https://github.com/Microsoft/vscode/labels/help wanted

Tried reproducing the second issue -> by holding F11 you are basically juming in and out of zen mode all the time but I still could not get into a broken state like you describe.
Even if the bug could be reproduced it is very random and would not happen in a real life scenario - why would a user hold F11 for 30 seconds?
Anywas closing as designed, does not repro


Macro commands should take care of different user name

If your username is different from "pi", you get the error
// sh: 0: Can't open /home/pi/Gab3d-Klipper-Utilities/backup_config.sh
when launching the macro

thanks fixing it

Fixed in v0.0.23

Tested and working perfectly, thank you!


Unable to Install on Mac OS

When trying to install, I get the following error:
Compiling /tmp/easy_install-9FmuOc/h5py-2.5.0/h5py/h5o.pyx
Compiling /tmp/easy_install-9FmuOc/h5py-2.5.0/h5py/h5ds.pyx
Compiling /tmp/easy_install-9FmuOc/h5py-2.5.0/h5py/h5ac.pyx
In file included from /tmp/easy_install-9FmuOc/h5py-2.5.0/h5py/defs.c:252:
/tmp/easy_install-9FmuOc/h5py-2.5.0/h5py/api_compat.h:27:10: fatal error:
'hdf5.h' file not found
#include "hdf5.h"
^
1 error generated.
error: Setup script exited with error: command 'cc' failed with exit status 1

try brew install h5py

I installed hdf5 from source, installed h5py (pip install h5py).
reinstalled python, numpy, scipy...etc. and then it finally worked.


[PUI] Plugin settings UI

Adds functionality to render custom "configuration" UI elements for a plugin, in the new interface.
Expands existing functionality similar to how custom panels are implemented.
The plugin can dynamically render content to this window:

And another example, from the wireviz plugin:

@wolflu05 I'm all for refactoring / making this more generic. Maybe we can do that on next feature integration, or as a separate PR?

Q: Why is this removed?

@matmair I have slightly tweaked the mechanism for switching between "user settings" / "system settings" / "admin section" - the functionality is still there but visually cleaned up a bit

Playwright testing has now been added too


Add initial RFC document

Motivation and Context
Design for upcoming implementation of endpoints 2.0
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Rendered


HIVE-24467:Task.removeFromChildrenTasks should be thread safe for par…

@maheshk114 Please review this pr. Thanks.


[Feature Request] Request to Document Behaviour Change in Unauthenticated Request Handling in OpenSearch 2.11.0 or later

Is your feature request related to a problem? Please describe
In OpenSearch 2.11.0, there was a change in how unauthenticated requests are handled. Prior to this release, unauthenticated requests did not count towards API rate limiting. After this release, they do count, so making too many unauthenticated requests will result in the IP being locked out for a period.
This can have a negative impact if:

The user has a health check that does not use authentication.
The user's health check comes from the same IP as their application server.

Under these circumstances, the user's application will be prevented from connecting to OpenSearch after upgrading to 2.11.0 or later.
To my understanding, this was implemented in #3411. The change was mentioned in release notes, but this does not explain the impact:

Refactors reRequestAuthentication to call notifyIpAuthFailureListener before sending the response to the channel.

Multiple clusters that we manage have been impacted by this behaviour change so far. We expect to see more instances of this as we upgrade additional clusters from 1.x.
Describe the solution you'd like
I would like to request that this behaviour change be documented on the OpenSearch breaking changes page to ensure users are aware of its impact.
Related component
Other
Describe alternatives you've considered
I can't think of another good solution. I am not asking to revert the change - to my understanding, it was made for valid security reasons.
Additional context
Steps to reproduce this behaviour change
Old Behaviour
# Run OpenSearch 2.10.0 using docker compose file and security config file (yml file contents mentioned at the end)
#create a directory that contains both docker-compose.yml and config.yml files
#expected Directory Structure:
# |-opensearch-docker-2-10
# | |-docker-compose.yml
# | |-config.yml

docker-compose up -d

# Wait for it to come up
# Confirm we can connect with an authenticated user
docker ps
docker logs <opensearch-container-id>
curl --insecure https://localhost:9200/ -u admin:admin

# Make several unauthenticated requests
for i in {1..15}; do curl -v "https://localhost:9200" --insecure; done

# An authenticated user from the same IP is still able to connect
curl --insecure https://localhost:9200/ -u admin:admin

# We don't see any message about IP being blocked
docker logs <opensearch-container-id>

# Stop and delete the containers
docker-compose down -v

New Behaviour
#Run OpenSearch 2.11.0 using docker compose file and security config file (yml file contents mentioned at the end)
#create a directory that contains both docker-compose.yml and config.yml files
#expected directory structure:
# |-opensearch-docker-2-11
# | |-docker-compose.yml
# | |-config.yml

docker-compose up -d

# Wait for it to come up
# Confirm we can connect with an authenticated user
docker ps
docker logs <opensearch-container-id>
curl --insecure https://localhost:9200/ -u admin:admin

# Make several unauthenticated requests
for i in {1..15}; do curl -v "https://localhost:9200" --insecure; done

# An authenticated user from the same IP is not able to connect. It fails with an error.
curl --insecure https://localhost:9200/ -u admin:admin

{
  "error": {
    "status": "error",
    "reason": "Authentication finally failed"
  }
}

# We can see message about IP being blocked in `docker logs <opensearch-container-id>`

[2024-11-14T15:12:04,779][INFO ][o.o.s.a.b.HeapBasedClientBlockRegistry] [opensearch-node1] Blocking /<IP_ADDRESS>

# Stop and delete the containers
docker-compose down -v

Security config yml file (the same file used in both 2.10.0 and 2.11.0)
#create the config.yml file (The file is the same as present here, just uncomment the "auth_failure_listeners" section)
---

# This is the main OpenSearch Security configuration file where authentication
# and authorization is defined.
#
# You need to configure at least one authentication domain in the authc of this file.
# An authentication domain is responsible for extracting the user credentials from
# the request and for validating them against an authentication backend like Active Directory for example.
#
# If more than one authentication domain is configured the first one which succeeds wins.
# If all authentication domains fail then the request is unauthenticated.
# In this case an exception is thrown and/or the HTTP status is set to 401.
#
# After authentication authorization (authz) will be applied. There can be zero or more authorizers which collect
# the roles from a given backend for the authenticated user.
#
# Both, authc and auth can be enabled/disabled separately for REST and TRANSPORT layer. Default is true for both.
#        http_enabled: true
#        transport_enabled: true
#
# For HTTP it is possible to allow anonymous authentication. If that is the case then the HTTP authenticators try to
# find user credentials in the HTTP request. If credentials are found then the user gets regularly authenticated.
# If none can be found the user will be authenticated as an "anonymous" user. This user has always the username "anonymous"
# and one role named "anonymous_backendrole".
# If you enable anonymous authentication all HTTP authenticators will not challenge.
#
#
# Note: If you define more than one HTTP authenticators make sure to put non-challenging authenticators like "proxy" or "clientcert"
# first and the challenging one last.
# Because it's not possible to challenge a client with two different authentication methods (for example
# Kerberos and Basic) only one can have the challenge flag set to true. You can cope with this situation
# by using pre-authentication, e.g. sending a HTTP Basic authentication header in the request.
#
# Default value of the challenge flag is true.
#
#
# HTTP
#   basic (challenging)
#   proxy (not challenging, needs xff)
#   kerberos (challenging)
#   clientcert (not challenging, needs https)
#   jwt (not challenging)
#   host (not challenging) #DEPRECATED, will be removed in a future version.
#                          host based authentication is configurable in roles_mapping

# Authc
#   internal
#   noop
#   ldap

# Authz
#   ldap
#   noop

_meta:
  type: "config"
  config_version: 2

config:
  dynamic:
    # Set filtered_alias_mode to 'disallow' to forbid more than 2 filtered aliases per index
    # Set filtered_alias_mode to 'warn' to allow more than 2 filtered aliases per index but warns about it (default)
    # Set filtered_alias_mode to 'nowarn' to allow more than 2 filtered aliases per index silently
    #filtered_alias_mode: warn
    #do_not_fail_on_forbidden: false
    #kibana:
    # Kibana multitenancy
    #multitenancy_enabled: true
    #private_tenant_enabled: true
    #default_tenant: ""
    #server_username: kibanaserver
    #index: '.kibana'
    http:
      anonymous_auth_enabled: false
      xff:
        enabled: false
        internalProxies: '192\.168\.0\.10|192\.168\.0\.11' # regex pattern
        #internalProxies: '.*' # trust all internal proxies, regex pattern
        #remoteIpHeader:  'x-forwarded-for'
        ###### see https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html for regex help
        ###### more information about XFF https://en.wikipedia.org/wiki/X-Forwarded-For
        ###### and here https://tools.ietf.org/html/rfc7239
        ###### and https://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Remote_IP_Valve
    authc:
      kerberos_auth_domain:
        http_enabled: false
        transport_enabled: false
        order: 6
        http_authenticator:
          type: kerberos
          challenge: true
          config:
            # If true a lot of kerberos/security related debugging output will be logged to standard out
            krb_debug: false
            # If true then the realm will be stripped from the user name
            strip_realm_from_principal: true
        authentication_backend:
          type: noop
      basic_internal_auth_domain:
        description: "Authenticate via HTTP Basic against internal users database"
        http_enabled: true
        transport_enabled: true
        order: 4
        http_authenticator:
          type: basic
          challenge: true
        authentication_backend:
          type: intern
      proxy_auth_domain:
        description: "Authenticate via proxy"
        http_enabled: false
        transport_enabled: false
        order: 3
        http_authenticator:
          type: proxy
          challenge: false
          config:
            user_header: "x-proxy-user"
            roles_header: "x-proxy-roles"
        authentication_backend:
          type: noop
      jwt_auth_domain:
        description: "Authenticate via Json Web Token"
        http_enabled: false
        transport_enabled: false
        order: 0
        http_authenticator:
          type: jwt
          challenge: false
          config:
            signing_key: "base64 encoded HMAC key or public RSA/ECDSA pem key"
            jwt_header: "Authorization"
            jwt_url_parameter: null
            jwt_clock_skew_tolerance_seconds: 30
            roles_key: null
            subject_key: null
        authentication_backend:
          type: noop
      clientcert_auth_domain:
        description: "Authenticate via SSL client certificates"
        http_enabled: false
        transport_enabled: false
        order: 2
        http_authenticator:
          type: clientcert
          config:
            username_attribute: cn #optional, if omitted DN becomes username
          challenge: false
        authentication_backend:
          type: noop
      ldap:
        description: "Authenticate via LDAP or Active Directory"
        http_enabled: false
        transport_enabled: false
        order: 5
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          # LDAP authentication backend (authenticate users against a LDAP or Active Directory)
          type: ldap
          config:
            # enable ldaps
            enable_ssl: false
            # enable start tls, enable_ssl should be false
            enable_start_tls: false
            # send client certificate
            enable_ssl_client_auth: false
            # verify ldap hostname
            verify_hostnames: true
            hosts:
            - localhost:8389
            bind_dn: null
            password: null
            userbase: 'ou=people,dc=example,dc=com'
            # Filter to search for users (currently in the whole subtree beneath userbase)
            # {0} is substituted with the username
            usersearch: '(sAMAccountName={0})'
            # Use this attribute from the user as username (if not set then DN is used)
            username_attribute: null
    authz:
      roles_from_myldap:
        description: "Authorize via LDAP or Active Directory"
        http_enabled: false
        transport_enabled: false
        authorization_backend:
          # LDAP authorization backend (gather roles from a LDAP or Active Directory, you have to configure the above LDAP authentication backend settings too)
          type: ldap
          config:
            # enable ldaps
            enable_ssl: false
            # enable start tls, enable_ssl should be false
            enable_start_tls: false
            # send client certificate
            enable_ssl_client_auth: false
            # verify ldap hostname
            verify_hostnames: true
            hosts:
            - localhost:8389
            bind_dn: null
            password: null
            rolebase: 'ou=groups,dc=example,dc=com'
            # Filter to search for roles (currently in the whole subtree beneath rolebase)
            # {0} is substituted with the DN of the user
            # {1} is substituted with the username
            # {2} is substituted with an attribute value from user's directory entry, of the authenticated user. Use userroleattribute to specify the name of the attribute
            rolesearch: '(member={0})'
            # Specify the name of the attribute which value should be substituted with {2} above
            userroleattribute: null
            # Roles as an attribute of the user entry
            userrolename: disabled
            #userrolename: memberOf
            # The attribute in a role entry containing the name of that role, Default is "name".
            # Can also be "dn" to use the full DN as rolename.
            rolename: cn
            # Resolve nested roles transitive (roles which are members of other roles and so on ...)
            resolve_nested_roles: true
            userbase: 'ou=people,dc=example,dc=com'
            # Filter to search for users (currently in the whole subtree beneath userbase)
            # {0} is substituted with the username
            usersearch: '(uid={0})'
            # Skip users matching a user name, a wildcard or a regex pattern
            #skip_users:
            #  - 'cn=Michael Jackson,ou*people,o=TEST'
            #  - '/\S*/'
      roles_from_another_ldap:
        description: "Authorize via another Active Directory"
        http_enabled: false
        transport_enabled: false
        authorization_backend:
          type: ldap
          #config goes here ...
    auth_failure_listeners:
       ip_rate_limiting:
         type: ip
         allowed_tries: 10
         time_window_seconds: 3600
         block_expiry_seconds: 600
         max_blocked_clients: 100000
         max_tracked_clients: 100000
       internal_authentication_backend_limiting:
         type: username
         authentication_backend: intern
         allowed_tries: 10
         time_window_seconds: 3600
         block_expiry_seconds: 600
         max_blocked_clients: 100000
         max_tracked_clients: 100000

docker-compose.yml file (for version 2.10.0)
version: '3'
services:
  opensearch-node1: # This is also the hostname of the container within the Docker network (i.e. https://opensearch-node1/)
    image: opensearchproject/opensearch:2.10.0 # Specifying the latest available image - modify if you want a specific version
    container_name: opensearch-node1
    environment:
      - cluster.name=opensearch-cluster # Name the cluster
      - node.name=opensearch-node1 # Name the node that will run in this container
      - discovery.seed_hosts=opensearch-node1,opensearch-node2 # Nodes to look for when discovering the cluster
      - cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2 # Nodes eligible to serve as cluster manager
      - bootstrap.memory_lock=true # Disable JVM heap memory swapping
      - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # Set min and max JVM heap sizes to at least 50% of system RAM
      - OPENSEARCH_INITIAL_ADMIN_PASSWORD=${OPENSEARCH_INITIAL_ADMIN_PASSWORD}    # Sets the demo admin user password when using demo configuration, required for OpenSearch 2.12 and later
    ulimits:
      memlock:
        soft: -1 # Set memlock to unlimited (no soft or hard limit)
        hard: -1
      nofile:
        soft: 65536 # Maximum number of open files for the opensearch user - set to at least 65536
        hard: 65536
    volumes:
      - opensearch-data1:/usr/share/opensearch/data # Creates volume called opensearch-data1 and mounts it to the container
      - "./config.yml:/usr/share/opensearch/config/opensearch-security/config.yml"
    ports:
      - 9200:9200 # REST API
      - 9600:9600 # Performance Analyzer
    networks:
      - opensearch-net # All of the containers will join the same Docker bridge network
  opensearch-node2:
    image: opensearchproject/opensearch:2.10.0 # This should be the same image used for opensearch-node1 to avoid issues
    container_name: opensearch-node2
    environment:
      - cluster.name=opensearch-cluster
      - node.name=opensearch-node2
      - discovery.seed_hosts=opensearch-node1,opensearch-node2
      - cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2
      - bootstrap.memory_lock=true
      - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m"
      - OPENSEARCH_INITIAL_ADMIN_PASSWORD=${OPENSEARCH_INITIAL_ADMIN_PASSWORD}
    ulimits:
      memlock:
        soft: -1
        hard: -1
      nofile:
        soft: 65536
        hard: 65536
    volumes:
      - opensearch-data2:/usr/share/opensearch/data
      - "./config.yml:/usr/share/opensearch/config/opensearch-security/config.yml"
    networks:
      - opensearch-net
  opensearch-dashboards:
    image: opensearchproject/opensearch-dashboards:2.10.0 # Make sure the version of opensearch-dashboards matches the version of opensearch installed on other nodes
    container_name: opensearch-dashboards
    ports:
      - 5601:5601 # Map host port 5601 to container port 5601
    expose:
      - "5601" # Expose port 5601 for web access to OpenSearch Dashboards
    environment:
      OPENSEARCH_HOSTS: '["https://opensearch-node1:9200","https://opensearch-node2:9200"]' # Define the OpenSearch nodes that OpenSearch Dashboards will query
    networks:
      - opensearch-net

volumes:
  opensearch-data1:
  opensearch-data2:

networks:
  opensearch-net:

docker-compose.yml file (for version 2.11.0)
version: '3'
services:
  opensearch-node1: # This is also the hostname of the container within the Docker network (i.e. https://opensearch-node1/)
    image: opensearchproject/opensearch:2.11.0 # Specifying the latest available image - modify if you want a specific version
    container_name: opensearch-node1
    environment:
      - cluster.name=opensearch-cluster # Name the cluster
      - node.name=opensearch-node1 # Name the node that will run in this container
      - discovery.seed_hosts=opensearch-node1,opensearch-node2 # Nodes to look for when discovering the cluster
      - cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2 # Nodes eligible to serve as cluster manager
      - bootstrap.memory_lock=true # Disable JVM heap memory swapping
      - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # Set min and max JVM heap sizes to at least 50% of system RAM
      - OPENSEARCH_INITIAL_ADMIN_PASSWORD=${OPENSEARCH_INITIAL_ADMIN_PASSWORD}    # Sets the demo admin user password when using demo configuration, required for OpenSearch 2.12 and later
    ulimits:
      memlock:
        soft: -1 # Set memlock to unlimited (no soft or hard limit)
        hard: -1
      nofile:
        soft: 65536 # Maximum number of open files for the opensearch user - set to at least 65536
        hard: 65536
    volumes:
      - opensearch-data1:/usr/share/opensearch/data # Creates volume called opensearch-data1 and mounts it to the container
      - "./config.yml:/usr/share/opensearch/config/opensearch-security/config.yml"
    ports:
      - 9200:9200 # REST API
      - 9600:9600 # Performance Analyzer
    networks:
      - opensearch-net # All of the containers will join the same Docker bridge network
  opensearch-node2:
    image: opensearchproject/opensearch:2.11.0 # This should be the same image used for opensearch-node1 to avoid issues
    container_name: opensearch-node2
    environment:
      - cluster.name=opensearch-cluster
      - node.name=opensearch-node2
      - discovery.seed_hosts=opensearch-node1,opensearch-node2
      - cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2
      - bootstrap.memory_lock=true
      - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m"
      - OPENSEARCH_INITIAL_ADMIN_PASSWORD=${OPENSEARCH_INITIAL_ADMIN_PASSWORD}
    ulimits:
      memlock:
        soft: -1
        hard: -1
      nofile:
        soft: 65536
        hard: 65536
    volumes:
      - opensearch-data2:/usr/share/opensearch/data
      - "./config.yml:/usr/share/opensearch/config/opensearch-security/config.yml"
    networks:
      - opensearch-net
  opensearch-dashboards:
    image: opensearchproject/opensearch-dashboards:2.11.0 # Make sure the version of opensearch-dashboards matches the version of opensearch installed on other nodes
    container_name: opensearch-dashboards
    ports:
      - 5601:5601 # Map host port 5601 to container port 5601
    expose:
      - "5601" # Expose port 5601 for web access to OpenSearch Dashboards
    environment:
      OPENSEARCH_HOSTS: '["https://opensearch-node1:9200","https://opensearch-node2:9200"]' # Define the OpenSearch nodes that OpenSearch Dashboards will query
    networks:
      - opensearch-net

volumes:
  opensearch-data1:
  opensearch-data2:

networks:
  opensearch-net:

@DebashishSen-Netapp Would the ignore_hosts setting work for you use-case? https://opensearch.org/docs/latest/security/configuration/api-rate-limiting/#ip-address-rate-limiting
This setting was introduced in 2.17.

@cwperks Thank you for pointing out the new ignore_hosts setting.
I just tested the ignore_hosts setting in version 2.17, and it does work to avoid blocking specific IPs while handling unauthenticated requests.
For reference, here is the ip_rate_limiting configuration section with the ignore_hosts setting:
  "ip_rate_limiting": {
    "type": "ip",
    "ignore_hosts": [
      "<IP_ADDRESS>"
    ],
    "allowed_tries": 10,
    "time_window_seconds": 3600,
    "block_expiry_seconds": 600,
    "max_blocked_clients": 100000,
    "max_tracked_clients": 100000
  }

I also observed that the setting does not have an effect if we set a CIDR range, for example: "<IP_ADDRESS>/24". In this case, the IPs within the range still get blocked. Therefore, users need to list individual IPs in the setting. It might be beneficial to add CIDR support for this setting.
I would still like to request that this behaviour change be documented on the OpenSearch breaking changes page to ensure users are aware of its impact. Additionally, the workaround of using the ignore_hosts setting can also be mentioned.


hotfix home menu overflow

Description
Fixes https://github.com/dust-tt/tasks/issues/1867
Risk
Low
Deploy Plan

deploy front

@Duncid hotfixes the issue. xl might be a bit big for a mobile navigation but at least it works at all time here.


Switch over to SearchView

Instead of the old-style search dialog, use the SearchView on the AB. Requirements for this are:

Theming should be consistent with the currently selected theme for the ActionBar.
All text fields of the SearchView should be legible.
Search suggestions should behave like a filter on the currently visible folder.
Search should behave as it currently does, aka search in the file tree starting from the current folder.

Cleaning backlog - not enough demand.


Replaced FixedValue with Value

@mcardosos,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

PTAL @jhendirxMSFT @marstr

Fixes this Travis failure.
According to @olydis , FixedValue should not be used unless it is strictly necessary,

Most important effect: there are no breaking changes in the SDK.


Fix undoing "Move tiles" TileMapLayer action when drag/drop areas overlap

Fixes #96839.
(not sure about cherry-picking for 4.2 and earlier)

Thanks!

Cherry-picked for 4.3.1.


Court Actions Bot

Responsible for initiating the following actions:

Passing Core and DisputeKit phases
Passing dispute periods
Executing delayed stakes
Drawing jurors
Executing the token and ETH redistribution between jurors
Executing the ruling

For future follow-up: multicall


BUH GUH???

wont work due to CyDJ name in files conflicting or soemthign idk too dank for right now


I run the app module of this project, and input "123" ,but it can't be scanned by other qr scanner.

Describe the option you are trying to implement
I want to create QR code with ....
Example
Attach an example of QR code you want to have, if possible.

In this paticular case logo is too big. Make it smaller. Also this readme section will be useful to read

in above case problem is the eyes because eyes must be clearly visible. your background line colour and eyes colour same and overlapping. check the below example. it can be achieve like this.


(S3): Rule S3_BUCKET_SSL_REQUESTS_ONLY is overly permissive

What is the problem?
The rule https://github.com/aws-cloudformation/aws-guard-rules-registry/blob/main/rules/aws/amazon_s3/s3_bucket_ssl_requests_only.guard is overly permissive.
Following the main points:

The rule checks only for Effect==Deny and Condition Bool.'aws:SecureTransport' == false. It should also be checking for all the attributes specified in the error message: Fix: Set a bucket policy statement to '"Action":"s3:","Effect":"Deny","Principal":"","Resource":"*","Condition":{"Bool":{"aws:SecureTransport":false}}'
When evaluating a Deny statement, evaluating a single Condition key is not enough. The reason for that is if there is a second condition the statement might not be evaluated to true
"*" it's not a valid Resource for S3 Bucket

Reproduction Steps
Example below specifying an Action in the Deny to force a no match rule. The same applies for Principal, Resource.
- name: S3 Bucket Policy statement only allows requests to use Secure Socket Layer (SSL), FAIL
  input:
    Resources:
      ExampleS3:
        Type: AWS::S3::BucketPolicy
        Properties:
          Bucket: !Ref rLogsBucket
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Principal: "*"
                Action: "s3:AbortMultipartUpload"
                Effect: "Deny"
                Condition:
                  Bool:
                    "aws:SecureTransport": false
                Resource: "*"

  expectations:
    rules:
      S3_BUCKET_SSL_REQUESTS_ONLY: FAIL

Example below specifying an additional Condition so the statement returns false
- name: S3 Bucket Policy statement only allows requests to use Secure Socket Layer (SSL), FAIL
  input:
    Resources:
      ExampleS3:
        Type: AWS::S3::BucketPolicy
        Properties:
          Bucket: !Ref rLogsBucket
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Principal: "*"
                Action: "s3:*"
                Effect: "Deny"
                Condition:
                  Bool:
                    "aws:SecureTransport": false
                  StringEquals:
                     "aws:PrincipalAccount": "123456789012"
                Resource: "*"

  expectations:
    rules:
      S3_BUCKET_SSL_REQUESTS_ONLY: FAIL

What did you expect to happen?
I expected the rule to provide the intended guardrail for all scenarios.
What actually happened?
The rule is overly permissive, it does not provide its main objective.
CloudFormation Guard Version
2.1.3
OS
Amazon Linux
OS Version
No response
Other information
The rule should have additional assertions to cover the possible scenarios.

Thank you for submitting this issue. We are reviewing on our side with the tests you provided.

@fabiodouek looking at this we can require that it has the Action, Resource * and Principal * in the statement to tighten down. Have you tested anything similar that meets the requirements?

Hi @grolston , the Conditions also have to be tweaked.
Unfortunately it seems to be a challenge in Guard to do a dict exact match in a simple way. So it has to check the non-presence of the expected attributes. Following an example of a rule and tests tweaked. Maybe there is a way to simplify this?
Rule
#
#####################################
##           Gherkin               ##
#####################################
# Rule Identifier:
#    S3_BUCKET_SSL_REQUESTS_ONLY
#
# Description:
#   Checks if Amazon S3 buckets have policies that require requests to use Secure Socket Layer (SSL).
#
# Reports on:
#    AWS::S3::BucketPolicy
#
# Evaluates:
#    AWS CloudFormation
#
# Rule Parameters:
#    NA
#
# Scenarios:
# a) SKIP: when there are no S3 Bucket Policy Document resource present
# b) PASS: when all S3 Bucket Policy Document set to deny if condition SecureTransport not true
# c) FAIL: when all S3 Bucket Policy Document does not have deny on insecure transport actions
# d) SKIP: when metadata includes the suppression for rule S3_BUCKET_SSL_REQUESTS_ONLY

#
# Select all S3 resources from incoming template (payload)
#
let s3_buckets_policies_ssl_requests_only = Resources.*[ Type == 'AWS::S3::BucketPolicy'
  Metadata.guard.SuppressedRules not exists or
  Metadata.guard.SuppressedRules.* != "S3_BUCKET_SSL_REQUESTS_ONLY"
]

# Select secure S3 Bucket Policy resources from incoming template
let ssl_secure_bucket_policies = %s3_buckets_policies_ssl_requests_only[
  Properties.PolicyDocument {
    some Statement[*] {
      Effect == 'Deny'
      Action == 's3:*'
      Condition[ keys != 'Bool'] empty
      Condition[ keys == 'Bool'] not empty {
        this[ keys == /(?i)^aws:SecureTransport$/ ] == false
        this[ keys != /(?i)^aws:SecureTransport$/ ] !exists
      }
      some Resource == /^[^\/\*]*$/
      some Resource == /^[^\/]*\/\*$/
      Resource IN [/^[^\/\*]*$/, /^[^\/]*\/\*$/]
    }
  }
]

rule S3_BUCKET_SSL_REQUESTS_ONLY when %s3_buckets_policies_ssl_requests_only !empty {
  %ssl_secure_bucket_policies !empty
  <<
    Violation: Bucket policies must feature a statement to enforce TLS usage.
    Fix: Set a bucket policy statement to '"Action":"s3:*","Effect":"Deny","Principal":"*","Resource":"*","Condition":{"Bool":{"aws:SecureTransport":false}}' .
  >>
}

Tests
###
# S3_BUCKET_SSL_REQUESTS_ONLY tests
###
---
- name: Empty, SKIP
  input: {}
  expectations:
    rules:
      S3_BUCKET_SSL_REQUESTS_ONLY: SKIP

- name: No resources, SKIP
  input:
    Resources: {}
  expectations:
    rules:
      S3_BUCKET_SSL_REQUESTS_ONLY: SKIP

- name: S3 Bucket Policy statement only allows requests to use Secure Socket Layer (SSL), PASS
  input:
    Resources:
      ExampleS3:
        Type: AWS::S3::BucketPolicy
        Properties:
          Bucket: !Ref rLogsBucket
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Principal: "*"
                Action: "s3:*"
                Effect: "Deny"
                Condition:
                  Bool:
                    "aws:SecureTransport": false
                Resource:
                  - !GetAtt Bucket.Arn
                  - !Sub "${Bucket.Arn}/*"

  expectations:
    rules:
      S3_BUCKET_SSL_REQUESTS_ONLY: PASS

- name: S3 Bucket Policy statement does not allow requests to use Secure Socket Layer (SSL), FAIL
  input:
    Resources:
      ExampleS3:
        Type: AWS::S3::BucketPolicy
        Properties:
          Bucket: !Ref rLogsBucket
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Sid: "DenyNoSSL"
                Effect: "Allow"
                Principal: "*"
                Action: "s3:*"
                Resource:
                  - !GetAtt Bucket.Arn
                  - !Sub "${Bucket.Arn}/*"
                Condition:
                  Bool:
                    "aws:SecureTransport": false
  expectations:
    rules:
      S3_BUCKET_SSL_REQUESTS_ONLY: FAIL

- name: S3 Bucket Policy statement does not allow requests to use Secure Socket Layer (SSL), FAIL
  input:
    Resources:
      ExampleS3:
        Type: AWS::S3::BucketPolicy
        Properties:
          Bucket: !Ref rLogsBucket
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Action: "s3:*"
                Effect: "Deny"
                Principal: "*"
                Resource:
                  - !GetAtt Bucket.Arn
                  - !Sub "${Bucket.Arn}/*"
                Condition:
                  Bool:
                    "aws:SecureTransport": true
  expectations:
    rules:
      S3_BUCKET_SSL_REQUESTS_ONLY: FAIL

- name: S3 Bucket Policy statement to only allow requests to use Secure Socket Layer (SSL) missing, FAIL
  input:
    Resources:
      ExampleS3:
        Type: AWS::S3::BucketPolicy
        Properties:
          Bucket: !Ref rLogsBucket
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Sid: "AWSLogDeliveryWrite"
                Effect: "Allow"
                Principal:
                  Service:
                    - "delivery.logs.amazonaws.com"
                Action: "s3:PutObject"
                Resource:
                  - !GetAtt Bucket.Arn
                  - !Sub "${Bucket.Arn}/*"
                Condition:
                  StringEquals:
                    "s3:x-amz-acl": "bucket-owner-full-control"
  expectations:
    rules:
      S3_BUCKET_SSL_REQUESTS_ONLY: FAIL

- name: S3 Bucket Policy statement to only allow requests to use Secure Socket Layer (SSL) missing but rule suppressed, SKIP
  input:
    Resources:
      ExampleS3:
        Type: AWS::S3::BucketPolicy
        Metadata:
          guard:
            SuppressedRules:
            - S3_BUCKET_SSL_REQUESTS_ONLY
        Properties:
          Bucket: !Ref rLogsBucket
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Sid: "AWSLogDeliveryWrite"
                Effect: "Allow"
                Principal:
                  Service:
                    - "delivery.logs.amazonaws.com"
                Action: "s3:PutObject"
                Resource:
                  - !GetAtt Bucket.Arn
                  - !Sub "${Bucket.Arn}/*"
                Condition:
                  StringEquals:
                    "s3:x-amz-acl": "bucket-owner-full-control"
  expectations:
    rules:
      S3_BUCKET_SSL_REQUESTS_ONLY: SKIP

- name: S3 Bucket Policy statement less literal test 2, PASS
  input:
    Resources:
      Bucket:
        Type: AWS::S3::Bucket
      BucketPolicy:
        Type: AWS::S3::BucketPolicy
        Properties:
          Bucket: !Ref Bucket
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Sid: EnforceTls
                Effect: Deny
                Action: "s3:*"
                Principal: "*"
                Resource:
                  - !GetAtt Bucket.Arn
                  - !Sub "${Bucket.Arn}/*"
                Condition:
                  Bool:
                    "aws:SecureTransport": false
  expectations:
    rules:
      S3_BUCKET_SSL_REQUESTS_ONLY: PASS

- name: S3 Bucket Policy statement less literal test 3, PASS
  input:
    Resources:
      Bucket:
        Metadata:
          guard:
        Type: AWS::S3::Bucket
      BucketPolicy:
        Type: AWS::S3::BucketPolicy
        Properties:
          Bucket: !Ref Bucket
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Sid: DeleteProtection
                Action: s3:Delete*
                Effect: Deny
                Principal: '*'
                Resource:
                  - !GetAtt Bucket.Arn
                  - !Sub "${Bucket.Arn}/*"
              - Sid: EnforceTls
                Effect: Deny
                Action: "s3:*"
                Principal: "*"
                Resource:
                  - !GetAtt Bucket.Arn
                  - !Sub "${Bucket.Arn}/*"
                Condition:
                  Bool:
                    "aws:SecureTransport": false
  expectations:
    rules:
      S3_BUCKET_SSL_REQUESTS_ONLY: PASS

###### New tests
- name: Trying to trick, retricted action , FAIL
  input:
    Resources:
      ExampleS3:
        Type: AWS::S3::BucketPolicy
        Properties:
          Bucket: !Ref rLogsBucket
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Principal: "*"
                Action: "s3:AbortMultipartUpload"
                Effect: "Deny"
                Condition:
                  Bool:
                    "aws:SecureTransport": false
                Resource: "*"

  expectations:
    rules:
      S3_BUCKET_SSL_REQUESTS_ONLY: FAIL

- name: Trying to trick, added new Condition Operator, FAIL
  input:
    Resources:
      ExampleS3:
        Type: AWS::S3::BucketPolicy
        Properties:
          Bucket: !Ref rLogsBucket
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Principal: "*"
                Action: "s3:*"
                Effect: "Deny"
                Condition:
                  Bool:
                    "aws:SecureTransport": false
                  StringEquals:
                     "aws:PrincipalAccount": "123456789012"
                Resource: "*"

  expectations:
    rules:
      S3_BUCKET_SSL_REQUESTS_ONLY: FAIL

- name: Trying to trick, added new Condition key, FAIL
  input:
    Resources:
      ExampleS3:
        Type: AWS::S3::BucketPolicy
        Properties:
          Bucket: !Ref rLogsBucket
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Principal: "*"
                Action: "s3:*"
                Effect: "Deny"
                Condition:
                  Bool:
                    "aws:SecureTransport": false
                    "aws:AddedNewKey": false
                Resource: "*"

  expectations:
    rules:
      S3_BUCKET_SSL_REQUESTS_ONLY: FAIL

- name: Trying to trick Key upper case, PASS
  input:
    Resources:
      Bucket:
        Metadata:
          guard:
        Type: AWS::S3::Bucket
      BucketPolicy:
        Type: AWS::S3::BucketPolicy
        Properties:
          Bucket: !Ref Bucket
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Sid: EnforceTls
                Effect: Deny
                Action: "s3:*"
                Principal: "*"
                Resource:
                  - arn:aws:s3:::DOC-EXAMPLE-BUCKET/*
                  - arn:aws:s3:::DOC-EXAMPLE-BUCKET
                Condition:
                  Bool:
                    "aws:SECURETRANSPORT": false
  expectations:
    rules:
      S3_BUCKET_SSL_REQUESTS_ONLY: PASS

- name: Resource not list, FAIL
  input:
    Resources:
      Bucket:
        Metadata:
          guard:
        Type: AWS::S3::Bucket
      BucketPolicy:
        Type: AWS::S3::BucketPolicy
        Properties:
          Bucket: !Ref Bucket
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Sid: EnforceTls
                Effect: Deny
                Action: "s3:*"
                Principal: "*"
                Resource: "*"
                Condition:
                  Bool:
                    "aws:SecureTransport": false
  expectations:
    rules:
      S3_BUCKET_SSL_REQUESTS_ONLY: FAIL

- name: Correct Resource, PASS
  input:
    Resources:
      Bucket:
        Metadata:
          guard:
        Type: AWS::S3::Bucket
      BucketPolicy:
        Type: AWS::S3::BucketPolicy
        Properties:
          Bucket: !Ref Bucket
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Sid: EnforceTls
                Effect: Deny
                Action: "s3:*"
                Principal: "*"
                Resource:
                  - arn:aws:s3:::DOC-EXAMPLE-BUCKET
                  - arn:aws:s3:::DOC-EXAMPLE-BUCKET/*
                Condition:
                  Bool:
                    "aws:SecureTransport": false
  expectations:
    rules:
      S3_BUCKET_SSL_REQUESTS_ONLY: PASS

- name: Correct Resource, PASS
  input:
    Resources:
      Bucket:
        Metadata:
          guard:
        Type: AWS::S3::Bucket
      BucketPolicy:
        Type: AWS::S3::BucketPolicy
        Properties:
          Bucket: !Ref Bucket
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Sid: EnforceTls
                Effect: Deny
                Action: "s3:*"
                Principal: "*"
                Resource:
                  - arn:aws:s3:::DOC-EXAMPLE-BUCKET/*
                  - arn:aws:s3:::DOC-EXAMPLE-BUCKET
                Condition:
                  Bool:
                    "aws:SecureTransport": false
  expectations:
    rules:
      S3_BUCKET_SSL_REQUESTS_ONLY: PASS

- name: Incorrect Resource added /, FAIL
  input:
    Resources:
      Bucket:
        Metadata:
          guard:
        Type: AWS::S3::Bucket
      BucketPolicy:
        Type: AWS::S3::BucketPolicy
        Properties:
          Bucket: !Ref Bucket
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Sid: EnforceTls
                Effect: Deny
                Action: "s3:*"
                Principal: "*"
                Resource:
                  - arn:aws:s3:::DOC-EXAMPLE-BUCKET/xxx/*
                  - arn:aws:s3:::DOC-EXAMPLE-BUCKET
                Condition:
                  Bool:
                    "aws:SecureTransport": false
  expectations:
    rules:
      S3_BUCKET_SSL_REQUESTS_ONLY: FAIL

- name: Incorrect Resource added / 2, FAIL
  input:
    Resources:
      Bucket:
        Metadata:
          guard:
        Type: AWS::S3::Bucket
      BucketPolicy:
        Type: AWS::S3::BucketPolicy
        Properties:
          Bucket: !Ref Bucket
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Sid: EnforceTls
                Effect: Deny
                Action: "s3:*"
                Principal: "*"
                Resource:
                  - arn:aws:s3:::DOC-EXAMPLE-BUCKET/*
                  - arn:aws:s3:::DOC-EXAMPLE-BUCKET/
                Condition:
                  Bool:
                    "aws:SecureTransport": false
  expectations:
    rules:
      S3_BUCKET_SSL_REQUESTS_ONLY: FAIL

- name: 2 correct resources, 1 incorrect, FAIL
  input:
    Resources:
      Bucket:
        Metadata:
          guard:
        Type: AWS::S3::Bucket
      BucketPolicy:
        Type: AWS::S3::BucketPolicy
        Properties:
          Bucket: !Ref Bucket
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Sid: EnforceTls
                Effect: Deny
                Action: "s3:*"
                Principal: "*"
                Resource:
                  - arn:aws:s3:::DOC-EXAMPLE-BUCKET/*
                  - arn:aws:s3:::DOC-EXAMPLE-BUCKET
                  - arn:aws:s3:::DOC-EXAMPLE-BUCKET/
                Condition:
                  Bool:
                    "aws:SecureTransport": false
  expectations:
    rules:
      S3_BUCKET_SSL_REQUESTS_ONLY: FAIL

I ran into the exact same issue:  "Unfortunately it seems to be a challenge in Guard to do a dict exact match in a simple way"
My first pass through I made it pretty rigid by defining the exact match. Let me take a look at what you have here and see if that works out.

@fabiodouek looking at what you have above, we are looking at adding the following to the check:
# Select secure S3 Bucket Policy resources from incoming template
let ssl_secure_bucket_policies = %s3_buckets_policies_ssl_requests_only[
  Properties.PolicyDocument {
    some Statement[*] {
      Principal == "*"
      Action == "s3:*"
      Effect == 'Deny'
      Condition {
        Bool.'aws:SecureTransport' == false
      }
    }
  }
]

rule S3_BUCKET_SSL_REQUESTS_ONLY when %s3_buckets_policies_ssl_requests_only !empty {
  %ssl_secure_bucket_policies !empty
  <<
    Violation: Bucket policies must feature a statement to enforce TLS usage.
    Fix: Set a bucket policy statement to '"Action":"s3:*","Effect":"Deny","Principal":"*","Resource":"*","Condition":{"Bool":{"aws:SecureTransport":false}}' .
  >>
}

/cc @akshayrane

Hi @grolston , @akshayrane ,
Is there a reason to lower the bar for this rule?
The enforcement in the rule you are presenting does not achieve the desired outcome and it cannot be trusted.
If you run it against the unit tests I've provided, many of these tests will not pass.
On the other hand, the rule I've provided does a strict check and would prevent the rule to be bypassed either intentionally or unintentionally.
In case you decide to go with a more relaxed rule, I would suggest to add a disclaimer saying that the rule does not prevent to be bypassed, as there are customers trusting that the rules in this repo are reliable.
Regards,
Fabio.

Looks like the problem is still actual, policy from the remediation section does not pass this check - https://docs.aws.amazon.com/securityhub/latest/userguide/s3-controls.html#s3-5


Cannot apply clip path to Backdrop Blur

Description
I'm not sure if this is intentional, but since version 0.1.148 we are no longer able to apply a path to BackdropBlur clip.
We receive the following error: Expected type object, got string.
Screenshot of error attached

Version
0.1.180
Steps to reproduce
            <BackdropBlur
                blur={10}
                clip={d}
            >

                <Fill color={'rgba(0,0,40,0.1)'}>

                </Fill>

            </BackdropBlur>

where d= some path string i.e. 'M0,0 ...'
Snack, code example, screenshot, or link to a repository
const d = M-5 ${2 * sideRadius}C0 ${sideRadius} ${sideRadius} 0 ${2 * sideRadius} 0H${hW}C${rW} 0 ${x4} ${y4} ${x5} ${y5}C${x6} ${y6} ${w - x6} ${y6}     ${w / 2 + cR} ${y5}C${w - x4} ${y4} ${w - rW} 0 ${w - hW} 0H${w - 2 * sideRadius}C${w - sideRadius} 0 ${w} ${sideRadius} ${w + 5} ${2 * sideRadius}V${h}H0Z;
return (
    <Group>
        <Group  transform={[{ translateY }]}>
            <Circle cx={cx} cy={y} r={activeRadius} color='rgba(255,131,0,1)'>
                <Blur blur={15} />
            </Circle>

            <BackdropBlur
                blur={10}
                clip={d}
            >

                <Fill color={'rgba(0,0,40,0.1)'}>

                </Fill>

            </BackdropBlur>
            <Path path={d}>
                <Shadow dx={0} dy={0.5} blur={1} color={'rgba(255,255,255,0.22)'} inner shadowOnly />
            </Path>
        </Group>
    </Group>
)

@MydusApps Are you using the latest version of the library? We can confirm that string as path are not supported at the moment (see #1454) but clipping paths are working as expected. They are part of our test suite and we use them in our projects.


Add autocorrects to package suggestion code

Motivation
We've previously added functionality to add import autocorrects, and logic to determine when they're needed. This joins them together, actually invoking the autocorrects as part of the packaging process.
Test plan
See included automated tests. Added a CLI test that shows the autocorrects in action.

We have a policy of testing changes to Sorbet against Stripe's codebase before
merging them. I've kicked off a test run for the current PR.  When the build
finishes, I'll share with you whether or how it failed. Thanks!
Stripe employees can see the build results here:
→ https://go/builds/bui_Khqg9qMlnzrniK
→ https://go/builds/bui_Khqgeox4cy1uvi


Your web app is ready! 🚀

Hey! 👋
Someone has requested a demo of your project using Ukoreh! 🧙♂.
The app compiled fine and is now live at https://flutter-preview.github.io/MJ12358-flutter-widgetz

@sleepingexperiments You have been reported to GitHub for spam.


Get connected

Global Ecovillage Network:
http://gen-europe.org/about-us/index.htm

now in "rfcs" repo


Fix deprecated Nothing

Found one more deprecation warning to fix for 0.4

@abeschneider Sorry to bother you so much!

Thanks for the update. Definitely not bothering me by fixing code!


README.prod.md - fix a typo

Automated message from Dropbox CLA bot
@SummerBulb, it looks like you've already signed the Dropbox CLA. Thanks!

Merged, thanks @SummerBulb !


PubSubIPCEventStreamAgent.java: NullPointerException if event stream connect sends empty string for the auth token

If you are using the IPC layer and send an empty auth token in the connect message:
{ "authToken":""}
and then immediately send an aws.greengrass#SubscribeToTopic message
{"topic":"test/topic"}
the service will throw a null pointer exception. I think it is probably to do with unsafely dereferencing the auth data here:
        serviceName = context.getAuthenticationData().getIdentityLabel();

https://github.com/aws-greengrass/aws-greengrass-nucleus/blob/64fe5564de21d3ef12da92b9160c9af3b0840bde/src/main/java/com/aws/greengrass/builtin/services/pubsub/PubSubIPCEventStreamAgent.java#L216
Here's a dump of the error message:
2021-03-03T10:55:46.375Z [INFO] (Thread-4) software.amazon.awssdk.eventstreamrpc.RpcServer: New connection code [AWS_ERROR_SUCCESS] for Id 27, Class ServerConnection, Refs 1 - . {}
2021-03-03T10:55:46.440Z [ERROR] (Thread-4) com.aws.greengrass.ipc.IPCEventStreamService: Received empty auth token to authenticate IPC client. {}
2021-03-03T10:55:46.441Z [ERROR] (Thread-4) software.amazon.awssdk.eventstreamrpc.ServiceOperationMappingContinuationHandler: class java.lang.RuntimeException occurred while attempting to authN/authZ connect: Received empty auth token to authenticate IPC client. {}
java.lang.RuntimeException: Received empty auth token to authenticate IPC client
at com.aws.greengrass.ipc.IPCEventStreamService.ipcAuthenticationHandler(IPCEventStreamService.java:215)
at com.aws.greengrass.ipc.IPCEventStreamService.lambda$startup$2(IPCEventStreamService.java:104)
at software.amazon.awssdk.eventstreamrpc.ServiceOperationMappingContinuationHandler.onConnectRequest(ServiceOperationMappingContinuationHandler.java:85)
at software.amazon.awssdk.eventstreamrpc.ServiceOperationMappingContinuationHandler.onProtocolMessage(ServiceOperationMappingContinuationHandler.java:39)
at software.amazon.awssdk.crt.eventstream.ServerConnectionHandler.onProtocolMessage(ServerConnectionHandler.java:49)
2021-03-03T10:55:46.446Z [INFO] (Thread-4) software.amazon.awssdk.eventstreamrpc.ServiceOperationMappingContinuationHandler: Sending connect response for null. {}
Exception in thread "Thread-4" java.lang.NullPointerException
at com.aws.greengrass.builtin.services.pubsub.PubSubIPCEventStreamAgent$SubscribeToTopicOperationHandler.(PubSubIPCEventStreamAgent.java:210)
at com.aws.greengrass.builtin.services.pubsub.PubSubIPCEventStreamAgent.getSubscribeToTopicHandler(PubSubIPCEventStreamAgent.java:62)
at com.aws.greengrass.ipc.modules.PubSubIPCService.lambda$startup$0(PubSubIPCService.java:50)
at software.amazon.awssdk.eventstreamrpc.ServiceOperationMappingContinuationHandler.onIncomingStream(ServiceOperationMappingContinuationHandler.java:139)
at software.amazon.awssdk.crt.eventstream.ServerConnectionHandler.onIncomingStream(ServerConnectionHandler.java:63)
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00000000, pid=6770, tid=6829
#
# JRE version: OpenJDK Runtime Environment (<IP_ADDRESS>+1) (build <IP_ADDRESS>+1-post-Raspbian-1deb10u2)
# Java VM: OpenJDK Server VM (<IP_ADDRESS>+1-post-Raspbian-1deb10u2, mixed mode, serial gc, linux-)
# Problematic frame:
# C  0x00000000
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/pi/GreengrassCore/hs_err_pid6770.log
#
# If you would like to submit a bug report, please visit:
#   Unknown
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Aborted

Empty is not null, so I don't think that should cause a NPE. The cause of the NPE would seem to be that you are calling the method before waiting for the connect future to complete. Does that explanation fit with what you see?

Hi @cthulhuology, This issue hasn’t been active in longer than a week. Because it has been longer than a week since the last update on this, and in the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please provide us with more information on how to replicate this.


Sunbread bduss

代码基本成功，合并

Agree.


Fix: Branches with multiple slashes aren't fully supported

Fixes #4492
Test URLs

https://github.com/yakov116/TestR/tree/this/branch%2Fhas%2Fmany%2Fslashes

Screenshot
n/a

If I remember correctly GitHub does not always put the %

My bad I meant to review this.
We forgot about https://github.com/refined-github/refined-github/blob/1fd3bbb39a5e5eea712a7973fac1faa6ff5fef66/source/features/list-prs-for-branch.tsx#L18
Which is still broken for commit lists etc


Add "forever alone, yao ming" face

Aka http://ragemaker.net/images/Sad/forever not giving a fuck.png

Added in 6ca6e62b7e0f757615dfcd7882e18e0a6d800de9


Add support for STM32F469XI and STM32F469I Discovery Kit

This PR fixes support for the STM32F469XI SoC and support for the STM32F469I Discovery kit board.
Documentation for the STM32F469I Discovery kit board is added based on the STM32F4DISCOVERY format.

Sorry about that PR #211 is going to make changes that will impact things.

Ok, PR #211 is merged so the changes I suggested should make sense now.


Thanks for the Rover support

Thanks for the rover support. It arrived today so anxious to get this on it and start testing.

Sure, let us know how it goes.
Please note that the rover support is very basic/primitive: essentially direct PWM control via MAVROS RC override messages. Here is the example of the rover in action. The main goal is to show that it should be possible to enable APM support with relatively few changes. If your rover can use sensors like GPS or optical flow etc to get a pose then our standard waypoint control should work as well. We haven't tested it on the rover though let alone any APM-based vehicle...

Kancier Pierre is the guy that does the ROS interfacing with APM. The rover code just underwent a major upgrade. He is checking out the ROS part now. Should be able to use setpoint_velocity plugin that uses cmd_vel once that is finished. That plugin uses r/c override too but its simpler to use. I have lots of sensors to try. Zed Realsense 3 different lidars and a radar unit for OA. Rover came in Sat. Finished wiring it last night. Has a TX2 and J120. I thought that model had a good chance of working with a rover since its shot at low altitude. This is the ArduRover R1. Comes with Pixhawk cube 2.1. Roboclaw motor controller. Just started selling them on the 1st of this month. Ready to run with Mission Planner or a radio right out of the box. Has Apsync for streaming video and telemetry tuning etc via webpage and wifi hotspot it creates on the companion computer. Nick Nunno designed them I help with the computer side of things. So this is what I want to implement your work on. I think its going to be a really nice system for hobbyists and schools.

On Oct 16, 2017, at 10:54 AM, Alexey Kamenev<EMAIL_ADDRESS>wrote:
Sure, let us know how it goes.
Please note that the rover support is very basic/primitive: essentially direct PWM control via MAVROS RC override messages. Here is the example of the rover in action https://www.youtube.com/watch?v=ZKF5N8xUxfw&t=127. The main goal is to show that it should be possible to enable APM support with relatively few changes. If your rover can use sensors like GPS or optical flow etc to get a pose then our standard waypoint control should work as well. We haven't tested it on the rover though let alone any APM-based vehicle...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/NVIDIA-Jetson/redtail/issues/11#issuecomment-336931590, or mute the thread https://github.com/notifications/unsubscribe-auth/ARSTgxVcYh-zW8F8eqI89Du68prDPduUks5ss3wjgaJpZM4P5jtv.

https://youtu.be/Jado7z2cwhc https://youtu.be/Jado7z2cwhc. First test

On Oct 16, 2017, at 10:54 AM, Alexey Kamenev<EMAIL_ADDRESS>wrote:
Sure, let us know how it goes.
Please note that the rover support is very basic/primitive: essentially direct PWM control via MAVROS RC override messages. Here is the example of the rover in action https://www.youtube.com/watch?v=ZKF5N8xUxfw&t=127. The main goal is to show that it should be possible to enable APM support with relatively few changes. If your rover can use sensors like GPS or optical flow etc to get a pose then our standard waypoint control should work as well. We haven't tested it on the rover though let alone any APM-based vehicle...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/NVIDIA-Jetson/redtail/issues/11#issuecomment-336931590, or mute the thread https://github.com/notifications/unsubscribe-auth/ARSTgxVcYh-zW8F8eqI89Du68prDPduUks5ss3wjgaJpZM4P5jtv.

This is cool, thanks for sharing! Does the rover have Jetson with Redtail running already (I could not see it from the video)?

Not yet but close. I just got it Sat. And there was a shortage of pix hawks so I didn’t get one went to a customer so I had to install all that. Just about to get to redtail. Those rovers sell for 800 bucks ready to go. Been dealing with a few issues on the rovers so haven’t had time to concentrate on it.
But the rover is going to be at Nvidia Showcase in Nov and I’m going to do my best to have it running by then for the show. Might need to ask lots of questions :)
I don’t have a Earle-brain but I do have a navio2 pretty similar from what I’ve read. So between the two should get something going. And I can get in touch with Pierre for any problems so he can help fix them.
There are a couple more guys that have contacted me on FB that are trying to get it running as well.
I was just using a xbox controller over the 2nd channel of the telemetry radio to control it. It has 10Km range :) Up to 40km with the right antennas. You just create dsm packets and send them down a slip/ppp connection.
There have been several inquiries for projects that redtail would be perfect for. So we want to get it up and running as quickly as possible. If I have too I’ll use px4 for the demo no-one will know but me :)
I built my camera array on 1/2” carbon tube. A pair of small clamps are on top of the rover and it just clamps to that. I was afraid the motor spikes on the scooter would wreck one of my nvidias so just waited until the ardurover was here. I’m just using 3 webcams but they have adjustable focus and seem to work ok. Thanks again for putting this up it would have taken me forever to get to this stage :)
This is my other rover its a pure ROS bot. Having a lot of issues with wheel alignment though. Doesn’t run straight and gets the navigation all messed up trying to correct it. Need to design some motor holders that allow me to adjust the toe in. Its all components from servo-city pretty much. Only takes 1 Allen wrench and a screwdriver to assemble it. It has a TX1 in it so redtail capable too. I have a TX2 on a j120 in the new rover.

On Oct 19, 2017, at 7:25 PM, Alexey Kamenev<EMAIL_ADDRESS>wrote:
This is cool, thanks for sharing! Does the rover have Jetson with Redtail running already (I could not see it from the video)?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/NVIDIA-Jetson/redtail/issues/11#issuecomment-338073393, or mute the thread https://github.com/notifications/unsubscribe-auth/ARSTg4qDxGMP9-A35OGzkdNDHNh-cFBMks5st-h2gaJpZM4P5jtv.

Finished the set-up last night. Couldn’t afford a Earle brain so I used a navio2 and PI III. Raining today so can’t test it but the rest of the week is supposed to be nice. Do you think it would recognize two rows of orange cones instead of having to have a full wall on each side?

On Oct 19, 2017, at 7:25 PM, Alexey Kamenev<EMAIL_ADDRESS>wrote:
This is cool, thanks for sharing! Does the rover have Jetson with Redtail running already (I could not see it from the video)?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/NVIDIA-Jetson/redtail/issues/11#issuecomment-338073393, or mute the thread https://github.com/notifications/unsubscribe-auth/ARSTg4qDxGMP9-A35OGzkdNDHNh-cFBMks5st-h2gaJpZM4P5jtv.

We used Erle Brain primarily because it came as default with Erle Rover. You could replace it with any other flight controller like Pixhawk etc.
As for the cones: that would be an interesting experiment. I have a feeling it probably won't drive well with default network that was trained on forest images so you might need to do some fine-tuning of the network with your dataset.

Ran into a show stopper with apm. The recent changes have altered the way it works so its not responding. So I’m gonna switch over to PX4. How much difference is there between the two? How much code would need to be modified? Seems to me I could use the drone code to interface to px4 and the model part would not need changing. Am I on the right track? Actually I think px4 is much better written. More modular and easier to add drivers for other devices. I’ve had much less difficulty working with it than APM. But I’m in a sticky posit position since the ArduRover is supposed to run apm. I’ve had the pixhawk2 cube for a year now and so far they haven’t been able to get the ROS interface working. Not happy about it holding up my work in a big way. I have a Roboteq controller and a ROS stack to run it. Wondering if it wouldn’t be easier just to integrate redtail into that. My friend Rafaello Bonghi’s GitHub has a complete ROS stack with perception lidar and rtabmap for SLAM ready to go. So I’m going to look at those two options while the app folks get their act together.

On Oct 24, 2017, at 11:08 AM, Alexey Kamenev<EMAIL_ADDRESS>wrote:
We used Erle Brain primarily because it came as default with Erle Rover. You could replace it with any other flight controller like Pixhawk etc.
As for the cones: that would be an interesting experiment. I have a feeling it probably won't drive well with default network that was trained on forest images so you might need to do some fine-tuning of the network with your dataset.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/NVIDIA-Jetson/redtail/issues/11#issuecomment-339043883, or mute the thread https://github.com/notifications/unsubscribe-auth/ARSTgyUt5e_prqORlsYYjP7mPdnLHMVXks5svguOgaJpZM4P5jtv.

Up and running I’ll be testing it in the next couple of days.

On Oct 24, 2017, at 11:08 AM, Alexey Kamenev<EMAIL_ADDRESS>wrote:
We used Erle Brain primarily because it came as default with Erle Rover. You could replace it with any other flight controller like Pixhawk etc.
As for the cones: that would be an interesting experiment. I have a feeling it probably won't drive well with default network that was trained on forest images so you might need to do some fine-tuning of the network with your dataset.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/NVIDIA-Jetson/redtail/issues/11#issuecomment-339043883, or mute the thread https://github.com/notifications/unsubscribe-auth/ARSTgyUt5e_prqORlsYYjP7mPdnLHMVXks5svguOgaJpZM4P5jtv.

Its all up and working now found a forest trail here in town to test with. Do you think the bridge is doable ? Jetson and pixhawk2 serial connection.

On Oct 24, 2017, at 11:08 AM, Alexey Kamenev<EMAIL_ADDRESS>wrote:
We used Erle Brain primarily because it came as default with Erle Rover. You could replace it with any other flight controller like Pixhawk etc.
As for the cones: that would be an interesting experiment. I have a feeling it probably won't drive well with default network that was trained on forest images so you might need to do some fine-tuning of the network with your dataset.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/NVIDIA-Jetson/redtail/issues/11#issuecomment-339043883, or mute the thread https://github.com/notifications/unsubscribe-auth/ARSTgyUt5e_prqORlsYYjP7mPdnLHMVXks5svguOgaJpZM4P5jtv.

TrailNet has successfully flown our MAV over a small wooden bridge up here in Washington.  We've also run our forest-trained model on a rover indoors, in our office hallways, with no retraining.  So the generalization we've observed has been very good, but that's no guarantee..


sails.getDatastore().transaction() vs sails.transaction()

Sails version: 1.2.3
In sails console:
sails> sails.transaction === sails.getDatastore().transaction
true
sails> sails.sendNativeQuery === sails.getDatastore().sendNativeQuery
true

But according to the documentation:

To access one of these at runtime, call either sails.getDatastore() or the .getDatastore() model method.

Is it necessary to use sails.getDatastore().x() instead of sails.x()?

I'll consult with the team for deeper reasoning in whether this is truly necessary or just best practice and any potential repercussions in the long-run.

@johnabrams7 did the team have any opinions?

@alxndrsn  So good news, either method is going to be official from now on.  The transaction only method without .getDatastore() was undocumented but available for convenience and testing.  The docs will be updated to include it as an alternative method. 👍
If you want, we'd be more than happy to check out a PR for the docs if you want to give it a go!  😎


Add identity provider

Architecture:
https://lucid.app/lucidchart/invitations/accept/d6d776a7-89f7-4fce-ace7-3dd7a7d7d91e

Updated the CI to also run for PRs going into this branch (I think). Should remove that part before merging into main.
The CI now succeeds on this branch. This did require some changes though:

--ignore-scripts had to be removed from the npm ci calls since bcrypt needs a script to run when installing.
14.0 had to be removed since for some reason the openid-client used in solid-client-authn does not receive a body when accessing /.well-known/openid-configuration. It works in the browser though so there is probably an issue with 14.0 there.
15.0 had to be removed since there's an issue with the npm version that gets installed along with it causing the post-install scripts not to run. This means the build script would not run after running npm ci.
15.x required the change in eeda094fdb0fb591b5e9de01cd4d7535b2178c98 to work.

15.0 could be added by still running the build script after running npm ci (this would cause all other versions to build twice though, but since there is a cache this might not be much of an issue.
I don't think there's an easy fix to still support 14.0 in the CI though. We actually do support that version as everything still works in the browser, it's just the node version of the solid-client-authn used in the integration returns wrong results in 14.0 so probably the result of an edge case bug in 14.0. We could ignore this integration test in this version or the .0 perhaps but that would set the door open for different exceptions per version. We could also look for the first 14.x version that does work and use that instead.

* 14.0 had to be removed

That's acceptable, let's just find the minimum 14.x version that works.

Shall we also create issues for missing functionality like the client id?

Shall we also create issues for missing functionality like the client id?

Created #718. I think that's the only one still needed unless @matthieubosquet knows of some more.

Are all of the templates injection-proof? That is, if I inject <script>alert(1)</script> for any variable, will the HTML be escaped?
(Whether or not the values are constrained beforehand is another matter; I just want to check that all templates will produce correct HTML regardless of the input given to them.)

Are all of the templates injection-proof? That is, if I inject <script>alert(1)</script> for any variable, will the HTML be escaped?

I actually had no idea so I added a unit test for that. The ejs library that is used for rendering escapes such strings.

All the comments above should be covered, and the branch is up to date with the main branch and all tests succeed, so as far as I'm concerned a (squash) merge should finally be possible.

Yeah let's go!


Clean-up wasmi executor

Codecov Report

Merging #430 (7ec4035) into master (727cec7) will increase coverage by 0.01%.
The diff coverage is 98.45%.

@@            Coverage Diff             @@
##           master     #430      +/-   ##
==========================================
+ Coverage   74.65%   74.67%   +0.01%
==========================================
  Files          72       72
  Lines        7131     7124       -7
==========================================
- Hits         5324     5320       -4
+ Misses       1807     1804       -3

Impacted Files
Coverage Δ

wasmi_v1/src/engine/stack/mod.rs
79.10% <ø> (+1.96%)
:arrow_up:

wasmi_v1/src/engine/mod.rs
85.26% <75.00%> (ø)

wasmi_v1/src/engine/executor.rs
98.71% <98.94%> (ø)

wasmi_v1/src/engine/stack/frames.rs
93.10% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


luci-app-acme:  rename keylength to key_type

The acme.sh package was changed recently:

key_size option were renamed to key_type
the webroot option is now should be a fixed path /var/run/acme/challenge to simplify configuration as part of https://github.com/openwrt/packages/pull/17721

@tohojo @hgl Please explain how to specify that I do really want to use a webroot but with the new /var/run/acme/challenge folder. The entire webroot option was deprecated so how the acme can distinguish webroot with a custom path like /var/www/acme/ and the new folder?
For now I made the /var/run/acme/challenge as a default value. So in the script you can just check if it's not the default value or empty and only then write a deprecation notice.
The current validation method is standalone, maybe we should change it to a webroot?
@jow- Please give an advice. We have a DNS API and for example for the DuckDNS:
config cert 'duckdns_wildcard'
  option validation_method 'dns'
  option dns 'dns_duckdns'
  list credentials 'DuckDNS_Token="6b52e9da-5229-4304-b846-187355f9q91e"'
  list domains 'example.duckdns.org'
  list domains '*.example.duckdns.org'

The problem is that the credentials is list of properties but I wish to turn it into a plain form. So when selecting a provider it's specific fields will be shown.
E.g. for the DuckDNS just show a field "Token" but on the form save it will be added to the list credentials 'DuckDNS_Token. How to make this saving?
For each provider we need a separate fields but it should be enough to just support a few main (Gandi, Cloudflare) and some standard like acmedns and nsupdate.
CC @jannispinter @zhanhb

webroot should not be customizable. All httpds should just use the standardized path.
Listing all credentials for all dns providers is impossible, since acme tries to be client agnostic. Users are expected to specify values pertain to the client they use. In other words, the Token example you use might only work for acme-acmesh, but not acme-uacme (if it’s created in the future).

Ok, I added a DNS API specific fields. At first step only some popular but later I'll add all of them. I just want to make a cleanup in the acme.sh itself because now it's a mess.

@stokito First off, I want to thank you for taking the time writing this. Listing the DNS values must be a nontrivial work.
However, as I mentioned previously, the values like dns_cf are acme.sh specific. If this package absolutely has to explicitly list them, they should at least be nested under acme.sh.
I personally think we shouldn't explicitly list them. Users are expected to check OpenWrt documentation on acme (which should be updated) and use the dns value for the client they choose (e.g, acme-acmesh, acme-uacme, etc). For acme-acmesh it's dns_cf, for acme-uacme, it might be something else, so this LuCI package should just offer a text field. The same goes for credentials, which are essentially options for dns.

The acme-uacme is not even created yet (right?). But also I honestly don't see any reason why to use it: it's written in C (so needs to be compiled for all routers and waste CI time), depends on gnutls and much bigger than acme.sh. The acme.sh is also bloated but still is smaller than the uacme.
Currently uacme dns-01 supports only nsupdate, CF, gandi, deSEC.io. If in future the uacme will be supported we anyway need to change the UI to at least change translation keys and I'll do that.
Instead of uacme maybe in future the only one alternative ACME client that can be supported is LE certbot. But it's depends on Python and heavy. Maybe for x86 it may make sense.

acme-uacme only serves an example. There are other potential clients like lego, which also has comprehensive support for dns-01.
I think my point is, it's best if this package is client agnostic. Asking you and other maintainers to keep this package up-to-date whenever a new client is added is unsustainable, and supporting all DNS values for all clients could also bloat this package.

The Lego is bloated too so I don't feel that this will be an issue in nearest years. We can solve problems for users today and once a new problems occur we can solve them latter. But maybe this won't happen if solve a root of a problem of many DSP APIs:
0. The acme.sh and lego (maybe even dnscontrol) may synchronize variable names.

Even today users may use relatively simple solution ACME DNS. There are few problems but this is a working solution.
The DNS providers may implement some basic standard API for ACME.

If none of them solved we can add a variable transform into OpenWrt acme.
Today most users will use DuckDNS or some popular DNS provider like Gandi and use the acme.sh so this already covers 99% of users. The credetials edit is still visible for users so even if we won't update in future users still can add any credential var that they need.
I really don't see problems here

I'm not sure I understand the solutions you mentioned:

Do you mean DNS values should be standardized and each client should convert from them?
You want to ask DNS-01 users who don't use acme.sh to host their own name server? How does that "solve the root problem"?
I don't understand what you mean by this.

We can solve problems for users today and once a new problems occur we can solve them latter.

We are in circles. The current solution forces maintainers into a corner (supporting all DNS values for all clients). I don't understand why you would dismiss it as a non-issue. The acme package previously tried to update all available httpds after a certificate renews, and we migrated away from that. We should not fall into the same trap here.

Do you mean DNS values should be standardized and each client should convert from them?

Yes but if they don't then we can convert here.

You want to ask DNS-01 users to host their own name server? How does that "solve the root problem"?

It works like: you configure a CNAME for your subdomain to the acme-dns.io subdomain and the TXT record is updated there. This works only for subdomains but covers many cases.

The DNS providers may implement some basic standard API for ACME.

https://community.letsencrypt.org/t/dns-api-standard-or-specification/189887

The current solution forces maintainers into a corner (supporting all DNS values for all clients)

There is no corner. A user can add any variable directly to the credentials input. If the acme.sh has a new provider then a user still can edit a UCI config manually.
I think that eventually all DNS providers will have the same API.
Even now adding a new dns provider is a few simple lines change.

The whole discussion around multiple backends is a bit hypothetical given that we don't have more than one currently. I don't think we should be limiting ourselves because future clients may not support the same feature set; if this is the case, we can just add a check to the UI and remove/grey out the providers that are not supported by the currently installed backend.
It a second client shows up that supports the same backend, but uses a different variable name to do so, that backend will just have to translate appropriately. Yes, this way we're making the acme.sh variable names the de facto "acme framework" names for those providers, but I don't think that's such a big deal: the names are a bit arbitrary anyway, and they're tied to the (often proprietary) provider anyway, so it's not like we have much say in the matter anyway. The best we can do is maybe bikeshed the names a bit, and sidestepping that by just going with the names that already exist is fine by me...
However, I don't think we should be endorsing any particular provider by setting a default value. Users will need to have an account with a provider before configuring this anyway, so let's just list the providers alphabetically, and they can pick whichever one works for them.

Not just credentials, also this:
o.value("dns_duckdns", "DuckDNS.org");

This works for acme.sh but not lego for example.

Why not? Because lego doesn't support that provider at all? Then we can just prune the list according to which backend is installed, as mentioned above...
(Side note, I don't think lego is going to be usable on openwrt at all since golang only has limited architecture support, sadly)

Users will need to have an account with a provider before configuring this anyway, so let's just list the providers alphabetically, and they can pick whichever one works for them.

I agree and I even implemented some JS code to pre-selct the dns_duckdns if the domain ends with .duckdns.org and similarly for freedns. But it works with a bug so I didn't included it into the PR.
The main reason why I kept the duckdns by default is that if no default specified then anyway a first item will be selected e.g. 1984.is. So anyway we have a problem here so I decided to keep the DuckDNS by default which I believe should be the most popular option in context of routers.
Generally speaking this can be solved in a nice way.
We can lookup NS record of the domain and determine a provider by it e.g. ns1.gandi.net definetely belongs to gandi. Or a domain may add some TXT  like "DNSAPI=gandi" and this can help to autodiscovery.
But this is non necessary complication.
@tohojo JFYI the Lego has a PR for the DuckDNS and also Golang can be compiled to MIPS (I used a Golang program on TPLINK wrn1043nd)

Because this value, as far as acme-common is concerned, is passed directly to the client. It's dns_cf for acme.sh's --dns flag, and cloudflare for lego's, for example. So either acme-lego or this package has to convert dns_cf to cloudflare.

Right, but that's kinda fundamental when the clients can't agree, no? Either acme.sh has to convert from "cloudflare" to "dns_cf", or lego has to do the reverse.

The whole name conversion and provider list could be avoided, if this package simply offers a text field like how acme-common handles it.

Right, but that's just bailing out and leaving the user to deal with the incompatibility. If acme-common is supposed to be an abstraction layer, we need to deal with this sort of incompatibility somehow. The goal of having a common format for /etc/config/acme is that the same config file should keep working across client implementations. If we tell users "figure out what your client supports and put the client-specific values into the config file", then what's the point of having the common framework?

The goal of having a common format for /etc/config/acme is that the same config file should keep working across client implementations

I'm not sure this was considered when developing acme-common. Even the same config can mean different things for different clients. For example, days mean how many days have passed in acme.sh, but how many remains in lego.  The calias and dalias options aren't guaranteed to work across different clients either.
Precisely define what each config means and have different client do the conversion is not really feasible, even if it is, users aren't supposed to switch clients frequently, is it really worth every client maintainer's effort to support this?
IMHO acme-common exists mostly to address code reuse.

Another difference: days is only consulted when issuing in acme.sh, but lego it's only consulted when renewing. There is no way to make lego behave the same as acme.sh.
The point is, have an universal config that work across clients is a really hard promise to keep.

A small off topic:
On the UI we need to show a link to acme.sh Wiki with instructions for the DNS provider.
There are two pages dnsapi and dnsapi2.
I just added anchors for each DNS provider with the same name as it's code e.g. https://github.com/acmesh-official/acme.sh/wiki/dnsapi#dns_aws
And for providers on the dnsapi2 page I added links e.g. https://github.com/acmesh-official/acme.sh/wiki/dnsapi#dns_porkbun
So now we need to add some JS handler that will change the link to a wiki when the DNS provider dropdown is changed

Ok, so I made the dynamic URL to DSN API Wiki with instructions.
Also added more fields for other providers.
Please merge

I'm not sure this was considered when developing acme-common. Even the same config can mean different things for different clients. For example, days mean how many days have passed in acme.sh, but how many remains in lego. The calias and dalias options aren't guaranteed to work the same way across different clients either.
Precisely define what each config means and have different clients do the conversion is not really feasible, even if it is, users aren't supposed to switch clients frequently, is it really worth every client maintainer's effort to support this?

Yes, I definitely think we should strive for compatibility. It may not be achievable for all things, but it's fine to have some things that are only supported by one client, when that is not avoidable. Then we can just disable those config options when an incompatible client is installed (or consider not supporting such options at all if they're not really needed). Having different semantics for the same config option we should definitely avoid, though! In that case they should have different names (and only work for the client that supports them).
It's not really clear to me why supporting a lot of different clients is useful, though. I can maybe see the value of supporting uacme assuming it can be made smaller than acme.sh (since acme.sh pulls in the openssl binaries), but what's the benefit of lego, exactly? :)

@tohojo I fixed your comments, please check

@tohojo It turns out that we can allow only to list files without reading them. So I restored the certificates tab because I believe it will be useful.

it's fine to have some things that are only supported by one client, when that is not avoidable.

For a new client author, finding some options unsupportable is the easy part. It doesn't create compatibility issues since the
client can just ignore the options.

Having different semantics for the same config option we should definitely avoid, though!

The hard part is that author has to be aware it's different before she can avoid. Unless we provide a clear document or the author is very familiar with acme.sh, it can be really hard to discover days might not mean what she thought it meant for example. The extra effort involves understanding how the options work in acme.sh and how they differ from the new client.
Another big issue is that how credentials should be supported. Currently, this package uses acme.sh specific values like CF_Zone_ID, which isn't supported by lego. It either has to translate all these environ variables (not an easy task, since in acme-common we just directly eval export them) or just ask users to use different credential values, breaking the compatibility promise we want to keep. What do you think we should do in this regard?
This makes writing a new client package require deep understanding of acme.sh first.

what's the benefit of lego, exactly?

It has both comprehensive DNS support and no dependencies on openssl. acme.sh and uacme only has either one of the benefits. It shouldn't matter unless we want to endorse acme.sh and discourage other new clients.

It's not really clear to me why supporting a lot of different clients is useful, though.

I'm not sure this is a good strategy. The original goal was that writing a new client should be easy, since it can leverage a lot of existing code from acme-common, but now it becomes that writing a new client is discouraged, because we thought "supporting a lot of different clients isn't useful" and it requires deep understanding of acme.sh first.
Even if good acme clients are few now (which I'm not sure is true), the acme spec can still innovate and warrants new client to pop up.

To provide a more concrete example. Let’s say the lego package wants to support days, what it should do? Since converting remaining days to days passed requires parsing the notAfter value from the certificate, and the lego cli doesn’t offer that, the package has to introduce another option like days_remain. So now the user has to modify the config in order for it to work the same way after switching from acme.sh to lego. And what should this LuCI package do? Detecting what client is used and hide show options as needed? Plus the DNS provision list it has to support, this quick gets out of hand.

@hgl yes, you are right and we should try to keep all client agnostic but this still not fully possible. From the UI side it should be not that hard to show or hide fields depending on a client type. So we can show the days for acme.sh and another field remainingDays for the lego.

@stokito I don't have LuCI merge rights, and I have stated my concerns about the current design.
Need a LuCI maintainer to make the call.

@tohojo @systemcrash I fixed many small issues and re-committed with more clear changes.
I feel that the PR is ready or at least good enough to be merged.
There is already a lot of changes and if anything else we can make a separate PR.
Please note that current users have a broken luci-app-acme that doesn't correspond for a new version of acmesh.

Right, so after reviewing this discussion again: if the expectation is that the supported fields and/or there semantics is going to vary between different clients, that means that we're going to have to make adjustments in the UI depending on which client is installed in any case. In which case I don't see any obstacles to merging this, including the DNS provider list. @hgl WDYT?

that means that we're going to have to make adjustments in the UI depending on which client is installed in any case
Not if we only standardize option names and not values, but I guess making the UI offer values does make it more user friendly. I can get behind it since you gave the green light.

And maybe we only need to consider this once multi-client support is really needed, but just to put it out there: we might need to consider what should happen if the user uninstalls the current client and installs a new one. For new options, maybe we can just display an empty value. For options with the same name but different values (e.g., DNS provider), the current value is invalid, maybe the field should be marked with error or something?

Not if we only standardize option names and not values, but I guess making the UI offer values does make it more user friendly. I can get behind it since you gave the green light.

Cool. Merging, then :)

And maybe we only need to consider this once multi-client support is really needed, but just to put it out there: we might need to consider what should happen if the user uninstalls the current client and installs a new one. For new options, maybe we can just display an empty value. For options with the same name but different values (e.g., DNS provider), the current value is invalid, maybe the field should be marked with error or something?

Yeah, hard to discuss all that in the abstract, let's evaluate once we actually have another client implementation to look at...

thank you all!

FYI: I sent a PR to acmesh where proposed to get automatically the list of DNS provides and their options https://github.com/acmesh-official/acme.sh/pull/4738

So, I had to change this manually in my config still in /etc/confic/acme from keylength to key_type. When can we expect this to get fixed & pushed in the luci-app-acme LuCI GUI?

@LokeYourC3PH it's already merged and available. About a month ago I also added a script to migrate the old options to new.
FYI: You can remove the key_type and by default it will be ec256 which is shorter and supported by all modern servers.

Well whatever it is, on my Linksys E7350 (ramips/mt7621) running OpenWRT 23.05.3 r23809-234f1a2efa, the latest luci-app-acme (Version: git-23.074.38708-acf40dc) still creates those values in the config when it shouldn't. The option for "Key Size"

should write the key_type instead, and only have RSA2048 or EC256 as an option available, yet it doesn't, hence why I was curious when that will be changed.

Maybe the change wasn't backported yet to the 23.05 (i.e. May of 2023, the PR was merged later).
This is a minor thing and the old keysize option is still supported.

It's as a matter of fact completely deprecated and doesn't work as it seems:
daemon.warn acme: Option "keylength" is deprecated, please use key_type (e.g., ec256, rsa2048) instead.

Ryan @.***> writes:

Maybe the change wasn't backported yet to the 23.05 (i.e. May of 2023, the PR was merged later).
This is a minor thing and the old keysize option is still supported.

It's as a matter of fact completely deprecated and doesn't work as it seems:
daemon.warn acme: Option "keylength" is deprecated, please use key_type (e.g., ec256, rsa2048) instead.

The code that emits this warning goes on to convert the old value, so
things should work just fine apart from that message in the logs...


Make listener callback more scalable

Hi! At the moment lister called with only one object 'messageObject' and MMWormhole allows only one listener for identifier. To make implementation more scalable: several listeners can be registered for one identifier; one block can be used to listen for several identifiers - just add additional argument to the listener "identifier:(NSString*)identifier" this will make life mush easier and will allow to create more robust high level design implementation over MMWormhole
P.S. @cnstoll I'm using currently active MMWormhole 1.1.1

I'm having a little trouble following along here. I think you could already achieve this by having multiple wormholes, right? If you wanted one block to be called for multiple listeners, or for multiple identifiers, it seems like there are a few ways you could design your own code to make that happen. What would we do from a framework design perspective to make the library support that without making the interface more complex than it needs to be for simple use cases. It's a delicate balance to strike, and at least for now I tend to err on the simplicity side of things.
Feel free to add more detail or submit a PR that illustrates your use case.
Thanks,

Conrad

Having multiple wormholes is very expensive and error prone, especially at the moment when library have issues sending messages several times (mentioned in Issues) - so it will turn into hell of messages and broken behaviour. Adding just one additional param, that is usually a standard way of implementing callbacks, like context will give option to the user of your library to decide on his own how to use it and not to restrict. I created pull request
/Sergey

Understood. Hopefully the duplicate message issues will all be resolved in the 1.2.0 version we're about to release. I'm concerned about the perception that creating multiple wormholes is expensive. The wormhole object itself is very cheap, and having multiple wormholes for different components of a complex app should be considered a best practice from a object oriented design perspective. Hopefully the fixes for some of the messaging issues will resolve that.


9v9 format adaptation

update configs (map pool, exec configs)
add missing class icons
adapt queue to displaying 9 classes


Increase the width of medical history details Text area in patient registration form on mobile view

Describe the bug
in the mobile view, the medical history details text boxes in patient registration form is not using the full width of the view port
To Reproduce
Steps to reproduce the behavior:

Go to patient tab
Click on add patients
switch to mobile view and select any medical history
See error

Expected behavior
increase the width of medical history details text box in mobile view to adjust with view port size
Screenshots

can you assign this to me! I would love to take up this issue.

hey @nihal467  could you please assign this issue to me?

hey @GuntreddyHemanth let me know if you are not working on this issue

Please assign to someone I not working on it right now
On Mon, 14 Oct, 2024, 8:30 AM Abhishek Patel, @.***>
wrote:

hey @GuntreddyHemanth https://github.com/GuntreddyHemanth let me know
if you are not working on this issue
—
Reply to this email directly, view it on GitHub
https://github.com/ohcnetwork/care_fe/issues/8763#issuecomment-2409851416,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BB3VXYLDYF5DKKHTA3P4E6LZ3MXUTAVCNFSM6AAAAABPYR3ZSWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBZHA2TCNBRGY
.
You are receiving this because you were mentioned.Message ID:
@.***>

@nihal467 @rithviknishad  i would like to try to work on this issue

If this issue still persists can you assign it to me?


Update create-a-phone-system-call-queue.md

Removing the redundant 'with' in the 'Create a call queue' section.

@JohanFreelancer9 Copy editing is needed for this PR. Thanks.

@JohanFreelancer9 Copy editing is needed for this PR. Thanks.

@MikePlumleyMSFT PR has been copyedited and is ready for final review, could you please check and merge? Thanks!

@MikePlumleyMSFT PR has been copyedited and is ready for final review, could you please check and merge? Thanks!


Lightning GBenchmarks update to follow the new monorepo structure

Before submitting
Please complete the following checklist when submitting a PR:

[ ] All new features must include a unit test.
If you've fixed a bug or added code that should be tested, add a test to the
tests directory!

[ ] All new functions and code must be clearly commented and documented.
If you do make documentation changes, make sure that the docs build and
render correctly by running make docs.

[ ] Ensure that the test suite passes, by running make test.

[ ] Add a new entry to the .github/CHANGELOG.md file, summarizing the
change, and including a link back to the PR.

[ ] Ensure that code is properly formatted by running make format.

When all the above are checked, delete everything above the dashed
line and fill in the pull request template.

Context:
The benchmarks support functionality needs to be updated to the new repository structure.
Description of the Change:
Benefits:
Possible Drawbacks:
Related GitHub Issues:

@AmintorDusko What is the status of this PR?

@maliasadi, this is only a placeholder, feel free to close it.