skip-tls-verify-registry option doesn't work with self-signed cert

Before proceeding

[X] I didn't find a similar issue

Version
2.10.5
How to reproduce

I'm running docker-registry behind nginx with self-signed cert on external virtual machine. Docker login goes fine with it after added do insercure-registries.
ssl config:

[req]
default_bits = 4096
default_md = sha256
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = VA
L = SomeCity
O = MyCompany
OU = MyDivision
CN = <IP_ADDRESS>
[v3_req]
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
IP.1 = <IP_ADDRESS>

ssl command:
openssl req -new -nodes -x509 -days 365 -keyout <IP_ADDRESS>-key.pem -out <IP_ADDRESS>.crt -config ssl_config

nginx.conf
events {}

http {

    server {
        listen 5000 ssl;
        http2  on;
        server_name _;

        ssl_certificate     /etc/nginx/certs/<IP_ADDRESS>.crt;
        ssl_certificate_key /etc/nginx/certs/<IP_ADDRESS>-key.pem;

        client_max_body_size 0;
        chunked_transfer_encoding on;

        location /v2/ {
            proxy_pass http://<IP_ADDRESS>:5005;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Forwarded-Host   $host:$server_port;
            proxy_set_header X-Original-URI     $request_uri;
            proxy_set_header Docker-Distribution-Api-Version registry/2.0;
            proxy_read_timeout                  900;
            proxy_buffering off;                        # disable buffering of responses from the proxied server
            proxy_request_buffering off;                # disable buffering of responses from client
            proxy_ignore_headers "X-Accel-Buffering";   # disable buffering of a response

            proxy_no_cache 1;                           # conditions under which the response will not be saved to a cache
            proxy_cache_bypass 1;                       # conditions under which the response will not be taken from a cache
            proxy_cache off;                            # disable caching
        }
    }
}

Following "First app guide"(https://habr.com/en/companies/flant/articles/597001/) with notes to custom registries.  I trying to deploy it to provider-hosted Deckhouse CE cluster withouth ssh access to nodes but with kubectl and dashboards for operation.

when I run
werf converge --repo <IP_ADDRESS>:5000/werf-first-app --skip-tls-verify-registry=true

it returns an tls certificate check error
Result
Deployment fails with certificates validation errors

│ RESOURCE (→READY)                      STATE    INFO
│ Deployment/werf-first-app              WAITING  Ready:0/1
│  • Pod/werf-first-app-5775764db-pfm9b  CREATED  Status:ImagePullBackOff  Errors:1  LastError:"ImagePullBackO
│                                                 ff: Back-off pulling image \"<IP_ADDRESS>:5000/werf-first-ap
│                                                 p:7757993cc8b84ea8ee8a31895dd766296f96e6aff15b2af105e5e61f-1
│<PHONE_NUMBER>97\""
└ Progress status

Building failure deploy plan
Executing failure deploy plan
┌ Progress status
│ RESOURCE (→READY)                      STATE    INFO
│ Deployment/werf-first-app              FAILED   Ready:0/1
│  • Pod/werf-first-app-5775764db-pfm9b  CREATED  Status:ErrImagePull  Errors:2  LastError:"ErrImagePull: fail
│                                                 ed to pull and unpack image \"<IP_ADDRESS>:5000/werf-first-a
│                                                 pp:7757993cc8b84ea8ee8a31895dd766296f96e6aff15b2af105e5e61f-
│<PHONE_NUMBER>597\": failed to resolve reference \"<IP_ADDRESS>:
│                                                 5000/werf-first-app:7757993cc8b84ea8ee8a31895dd766296f96e6af
│                                                 f15b2af105e5e61f-1727264922597\": failed to do request: Head
│                                                  \"https://<IP_ADDRESS>:5000/v2/werf-first-app/manifests/775
│                                                 7993cc8b84ea8ee8a31895dd766296f96e6aff15b2af105e5e61f-172726
│                                                 4922597\": tls: failed to verify certificate: x509: certific
│                                                 ate signed by unknown authority"
└ Progress status

┌ Failed operations
│ Track resource readiness: Deployment/werf-first-app
└ Failed operations

Running time 264.51 seconds
Error: release deploy: failed release "werf-first-app" (namespace: "werf-first-app"): execute deploy plan: error waiting for operations completion: error executing operation: track resource readiness: track deployment: waiting for resource "werf-first-app/Deployment/werf-first-app" readiness failed
111

Expected result
Deployment successfull
Additional information
No response

The --skip-tls-verify-registry=true option applies only during the build process. To resolve certificate verification issues during deployment (e.g., x509: certificate signed by unknown authority), this needs to be addressed separately and falls outside the responsibility of werf.
Possible solutions include:

Adding the self-signed certificate to the trusted certificates on each Kubernetes node.
Configuring container runtime settings to skip certificate verification for the registry.


Import ENS

What was wrong?
#342 - want ens support
How was it fixed?

Import from https://github.com/carver/ens.py to a sibling module ens
Many calls like eth.getBalance(), eth_sendTransaction(), etc now accept ENS names as arguments where they take an address normally, via a new name_to_address_middleware.
Contract converts from name to address in:

call/transaction arguments
constructor arguments

Address for interacting with the contract (ie~ contract.address) is stored as a name and converted to address on demand
The chain stalecheck happens by default, only when the ens module is making calls

Essentially all of the features are opt-in, having no effect if you don't use ENS names. The only gotcha is if a user did something really weird: convert their address to bytes, and then to a str, and that address happened to end in 0x2e657468 (which is '.eth' in ascii), and they pass that address in to any of these functions. This PR would treat that address as a name, and almost certainly fail the name lookup.
An address ending in 0x2e657468 will not be treated as an ENS name for people who send in their address as bytes or a hex str.  I feel pretty confident that sending the address in as an ascii-decoded str is... wrong enough that we can just let it fail.
Cleanup work todo:

[x] move test reconfiguration of py2 to its own PR
[x] add docs (see linked issue)

Cute Animal Picture

Ok, ready for review again. This PR only adds the ENS library, it doesn't do any web3 integration yet. I'll open that one later, when this looks good.
I agree that the tests are cleaner now without the mocking, and less prone to breakage from refactoring. In order to accomplish tests without (much) mocking, a fixture deploys the full suite of ENS contracts to EthereumTesterProvider, once at the start of the session. (When I tried to do it for every test, the suite took waay too long) It comes with the downside that the name state carries over from test to test. It's mitigated by these two mechanisms:

using new names in each test, so the namespace doesn't overlap
wiping out the changes made, at the end of the test, when relevant (for anything parametrized)

Half-vetted thought: Maybe when py-evm is ready to use in tests, we could get some kind of easy rewind or snapshot mechanism for testing?
When trying to test the .eth registrar without mocks, I hit a snag with a failing transaction. Instead of taking another day or two to debug and rewrite those tests, I just marked it as "Alpha" quality in the docs. We don't need it for web3 features, anyway. If you think we need to be more careful than that, I can remove mention of it in the docs, and/or move ens.registrar to ens._registrar. I'd rather do that then get these tests resolved (for now)

@pipermerriam I went the route of removing the registrar for this changeset. I'm trying to get everything needed for v4-beta merged in first, then I'll come back around for the stable and bonus features.

Ok, maybe we can do a code walkthrough during or after devcon, because I would like more thoughts on it, but I don't want it to hold up the merge.


No strikethrough support

In HTML, strikethough can be indicated with <s>text</s>, text or text (deprecated). Turndown does not support this. Any of these inputs gives the output:
text
Result:
text
The output should be:
~~text~~
Result:
text

Even when trying to add a strikethrough rule, using the example given:
turndownService.addRule('strikethrough', {
  filter: ['del', 's', 'strike'],
  replacement: function (content) {
    return '~' + content + '~'
  }
})

I get the error: Type '"strike"' is not assignable to type ... (followed by 100 types).
This is in Typescript.
How do we convert strikethrough text to markdown?


Left Panel Auto Toggle on Command Execution

Coverage decreased (-0.06%) to 85.155% when pulling 42f1d3e9050ed1b9a0a55f449176e203892827c1 on awarenessxz:v1.5_Others into aea175bf9d094d54d2cd8006dae14c55838befd1 on CS2103AUG2017-W14-B2:master.

Coverage decreased (-0.06%) to 85.155% when pulling 9b8851999c2fd044eca42e1ce513500d5c8c3dfa on awarenessxz:v1.5_Others into aea175bf9d094d54d2cd8006dae14c55838befd1 on CS2103AUG2017-W14-B2:master.

Coverage decreased (-0.03%) to 85.189% when pulling 9b8851999c2fd044eca42e1ce513500d5c8c3dfa on awarenessxz:v1.5_Others into aea175bf9d094d54d2cd8006dae14c55838befd1 on CS2103AUG2017-W14-B2:master.

Coverage decreased (-0.03%) to 85.189% when pulling c6c90c6c979b4bb6b3f4e2108b87ef0988f30312 on awarenessxz:v1.5_Others into aea175bf9d094d54d2cd8006dae14c55838befd1 on CS2103AUG2017-W14-B2:master.

Coverage increased (+0.04%) to 85.256% when pulling e4e0b5787591f341a7b90660863eccadf8efb84d on awarenessxz:v1.5_Others into aea175bf9d094d54d2cd8006dae14c55838befd1 on CS2103AUG2017-W14-B2:master.

Coverage increased (+0.04%) to 85.256% when pulling e4e0b5787591f341a7b90660863eccadf8efb84d on awarenessxz:v1.5_Others into aea175bf9d094d54d2cd8006dae14c55838befd1 on CS2103AUG2017-W14-B2:master.

Coverage increased (+0.04%) to 85.256% when pulling b4522271b7218f9160cfc086c5fb741b5f4bb310 on awarenessxz:v1.5_Others into aea175bf9d094d54d2cd8006dae14c55838befd1 on CS2103AUG2017-W14-B2:master.


Homebridge UI dont show update for homebridge

Describe The Bug:
Don show update available for homebridge, any issue for detect it?

Screenshots:

screenshot
Environment:

Node.js Version: 12.18.3
NPM Version: 6.14.8
Homebridge Version: 1.2.3
Homebridge Config UI X Version: 4.35
Operating System: Raspbian
Process Supervisor: hb-service

Homebridge Version: 1.2.3

The "latest" homebridge version is currently set to 1.1.6 due to some users facing issues in 1.2.x. When the "latest" version is set to be > 1.2.3 you will see an update available notification in the UI.

Ohh.. ok. So, its secure update to 1.2.4? (To me that im in 1.2.3).

Yes, 1.2.4 won't be any worse than 1.2.3 😄

Lol ok 😂, thanks.


can you zip the

first off , thanks for your great work,
secondly, could you help us who blocked by GFW, very slow  download speed.
to zip  all of pre-trained model files as one?
it will be very helpful for us download it.
thanks in advance.

I recommend that you work directly with a Dockerfile, then you can create a ready-made image with all the models loaded in the path.


Flushing UART with full buffer prevents further reads from buffer (IDFGH-6819)

Environment

Development Kit:      none
Kit version N/A
Module or chip used:  ESP32-WROOM-32D
IDF version: v4.4
Build System:         idf.py
Compiler version (run xtensa-esp32-elf-gcc --version to find it):
// 1.22.0-80-g6c4433a
Operating System:     Windows
environment type: PowerShell
Using an IDE?: Yes, VS Code with Espressif IDF extension
Power Supply:         external 3.3V

Problem Description
When calling uart_flush() with a full UART RX buffer, the ring buffer is cleared, but all subsequent calls to uart_read_bytes() return zero bytes. I have tracked the problem down to  "xSemaphoreTake(rbGET_RX_SEM_HANDLE(pxRingbuffer), xTicksRemaining)" returning pdFALSE in ringbuf.c at line 776 and subsequently not actually reading any data. This essentially means, that once you call uart_flush() with a full RX buffer, you can no longer read any UART data until you reboot the device. If the buffer is not full, when flushing, everything functions as expected.
Expected Behavior
calling uart_flush() with a full UART RX buffer, clears the ring buffer and subsequent calls to uart_read_bytes() return data received after flushing.
Actual Behavior
calling uart_flush() with a full UART RX buffer, clears the ring buffer but subsequent calls to uart_read_bytes() return 0 bytes.
Steps to reproduce

Load the uart_echo example from the release/v4.4 branch
Configure pins etc. in menuconfig
Paste code below into uart_echo_example_main.c
Compile and upload to ESP
Launch JTAG debugger
Send enough data to fill UART buffer
Set a break point at "if (change_me == true)"
change the value of change_me to true
Follow code execution

Code to reproduce this issue
GIST
Debug Logs
Debug log goes here, should contain the backtrace, as well as the reset source if it is a crash.
Please copy the plain text here for us to search the error log. Or attach the complete logs but leave the main part here if the log is *too* long.

Other items if possible

[x] sdkconfig file (attach the sdkconfig file from your project folder)
[x] elf file in the build folder (note this may contain all the code details and symbols of your project.)
[ ] coredump (This provides stacks of tasks.)

files.zip

https://github.com/espressif/esp-idf/commit/708e3b6ec0a21bdba1e9b1b7a21af629b5692b83

That definitely looks like the solution. Thanks! Just curious, any reason this was not included for v4.4 launch? Also, would you recommend switching my (still in development) project to the master branch or just manually port this patch to v4.4?

Thanks for reporting and the notes. We have back ported the fix to release/4.4, currently under internal reviewing. Will sync up once the fix on release/4.4 is available.

I have manually applied the commit changes to my uart.c and can confirm, that the problem is resolved. As far as I am concerned this issue can be closed, unless @o-marshmallow wants to do anything else.

Hi @gril002 , thanks for confirming it works.
Personally, I would advise you to stay on release/v4.4 branch as master is slowly making its way to the next major version.
Any bug found on master and v4.4 will be fixed to master and then backported to v4.4. This current fix is currently under (internal) review, it will soon be merged to release/v4.4 branch.

Is it also present in release/v4.3, would it be possible to backport it there as well please?

Is it also present in release/v4.3, would it be possible to backport it there as well please?

The fix is already in v4.3 branch: a5a4718600498034ffa741c4351d36b7a3361290

Brillant, thank you.

I'm sorry, I'm having the same issue that has been described here, but I'm not sure if I understand what needs to be done to resolve it.
I'm using IDF 4.3.1 and I would prefer not to change it as things are running smooth (except for this one), and I remember that it was not an easy process to update the version that I was running before getting 4.3.1.
So, should I just take the new uart.c and put it ...\components\driver folder, and where to take it from?
Thanks a lot.


added dockerfile and example docker compose file

Hi guys,
Thought nowadays it's important to add basic dockerfile for that important utility.
It's not close to cover all use cases, my focus was to enable my use case which is to route uart device to UDP port, feel free to modify to your needs.
Also, I added a little docker-compose example to show a use case I find important

Any reason to require running it inside a container rather than directly on host?

Sure,
Docker allows easy deployment, I don't have to worry for dependencies to be installed on the host or configuration files.
The Image I built if fully packed with the dependencies relevant to mavlink-router and all I have to do is to include it in my k8s configuration to make it work.
I have no affinity to any host, this is the easiest & most efficient way to scale a working solution in my opinion.

Merged another PR adding 2 example docker containers


Restaurant review fine-tuned model link problem

The link points to the dataset instead of model checkcpoint?

Thanks for pointing this out. The problem is fixed now.


Doesn't work on Windows XP

I have Ruby 1.8. 7 on win XP installed, and it doesn't work at all for me. Everytime it's just says "invalid option -U  (-h will show valid options) and nothing more with any switches.

Hi Dimsok, thanks for reporting this. Ruby 1.8.7 was released in 2008 and is no longer supported or maintained by the Ruby developers. Versions as early as 1.9.3 seem to be working fine. Are you able to test this out on a newer version of Ruby (or Windows) to see if it works there?

I can't use latest version cause of XP. I did try ruby-1.9.3-p551-i386-mingw32, make install nokogiri, but it shows some error, Maybe it's because that i tried it in portable mode or not installed all needed components as listing in script.
 I have installed gem and try to fine gems for needed components on rugems.org, but mostly gems only for ruby 2.5 and don't have old version.  Or all these not really necessary?
require 'yaml'
require 'fileutils'
require 'zlib'
require 'optparse'
require 'nokogiri'
require 'open-uri'

Yes, you definitely need all of the required gems or the script won't work at all. For example, without zlib you won't have any way of opening the .dict.dz files to search inside of them.

Ok, i made it works, but still can't use cause of 2 reasons:

The default way "c:\Documents and Settings\Administrator.goldendict" is works but when i try to set :dict_dir: "H:\Progam files\GoldenDict\content\dicts", i get:
C:/Program Files/Ruby/lib/ruby/1.9.1/psych.rb:203:in parse': (<unknown>): fou unknown escape character while parsing a quoted scalar at line 15 column 12 ( ych::SyntaxError)      from C:/Program Files/Ruby/lib/ruby/1.9.1/psych.rb:203:in parse_strea
 from C:/Program Files/Ruby/lib/ruby/1.9.1/psych.rb:151:in `parse'
 from C:/Program Files/Ruby/lib/ruby/1.9.1/psych.rb:127:in `load'
 from C:/33/gdcl-master/gdcl.rb:26:in `<main>'

When i try search words with cyrillic, i get:
C:\Documents and Settings\Administrator.goldendict\dic\en>C:\33\gdcl-master\gdc
l.rb en аберрациия
C:/33/gdcl-master/gdcl.rb:239:in sub': incompatible encoding regexp match (UTF- 8 regexp with ASCII-8BIT string) (Encoding::CompatibilityError)      from C:/33/gdcl-master/gdcl.rb:239:in block in '
from C:/33/gdcl-master/gdcl.rb:238:in each'      from C:/33/gdcl-master/gdcl.rb:238:in '

Is there a way to resolve it?

Your problem 1. is because you were using Windows "" characters to separate your file path, rather than "/". Ruby uses "/" to separate paths, regardless of the OS you are using. You should be able to figure out how to fix it using the information in the StackOverflow link.
Your problem 2. may just come down to the fact that you are using XP. Are you sure that XP supports UTF-8?

Of course it supports utf8.  Or are you talking about command line? I can see chinese characters etc, but not in command line. If so. is there a way to use ansi 1251 instead of utf8?

The first was resolved, the second no after i did try chcp 65001 in cmd.
By the way, is there a way to use it portable? I mean always store config.yml in folder of  gdcl.rb and not copy it to .config.


sprig.pushUrl doesn't work when adding a hashtag to create a jump link

I've got a matrix block that is sprig reactive and I am successfully pushing the category to the url so the tabs display correctlyk when deep linking. However what I need is to add a #section-4068 (4068 temporarily hard coded - is actually block.id from a matrix field) so that the browser will smooth scroll to the correct section on the page.
I've tried this:
  {% do sprig.pushUrl('?' ~ {categoryId: categoryId,} ~ '#section-4068' |url_encode) %}

but then I get an Array to string conversion error.
I tried a couple of other options but nothing seemed to work.
manually typing this for the browser works as expected but I need to be able to push the hash.
https://dpmc-2023.ddev.site/fellows?categoryId=4264#section-4068

The error, assuming it pertains to the line you shared, seems to indicate that categoryId is an array. Since I can’t see the rest of your code though, I can’t say why that might be.


Inconsistent colors for checked checkbox and focused input

According to this guidline, checked checkbox and focused input should have the same colors.
But in MUI v1-alpha I've found the follovwing colors:
Input inkbar - backgroundColor: theme.palette.primary[theme.palette.type === 'light' ? 'A700' : 'A200'],
Checked checkbox - color: theme.palette.primary[500],
Is it expected behavior?

Sounds like an inconsistency with the specification.
The specification asks for the TextField the following:

Color: 100% primary color (Dark A700)

so theme.palette.primary.A700
And asks for the selection controls the following:

On: Swatch 500, Opacity 100%

so theme.palette.primary.500
From my perspective, we are good.

Actually, I'm wondering if we should make a call and normalize the TextField spec to the selection controls.

Well, I don't have much argument for either direction. Let's stick to the specification for now.


Tab AutoComplete + exit/quit

@ideoforms here's the full list based on README.md
with autocomplete.
now there's 203 different hooks/handlers.
looks like this:

there's also exit and quit for exiting cleanly.
fixes part 1 of https://github.com/ideoforms/AbletonOSC/issues/36
it does not address Add serialisation to allow querying history from previous sessions cos i'm betting that's a big deal.

Nice, definitely a quality of life improvement and code looks good - thanks! Will merge now.
I think readline provides some kind of internal history tracking that might make it straightforward to resume history from previous sessions, but no need to address both here.


GM: Tahoe/Yukon 2019 Support

Checklist

[x] added entry to CAR in selfdrive/car/*/values.py and ran selfdrive/car/docs.py to generate new docs
[ ] test route added to routes.py
[ ] route with openpilot:
[ ] route with stock system:
[x] car harness used (if comma doesn't sell it, put N/A): GM Bolt/Camera Harness

Closing because I can't get tester to upload a route and due to Comma's lack of interest into porting new GM cars at this time.


Better error message

Ensures that the error raised contains the from and to currency codes.
Prior to this change, the error raised would not contain the from & to currency codes, eg:
Exchange::NoRateError: No rates where found for  to 1.380024 at Sun Aug 01 00:00:00 +1200 2010
This is because the method only raises an error when from_code and to_code are nil. This is an perfectly fine way to raise the error, but it also means that those nil values are getting used in the error message string. This commit supplies the original from & to codes as well, so they they may be used in the error message.
This is a fairly ugly and direct way to fix this issue, so feel free to take it or leave it -- but please do add the currency codes to the error message one way or another.

I will put some work into this in the next days in order to provide a patch. Thanks for raising the issue.


fix(tx_pool): mark tx as known only after is is verified and inserted…

… in the tx pool or db
Purpose

How does the solution address the problem

Changes made

prnet cleaned-up successfully

Actually this is not good fix, you have created bug, when you do not mark non-valid transaction as know. Even transaction that fails validation should be mark as know

Never mind, this is not needed


TS definitions

Hi Sindre,
I added TypeScript definitions as I'm using this in a TS project. I've tested the definitions with yarn link and they are working fine for me, however let me know if I overlooked something or if you'd rather have it in a @types module.
Mvh
Sindre

Sorry, it's better to publish them to DefinitelyTyped, see https://github.com/sindresorhus/ama/issues/439 for more info.

OK, I was not aware, I'll publish them to DefinitelyTyped instead.

Published, just waiting for the PR to go though: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/27299

I now accept TypeScript definitions if anyone looking is interested in submitting it here.
See: https://github.com/sindresorhus/ama/issues/439#issuecomment-414212229
Please follow this guide: https://github.com/sindresorhus/typescript-definition-style-guide


Fixed bugs for conv2d

Solved bugs raised by @zhreshold and https://github.com/dmlc/tvm/issues/1420

please followhttps://docs.tvm.ai/contribute/code_review.html#ensure-test-coverage to add regression testcase to avoid this from happening again

Thanks @Laurawly for fixing it. I can confirm it works for my workloads.
However apparently the default kernels are not optimized for intel graphic cards, therefore it's running much slower than cpu with apple blas. I will look into autotvm later.

Mac intel graphics doesn’t recognize intel sub group shuffling instructions somehow, that’s why you have to call the cuda schedule which is not optimized for intel graphics. @tqchen should we make the intel subgroup shuffle instructions banned when running on intel graphics on Mac?

Just had a quick conversation with Yida offline, he mentioned there's Intel's extension to OpenCL which adds support of subgrouping, just wondering if you are familiar with that on Mac?


Tests multi/hybridArcVariationalEquations failing sometimes

Running the tests for the develop branch of tudat, the tests 160 (test_propagators_MultiArcVariationalEquations) and 161 (test_propagators_HybridArcVariationalEquations) sometimes fail, so I guess there is some undefined behavior going on. Tests were run on macos 13.2.
Error logs are attached.
error_test160.txt
error_test161.txt
@DominicDirkx Should I assign this to someone (whom?)?

Hi Miguel, very strange... We'll have a look at this in the near future. Could you assign me and Marie?

Hi Dominic. As requested, I ran the two test in debug mode, the errors are attached. The errors continue to only happen occasionally.
For the hybrid arcs test the error continues to be
std::runtime_error: Error, for arc 2 out of 2, body Mars is estimated but not propagated.
For the multi arcs test the error now is
std::runtime_error: Error, for arc 5 out of 10, body Earth is estimated but not propagated.
(before it was failing for arc 2 out of 10).
error_test_hybrid_debug.txt
error_test_multi_debug.txt

Can you get a stack trace from the debugger from it?

Fixed!


⚠ Jenkins Plugins Artifactory has degraded performance

In fb869da, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1227 ms

Resolved: Jenkins Plugins Artifactory performance has improved in f36c62c after 39 minutes.


docs: add v0.2.1 release details to the CHANGELOG

Description
Add the v0.2.1 release details to the changelog.
Review Checklist

[ ] I have added documentation for new/changed functionality in this PR or in openfga.dev
[X] The correct base branch is being used, if not main

Codecov Report

Merging #203 (2baa428) into main (2dfe665) will decrease coverage by 0.02%.
The diff coverage is n/a.

:exclamation: Current head 2baa428 differs from pull request most recent head 94a2ee6. Consider uploading reports for the commit 94a2ee6 to get more accurate results

@@            Coverage Diff             @@
##             main     #203      +/-   ##
==========================================
- Coverage   75.73%   75.71%   -0.03%
==========================================
  Files          79       79
  Lines        8897     8897
==========================================
- Hits         6738     6736       -2
- Misses       1762     1763       +1
- Partials      397      398       +1

Impacted Files
Coverage Δ

server/commands/check.go
86.27% <0.00%> (-0.57%)
:arrow_down:

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


The new cookies API doesn't actually set cookies in Safari?

Describe the bug
I've migrated to SvelteKit 1.0.0-next.475 and its new cookies API, and logging into my website no longer works, cookies are no longer set at all.
Reproduction
https://github.com/kevinrenskers/sk-cookie-bug
On the homepage I show the token which is stored in a cookie, which of course defaults to undefined. There is a link to a login page, which has a login button. This does a request to a local endpoint, which sets a cookie. It then redirects you back to the homepage, and that token should now be updated.
In reality the token is still undefined, and looking at the cookies in the storage inspector, there is nothing there.
This used to work with the previous set-header method just fine.
Logs
No response
System Info
System:
    OS: macOS 12.5.1
    CPU: (10) arm64 Apple M1 Max
    Memory: 574.67 MB / 32.00 GB
    Shell: 3.5.1 - /opt/homebrew/bin/fish
  Binaries:
    Node: 16.17.0 - ~/Library/pnpm/node
    npm: 8.15.0 - ~/Library/pnpm/npm
  Browsers:
    Safari: 15.6.1
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.71
    @sveltejs/kit: next => 1.0.0-next.475
    svelte: ^3.44.0 => 3.50.0
    vite: ^3.1.0 => 3.1.0

Severity
blocking an upgrade
Additional Information
No response

Update: it works fine in Microsoft Edge and in Chrome, but not in Safari (version 15.6.1).

I think it's because secure: true is the default when using cookies.set.
Safari doesn't allow setting https only cookies on http connections, while other browsers understand we are developing and it doesn't matter.

You're right, setting secure specifically to false fixes the problem. Ugh.
Maybe SvelteKit should use the dev environment value to automatically do this, instead of always using secure: true as the new default.

Deleting cookies doesn't seem to work either, in none of the browsers. I've added a logout button to my example repo which deletes the cookies in a server endpoint but nothing happens, cookie is still there. Not just in Safari, also Chrome.

Deleting cookies doesn't seem to work either, in none of the browsers. I've added a logout button to my example repo which deletes the cookies in a server endpoint but nothing happens, cookie is still there. Not just in Safari, also Chrome.

I have a related issue #6609 (waiting for it to be re-opened as it still persists).
You can try the workaround mentioned here.

Ha yea I just found the same workaround. But even then the homepage doesn't update to reflect the newly deleted token, even when calling invalidateAll().

Maybe SvelteKit should use the dev environment value to automatically do this, instead of always using secure: true as the new default.

@kevinrenskers I see your point, but that might open another can of worms. "Hey, what happened, SvelteKit's making my secure cookies insecure!"
AFAICT Safari is the main problem -- Chrome and FF accept secure cookies over http://localhost. Not sure about Edge, but it should be Chrome-like. Maybe the solution is documenting this?

Why is SvelteKit choosing the default to be secure anyway, if that causes problems in a major browser? Seems better to leave it up to devs to set this themselves, then there is no hidden behavior that you then have to work against.

I think it would be clearer if the defaults matched the regular cookie-setting defaults, especially if not doing so breaks things on a major browser.
With normal cookies, they are secure if you set them to be.
Next best would be using the dev flag, which is what anyone who wants secure cookies will end up using anyway.

This is hopefully fixed in the latest release by https://github.com/sveltejs/kit/pull/6811


Need UI to Design.

UI to design

https://xd.adobe.com/view/182db13e-dc6a-40ec-a319-5bf018182399-4d7e/screen/f5bd120e-aa6f-4478-a67c-a0cae74f1f9c/

Verified this issue on dev app v1.9.0(329)


Memoizing

Dynamic programming appears to be basically recursive, memoized algorithms. What's a nice way to do memoization in Go?
@FilWisher

Here is quite a clear explanation of memoization vs dynamic programming
Although from a high level view, it seems like tabulation and memoization are playing the same role from slightly different angles.
We would have to know the problem being solved first (I suggest we find one) and then either using tables or or maps.

I think that whether you memoize vs tabulate is basically the difference between top-down vs bottom-up? We've seen some examples of both I think. Still, we should probably do some tabulation as that's more of a change for us.
I'm for maps!

This is issue is being automatically closed as it's more than a year old. Please feel free to reopen it if it's still relevant to your project.


[FEATURE] Improve test coverage for SpacyColumn and SpacyCell

Important to test CellColumn, Khaled ran into an issue where
Fixed the issue with #140, but still need tests.


Encoding of Numeric inside a custom type panics

I receive a panic when I try to insert entries with custom types containing Numeric fields. The  relevant schema looks like this:
CREATE TYPE product_dimension AS (
  type TEXT,
  unit TEXT,
  value NUMERIC(8,2)
);

CREATE TABLE product (
  [...]
  dimensions product_dimension[],
  [...]
);

I get the following error message If I try to insert a row with value = 55.44:
panic encode []ProductDimension: cannot convert {5044 -2 2 false} to Numeric

I guess he is trying to convert a Numeric struct to a Numeric struct, but I might be wrong. This is the generated code that causes the panic:
func (tr *typeResolver) newProductDimensionArrayInit(ps []ProductDimension) pgtype.ValueTranscoder {
	dec := tr.newProductDimensionArray()
	if err := dec.Set(tr.newProductDimensionArrayRaw(ps)); err != nil {
		panic("encode []ProductDimension: " + err.Error()) // should always succeed
	}
	return textPreferrer{ValueTranscoder: dec, typeName: "_product_dimension"}
}

Considering that the comment says should always succeed I'm inclined to think that this might be a bug.

Thanks for the detailed report. I can reproduce. The error is that pgtype.Numeric cannot be Set from another pgtype.Numeric instance. This doesn't occur with other numeric types because they're mapped to a literal type; pgtype.Int8 uses the Go int64 scalar type.

panic encode []ProductDimension: cannot convert {5044 -2 2 false} to Numeric

That's the Go representation of a Numeric type, 5044e-2 (assuming you meant 50.44 instead of 55.44).
Here's the minimal reproducible case:
func TestNewQuerier_SetNumericType(t *testing.T) {
	num := &pgtype.Numeric{}
	require.NoError(t, num.Set(64))
	decoder := &pgtype.Numeric{}
	err := decoder.Set(num)
	require.NoError(t, err) // same error here
}

I'm not sure if this is intended behavior by pgtype. I expected that pgtype.Numeric could be Set from another pgtype.Numeric but I'll file a bug upstream to make sure.
As a workaround, I tried to set --gotype 'numeric=*string', so you could use a string type for numeric. That didn't work. I'll take a look at making that work since that's a clear bug in pggen.

So, we're a bit stuck. Here's the options:

We can't use pgtype.Numeric because pgtype.Numeric.Set doesn't support being set from another instance of pgtype.Numeric.

--gotype numeric=*string doesn't work because AssignTo doesn't support assigning to a string pointer, which pggen relies on for decoding. Curiously, pgtype.Numeric.AssignTo doesn't support strings, but pgtype.Numeric.Set does support strings. I'll open a PR to add assigning a numeric to *string but that blocks the fix of decoding to a string.

--gotype numeric=float64 will work but you might lose precision.

--gotype numeric=int64 will work but only for whole numbers. It fails on any numeric with a fractional part.

Short term, you're best bet is probably to rely on an external type and register the encoder and decoder: https://github.com/jackc/pgx/wiki/Numeric-and-decimal-support.
Medium term, --gotype numeric=*string should work for all cases but is blocked by merging a PR into pgtype for pgtype.Numeric.AssignTo. I'd like to avoid requiring an external library.

I added an example of how to make this work with a real Decimal type in 7f87888. The main trick is to register the data type on the Querier:
	q := NewQuerierConfig(conn, QuerierConfig{
		DataTypes: []pgtype.DataType{
			{
				Value: &shopspring.Numeric{},
				Name:  "numeric",
				OID:   pgtype.NumericOID,
			},
		},
	})

And then, when invoking pggen, use: --go-type numeric=github.com/shopspring/decimal.Decimal.

@jschaf Thank you for your quick and detailed feedback. I was already using float64 as input, so the workaround with --gotype numeric=float64 didn't come with any additional loss of precision.


make component_id available in component's template context

Sometimes you have to create child components with need of sub HTML tags with certain IDs. It would come handy to know the ocmponent_id in the template, to create things like

...

ATM this is only possible if you save it in a normal attribute, or save it in a "readonly" attribute like _id in __init__(), and override get_context_data to include this attr in the context.
Would you mind to add component_id to the general included context attrs?

BTW, maybe component_key as well? In case of anyone needs it?

@nerdoc Good idea! That should be straight-forward to add it in. I'll do it for the next release. 👍

Should be fixed in 0.44.1 which I just deployed: https://pypi.org/project/django-unicorn/0.44.1/.

Hmmm. Using 0.44.1, the values are available under unicorn.component_{key|id|name}, but...:
  ID: {{ unicorn.component_id }}

  Name: {{ unicorn.component_name }}

  Key: {{ unicorn.component_key }}

produces:
ID: UTCAwWeL:core.nullable-check-button:16
Name: core.nullable-check-button
Key: 16

What I need here (and I suppose most of the people needing this feature, too...?) is, to use the name and id as their corresponding HTML attributes. But you can't use strings with ":" and ":" in an identifier in HTML.
So a
<input
  id="{{ unicorn.component_id }}"
  name="{{ unicorn.component_name }}"
  ...
>```
is not possible here.

I know - if you replace each ./: with an unterline or hyphen, it would be possible, but then the strings would not be tracable back to their origin's component ID...

I think you have to decide - I for myself would even go so far to change names and ids within Unicorn to HTML-usable ones, meaning getting rid of the colons and dots...?

A possible (quick & dirty) solution would be replacing the 2 lines in unicorn_view.py, line 488f, with
"component_id": self.component_id.replace(":","_").replace(".","_"),
"component_name": self.component_name.replace(":","_").replace(".","_"),

Ok, I totally forgot about nested components. That's an internal identifier, so I could potentially change the colon to a pipe | instead? The dot I might just replace as you are here. Thanks for being this to my attention, do you want to make a new issue for this?

No, pipe is as good as colon. So if you need these colons as separators internally, the HTML ids could be "shadows" of them, and don't need to be reflected back into python code any more, right.
In this case, my solution with replacing everything with a hyphen or underline would work anyhow - as long as no one comes to the blunt idea of putting that HTML identifier back into code and reference a component in the backend.
What you have to think about is nesting, yes: if some component wants to change data in the parent's backend, it can use parent. But if someone uses e.g. unicorn.component_id in the frontend to reference another component in a row in the backend, struggle begins.
So maybe it is better to keep them "in sync" and use consistent names.
Another possibility would be .replace(":","_").replace(".","-") or .replace(":","__").replace(".","_").


x/crypto/ocsp: ParseResponse makes incorrect choices about response and issuer verification

x/crypto/ocsp makes an incorrect assumption about the contents of the BasicOCSPResponse's certs field and has a broken API as a result.

Per RFC 6960 Section 4.2.1 ASN.1 Specification of the OCSP Response:

The responder MAY include certificates in
the certs field of BasicOCSPResponse that help the OCSP client verify
the responder's signature.  If no certificates are included, then
certs SHOULD be absent.

Notably, the RFC makes no assertions about the contents of these certificates, whether they are strictly delegated OCSP issuers (as discussed in another Go issue or whether they can include or not include intermediate CAs necessary to tie the OCSP responder's cert back to a concrete root.
However, x/crypto/ocsp's ParseResponse and ParseResponseForCertificate incorrectly assume that any certificates included in the response are a delegated OCSP signer and its chain, assuming the delegated OCSP signer is the first certificate. This is not guaranteed by the RFC and is not assumed by other OCSP libraries. Go is unique and non-conformant in this regard.
In particular, if the caller passes an issuer parameter value, Go incorrectly assumes that this issuer must have either directly issued the OCSP response or issued the first certificate in the BasicOCSPResponse's certs field.
This has no basis in the RFC.
Further, and more risky is the beavhior around issuer=nil: here, while the BasicOCSPResponse's certs field is used to verify the signature, no grounding to a trusted certificate. This is only safe over a secure transport for OCSP requests/responses and the docs make no mention of this. (cc @golang/security and @rolandshoemaker).

As discussed at a previous issue, this assumption about the structure of BasicOCSPResponse is at least historically invalid for public CAs.
For private CAs:

Vault's PKI OCSP responser provisions the Certificates field pointing to the leaf's issuing CA (which also issued the OCSP response).
Dogtag PKI's OCSP responder does similarly, but supports external (delegated) OCSP certificates in addition to provisioning the full chain of the leaf.
Without running, it appears the Packetfence OCSP responder follows the same approach wherein the CA certificate is again provisioned here in the Certificate field.

I've not checked other CA libraries, but given we've now found three independent private CAs with this behavior that aren't forbidden by spec, and given Go seems alone in this behavior (and other tools like openssl do the right thing), it seems like fixing Go is the correct approach.
On the usage side, the story is more complicated.

Square's certigo library uses the issuer in the response field, meaning if they'd be affected by this issue in Go's OCSP parsing if contacting one of these private CAs.
Snowflake's ocsp.go library has the same issue.
Caddy's certmagic has the same issue.
Google's webpacker, might appear to use this in a security-critical context with a nil issuer, though it looks like the chain-related version below has correctly specified an issuer.
Digitorus's pdfsign appears to read OCSP info out of the PDF context and attempt to verify the info there, which might be considered a security problem.

This shows that consumers of Go's OCSP library are likely unaware of the implications of the API design of passing a non-nil issuer.
Most usages of nil parameters seem safe on first glance, but their authors should probably investigate further. Since I didn't see any really obvious incorrect usages, and the other behavior is a fail-closed behavior, I did not think this warranted a security issue.

I'd propose the following fixes:

Update the docs to more adequately warn about specifying a nil issuer here.
Update the API to correctly return all certs fields, allowing callers to perform more advanced chain building with a nil issuer parameter if they desire.
Fix the library to not err if issuer == certs[0] (i.e., if issuer != certs[0], do the signature check that exists today).

This appears to be the minimally invasive sets of changes that allow more complex libraries tao get more correct behavior while affecting the library the least.
As I get time, and if people here are happy with this, I'll open a CL with these changes.

See also: https://github.com/golang/go/issues/21527
See also: https://github.com/golang/go/issues/40017
Reproducer: https://go.dev/play/p/Nr-VKOD_fxH

What version of Go are you using (go version)?

$ go version
go version go1.20.3 linux/amd64

Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/cipherboy/.cache/go-build"
GOENV="/home/cipherboy/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/cipherboy/go/pkg/mod"
GONOPROXY="github.com/hashicorp"
GONOSUMDB="github.com/hashicorp"
GOOS="linux"
GOPATH="/home/cipherboy/go"
GOPRIVATE="github.com/hashicorp"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.20.3"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/cipherboy/GitHub/cipherboy/vault/go.mod"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build652088920=/tmp/go-build -gno-record-gcc-switches"

What did you do?
Above, including reproducer.
What did you expect to see?
Go should not have erred on the first ocsp.ParseResponse call with the issuer.
What did you see instead?
Go erred with bad OCSP signature: crypto/rsa: verification error

cc @golang/security

Notably, the RFC makes no assertions about the contents of these certificates, whether they are strictly delegated OCSP issuers (as discussed in https://github.com/golang/go/issues/40017 or whether they can include or not include intermediate CAs necessary to tie the OCSP responder's cert back to a concrete root.

I think the RFC is a little vague and confusing (in an extremely PKIX-y way) here. There is no restriction put on what can be in certs, just saying that they help the OCSP client verify the responder's signature. That said RFC 6960 Section <IP_ADDRESS>. requires that if a delegated signing certificate is used it should be issued by the certificate that signed the certificate being checked. In the delegation case certs then only really needs to contain a single certificate, but the RFC leaves the door open to put whatever else you want in there.
In theory you can put the rest of the chain (e.g. delegated signer -> intermediate issuer -> root) in the response, but we have no interest in verifying the rest of that chain (or any other chain in the response) since we only care that the delegated signer links back to the issuer of the certificate being checked (https://go.dev/cl/57510 contains some previous discussion of this behavior, and why we do what we do).
I think one of the reasons the API is designed in the way it is, and assumes that the caller has the issuer on hand, is that if you are verifying the validity of a certificate, you are, 99% of the time, going to have its issuer on hand. In theory there could be value in verifying OCSP responses that contain the fully chain from OCSP signer to certificate issuer for cases where you do not have the issuer already, but I'm not sure there are any real world cases where this is the case (at least ones I'd want to explicitly support).

For private CAs

These are interesting examples, and given there are implementations in the wild we probably need to consider supporting them, but I'm not entirely clear what value is being added here.
From the Vault perspective, what is the rationale for including the issuing certificate (which isn't delegated) to the response? Is it expected that the relying party won't already have it? It seems like this unnecessarily inflates the size of the response.

Update the docs to more adequately warn about specifying a nil issuer here.

Seems reasonable to say this should only be done if the response was provided over an otherwise trusted channel. Even with that said though we probably also should be explicit that if issuer == nil you need to check that the response was signed by a certificate issued by the certificate that signed the response (I wish we'd never included signature verification in parsing, this API is cursed).

Update the API to correctly return all certs fields, allowing callers to perform more advanced chain building with a nil issuer parameter if they desire.

Not sure I'm convinced this is something we really want to support. Just exposing all of the certificates sent isn't particularly complicated, but it encourages users to use OCSP in a way that isn't really relevant to web PKI (which is the subset of PKIX that we target, in an attempt to prune away the overwhelming complexity that is PKIX), and that I don't think we have any particular interest in providing broader support for elsewhere (i.e. in the standard library).

Fix the library to not err if issuer == certs[0] (i.e., if issuer != certs[0], do the signature check that exists today).

Seems reasonable to handle this redundancy, since it does appear in the wild.

@rolandshoemaker writes:

That said RFC 6960 Section <IP_ADDRESS>. requires that if a delegated signing certificate is used it should be issued by the certificate that signed the certificate being checked. In the delegation case certs then only really needs to contain a single certificate, but the RFC leaves the door open to put whatever else you want in there.

I don't think this is quite a valid read, though I agree in practice.
Notably, that paragraph in RFC 6960 goes on to write:

The CA SHOULD use the same issuing key to issue a delegation certificate as that used to sign the certificate being checked for revocation.

and further, the extended note is of relevance:

Note: For backwards compatibility with RFC 2560, it is not
prohibited to issue a certificate for an Authorized
using a different issuing key than the key used to issue the
certificate being checked for revocation.  However, such a
practice is strongly discouraged, since clients are not
required to recognize a responder with such a certificate as an
Authorized Responder.

Which is to say, this is likely another case where the CA the Entity (with a capital E) is different than "the concrete certificate with the IsCA basis constraint assert) and something legacy did happen, I agree.
But, more to the point, nothing guarantees the first item is also the responder.

Finishing the investigation, I think EJBCA has the same issue:

responseChain is built from fullCertificateChain.
It builds the OCSP response with this full chain -- either of the signing CA or with the delegated signer AND the signing CA's chain.
BouncyCastle will happily include that chain in the ASN.1 response.

Following that BouncyCastle lead:

Maritime Connectivity PKI seems to have the same behavior as Vault, assuming it is configured to directly use the ICA and not a delegated signer (unverified whether this is possible or not).
If my read of otoroshi is correct this directly uses the root CA and again places it in the certs field.

So yeah, we can fix this on the Vault side, but this is a lot of additional private CAs--including EJBCA--that have this same behavior.
Go is broken validating all of them.

Yeah, I think it'd probably also be reasonable to just iterate across all of the certificates in certs to find one that validates the signature, rather than always picking the first one 🤷.

Thanks Rolland! I'll pick this up on Monday with a patch set then.

A

On Fri, Apr 14, 2023, 17:37 Roland Bracewell Shoemaker <
@.***> wrote:

Yeah, I think it'd probably also be reasonable to just iterate across all
of the certificates in certs to find one that validates the signature,
rather than always picking the first one 🤷.
—

Reply to this email directly, view it on GitHub

https://github.com/golang/go/issues/59641#issuecomment-1509303541, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAG7E3QCPQCJSLW27AJTW6LXBG7Q3ANCNFSM6AAAAAAW6ZUWPQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

It looks like the linked Gerrit CL was filed over a year ago, but  it was never reviewed and no further progress was made.
This has become relevant again in this (invalid) bugzilla CA incident report. The incident report was filed because an external tool (SSLMate's OCSP Watch) was reporting that the CA's OCSP responses are malformed because it can't verify their signature. However what is actually happening is that the CA has embedded the issuing certificate (which is not a delegated responder) in the OCSP response's certs field. Therefore x/crypto/ocsp's requirement that certs[0] be signed by issuer fails, because those are in fact the same CA.
What is the status of the attached CL? Does the Go crypto team intend to review it and move towards merging it? Has there been a decision to not move forward with a slightly-more-permissive ocsp.ParseResponseForCert API?
I'd be happy to take over moving this forward, if Alex Scheel no longer wants to drive it.

This slipping through the cracks is my fault. Given this is the first time we've heard about it cropping up in the wild again though makes me agree with @AGWA that perhaps this does not seem so widespread of a misconfiguration to warrant additional complexity.
Our behavior here is strange though, in that the documentation is vague in what we enforce, and we should at least be documenting the constraints that ParseResponse has (and perhaps why), since they are clearly not obvious (especially to anyone who hasn't been staring at PKIX RFCs for multiple hours a day).
I think really what we need, as @aarongable mentions, is a new, somewhat less cursed OCSP API, but that requires investing the time to design one.

...their responder is nevertheless misconfigured...
...reject these broken respones...

I strongly disagree with both of these characterizations. Their OCSP responses are fully compliant with both the letter and the spirit of RFC 6960, and with other major OCSP-validation implementations. Their responder is not misconfigured, and their responses are not broken. They are just incompatible with Go's implementation decisions.

In this case, there is only one (brand new) WebPKI CA affected, and they're fixing their responder, which makes this a good place for Go to hold the line.

But I think this is a totally reasonable stance to have. I think it's fine for Go to take a strongly opinionated stance here, with two caveats:
a) as Roland says, that stance needs to be well-documented (I'm happy to file a PR to improve the documentation here, and then this issue and other related CLs should be closed); and
b) ideally the WebPKI community should have some way to know that violating Go's constraints here is a meaningful finding that should be fixed, but not a CA incident.

I think really what we need is a new, somewhat less cursed OCSP API

My back-of-the-napkin proposal would be to mirror x509.RevocationList, i.e. only provide two methods:
func ParseOCSPResponse(der) (*OCSPResponse, error)
func (*OCSPResponse) CheckSignatureFrom(*Certificate) (error)

The CheckSignatureFrom method would require that the signature "chain up to" to the provided issuer certificate, but would be willing to use one of the certificates from the response's certs field as a delegated responder between the response itself and the provided issuer. It would enforce that the delegated responder has the id-kp-OCSPSigning EKU, but nothing else (e.g. it wouldn't check that the delegated responder is not expired or not revoked).


Gold star added

Fixes Issue ##8848
Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[x] My change requires changes to the documentation.
[x] I have updated the documentation accordingly.
[x] All new and existing tests passed.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

I will add a modal so when clicked, it will display a Premium Account description. Much like X's verified account blue check.

Closing to reopen to get latest changes.


IOS: drag and drop not working on ios. while working perfectly on android.

<DraggableFlatList
data={data}
renderItem={renderItem}
keyExtractor={(item, index) => index.toString()}
onDragEnd={({ data }) => setData(data)}

const renderItem = useCallback(
({ item, index, drag, isActive }) => {
return (
<TouchableOpacity
style={{
height: 50,
backgroundColor: isActive ? colors.paratGreen : index % 2 === 0 ? colors.solidRed : colors.solidBgFb,
alignItems: "center",
justifyContent: "center",
marginVertical: hp('0.25')
}}
onLongPress={drag}
>
<Text
style={{
fontFamily: fontFamily.semiBold,
color: colors.white,
fontSize: hp('2'),
}}
>
{item.serviceName}

);
},
[]
);

I'm also facing this same issue.

We can hope that the issue will be solved soon. please when will you get
the solution for that. kindly share that solution with me.
On Thu, Sep 23, 2021 at 3:31 AM Hitesh Kumar @.***>
wrote:

I'm also facing this same issue.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/computerjazz/react-native-draggable-flatlist/issues/314#issuecomment-925375696,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKV2NFME3UMK7WMO6DUJHJDUDJKK3ANCNFSM5EEOJHSA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

@umairalirehan You might need to downgrade react-native-reanimated, v 1.13.3 is the latest working version with draggable flatlist

I also had a problem matching this description, having react-native-reanimated v2.1.0, and in the simulator drag would trigger, setting isActive to true, but no drag would occur when the gesture began. However, per #282, after disabling debugging (ctrl+cmd+z and then select Stop Debugging from the menu) the library worked as expected (even with react-native-reanimated v2.1.0).
Bottom line: if you have this issue in the simulator, try turning debugging off.

my problem solved with your help. its working now by closing debugging mode off. you are a great helper. thanks alot

I solved this issue by removing the changes made to AppDelegate.m file, which was a fix to another problem https://github.com/facebook/react-native/issues/16376#issuecomment-810094592

I also had a problem matching this description, having react-native-reanimated v2.1.0, and in the simulator drag would trigger, setting isActive to true, but no drag would occur when the gesture began. However, per #282, after disabling debugging (ctrl+cmd+z and then select Stop Debugging from the menu) the library worked as expected (even with react-native-reanimated v2.1.0).
Bottom line: if you have this issue in the simulator, try turning debugging off.

I have turn off debugging and it working. Thanks !!

Hi, I am having exactly the same issue, but I am not in debug mode.
Android works perfectly, but iOS does not.
Does this library supports latest react-native and reanimated?
I am using these versions:
"react-native": "0.73.6",
"react-native-reanimated": "^3.11.0",

still facing issue in iOS

any solutions?


added timezone update

How To Test

Type in -> anime-today America/Los_Angeles DMY
You should expect Anime for 07/07/2018 in chat.

@shoutoutloud I'll get to this sometime Monday. Thanks for contributing.

Okay will do. Thanks for pointing out.

@lamdaV  Have a look.

LGTM.
I'll update the help message and clean up a few things on my end.


Shader system improvements (redo)

An update of #2715 which updates the target branch to develop.
Provides the following changes:

Store the original values for the fragment/vertex header such that they can be accessed by child classes.
Store the original values for the fragment/vertex body such that they can be accessed by child classes.
Store the original values for the fragment/vertex source such that they can be accessed by child classes.
Added a configurable glVersion annotation (and corresponding variables) which can be used to modify the GLSL version directive. The default value has been set to 120, which should resolve an issue on some platforms where the uniform type is unavailable.
Added checks to __processGLData to ensure a variable exists before it is assigned via Reflection.

This resolves an issue caused by custom implementation of variables in child classes.
Added caching to the field check to reduce calls to Reflect.fields, improving performance.

These changes were performed to support fixes for FlxRuntimeShader, as part of pull requests HaxeFlixel/flixel-addons#368 and HaxeFlixel/flixel-addons#399. Making changes here prevents code duplication in FlxRuntimeShader, improving maintainability.
These changes have been tested with Friday Night Funkin', where it is used on Windows, MacOS, Linux, and HTML5 platforms.

Can confirm that our usage in it for FNF has gone well and it's been pretty battle tested!


command line arguments should overwrite --profile

Is your feature request related to a problem? Please describe.
Currently, arguments in the profile config.yaml override given command line arguments. For example, if you have a profile that specifies
jobs: 10

but submit with snakemake -j 16 --profile some-profile, it will run with -j 10, not -j 16.
Describe the solution you'd like
Command line arguments provided should overwrite the given --profile.
Describe alternatives you've considered
Additional context

Hi,
Thanks for the report but I can't reproduce this:
(_hesiod_venv) [tbooth2@edgen-login0 snaketest]$ cat some-profile/config.yaml
jobs: 10
(_hesiod_venv) [tbooth2@edgen-login0 snaketest]$ cat Snakefile
rule dummy:
    shell:
        "echo HELLO"
(_hesiod_venv) [tbooth2@edgen-login0 snaketest]$ snakemake --profile ./some-profile/
Building DAG of jobs...
Using shell: /usr/bin/bash
Provided cores: 10
...
(_hesiod_venv) [tbooth2@edgen-login0 snaketest]$ snakemake -j 16 --profile ./some-profile/
Building DAG of jobs...
Using shell: /usr/bin/bash
Provided cores: 16
...

I'm using snakemake==7.18.2 and ConfigArgParse==1.5.3
ConfigArgParse is the module that handles loading the config, and it's supposed to work as you think it should. From https://pypi.org/project/ConfigArgParse/:

If an arg is specified in more than one place, then
commandline values override environment variables which override config file
values which override defaults.

Any chance you are setting both --jobs and also --cores (or --localcores)?

P.S. using snakemake 7.18.2 and ConfigArgParse 1.5.3 as well.


How can ProtoSchool best meet the needs of the libp2p team?

As we build the roadmap for ProtoSchool, we'd like to take into account the priorities of the libp2p team and plan for some tutorial content that best highlights your most common or most prioritized use cases or features.
For a sense of what ProtoSchool is capable of, please take a look at the existing tutorials, which run in-browser and (with the exception of the first tutorial on the list) offer coding challenges following the introduction of various content step-by-step. Beginner-friendliness is a major priority for this project, and as we consider requests from project teams we will also focus on ensuring that appropriate scaffolding exists to get users to the point where they can successfully approach those proposed topics.
Could you please take a look at your project roadmap and help me understand what ProtoSchool tutorial content might most help you achieve your goals for 2019 and 2020?
Do you have upcoming events where you hope to offer workshops? If you could envision that content fitting with the ProtoSchool tutorial format, please be sure to include these ideas and share the relevant event dates.
cc @mikeal

@yusefnapora

@mgoelzer Is the libp2p event originally scheduled for this June being pushed to 2020? Is there workshop content for that event that would make sense in ProtoSchool format?

@terichadbourne Yes, libp2p event being pushed indefinitely.  But we're in dire need of more online tutorial content, and I think Proto School could be a good venue to deliver that.

@yusefnapora Any chance you'd have a little time this week to chat a bit about potential libp2p tutorial conent for ProtoSchool? Just want to make sure I'm incorporating any of your more immediate needs as I build out my roadmap and Q2 OKRs.

Sure, thanks @terichadbourne!  Feel free to put something on my calendar anytime that works for you.


Enhancement: changing the stage in chart editor

Why don't you do changing of the stage in chart editor?

Done, see "Edit Scripts" in Chart Editor

Done, see "Edit Scripts" in Chart Editor

I mean to make the same panel as for changing characters


Update example code to use x/term instead of x/crypto/ssh/terminal

Because x/crypto/ssh/terminal is deprecated and moved to x/term.
https://pkg.go.dev/golang.org/x/crypto/ssh/terminal#pkg-overview

This will break compatibility with Go 1.13 though, is that right?

ssh/terminal is just the wrapper of x/term.
https://github.com/golang/crypto/blob/master/ssh/terminal/terminal.go
So the code that was originally working keeps working and doesn't break compatibility with Go 1.13 I think(I could confirm that the updated example code working with Go 1.13).


Mock logger giving me error for ASP.NET Core

I was trying to verify whether my log warning message is written via NUnit mocking. But I am getting error. Error message  :
An exception of type 'System.NotSupportedException' occurred in Moq.dll but was not handled in user code
Additional information: Invalid verify on a non-virtual (overridable in VB) member: m => m.LogWarning(String.Format("comments not found for part number :{0}", (Object)0), new[] { "111" })
code :
mockLogger.Verify(m => m.LogWarning($"comments not found for part number :{0}", "111"), Times.Exactly(1));
This is happening because nunit mocking framework  does not support extension methods. Few people on stack overflow suggest me to use Log method instead of level wise  methods.
Can anyone share his knowledge how to overcome this issue ?

@rahossain I was recently fighting with this issue myself. I found the simplest work-around is to create a wrapper class for the static method. If you provide your Stack Overflow link I can share what I did in more detail

here is stack overflow link:
http://stackoverflow.com/questions/41472479/mock-logger-giving-me-error-for-asp-net-core


Having the option to push/pull collection metadata to "child" resources

It would be convenient to "push" or "pull" metadata in a collections resource to it's "child" resources.

PUSH - For example, say that you've added several resources to a collection and you have added several keywords to the collections resource. Instead of editing each "child" resource individually to add the keywords, it would be convenient if you could just click "Push metadata to resources" which maybe opens a dialog where you can choose which elements ("keywords" in this case) and which resources to push to. Then the keywords in collections resource are copied to the selected "child" resources.

PULL (the inverse of PUSH) - For example, say you've added several resources to a collection and you have added different sets of keywords the various "child" resources. If you wanted the keywords of the collection resource to be the combined set of keywords from the "child" resources you should be able to click something like "Pull metadata from 'child' resources" which maybe opens a dialog where you can choose which elements ("keywords" in this case) and which resources to pull from. Then the keywords in collections resource are copied from the selected "child" resources.

Closing, stale


Alert lockfree duplicate handling

This is more of a question than something useful.
When two clients edit the same Flaw (or Affects of the same Flaw), they create a deadlock with a console message that looks like this
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/utils.py", line 84, in _execute
    return self.cursor.execute(sql, params)
psycopg2.errors.DeadlockDetected: deadlock detected
DETAIL:  Process 1180 waits for ShareLock on transaction 9013684; blocked by process 1187.
Process 1187 waits for ShareLock on transaction 9012362; blocked by process 1180.
HINT:  See server log for query details.
CONTEXT:  while updating tuple (15939,175) in relation "osidb_affect"

I thought that's because each thread deletes and replaces the Alert objects, so I created this PR. However, the PR, which minimizes changes done to Alerts, behaves the same.
(Alerts are created by _validation_* methods and each of them has only one mode of operation: Create an Alert if there's something wrong. So Alerts were updated by deleting all Alerts related to the given model (Flaw, Affect, etc.) and calling the _validation_* methods again.)
Any idea how to allow two clients work with the same Flaw without deadlocks?
(I haven't yet tried to use postgresql to see what it can tell me about the deadlocks, because I don't know anything about how to work with postgres yet.)
Related to OSIDB-3048

This is irrelevant. Noticed affect is not alert but my brain read it wrong until now. Tests show that if there are two transactions that edit two rows in the DB in the opposite order, they generate a deadlock. (Shown in internal Slack.) It's currently unavoidable. And has nothing to do with Alerts (it can happen on any model, it did happen a few times on Alerts, but also on Affects as seen in the error message above).


[Enhancement] Future Enhancements to Governance Action Processes and the Engine Host

Is there an existing issue for this?

[X] I have searched the existing issues

Please describe the new behavior that that will improve Egeria
Outstanding work for the Engine Host:

The engine host should wait for the start time of a governance action before running the govenrance action service.  The start time is passed to the governance service handler but is not not handled yet.
After loading configuration, the engine host should retrieve all outstanding governance actions assigned to its userId (processingEngineUserId) and start running them if they are outstanding

Enhancements to the choreographer for Governance Action Processes:

The NextGovernanceActionType relationship could be enhanced to support more options:

ability to filter/rename requestParameters passed to the governance service
ability to filter/rename governance action targets passed to the governance service
ability to kick off a different instance of the governance service for each governance action target of a particular name.

Once this filtering is in place it is possible to reestablish the accumulation of action targets as a working set throughout the process.

Alternatives
No response
Any Further Information?
No response
Would you be prepared to be assigned this issue to work on?

[X] I can work on this

This function is complete


[SCIM2] Specification violations in implementation according to RFC 7643

Describe the issue:

ResourceTypes  id considered as optional [1] but it considered as required in Charon core.
Schemas roles attribute needs required definition true as in [2] and it's missing in core definition.

How to reproduce:

Send a POST request to https://localhost:9443/scim2/ResourceTypes
Send a POST request to https://localhost:9443/scim2/Schemas and inspect roles attribute and it's definitions.

Expected behavior:
Behavior should be comply with RFC7643
Environment information

Product Version: IS 5.11.0
OS: Linux

References:
[1]https://tools.ietf.org/html/rfc7643#page-29
[2]https://tools.ietf.org/html/rfc7643#page-66

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


DaemonSet "csi-node-driver" is invalid

Expected Behavior
All pods are successfully launched by the operator.
Current Behavior
When the operator tries to create the csi-node-driver Deployment, it gets an error:
DaemonSet.apps "csi-node-driver" is invalid: [spec.template.spec.volumes[2].hostPath.path: Required value, spec.template.spec.containers[0].volumeMounts[3].name: Not found: "kubelet-dir", spec.template.spec.containers[0].volumeMounts[3].mountPath: Required value]

Possible Solution
N/A
Steps to Reproduce (for bugs)

Have an EKS 1.21 cluster
Deploy v3.24.3 of the helm chart with installation.kubernetesProvider=EKS

Context
The csi-node-driver Deployment failing to create causes the calico-node pods to be endlessly created and terminated.
Your Environment

Operating System and version: EKS 1.21

v3.24 doesn't support k8s 1.21?
https://projectcalico.docs.tigera.io/getting-started/kubernetes/requirements#supported-versions

Be aware of this if you're updating the EKS k8s version though: https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html

It's not clear if k8s 1.21 is the problem, and I can't easily upgrade my cluster(s) yet to test. All I know if that the latest chart version with the versions of the Tigera operator and Calico that is uses by default result in that invalid resource error when the operator tries to create the DaemonSet. This does not happen with the previous minor version of the chart (and the versions of those components that it uses by default)

I can't easily upgrade my cluster(s) yet to test
Then you need to use a version of Calico that does support k8s 1.21.  i.e. calico v3.23.x

Kubernetes APIs change all the time, its not possible for operator to support every version of kubernetes with every version of Calico.  We do try to ensure that there's always a range though.

Does Calico v3.24.x officially not support k8s v1.21 (because it's broken), or is it just not tested on it?

Does Calico v3.24.x officially not support k8s v1.21 (because it's broken), or is it just not tested on it?

"support" is a bit nebulous in an open source project - you're always free to do whatever you like with it.
But that doc gives the list of k8s versions where we'd consider it to be a bug if it didn't work with v3.24.  So in that sense, yes, this combination isn't supported.

We are seeing the same error on EKS 1.22 with platform version eks.6

I'm experiencing the same issue on bare-metal K8s 1.25.3.

Also getting this on a fresh install (bare metal k8s v1.25.0 - tigera-operator-v3.24.4):
{"level":"error","ts":1667745113.0094,"logger":"controller_installation","msg":"ResourceUpdateError","Request.Namespace":"default","Request.Name":"sh.helm.release.v1.tigera-operator-1667744253.v1","ResourceUpdateError":"Error creating / updating resource","error":"DaemonSet.apps \"csi-node-driver\" is invalid: [spec.template.spec.volumes[2].hostPath.path: Required value, spec.template.spec.containers[0].volumeMounts[3].name: Not found: \"kubelet-dir\", spec.template.spec.containers[0].volumeMounts[3].mountPath: Required value]","stacktrace":"github.com/tigera/operator/pkg/controller/installation.(*ReconcileInstallation).Reconcile\n\t/go/src/github.com/tigera/operator/pkg/controller/installation/core_controller.go:1351\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.3/pkg/internal/controller/controller.go:121\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.3/pkg/internal/controller/controller.go:320\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.3/pkg/internal/controller/controller.go:273\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.3/pkg/internal/controller/controller.go:234"}
{"level":"error","ts":1667745113.0108948,"msg":"Reconciler error","controller":"tigera-installation-controller","object":{"name":"sh.helm.release.v1.tigera-operator-1667744253.v1","namespace":"default"},"namespace":"default","name":"sh.helm.release.v1.tigera-operator-1667744253.v1","reconcileID":"5eed793e-f5b0-4b6e-8d2d-e3d03d937c04","error":"DaemonSet.apps \"csi-node-driver\" is invalid: [spec.template.spec.volumes[2].hostPath.path: Required value, spec.template.spec.containers[0].volumeMounts[3].name: Not found: \"kubelet-dir\", spec.template.spec.containers[0].volumeMounts[3].mountPath: Required value]","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.3/pkg/internal/controller/controller.go:273\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.3/pkg/internal/controller/controller.go:234"}

The kubelet dir does exist on the node in the standard location:
# ls -la /mnt/var/lib/kubelet/
total 72
drwxr-xr-x    8 root     root          4096 Nov  6 13:28 .
drwxr-xr-x   11 root     root          4096 Nov  6 14:17 ..
-rw-r--r--    1 root     root           966 Nov  6 13:28 config.yaml
-rw-------    1 root     root            62 Jan  1  1970 cpu_manager_state
drwxr-xr-x    2 root     root          4096 Nov  6 13:33 device-plugins
-rw-r--r--    1 root     root            89 Nov  3 00:19 graceful_node_shutdown_state
-rw-r--r--    1 root     root           176 Nov  6 13:28 kubeadm-flags.env
-rw-------    1 root     root            61 Jan  1  1970 memory_manager_state
drwxr-xr-x    2 root     root          4096 Nov  1 21:16 pki
drwxr-x---    2 root     root          4096 Jan  1  1970 plugins
drwxr-x---    2 root     root          4096 Jan  1  1970 plugins_registry
drwxr-x---    2 root     root          4096 Nov  6 13:28 pod-resources
drwxr-x---   31 root     root          4096 Nov  6 14:42 pods

@tmjd  I do not.  I was on version 3.19 when I did an upgrade to 3.24.4.  It was working before the upgrade.
I am seeing a different issue with the csi-node-driver daemonset now.  For me the cluster I'm working on is just for testing so I deleted everything for tigera and calico from the cluster and removed /var/lib/calico from the nodes and did a fresh install of Tigera-Operator v3.24.5.  It looks like the operator scaled the csi-node-driver DS to zero automatically right at install because there is a missing service account.
Describing the csi-node-driver daemonset shows this in events:
Error creating: pods "csi-node-driver-" is forbidden: error looking up service account calico-system/csi-node-driver: serviceaccount "csi-node-driver" not found
I don't mean to detract from the OP's original issue.  Though deleting everything and reinstalling to the latest version has led to a different issue for me.

I have the same issue on EKS 1.23 v1.23.13-eks-fb459a0. I thought it was an upgrade issue. I tried deleting the DS but it is not recreated with the same error.

EBS CSI driver should NOT be a requirement, that would be very annoying. It does not come pre-installed on EKS anymore, i do not use it, and would be reluctant to add just because of Calico in my use-case.
Same as @ArchiFleKs , i'm on EKS 1.23, was running Calico 3.24.1 fine. Now updated to 3.24.5 and this is happening.
AFAIK this error only happens in the tigera/operator pod. calico-node or typha is not showing problems.
Thank you

EBS CSI driver should NOT be a requirement, that would be very annoying. It does not come pre-installed on EKS anymore, i do not use it, and would be reluctant to add just because of Calico in my use-case.
Same as @ArchiFleKs , i'm on EKS 1.23, was running Calico 3.24.1 fine. Now updated to 3.24.5 and this is happening.
AFAIK this error only happens in the tigera/operator pod. calico-node or typha is not showing problems.
Thank you

For information I'm using EBS CSI driver install via the official helm chart. But I don't see the relation here. The CSI driver installed by calico is another CSI driver right ? Non related to EBS ?

Describing the csi-node-driver daemonset shows this in events:
Error creating: pods "csi-node-driver-" is forbidden: error looking up service account calico-system/csi-node-driver: serviceaccount "csi-node-driver" not found

@kyle-rf This is a separate issue you're hitting here with respect to the service name that I've recently submitted a fix for to our operator repo. The fix will be available in the next rebuild (eg. 3.24.6).
With respect to the "invalid" issue everyone is seeing I've been trying to reproduce the issue but have been unable to due to some unrelated blocking issues that I've only recently overcome. I'll prioritize this one now that I'm able to proceed and hopefully have an answer soon as well as an associated fix.

@ArchiFleKs could you provide detailed steps you ran to see the "error":"DaemonSet.apps \"csi-node-driver\" is invalid issue? I just setup a new EKS 1.23 cluster and installed Calico v3.24.3 via Helm and see the csi-node-driver pods running successfully.

@Josh-Tigera I'm not sure I really know when it started happening, I found this out when I upgraded from 3.24.4 to 3.24.5 but I might have been in a degraded state for longer.
What I don't understand is that now that I deleted the csi-node-driver from my cluster. I still get this error:
{"level":"error","ts":1669194644.1611958,"logger":"controller_installation","msg":"ResourceUpdateError","Request.Namespace":"tigera-operator","Request.Name":"sh.helm.release.v1.tigera-operator.v7","ResourceUpdateError":"Error creating / updating resource","error":"DaemonSet.apps \"csi-node-driver\" is invalid: [spec.template.spec.volumes[2].hostPath.path: Required value, spec.template.spec.containers[0].volumeMounts[3].name: Not found: \"kubelet-dir\", spec.template.spec.containers[0].volumeMounts[3].mountPath: Required value]","stacktrace":"github.com/tigera/operator/pkg/controller/installation.(*ReconcileInstallation).Reconcile\n\t/go/src/github.com/tigera/operator/pkg/controller/installation/core_controller.go:1351\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.3/pkg/internal/controller/controller.go:121\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.3/pkg/internal/controller/controller.go:320\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.3/pkg/internal/controller/controller.go:273\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.3/pkg/internal/controller/controller.go:234"}
{"level":"error","ts":1669194644.1613555,"msg":"Reconciler error","controller":"tigera-installation-controller","object":{"name":"sh.helm.release.v1.tigera-operator.v7","namespace":"tigera-operator"},"namespace":"tigera-operator","name":"sh.helm.release.v1.tigera-operator.v7","reconcileID":"c2645d51-fab9-437e-afab-f07991aaf762","error":"DaemonSet.apps \"csi-node-driver\" is invalid: [spec.template.spec.volumes[2].hostPath.path: Required value, spec.template.spec.containers[0].volumeMounts[3].name: Not found: \"kubelet-dir\", spec.template.spec.containers[0].volumeMounts[3].mountPath: Required value]","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.3/pkg/internal/controller/controller.go:273\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.3/pkg/internal/controller/controller.go:234"}

Which seems to be an operator issue because the object are not in my cluster anymore

@Josh-Tigera I can confirm that our production clusters are still running 3.24.1 whitout issue:
 k get tigerastatuses.operator.tigera.io
NAME        AVAILABLE   PROGRESSING   DEGRADED   SINCE
apiserver   True        False         False      21d
calico      True        False         False      25h

So issue seems to have happen during 3.24.5 upgrade

On a Kubernetes 1.22 running Calico v3.24.1 I tried to upgrade to v3.24.5 and getting the same error when operator restart with new version:
{"level":"error","ts":1669197747.275895,"logger":"controller_installation","msg":"ResourceUpdateError","Request.Namespace":"","Request.Name":"calico","ResourceUpdateError":"Error creating / updating resource","error":"DaemonSet.apps \"csi-node-driver\" is invalid: [spec.template.spec.volumes[2].hostPath.path: Required value, spec.template.spec.containers[0].volumeMounts[3].name: Not found: \"kubelet-dir\", spec.template.spec.containers[0].volumeMounts[3].mountPath: Required value]","stacktrace":"github.com/tigera/operator/pkg/controller/installation.(*ReconcileInstallation).Reconcile\n\t/go/src/github.com/tigera/operator/pkg/controller/installation/core_controller.go:1351\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.3/pkg/internal/controller/controller.go:121\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.3/pkg/internal/controller/controller.go:320\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.3/pkg/internal/controller/controller.go:273\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.3/pkg/internal/controller/controller.go:234"}
{"level":"error","ts":1669197747.2760081,"msg":"Reconciler error","controller":"tigera-installation-controller","object":{"name":"calico"},"namespace":"","name":"calico","reconcileID":"0f3068e2-a7df-4987-8fd4-908b9f95809b","error":"DaemonSet.apps \"csi-node-driver\" is invalid: [spec.template.spec.volumes[2].hostPath.path: Required value, spec.template.spec.containers[0].volumeMounts[3].name: Not found: \"kubelet-dir\", spec.template.spec.containers[0].volumeMounts[3].mountPath: Required value]","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.3/pkg/internal/controller/controller.go:273\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.3/pkg/internal/controller/controller.go:234"}

@Josh-Tigera We believe to have found the issue.
Helm v3 does not handle CRDs upgrade by default. It means that every changes made in crds folder of the Helm charts are not upgraded and only apply at first install (that's why a clean install is OK for you)
When I applied manually the latest crds folders of the v3.24.5 charts everything worked.
I believe you should either:

release a separate charts to handle CRDs upgrade
Tell user to upgrade CRDs separatly from Helm (that's what kube-prometheus-stack is doing from example)
Have the CRDs packaged in templates but that would cause issues at first install because no guarantee that installation CRD would be installed before the actual installation object.

Here in my case I didn't have the new spec kubeletVolumePluginPath in my CRD because it was not up to date

@ArchiFleKs : How did you make it work?

@jyotibhanot the key sentence is:

When I applied manually the latest crds folders of the v3.24.5 charts everything worked.

@jyotibhanot the key sentence is:

When I applied manually the latest crds folders of the v3.24.5 charts everything worked.

I tried that but it didn't work. I did :

helm install calico projectcalico/tigera-operator --version v3.24.4 --namespace tigera-operator
k apply -f . ( inside crd folders)

@jyotibhanot the key sentence is:

When I applied manually the latest crds folders of the v3.24.5 charts everything worked.

I tried that but it didn't work. I did :

helm install calico projectcalico/tigera-operator --version v3.24.5 --namespace tigera-operator
k apply -f . ( inside crd folders)

Use k replace instead of apply, I got an error with the installation CRD being too big.
I just k replace -f or k apply -f all the crds present in the crds folder of charts v3.24.5

So install helm chart, then apply crds and then helm upgrade. Is that the order.

If it is your first install of the tigera operator and you do not have any Tigera/Calico CRDs in your cluster you can just helm install and it should work.
If you already have older crds (and tigera operator already installed) you just:

kubectl replace -f crds
kubectl replace -f crds/calico
helm upgrade or helm install depending on if charts is already installed or not

If it is your first install of the tigera operator and you do not have any Tigera/Calico CRDs in your cluster you can just helm install and it should work.
If you already have older crds (and tigera operator already installed) you just:

kubectl replace -f crds
kubectl replace -f crds/calico
helm upgrade or helm install depending on if charts is already installed or not

Fresh install doesn't work directly. I am using EKS 1.23 and calico latest version. I keep getting this error ```{"level":"error","ts":1669206159.4830186,"msg":"Reconciler error","controller":"tigera-installation-controller","object":{"name":"default"},"namespace":"","name":"default","reconcileID":"6c4d18a1-7ade-41f5-8e78-1a9e3c803d52","error":"DaemonSet.apps "csi-node-driver" is invalid: [spec.template.spec.volumes[2].hostPath.path: Required value, spec.template.spec.containers[0].volumeMounts[3].name: Not found: "kubelet-dir", spec.template.spec.containers[0].volumeMounts[3].mountPath: Required value]","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.3/pkg/internal/controller/controller.go:273\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.12.3/pkg/internal/controller/controller.go:234"}

@Josh-Tigera We believe to have found the issue.

Helm v3 does not handle CRDs upgrade by default. It means that every changes made in crds folder of the Helm charts are not upgraded and only apply at first install (that's why a clean install is OK for you)
When I applied manually the latest crds folders of the v3.24.5 charts everything worked.
I believe you should either:
release a separate charts to handle CRDs upgrade
Tell user to upgrade CRDs separatly from Helm (that's what kube-prometheus-stack is doing from example)
Have the CRDs packaged in templates but that would cause issues at first install because no guarantee that installation CRD would be installed before the actual installation object.
Here in my case I didn't have the new spec kubeletVolumePluginPath in my CRD because it was not up to date

This is still a mystery to me because both v3.24.1 and v3.24.5 CRDs have the kubeletVolumePlugin field in the CRD (I just checked). There must be some other CRD difference that's aliasing to this same issue. I'll try a fresh install of v3.24.5 as well as an upgrade from v3.24.4 to v3.24.5 and see if I can figure out what's going on.

To be clear the issue might have happened before and I did not catch it. V3.24.1 was not a first install for me. I have been using tigera for more than a year on some clusters so my CRDs might have been older than v3.24.1. They just were never upgraded since my first install :/
So maybe a fresh install and upgrade from v3.24.1 to v3.24.5 is ok but what about people upgrading from older version ? Or having installed the chart a while ago for example. My guess is they are running very old versions of CRDs

I can confirm that updating the (numerous) CRDs manually allows me to upgrade to the v3.24.5 release in the same cluster where I originally encountered this problem

It looks like this is the same issue as https://github.com/projectcalico/calico/issues/7030 so I am going to close this and track all progress there. Please let me know if there's anything else specific to this issue that we might need to reopen this for.


Automated event handler invocation

applications don't need to call onEvent in a persist handler anymore
closes #93

Further changes:

command handler can now be defined as override def onCommand = ...
event handler can now be defined as override def onEvent = ...
snapshot handler can now be defined as override def onSnapshot = ...

Thanks for the feedback @volkerstampa. All comments covered in latest (already squashed) commit.


Merge Main to take into account last small bug corrections

Yes these are the changes + an extra line in a README since I forgot to list the new grad3d example in the REDAME under example folder.


Add Support for Windows

Adding this issue for tracking, my company will be working on providing this support as we have hundreds of windows boxes that will need this support.

We're looking for this as well.  Our numbers would be at least a hundred, potentially quite a bit more.
If you guys want some early testing let me know.

@split3  curious - are you guys using chocolatey?   https://chocolatey.org/packages/consul

We aren't, we have the windows support initially written entirely in puppet, just needs some tightening up and polish.

We will need to replace the staging module with archive to provide support for windows.  This initial work is already completed by #243

Initial code for this (work in progress) has been posted to the following branch:
https://github.com/solarkennedy/puppet-consul/tree/feature/windows_support
Still quite a bit of work like tests, nssm optional usage (defaulting to sc for management, etc)

Would love to have chocolatey support as well - is there a way I can contribute?

@split3 @wmuizelaar +1 on chocolatey support.
package {'consul':
  ensure => latest|version|installed|held,
  provider => chocolatey,
  source => 'internal source',
}

Here's the package fully ready to rock - https://chocolatey.org/packages/consul
We always suggest hosting your own internal packages on an internal package server when you are using Chocolatey for production purposes. You will see this package is ready to go already since it doesn't download any external resources, so it won't need any recompiling (downloading and internalizing resources). The moderator (me in this case) verified the checksums with the original shas from the hashicorp site.

Forgot to mention, there is a download link on the left side.

The feature branch that has this work is located here:
https://github.com/solarkennedy/puppet-consul/tree/feature/windows_support
Feel free to work from that to add the chocolatey support if desired.  I'm curious though, what value does chocolatey add that isn't covered by the module itself?

Based on your description, you offer install by url or by package - Chocolatey would be the by package route for Windows.
Lots of work went into that feature branch, and packaging could give you a second option without much more effort. One could use the consul package from https://chocolatey.org and offer the option to override that with an internal package.

We are cut over to puppet-archive (officially) now 100%.
I would be down for either installation approach, it doesn't have to be perfect the first time.

We want to use this module for managing Windows as well. Anything we can do to get the ball rolling on this again?

@solarkennedy From what I can see, you are already set up to support the Chocolatey package - https://github.com/solarkennedy/puppet-consul/blob/132a80cf64b9351a036f0baa5c2382f723a5c1cd/manifests/install.pp#L82-L84. Once the url route bits are accepted, there may not be much else that needs to change. Would need some testing.

Yea, and it is totally ok to release windows support as "experimental".
Do you want me to merge this as is? https://github.com/solarkennedy/puppet-consul/compare/feature/windows_support
Or does anyone have a fork that works that they can PR?

@solarkennedy that code looks mostly good to me. I'd only suggest as an enhancement to do similar to Puppet to find ProgramData.
Code in question - https://github.com/solarkennedy/puppet-consul/compare/feature/windows_support#diff-01eea9f59a7a7e8a90b87b99336e4cfbR5
Could do something like:
https://github.com/puppetlabs/puppet/blob/d00d0b7d34a211f59c5c58d0404e7b126681c2e8/install.rb#L258 and https://github.com/puppetlabs/puppet/blob/d00d0b7d34a211f59c5c58d0404e7b126681c2e8/install.rb#L253
You are at least guaranteed that the win32-dir gem is loaded with Puppet in the interim.
On second thought, maybe leave that the way it is. 👍

I know this code was used in production at my previous company for quite some time. Though it obviously hasn't been kept up2date and could probably use a little polish.

I will rubber stamp any Windows support PR. I don't personally run Windows so I'll have to lean on community support for real-world testing.

We're just getting started with consul and I hacked some code to wrap around your Linux code to make it work on Windows so I should be able to provide some decent testing.

Any change that this will picked up again, so we could use windows?


build: add warning message support

This patch introduces a mechanism to inform the user about missing
features or possible misbehaving features based on target system's
configuration.
The first feature's user is the string flow module, this module
implements an ascii fallback case the target system doesn't provide ICU.
We support the following formats:
warning-msg := "an arbitrary message"
warning-msg-$(CONFIG_OPTION) := "another arbitrary message"
Where warning-msg-$(CONFIG_OPTION) may expand either to warning-msg-y or warning-msg-m.
See: https://github.com/solettaproject/soletta/issues/463
Signed-off-by: Leandro Dorileo<EMAIL_ADDRESS>

LGTM. Now we do the config part of the deal (I guess that can wait for tomorrow).

Will you update this one?

applied