Explain how to download then the private key and provide CLI snippet

Once the key is imported in KV, then az keyvault key download returns the public key only.
A similar question & explanation regarding certificates is described at https://github.com/Azure/azure-sdk-for-js/issues/7647#issuecomment-594935307
ssh-keygen -t rsa -b 4096 -N $ssh_passphrase -f ~/.ssh/$ssh_key -C<EMAIL_ADDRESS>
az keyvault key import --name $ssh_key --vault-name $vault_name --pem-file ~/.ssh/$ssh_key --pem-password $ssh_passphrase
az keyvault key list --vault-name $vault_name
az keyvault key show --name $ssh_key --vault-name $vault_name
az keyvault key download --name $ssh_key --vault-name $vault_name --encoding PEM --file key2

Does KeyVault store both the public part in a KV Key and the private part of the imported key in a KV secret ?
what i sthe CLI snippet then to download the private key ?
az keyvault secret list --vault-name $vault_name
az keyvault secret show --name $vault_secret_name --vault-name $vault_name --output tsv

az keyvault secret download --file myLostKey.txt --name $vault_secret_name --vault-name $vault_name

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 08473c3b-c25b-50b4-40f3-0a9dba07d0ff
Version Independent ID: 92776ffc-8a65-7745-43ef-10dae51cf1f1
Content: Quickstart: Set and retrieve a key from Azure Key Vault
Content Source: articles/key-vault/keys/quick-create-cli.md
Service: key-vault
Sub-service: keys
GitHub Login: @msmbaldwin
Microsoft Alias: mbaldwin

@ezYakaEagle442
Thanks for your feedback! We will investigate and update as appropriate.

Closing this as a duplicate of https://github.com/Azure/azure-cli/issues/13548


[✨] feat: sitemap generator

Describe the bug
i open this as an issue because i cant open a feature request, it will be nice that we can add support of a sitemap generator i don't know if this can be done in this repo or has o be a separate package
This is a reference of how a sitemap generatos work in astro

@astrojs/sitemap

Your Example Website or App
none
Steps to Reproduce the Bug or Issue
none
Expected behavior
none
Screenshots or Videos
No response
Platform

OS: [e.g. macOS, Windows, Linux]
Browser: [e.g. Chrome, Safari, Firefox]
Version: [e.g. 91.1]

Additional context
No response

This is probably in the domain of SolidStart rather than the router

this is for solid and solid router not solid-start

I know you'd like this as a router feature, but I mention SolidStart as I'm not sure the router is capable enough to know the sitemap ahead of time.
Looking at Astro's sitemap plugin, it only works for routes with paths that are known at build time ie. fixed-path routes and dynamic routes that are statically generated with getStaticRoutes. Dynamic routes that are evaluated at runtime can't be included in a sitemap.
The router isn't in the position to know what routes are available at build time - it just knows the runtime routing schema. SolidStart on the other hand does know which routes are pre-rendered by crawling and explicit instruction.

Can't you just use a Vite plugin like:
https://github.com/jbaubree/vite-plugin-sitemap

@madaxen86 not yet, but this issue is for a feature request in solid or solid-router, that can only be a temporary solution


Properly count only the first hard link size on a rescan

Fixes #124
As a side effect also fixes the hard link information in the "info"
screen after a rescan.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.002%) to 95.613%

Totals

Change from base Build<PHONE_NUMBER>:
0.002%

Covered Lines:
2310

Relevant Lines:
2416

💛  - Coveralls


Use the exported keras.Variable class throughout code.

The exported keras.Variable class is a subclass of the backend specific implementation. However, that public class was not used internally to create variables, for instance via add_weight().
There was no convenient way to detect that a tensor really is a variable. This code would print False:
v = self.add_weight(x)
print(isinstance(v, keras.Variable)

This change makes keras.Variable the actual class used internally. The only exception is in SeedGenerator with an overridden backend.

Codecov Report
Attention: Patch coverage is 62.96296% with 10 lines in your changes missing coverage. Please review.

Project coverage is 62.38%. Comparing base (f52f9f5) to head (6129b2b).

Files with missing lines
Patch %
Lines

keras/src/backend/tensorflow/rnn.py
14.28%
6 Missing :warning:

keras/src/backend/numpy/core.py
0.00%
2 Missing :warning:

keras/src/backend/jax/core.py
50.00%
0 Missing and 1 partial :warning:

keras/src/backend/numpy/__init__.py
0.00%
1 Missing :warning:

:exclamation:  There is a different number of reports uploaded between BASE (f52f9f5) and HEAD (6129b2b). Click for more details.
HEAD has 6 uploads less than BASE

Flag
BASE (f52f9f5)
HEAD (6129b2b)

keras
4
1

keras-numpy
1
0

keras-tensorflow
1
0

keras-jax
1
0

Additional details and impacted files
@@             Coverage Diff             @@
##           master   #20330       +/-   ##
===========================================
- Coverage   78.87%   62.38%   -16.50%
===========================================
  Files         513      513
  Lines       49233    49227        -6
  Branches     9075     9075
===========================================
- Hits        38834    30708     -8126
- Misses       8532    16761     +8229
+ Partials     1867     1758      -109

Flag
Coverage Δ

keras
62.38% <62.96%> (-16.36%)
:arrow_down:

keras-jax
?

keras-numpy
?

keras-tensorflow
?

keras-torch
62.38% <62.96%> (+<0.01%)
:arrow_up:

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Updated for all of exports.py


Avoid T.must.

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[ ] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[x] Have you successfully run brew tests with your changes locally?

I just stumbled over these while refactoring some other alias-related code, so it made sense to also refactor this, but I don't think we need to proactively do anything about this pattern and assertions in general. Of course feel free to take a look, I'd assume this pattern is used in a couple of other places.


[BUG] aggregation works incorrectly with LIMIT

What is the bug?
LIMIT applied incorrectly in query with aggregation.
How can one reproduce the bug?
Steps to reproduce the behavior:
Run any query with aggregation which returns more than 200 rows. Try adding LIMIT clause.
For example:
select count(*) from online group by all_client / 100 limit 2000

(index online is taken from IT)
Physical plan tree is being executed:

What is the expected behavior?
LIMIT rule should be applied correctly for such queries.
Probably pushDownLimit should be rejected if query has aggregation.
What is your host/environment?
main @ 94d54795
Do you have any screenshots?
Customer request: https://opensearch.slack.com/archives/C051JEH8MNU/p1686871225569409
Do you have any additional context?
Related issues: #716, #1764, #1752

Is there any indication when the LIMIT issue will be resolved? I am having the same problem as well. Normal queries and such I can go up to any number. However anything with a group by in it is stuck at 200 or lower, the lower values do work.

Found a work around!
If you are experiencing this issue, aggregates/group by is causing and limiting results to only 200 max.
Don't run the query but instead do an explain on your SQL attempt.
The results of the explain will show you the standard opensearch query that would have been based on your SQL.

Get this out and clean it up, then drop back to the normal opensearch query method.

This will then as intended and return the full set of "buckets" not just 200.

One solution is to increase the limit for the SQL plugins at cluster level; details here: https://opensearch.org/docs/2.12/search-plugins/sql/settings/, adjust parameter: plugins.query.size_limit.


Links to cross-origin destinations are safe

Links to cross-origin destinations are safe (added rel="noopener”)

Thanks, but this isn't needed to my knowledge: https://mathiasbynens.github.io/rel-noopener/

2021 update: Browsers now implicitly set rel=noopener for any target=_blank link, following a spec change. If the demo on this page no longer seems scary, congratulations — you’re using a modern browser!


PEP541: Transfer ownership of gnpy to a new maintainer

Hi, I work for the @TelecomInfraProject organization as a maintainer of the oopt-gnpy software. Previously, this stuff was done by James Powell (@dutc) who also created the gnpy package at pypi. James is no longer with @TelecomInfraProject, unfortunately, meaning that the maintainer address listed in PyPI's Meta -> Author no longer works.
Can you please pass the ownership of gnpy to my account jktjkt?
I was not able to secure a proper handover before James' mail account was closed. I'm sorry that our internal process flaw causes extra work for you. I'll make sure that this event does not repeat by ensuring that there are more accounts distributed among several companies which are all listed as co-maintainers.
refs Telecominfraproject/oopt-gnpy#254

Is there something that I can do to help process this request?

Hi there, can I do something to get the maintainer access to the gnpy package at pypi?


Does SFTP use hosts in .ssh/config on MacOS?

I have a host defined in .ssh/config, but when I enter the hostname within the sftp.json file, I receive an getaddrinfo ENOTFOUND error.
Do I need to specify something within the json file to tell it to use the configuration found in config? Will it then also use the ssh key identify file specified within there?
Desktop (please complete the following information):

OS: Mac
VSCode Version 1.53.2
Extension Version 1.12.9

TIA

I have the same setup and haven't found a way to get around recognizing ~/.ssh/config.  The plugin seems to like only IP addresses.

Do you solve the problem?

Unfortunately not :(


blacken format

My editor auto formats using black. How do you feel about these changes?
The double quotes change seems to be a sticking point for some.
but if you're o.k. with it it'll make my life easier for submitting future changes (gzip and caching). I can also turn this off in my editor for your files only if you prefer. I find not having to think about formatting and using black to be a big plus.

Thanks for the submission but I don't like Black: It modifies way too much.
I have very specific settings based on Flake8 / isort and since this is not a real Python package, I didn't think it was necessary to add it in a setup.cfg file


[Relay] [WIP] Lambda Lifting

Jared need some code so I will make a pr right now

I think we should think about naming since this is a strange inbetween of classical lambda lifting and closure conversion.

I can remove the closure conversion pass. It is just that I am clueless on the case of 'function returning closure'.

@MarisaKirisame Is it still WIP? or ready for merging?

@yzhliu it was on hold, as we are working on more important things.

close this for now as it is on hold, please reopen when there are updates


Intercepting commands / Dim Philips Hue with Wiser dimmer

Hello everyone,
We have been using Wiser for six months and are happy with it so far :-)
However, in some rooms, we have Philips Hue lamps and would like to dim them using the Wiser dimmer. Unfortunately, Philips Hue lamps can’t be dimmed in the “traditional” way; they need to be dimmed via an app or a special dimmer (like many other lamps from different brands).
Is it somehow possible to change the behaviour of the Wiser dimmers so they only adjust the “brightness” value without actually dimming? This way, it would be possible to trigger a brightness change through the Hue Bridge via an API (e.g., Home Assistant or similar).
I think this type of intercepting would also be useful for other applications.
Alternatively, does anyone have a better idea for dimming Hue lamps without using an external dimmer switch?
Thanks in advance!

Hello,
Thanks for your help. I saw the issue you mentioned, but unfortunately i do not have scene triggers where i have Hue lamps.
From a technical point it would be enough when the devices can be set to a "simulate-mode", where the hardware doesn't do anything but emits the value changes. probably something similar exists for development reasons?

Every Wiser device press produces on the websocket an event. You could listen to the websocket with a home automation tool such as HomeAssistant, Homey Pro, Homebridge,.. and use it to trigger a flow, e.g. to dim your Hue device accordingly. I am currently figuring out if I should try to get MQTT out of Wiser actions via MicroPython or if I want that any Wiser action triggers a HTTP call to Homey, which I can then use directly to trigger a flow.
In Homey, there are also plugins that do not even require a Hue bridge to perform the action, but use ZigBee directly: https://github.com/JohanBendz/com.philips.hue.zigbee
So one of the remaining questions is also do you use a Hue Bridge or not. There are also bridge emulators such as https://github.com/diyhue/diyHue.


Display active python virtual environment

How does one enable the display of the current active python virtual environment in the prompt?

Whoops! Forgot to close this one. 😅


[Handles] project demo video

As an unfinished team member that isnt on the blockchain team I would like an exhaustive recoded demo video of what has been built and how to use it.

This was completed and added to the PR last week but due to a change to the retire_handle() extrinsic, I need to re-record it.

I recorded a new one this morning for the Readout meeting.
https://www.loom.com/share/50c706523ccb47159b8a7986d9d07997


WIP: chore: bump toolchain to nightly-2024-10-03

Description:
Bumps the toolchain to the latest nightly. Mostly in the (unlikely) hope that some of our instantiateMVars performance woes might disappear.
Still WIP, currently blocked on bumping the ElfSage toolchain
Testing:
What tests have been run? Did make all succeed for your changes? Was
conformance testing successful on an Aarch64 machine?
License:
By submitting this pull request, I confirm that my contribution is
made under the terms of the Apache 2.0 license.

@bollu the traces for the CSE tests changed. I've accepted the new trace somewhat blindly; could you confirm the difference is benign?

Yep, LGTM!

FYI: https://github.com/draperlaboratory/ELFSage/pull/15 where the toolchain is leanprover/lean4:nightly-2024-10-07
While that's upstreamed, we can use my fork of ELFSage.

FYI: https://github.com/draperlaboratory/ELFSage/pull/15 got merged.


Review and update spring cloud functions dependency for CVE

Reference: https://spring.io/blog/2022/03/29/cve-report-published-for-spring-cloud-function

The dependency that is used by the templates is spring-cloud-dependencies version 2021.0.1. This is an umbrella dependency that just pulls in a bunch of other dependencies. Reading this blog post about the issue, we are affected by “Information Exposure in Spring Cloud Function”, with a mitigation by a bump to spring-cloud-functions to 2.3.2 or higher. It appears to me that spring-cloud-dependencies has already made that bump based on my reading of this. https://mvnrepository.com/artifact/org.springframework.cloud/spring-cloud-dependencies/2021.0.1
If this is all true, then I think we are good and function users should not be affected. I would like for someone with more recent Java experience to validate these findings, however, as it’s been years and my Java fu is rusty.
/cc @trisberg


Unable to load project

Describe the bug
I'm unable to load a project that I'm working on - the project is viewable under my projects, but when I try to open it, I'm met with a pop up that reads:

Oops, There is an Issue!!!
Sorry about this
Issue loading project: "Cannot read properties of undefined (reading 'mutable')
Click ok to go to home page or last loaded project

To Reproduce
Attempt to open this project: https://play.flow.com/ac3c7983-446d-4587-b538-de0fe2df5f19
Console reads the following error message:
{
    "message": "user error: convert: failed to decode JSON-Cadence value: expecte JSON object, got A.0000000000000005.MetadataViews.Resolver",
    "path": [
        "project",
        "accounts"
    ],
    "extensions": {
        "code": "BAD_REQUEST"
    }
}

@bthaile mentioned this is likely due to improper import syntax.
Expected behavior
The project loads at the last save point.
Screenshots

Desktop (please complete the following information):

OS: [e.g. iOS] macOS 13.6
Browser [e.g. chrome, safari] Chrome
Version [e.g. 22] 116.0.5845.187 (Official Build) (arm64)

Didn't realize the "Reset project" would reset state - doing that let me open up the project again. Closing as the issue is resolved.


Teamnado 3921

Request to move TEAMNADO-3921 to prod-beta

Codecov Report

Merging #65 (d1962aa) into prod-beta (6a36705) will increase coverage by 1.47%.
The diff coverage is 0.00%.

@@              Coverage Diff              @@
##           prod-beta      #65      +/-   ##
=============================================
+ Coverage      88.20%   89.68%   +1.47%
=============================================
  Files             42       42
  Lines            670      669       -1
  Branches         124      123       -1
=============================================
+ Hits             591      600       +9
+ Misses            79       69      -10

Impacted Files
Coverage Δ

.../SatelliteManifestPanel/SatelliteManifestPanel.tsx
73.43% <0.00%> (+8.32%)
:arrow_up:

...anifestDetailSidePanel/ManifestDetailSidePanel.tsx
84.44% <0.00%> (-2.23%)
:arrow_down:

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


Test 7

created a branch, created a file and made a commit, and opened a pull request

test

Review for Approval


SQS Listener is not listening localstack queue

Type: Bug
Component:
SQS
Describe the bug
Hi!
I'm trying to list an SQS queue from localstack but I'm receiving a message that said the queue does not exist.
I don't if this is related to this issue #788
If this is not a bug, I'm sorry.
2021-09-30 10:41:15.273  WARN 25992 --- [           main] i.a.c.m.l.SimpleMessageListenerContainer : Ignoring queue with name 'EVENTS_DEV': The queue does not exist.; nested exception is com.amazonaws.services.sqs.model.QueueDoesNotExistException: The specified queue EVENTS_DEV does not exist for this wsdl version. (Service: AmazonSQS; Status Code: 404; Error Code: AWS.SimpleQueueService.NonExistentQueue; Request ID: IKNNYB2ICCTDT6DXQ15RAP5JCY92NVG1H0LZK69WJWMBXZ1YIFKI; Proxy: null)

If I use AWS CLI the queue is there.
> aws --endpoint http://localhost:4566 sqs get-queue-attributes --queue-url  http://localhost:4566/000000000000/MY_QUEUE
{
    "Attributes": {
        "ApproximateNumberOfMessages": "0",
        "ApproximateNumberOfMessagesDelayed": "0",
        "ApproximateNumberOfMessagesNotVisible": "0",
        "CreatedTimestamp": "1633012559.984967",
        "DelaySeconds": "0",
        "LastModifiedTimestamp": "1633012559.984967",
        "MaximumMessageSize": "262144",
        "MessageRetentionPeriod": "345600",
        "QueueArn": "arn:aws:sqs:sa-east-1:000000000000:MY_QUEUE",
        "ReceiveMessageWaitTimeSeconds": "0",
        "VisibilityTimeout": "30"
    }
}

I don't what I'm missing.
Sample
Here is my properties file
cloud.aws.credentials.accessKey=
cloud.aws.credentials.secretKey=
cloud.aws.sns.endpoint=http://localhost:4566
cloud.aws.sns.region=sa-east-1
cloud.aws.sqs.endpoint=http://localhost:4566
cloud.aws.sqs.region=sa-east-1
cloud.aws.credentials.instanceProfile=false
cloud.aws.credentials.useDefaultAwsCredentialsChain=false
cloud.aws.stack.auto=false

aws.queues.event=MY_QUEUE

Here is my bean configuration

@Configuration
public class AWSConfig {
    @Bean
    public QueueMessagingTemplate queueMessagingTemplate(AmazonSQSAsync amazonSQSAsync) {
        return new QueueMessagingTemplate(amazonSQSAsync);
    }
}

And here is my listener code
@Component
public class Listener {

    @SqsListener(value = "${aws.queues.event}", deletionPolicy = SqsMessageDeletionPolicy.NEVER)
    public void listen(String message, Acknowledgment acknowledgment) throws ExecutionException, InterruptedException {
        System.out.printf("Message received %s%n", message );
        acknowledgment.acknowledge().get();
    }
}

Thanks!

Maybe increase the logging level to make sure that the AWS client is using the correct endpoint?

@nickcaballero how can I do that?

Set logger to debug mode.
logging:
  level:
    'org.apache.http.headers': warn

@nickcaballero I put logging.level.root=DEBUG and the log is
3351c7257606045b29c98c1cc66f3592b670e213de1dce6f776cc55e2e6737b"
2021-09-30 15:26:40.957 DEBUG 10008 --- [           main] com.amazonaws.auth.AWS4Signer            : Generating a new signing key as the signing key not available in the cache for the date<PHONE_NUMBER>000
2021-09-30 15:26:40.987 DEBUG 10008 --- [           main] o.a.h.client.protocol.RequestAddCookies  : CookieSpec selected: default
2021-09-30 15:26:41.003 DEBUG 10008 --- [           main] o.a.h.client.protocol.RequestAuthCache   : Auth cache not set in the context
2021-09-30 15:26:41.004 DEBUG 10008 --- [           main] h.i.c.PoolingHttpClientConnectionManager : Connection request: [route: {}->http://localhost:4566][total available: 0; route allocated: 0 of 50; total allocated: 0 of 50]
2021-09-30 15:26:41.028 DEBUG 10008 --- [           main] h.i.c.PoolingHttpClientConnectionManager : Connection leased: [id: 0][route: {}->http://localhost:4566][total available: 0; route allocated: 1 of 50; total allocated: 1 of 50]
2021-09-30 15:26:41.031 DEBUG 10008 --- [           main] o.a.http.impl.execchain.MainClientExec   : Opening connection {}->http://localhost:4566
2021-09-30 15:26:41.050 DEBUG 10008 --- [           main] .i.c.DefaultHttpClientConnectionOperator : Connecting to localhost/<IP_ADDRESS>:4566
2021-09-30 15:26:41.053 DEBUG 10008 --- [           main] .i.c.DefaultHttpClientConnectionOperator : Connection established <IP_ADDRESS>:62910<-><IP_ADDRESS>:4566
2021-09-30 15:26:41.054 DEBUG 10008 --- [           main] h.i.c.DefaultManagedHttpClientConnection : http-outgoing-0: set socket timeout to 50000
2021-09-30 15:26:41.054 DEBUG 10008 --- [           main] o.a.http.impl.execchain.MainClientExec   : Executing request POST / HTTP/1.1
2021-09-30 15:26:41.054 DEBUG 10008 --- [           main] o.a.http.impl.execchain.MainClientExec   : Proxy auth state: UNCHALLENGED
2021-09-30 15:26:41.059 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 >> POST / HTTP/1.1
2021-09-30 15:26:41.059 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 >> Host: localhost:4566
2021-09-30 15:26:41.059 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 >> amz-sdk-invocation-id: 70586d2f-a0df-9715-6535-309298b2d871
2021-09-30 15:26:41.060 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 >> amz-sdk-request: attempt=1;max=4
2021-09-30 15:26:41.060 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 >> amz-sdk-retry: 0/0/500
2021-09-30 15:26:41.060 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 >> Authorization: AWS4-HMAC-SHA256 Credential=AKIAYZXAJXBEXGRHT7U2/20210930/us-east-1/sqs/aws4_request, SignedHeaders=amz-sdk-invocation-id;amz-sdk-request;amz-sdk-retry;host;user-agent;x-amz-date, Signature=d3924026fe75841a0e57fb74c94d21e79360d95ab9c704aabc2a2aa14361a584
2021-09-30 15:26:41.060 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 >> User-Agent: aws-sdk-java/1.11.951 Windows_10/10.0 OpenJDK_64-Bit_Server_VM/16.0.1+9-24 java/16.0.1 vendor/Oracle_Corporation, spring-cloud-aws/2.3.0 AmazonSQSBufferedAsyncClient/1.11.951
2021-09-30 15:26:41.060 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 >> X-Amz-Date: 20210930T182640Z
2021-09-30 15:26:41.060 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 >> Content-Type: application/x-www-form-urlencoded; charset=utf-8
2021-09-30 15:26:41.060 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 >> Content-Length: 56
2021-09-30 15:26:41.060 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 >> Connection: Keep-Alive
2021-09-30 15:26:41.060 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 >> "POST / HTTP/1.1[\r][\n]"
2021-09-30 15:26:41.060 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 >> "Host: localhost:4566[\r][\n]"
2021-09-30 15:26:41.060 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 >> "amz-sdk-invocation-id: 70586d2f-a0df-9715-6535-309298b2d871[\r][\n]"
2021-09-30 15:26:41.060 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 >> "amz-sdk-request: attempt=1;max=4[\r][\n]"
2021-09-30 15:26:41.060 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 >> "amz-sdk-retry: 0/0/500[\r][\n]"
2021-09-30 15:26:41.061 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 >> "Authorization: AWS4-HMAC-SHA256 Credential=AKIAYZXAJXBEXGRHT7U2/20210930/us-east-1/sqs/aws4_request, SignedHeaders=amz-sdk-invocation-id;amz-sdk-request;amz-sdk-retry;host;user-agent;x-amz-date, Signature=d3924026fe75841a0e57fb74c94d21e79360d95ab9c704aabc2a2aa14361a584[\r][\n]"
2021-09-30 15:26:41.061 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 >> "User-Agent: aws-sdk-java/1.11.951 Windows_10/10.0 OpenJDK_64-Bit_Server_VM/16.0.1+9-24 java/16.0.1 vendor/Oracle_Corporation, spring-cloud-aws/2.3.0 AmazonSQSBufferedAsyncClient/1.11.951[\r][\n]"
2021-09-30 15:26:41.061 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 >> "X-Amz-Date: 20210930T182640Z[\r][\n]"
2021-09-30 15:26:41.061 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 >> "Content-Type: application/x-www-form-urlencoded; charset=utf-8[\r][\n]"
2021-09-30 15:26:41.061 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 >> "Content-Length: 56[\r][\n]"
2021-09-30 15:26:41.061 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 >> "Connection: Keep-Alive[\r][\n]"
2021-09-30 15:26:41.061 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 >> "[\r][\n]"
2021-09-30 15:26:41.061 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 >> "Action=GetQueueUrl&Version=2012-11-05&QueueName=MY_QUEUE"
2021-09-30 15:26:41.094 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 << "HTTP/1.1 404 [\r][\n]"
2021-09-30 15:26:41.094 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 << "content-type: application/xml[\r][\n]"
2021-09-30 15:26:41.094 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 << "content-length: 337[\r][\n]"
2021-09-30 15:26:41.094 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 << "x-amzn-errortype: QueueDoesNotExist[\r][\n]"
2021-09-30 15:26:41.094 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 << "status: 404[\r][\n]"
2021-09-30 15:26:41.094 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 << "x-amzn-requestid: CMDZGU593IM71PPRCPU94ZY1UEY2TU1JIX4NIGH9AZSS8PUE8BBP[\r][\n]"
2021-09-30 15:26:41.094 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 << "x-amz-crc32:<PHONE_NUMBER>[\r][\n]"
2021-09-30 15:26:41.094 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 << "access-control-allow-origin: *[\r][\n]"
2021-09-30 15:26:41.094 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 << "access-control-allow-methods: HEAD,GET,PUT,POST,DELETE,OPTIONS,PATCH[\r][\n]"
2021-09-30 15:26:41.094 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 << "access-control-allow-headers: authorization,content-type,content-length,content-md5,cache-control,x-amz-content-sha256,x-amz-date,x-amz-security-token,x-amz-user-agent,x-amz-target,x-amz-acl,x-amz-version-id,x-localstack-target,x-amz-tagging,amz-sdk-invocation-id,amz-sdk-request[\r][\n]"
2021-09-30 15:26:41.094 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 << "access-control-expose-headers: x-amz-version-id[\r][\n]"
2021-09-30 15:26:41.094 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 << "connection: close[\r][\n]"
2021-09-30 15:26:41.094 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 << "date: Thu, 30 Sep 2021 18:26:41 GMT[\r][\n]"
2021-09-30 15:26:41.094 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 << "server: hypercorn-h11[\r][\n]"
2021-09-30 15:26:41.095 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 << "[\r][\n]"
2021-09-30 15:26:41.098 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 << HTTP/1.1 404
2021-09-30 15:26:41.099 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 << content-type: application/xml
2021-09-30 15:26:41.099 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 << content-length: 337
2021-09-30 15:26:41.099 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 << x-amzn-errortype: QueueDoesNotExist
2021-09-30 15:26:41.099 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 << status: 404
2021-09-30 15:26:41.099 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 << x-amzn-requestid: CMDZGU593IM71PPRCPU94ZY1UEY2TU1JIX4NIGH9AZSS8PUE8BBP
2021-09-30 15:26:41.099 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 << x-amz-crc32:<PHONE_NUMBER>
2021-09-30 15:26:41.099 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 << access-control-allow-origin: *
2021-09-30 15:26:41.099 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 << access-control-allow-methods: HEAD,GET,PUT,POST,DELETE,OPTIONS,PATCH
2021-09-30 15:26:41.099 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 << access-control-allow-headers: authorization,content-type,content-length,content-md5,cache-control,x-amz-content-sha256,x-amz-date,x-amz-security-token,x-amz-user-agent,x-amz-target,x-amz-acl,x-amz-version-id,x-localstack-target,x-amz-tagging,amz-sdk-invocation-id,amz-sdk-request
2021-09-30 15:26:41.099 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 << access-control-expose-headers: x-amz-version-id
2021-09-30 15:26:41.099 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 << connection: close
2021-09-30 15:26:41.099 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 << date: Thu, 30 Sep 2021 18:26:41 GMT
2021-09-30 15:26:41.099 DEBUG 10008 --- [           main] org.apache.http.headers                  : http-outgoing-0 << server: hypercorn-h11
2021-09-30 15:26:41.106 DEBUG 10008 --- [           main] com.amazonaws.retry.ClockSkewAdjuster    : Reported server date (from 'Date' header): Thu, 30 Sep 2021 18:26:41 GMT
2021-09-30 15:26:41.116 DEBUG 10008 --- [           main] org.apache.http.wire                     : http-outgoing-0 << "<ErrorResponse xmlns="http://queue.amazonaws.com/doc/2012-11-05/"><Error><Type>Sender</Type>AWS.SimpleQueueService.NonExistentQueue<Message>The specified queue MY_QUEUE does not exist for this wsdl version.</Message><Detail/></Error><RequestId>CMDZGU593IM71PPRCPU94ZY1UEY2TU1JIX4NIGH9AZSS8PUE8BBP</RequestId></ErrorResponse>"
2021-09-30 15:26:41.116 DEBUG 10008 --- [           main] h.i.c.DefaultManagedHttpClientConnection : http-outgoing-0: Close connection
2021-09-30 15:26:41.118 DEBUG 10008 --- [           main] o.a.http.impl.execchain.MainClientExec   : Connection discarded
2021-09-30 15:26:41.118 DEBUG 10008 --- [           main] h.i.c.PoolingHttpClientConnectionManager : Connection released: [id: 0][route: {}->http://localhost:4566][total available: 0; route allocated: 0 of 50; total allocated: 0 of 50]
2021-09-30 15:26:41.154 DEBUG 10008 --- [           main] com.amazonaws.util.XpathUtils            : Ingore failure in speeding up DTMManager

I've changed the bean configuration to this
@Configuration
public class AWSConfig {
    @Bean
    public QueueMessagingTemplate queueMessagingTemplate(AmazonSQSAsync sqs) {
        return new QueueMessagingTemplate(sqs);
    }

    @Bean
    @Primary
    public AmazonSQSAsync amazonSQSAsync() {
        return AmazonSQSAsyncClientBuilder.standard()
            .withEndpointConfiguration(new AwsClientBuilder.EndpointConfiguration("http://localhost:4566", "sa-east-1"))
            .withCredentials(new AWSStaticCredentialsProvider(new BasicAWSCredentials("accessKey", "secretKey")))
            .build();
    }
}

And now It worked.
Thanks!

Looking at the logs, it did send your request to localhost:4566. Were you able to determine what was wrong?

@nickcaballero I'm running localstack with 'sa-east-1' default region.
Using the logs I realized the region in the headers was
Authorization: AWS4-HMAC-SHA256 Credential=key/20210930/us-east-1/sqs/aws4_request, SignedHeaders=amz-sdk-invocation-id;amz-sdk-request;amz-sdk-retry;host;user-agent;x-amz-date, Signature=d3924026fe75841a0e57fb74c94d21e79360d95ab9c704aabc2a2aa14361a584[\r][\n]

As you can see the region in the was us-east-1.
After I changed the AmazonSQSAsync to my bean as primary (just like this) I realized the bean created by the framework has not the region overridden.
I think this can be a bug, So I open another issue


read image workflow

sprint april 2019

get archivesspace plugin to work (work with @jackflaps)

nice to have:

rewrite collection pages
frontend cleanup code
run tests
ask @jackflaps to add collection samples to /library/lib-sftp/archivematica-sample

implemented by @freyesdulib


OnePlus 7T HD1905 Fingerprint Shows as HD1901

They're the exact same print, so that's just a cosmetic thing. I might do something about that in a future update, but it's not a priority.


Need guidance in building chart programatically

Can this library be used to create helm chart programmatically ? If not any guidance on how that can be done by doing code changes to this library or some other way?

Hey @jaingaurav001

Can this library be used to create helm chart programmatically ?

What exactly do you mean by creating a helm chart? Are you looking for the functionality of helm create? Please expand on your question.
On a side note: This repository's goal is to provide an easy way for users to programmatically interact with helm, e.g. installing or updating a helm release by a provided chart specification.
Please refer to our examples to get a more in-depth view on what the client provides.


ledger-live-desktop: 2.46.0 -> 2.46.2

ledger-live-desktop: 2.46.0 -> 2.46.2
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

I've tried this and it works great with my Ledger Nano X

I've tried this and it works great with my Ledger Nano X

it works on both nano x and nano S plus (Don't have nano s)  it just needs to be approved

I've tried this and it works great with my Ledger Nano X

it works on both nano x and nano S plus (Don't have nano s) it just needs to be approved

Just wanted to add an extra data point to make it easier for reviewers to merge this :+1:

Result of nixpkgs-review pr 189842 run on x86_64-linux 1

1 package built:

ledger-live-desktop

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/1180


[ISSUE #425] Using templates to encourage useful issues and PRs

See #425 for more detail.

Codecov Report

Merging #426 (cc0eb0b) into develop (de478dc) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             develop    #426   +/-   ##
=========================================
  Coverage       2.93%   2.93%
  Complexity        89      89
=========================================
  Files            224     224
  Lines          10754   10754
  Branches         921     921
=========================================
  Hits             316     316
  Misses         10392   10392
  Partials          46      46

Continue to review full report at Codecov.

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

nice


Modal images

Is it possible to integrate a modal for images like lightbox, directly in the bootstrap?
In advance, thank you.

did you try putting an image inside http://twitter.github.com/bootstrap/javascript.html#modals ?

This is possible if you write completely custom controls for the modal—we won't be adding anything like that in the near future I think. You should, however, be able to just place any content in .modal without header or footer or body and be good to go.

@ghost
The following code does what you want, but it is not a substitute to colorbox and co.

@ghost
The following code does what you want, but it is not a substitute to colorbox and co.

Do not use the inline styles in a production environment. Put them in your CSS or LESS file.

@ghost
The following code does what you want, but it is not a substitute to colorbox and co.

Do not use the inline styles in a production environment. Put them in your CSS or LESS file.


Android's minimum API levels for arm and x86 have changed to 16

Support for ICS (Ice Cream Sandwich - Android API 14/15) was removed on 1/30/2018 in this commit per this changelog
arm and x86 now have a minimum API level of 16 instead of 14.

PR to address this issue can be found here: https://github.com/kennytm/rust-ios-android/pull/13

(Fixed by #13, thanks!)


Cannot duplicate structure fields more than once in a row.

Describe the bug
It is not possible to duplicate a structure fields more than once in a row using keyboard shortcuts.
To Reproduce
Steps to reproduce the behavior:

Open a file in the CodeBrowser
Create a new structure
Create a field by clicking on the green "plus" toolbar button, change its data type and/or give it a name
Duplicate the field using the appropriate keyboard shortcut (Option-D on macOS)
Trigger the shortcut again.
No further field duplications happen.

Expected behavior
Fields can be duplicated multiple times in a row.
Screenshots
Here's an animated GIF that shows the problem (I've added an overlay with keys being pressed)

Attachments
If applicable, please attach any files that caused problems or log files generated by the software.
Environment (please complete the following information):

OS: macOS 12.3.1
Java Version: 11.0.15
Ghidra Version: 10.1.3
Ghidra Origin: GitHub binary release

Yeah, structure/enum editing is something that feels unnecessarily stilted. While the layout offset/packing visualization comes in handy, it would be neat to have a C-struct text mode editor that makes it easier to copy-paste and duplicate chunks between elements and in and out of the program.
A bit like what we already have while editing functions directly.
Another idea would be making hex view mode in the editor persistent, I find myself toggling it on all the time.

We have talked about adding a free-form C structure entry mechanism.  Although, when reverse engineering a structure (i.e., packing disabled - default mode) such an editor can not be used since component placement must be very surgical and may be sparse - known vs unknown components).

When packing is disabled (default mode) components may only be placed at the end of the structure or where undefined (i.e., padding) components exist.  Provided this is the case one change we should probably make is to select the newly added component allowing the duplicate action to be repeated provided there is space.


Add warning limits

These are typically set at ±2σ. See Oakland for discussion.

[ ] Add Oakland spec + data

[ ] Ch 6, Worked Example 1
[ ] Ch 6, Worked Example 4

[ ] Rename {upper,lower}_limit to {upper,lower}_control_limit to distinguish from warning limits.

Unfortunately Oakland only provides constants up to n = 12, rather than the n = 25 that I'm using. Putting this aside for now.

To be clearer: x̄R limits can be calculated using the current constants table, but R̄ can't. It needs various values for Dʹ (as in Appendix C of Oakland).


Jump to name of declaration when using goto-definition

I'm not 100% sure about how the formatting in this project should be, sorry.
IntelliJ with editorconfig did its best :)

Looks good to me, the code style is fine too. Thanks for your contribution! 👍


fix: prototype poisoning (CWE-915)

NOTE from the project maintainer: Security Professionals: Please read the whole thread before accepting this at face value.  This is not a real vulnerability!  We're just trying to get the CVE folks to understand that (or even to respond to us.  ☹)

Added protection from prototype poisoning to mapObjIndexed().
For Proof of Concept exploit of the vulnerability visit https://jsfiddle.net/3pomzw5g/2/

@CrossEye :
We are a consumer of ramda, and got a VULN ticket to fix this Prototype Pollution vulnerability found in ramda. Just want to know if there are any tests set up to confirm if this issue can happen in Ramda? or if we can adopt the changes in this PR to fix this issue?

yanruzhang: I know nothing about such VULN tickets.  I don't have any sources for this.  I would hope that whatever gave you such a ticket would be able to give you information as well.  (And I hope you would share that with us!)
The code here is for a specific function and IMHO the test case does not actual demonstrate that vulnerability.  But that does not mean there is not one around, in this or another function.  But I'd like to see evidence of the problem before worrying about solutions.

The VULN ticket is a kind of ticket we use to fix vulnerability issues. There's one about  Ramda, and more specifically, _curry2 function 👇 , which this PR seems want to address.

Do you mean this _curry2 function doesn't actually have Prototype Pollution vulnerability?

@yanruzhang: This PR is not about _curry2; it's about mapObjIndexed.
But can you tell me the source of that report?  I haven't seen any reports of Prototype Pollution in Ramda, except for this issue, which I think is invalid, and I've been looking around for references to it in various  sources, but I don't know much about them.  What generates that report for you?  Does it have an online reference to the vulnerability?

@CrossEye
This is the source of the report: https://sca.analysiscenter.veracode.com/vulnerability-database/security/prototype-pollution/javascript/sid-32467

I did find that one in further research, but I can't find anywhere it gives a demo of the supposed vulnerability.  I'll keep looking, but that site seems pretty damned opaque.  Do you know anything about it?

@CrossEye
Sometime they don’t tell how to reproduce the vulnerability issue. Thanks for further looking into it, and we'd appreciate if you could let us know when you confirm if this can actually happen to ramda:
An attacker can inject properties into existing construct prototypes via the _curry2function and modify attributes such asproto, constructor, and prototype

@yanruzhang:
If that's all the information we can get, then I'm pretty sure I can simply say no, that cannot happen.
_curry2 depends on _isPlaceholder and _curry1.  curry1 depends on isPlaceholder.  Outside the calls to these internal functions, curry1 and curry2 only call the function supplied as a parameter.  And isPlaceholder checks the typeof of the supplied object and tests whether a specific string property of that object is true.  None of this can change the prototype of any object.
If you want to dig through every Ramda function to see if there's some possible prototype pollution, feel free.  Otherwise, I feel it's incumbent upon the reporter to demonstrate the existence of a problem.  But I can find no more information from veracode.  I've reached out to them but not heard back.
The simplest thing I can think of to check is the sort of canonical prototype pollution; the Ramda equivalent does not share the issue.  So my first thought is that no, this is not a real issue.
But without an actual demonstration, I'm not sure where to go.

I've posted a question in StackOverflow about this: https://stackoverflow.com/q/69936667.
Perhaps someone there will have some information.

So I've heard back from Veracode, and their source for the issue is this PR.
  But it's pretty clear to me that this does not do what's described as prototype pollution.  That you can create an object with a prototype is not prototype pollution.  Or if it is, then libraries are irrelevant, as a simple tweak to the original Fiddle shows that the same thing is true for Object.assign.
The snyk lodash report has a good test case for prototype pollution:
const mergeFn = require('lodash').defaultsDeep;
const payload = '{"constructor": {"prototype": {"a0": true}}}'

function check() {
    mergeFn({}, JSON.parse(payload));
    if (({})[`a0`] === true) {
        console.log(`Vulnerable to Prototype Pollution via ${payload}`);
    }
  }

check();

The closest Ramda equivalent is mergeDeepRight, and that does not share this problem.  Nor does mapObjIndexed; I will try to write up a full explanation to share with the Veracode team, although that might be time-consuming.

Below is a response I've drafted to send to Veracode.  Does anyone have any suggested improvements?
@ramda/core

Overview
There seems to be an erroneous vulnerability report in Veracode, saying that Ramda is subject to prototype pollution.
While we certainly have not definitively demonstrated that nothing in Ramda has this vulnerability, the examples so far are not examples of prototype pollution, only of the ability to create objects that the user didn't know would contain custom prototypes.
It seems like this report should be withdrawn.
Prototype Pollution
Prototype pollution is the ability for crafted input supplied to a generic function to the alter the prototype of built-in JavaScript constructs, such as Object.
One example, from a WhiteSource blog, is:
const getObject = require('getobject');
var obj = {};
var obj2 = 1;
console.log("Before Polluting : " + obj2.Check);  //~> 'Before Polluting : undefined'
getObject.set(obj, "__proto__.Check", "polluted");
console.log("After Polluting: " + obj2.Check);  //~> 'After Polluting: polluted'

Another one, closer to the case in question, from a snyk vulnerability report, looks like this:
const mergeFn = require('lodash').defaultsDeep;
const payload = '{"constructor": {"prototype": {"a0": true}}}'

function check() {
    mergeFn({}, JSON.parse(payload));
    if (({})[`a0`] === true) {
        console.log(`Vulnerable to Prototype Pollution via ${payload}`);
    }
  }

check(); //~> 'Vulnerable to Prototype Pollution via {"constructor": {"prototype": {"a0": true}}}'

What these have in common is that calling getObject.set or lodash.defaultsDeep modifies the prototype of the built-in Object, and thus they affect the behavior not just of the resulting object they return but also of any existing JavaScript objects and any newly created ones.
History
A Veracode vulnerability report said:

ramda is vulnerable to prototype pollution. An attacker can inject properties into existing construct prototypes via the _curry2 function and modify attributes such as __proto__, constructor, and prototype.

It has recently been updated to say this instead:

ramda is vulnerable to prototype pollution. An attacker is able to inject and modify attributes of an object through the mapObjIndexed function via the __proto__ property.

(It seems that this update was only in the last day or so, but that's not entirely clear.)
This was brought to our attention by a comment on an open issue in Ramda.  That issue, as discussed below, does not demonstrate prototype pollution, although it's an understandable mistake.  The commenter was able to point us to that report, but there was no other information available.
I am one of the founder of Ramda and currently its chief maintainer.  I reached out through Veracode's contact form online asking for more details.  When I didn't hear back in a few days, I dug a bit deeper and found contact emails online as well.  I emailed them, and a few days later got a response from a salesperson who thought I was in the market to buy their product.  I explained the problem and was told that this would be forwarded to someone who might know more.  Today, I heard back from someone else, a sales manager who had spoken to the technical team, who explained

We have based this artifact from the information available in https://github.com/ramda/ramda/pull/3192. In the Pull Request, there is a POC (https://jsfiddle.net/3pomzw5g/2/) clearly demonstrating the prototype pollution vulnerability in the mapObjIndexed function. In the demo, the user object is modified via the __proto__ property and is considered a violation to the Integrity of the CIA triad. This has been reflected in our CVSS scoring for this vulnerability in our vuln db.
There is also an unmerged fix for the vulnerability which has also been included in our artifact ( https://github.com/ramda/ramda/pull/3192/commits/774f767a10f37d1f844168cb7e6412ea6660112d )

In other words, the issue that was used to comment on Veracode's vulnerability report was earlier the issue which triggered the report.  Oh my aching head!  😄
That response continued:

Please let me know if there is a dispute against the POC, and we can look further into this.

This document is my attempt to explain the issue and thoroughly explore the reported vulnerability.
Reported Vulnerability
The reported issue was demonstrated with the code on a Fiddle.  It looks like this:
const hasOwn = JSON.parse('{"__proto__": {"isAdmin": true}}');
console.log(hasOwn.isAdmin); //~> undefined
const mapped = R.mapObjIndexed((val) => val, hasOwn);
console.log(mapped.isAdmin); //~> true

Note that hasOwn does not have isAdmin in its prototype, but mapped does have it.
The suggestion is that because of this Ramda's mapObjIndexed can cause prototype pollution.
Dispute
All the top answers on a search for "prototype pollution" have variants of the description on codeburst:

Prototype Pollution, as the name suggests, is about polluting the prototype of a base object which can sometimes lead to arbitrary code execution.

The above code does not do so.  It does not pollute the base objects.  It simply offers a surprising way to adjust the prototype of one specific object.  And this behavior has little to do with Ramda; it's part of the base language as well.  If we replaced the call to Ramda's mapObjIndexed with one to JavaScript's Object.assign, we get the exact same behavior.  As far as I can tell, there is no report out against Object.assign for prototype pollution.
Another way to look at it is to view some slight variants of the snyk demonstration above for mergeDeepRight and mapObjIndexed.  In each of these cases, the vulnerability is not found.
There's a reason these exploits are usually mentioned in combination of path-setting or deep merging and that they usually involve JSON.parse:  The usage of JSON.parse allows the code to create the __proto__ node without actually updating the prototype directly.  And then many deep-merge and path-setting functions work by mutating their input parameter with the values supplied.  In combination, that means that these tools will eventually do a deep set of someObject .__proto__ .isAdmin, and since a plain object supplied, someObject .__proto__ will be Object .prototype, which is then mutated to include isAdmin.
Ramda's design is different.  One of its guarantees is that it never mutates input data.  Ramda's equivalent of a deep set, assocPath, does not add properties to your object.  Instead it returns a new object, with all properties copied over from the old one and with your new property added or altered on this clone.  The various merge functions operate similarly.
That means there is a wall between the data you're trying to insert and the underlying Object prototype.  It's not clear if this wall is unbreachable, but it's more difficult than in the jQuery or lodash cases, where immutability is not the default.  While avoiding such an exploit was not a reason for Ramda's immutable design, it is a good demonstration of the advantages it offers.
So this vulnerability report was based on an invalid GitHub issue.  The Ramda team will close that issue soon.  In fact, it was only because of this report that it's been left open.
Can the Veracode team remove this entry from its database?
Follow-up
The history above was a dry recital of the order of events, but it has been a very frustrating process.  Would it be possible for Veracode's online reports to either directly include or offer a link to supporting evidence?  Here if the report linked back to the GitHub issue or supplied a proof-of-concept of the vulnerability, the Ramda team could have responded to this much more effectively.  Or, if that's not appropriate because they are reported before the team has a chance to work on the issue, could the report offer a "Challenge this finding" link with a way for tool maintainers to do what I've done?

@CrossEye So the GH issue was opened to fix an alleged vulnerability which VeraCode illustrated with my own example which wasn't even close to describing an actual prototype pollution? Bit confused right now.
Thanks for looking into this! LGTM

I've had no response yet, but now they've changed the description to:

ramda allows object prototype manipulation. An attacker is able to inject and modify attributes of an object through the mapObjIndexed function via the __proto__ property. However, due to ramda's design where object immutability is the default, the impact of this vulnerability is limited to the scope of the object instead of the underlying object prototype. Nonetheless, the possibility of object prototype manipulation as demonstrated in the proof-of-concept under References can potentially cause unexpected behaviors in the application. There are currently no known exploits.

(Of course References is not a link, and appears nowhere else on that page.)
I'm trying to decide if I want to get snarky and ask if they've filed the same issue against Object .assign.  Probably not at least until they respond.
For now, though, the only response seems to be that I've been added to their marketing email list.  😦

Hey Scott, really appreciate looking into this. Long fan and user of Ramda here!
Through my enterprise employer's account with VeraCode itself I was able to see the References tab, here's what's in it:

Their proof-of-concept is: https://jsfiddle.net/3pomzw5g/2/
The other links merely reference this PR and the mitigation commit.

@Dr1Ku:
Thank you very much.  That helps a lot.  It confirms what I suspected from their email.
I feel as though they've changed only their description in response to my dispute.  But at least I believe it's progress.
Also, "wacky" is a much more polite word than most of the ones I had in mind!  😄

Hey Scott, sure no worries. Yes I think they reacted to your email at least :D And apparently it's a been classified as a "SourceClear Premium (No CVE)" 'disclosure' (more like 'opinion piece'!) which renders the details and -worst of it all- the PoC viewable for logged-in customers only.. what a way to treat FOSS! Within my sphere of influence (read: project) we're going to go for bandaids like using more ramda-adjunct and temporarily ousting ramda just to jump through some compliance hoops, oh well.

After no response for a week, I've sent the following to Veracode:

Hi Folks,
I'm wondering if there is any response to this.
I see that the vulnerability report has been updated but not removed.  I still dispute the altered version of it.  If this behavior is a true vulnerability, could you point me to the equivalent report on JavaScript's Object.assign, which, as demonstrated earlier, has the exact same issue as the function in question.
My immediate goal is to see this report retracted.  But I also want to point out the pain involved in this process, pain that I think Veracode could fix:
I am not a customer, but your customers are coming to me as Ramda's maintainer to fix a problem you've reported.  That report really should have enough information in it to allow me to confirm the vulnerability reported.  I've learned that such information is available to a logged-in customer.  That doesn't help me or others in my position to find the information.  Resorting to email and filtering it through your sales department, is a pretty horrible process.  Could you alter your public reports to contain or point to a proof of concept of the vulnerability?  And could you further offer in the report some hint at a dispute process?
Thank you,
-- Scott

I've got to say this is extremely frustrating.

I heard back from Veracode today.  The sales manager, who has been a very helpful go-between for me with the engineering staff, said:

I wanted to provide an update, my engineering team got back to me with the following:
“updating our DB to remove the report is the final outcome”
I have also asked for them to let me know about your question regarding the ability to contend findings and will relay that back once feedback is received.
Otherwise, I hope this satisfies your request and please let me know if any further action is needed from us at this time.

This is very good news.  I'm still going to follow up with them on issues of an easier and transparent dispute process, and will report the results when I have them.

@Dr1Ku: would you be willing to check if this issue seems to have been cleared up?  The page at the center of this is gone (or no longer shows the content it had before.)  Their ramda page still lists one vulnerability.  But without logging in, I still can't check to see if this is the same prototype pollution one or something else.  It's quite possible this is about another issue which is fixed in master but not yet deployed.  But I simply cannot tell.

Hey Scott, their page for the prototype-pollution issue (SID-32467) is indeed not showing anything at the moment:

So that's removed. As far as the generic page for ramda 'vulns' (SourceClear Premium™.. vuln..?) goes:

It's just showing the remaining issue, Regular Expression Denial of Service (ReDoS), which is fixed from what I understood:

There are no further details other than links to the commit with the fix and the PR.

Let me know how I can further help!

@Dr1Ku:
Thank you very much for your help.   This is the news I was hoping for.  If I can either resurrect my linux box or somehow build on my Windows thingie, I will get that remaining issue behind us too!
Cheers!

I added an answer to the StackOverflow question, summing up the experience with this issue and Veracode.

hey folks, seems like someone assigned CVE-2021-42581 for this? assuming it should be disputed?

@assaf-benjosef:  Oh no, it's back!!  I have several evenings free this week and I'll try to take a look.  Do you know anything about the dispute resolution procedure.  I'm hoping it's easier than my Veracode experience.

@CrossEye I believe this form would be the best bet: https://cveform.mitre.org/
Should make a rejection change request there, they usually respond back in a couple days :)

Interestingly Snyk.io has added CVE-2021-42581 to their database as well, but only for Grafana packages, which I suppose depend on this library.

Well this appears to be a "malicious CVE"... the description mentions 0.27.0 as affected version, even when 0.27.1 was already released. That kind of implies that 0.27.1 was released as a fix for the reported vulnerability, increasing its credibility.
@CrossEye MITRE is the CNA who issues. I'm curious if they can tell you who asked them to submit this 10 days ago. @Marynk Was that you?

Interestingly Snyk.io has also added CVE-2021-42581 to their database, but only for Grafana packages, which I suppose depend on this library.

ahh seems like it was automatically created as a linux vulnerability due to a few distros adding this to their advisory database. It will be automatically revoked from snyk.io once the CVE is revoked. What we had control over was the decision of publishing an advisory against the independent ramda NPM package, which we did not do.
Did MITRE not reply to your request yet @CrossEye ?

@assaf-benjosef:
Nothing from MITRE.  This is starting to feel like Veracode all over again.
@dbolkensteyn:
I won't have time this evening, but will try to get more out of MITRE tomorrow.  After the dead silence on my previous message, I'm not really hopeful, however.

Just sent another request to Mitre.  The first one was never even acknowledged.  Trying a different email address just in case.

I would like to see this vulnerability rejected.  This is the second time I submit this.  I heard nothing, not even an automated reply, the first time: 2022-05-10.  I've supplied a different email address in case that was the issue.
The behavior mentioned in the original GitHub Pull Request that started this process is not prototype pollution. While it can be used to create and alter the prototype of a specific object, it can not modify preexisting objects' prototypes, and especially cannot modify built-in prototypes such as Object.prototype.
The github link supplied is where this started. The requested change was rejected, because this was not prototype pollution. Veracode, though, reported it as an error to their users, and the stackoverflow link explains the arduous process it took to get them to reject this vulnerability.
The other two links are to the Ramda REPL. One shows an example of how a library might be subject to prototype pollution. The second shows the equivalent Ramda code, which does not exhibit the same behavior.
Feel free to email me with follow-up questions<EMAIL_ADDRESS>(originally I used<EMAIL_ADDRESS>and either is fine.)

https://github.com/ramda/ramda/pull/3192
https://stackoverflow.com/a/70239612
http://link.fourwindssoft.com/52
http://link.fourwindssoft.com/53

Let's see if we have any better luck this time.

Dug up a direct email for Mitre, meant for reporting vulnerabilities, hoping they can at least route this to the appropriate group.  Something has to work, eventually.

I got a response from my email to Mitre,  which told me that they had already updated the CVE database.  It now lists the claim as "disputed", which is progress.  I really don't know the resolution process from there.

👍 https://github.com/CVEProject/cvelist/blame/master/2021/42xxx/CVE-2021-42581.json#L37

So, at long last, an update.  This whole business had chased me from doing OSS for the past year.  I was just too frustrated.  While I'm hoping I'm back.  But we'll have to find out.
You see, the answer is not good.
I had opened an email thread with Mitre, but they stopped responding, and didn't respond to pings, until today, fifteen months after I first started speaking with them.  I had pinged again this morning, and this afternoon, I got this reply:

I just spoke with our team and we are going to keep the record in the PUBLISHED state and note that it is disputed. It is very rare that we reject published records. We keep records that are in dispute in the PUBLISHED state so that CVE consumers can reach their own conclusions about whether the CVE Record has any value.
Should you choose, you can appeal the MITRE Top-Level Root’s decision. The program dispute policy is located here: https://www.cve.org/Resources/General/Policies/CVE-Record-Dispute-Policy.pdf
Regards
C

As far as I can tell, this means that Mitre takes no responsibility for fixing the problem they've caused.  The reason I ended up pinging them was that a coworker who was facing an issue from BlackDuck for another false vulnerability knew that I had been through this before and asked for advice.  (And if I become the go-to guy at my company for dealing with this, it will be a hard choice between retirement and suicide!)  He was right; it was a false report.  And I checked in with a third false report I knew about and found none of them had any response from Mitre.  So this does not seem to be an isolated incident.
Here's my response, sent at the local end of the work-week.  I hope I do hear back soon.

Chris,
Thank you for letting me know.
This has been extremely frustrating.  I feel that there's something wrong at Mitre that it has taken this long to resolve.
But I feel even more strongly that there's something broken in the whole process.  There are companies offering bounties for reporting  vulnerabilities, which gives an incentive  to report them without due diligence.
And yet there is no reasonable process for challenging these reports.   As I read your message, there is little chance of a CVE being withdrawn, so it is now my job as an unpaid open-source maintainer to try to convince the various security-related vendors to remove the CVE from their own databases.  I doubt there is a comprehensive list.  Can you suggest who else I need to get in touch with?  Here's a small start:

Aikido
Blackduck
Checkmarx
Contrast Scan
Coverity
Fortify
GitHub
GitLab
HCL AppScan
Invicti
JFrog
Mend.io
Kiuwan
Klocwork
Snyck
SonarQube
SonarSource
Sonatype
Synopsys
Veracode

Is this really the process?  It already has driven me from performing open-source work for a year.  After an extremely frustrating experience with Veracode (described at https://stackoverflow.com/q/69936667/), when this started again, I mostly gave up in exasperation.
Or is there some mechanism I don't know about that would make this easier?
Thanks,
-- Scott Sauyet

We'll see what next week brings.

One thing I'm not sure I ever mentioned above, Veracode, to their benefit, did eventually write a blog post demonstrating my point.  (Not that they told me about it, but someone posted a link on the StackOverflow issue.)  So one security company down, one zillion left to go.

I've got to say, there is a real temptation to find a way to post bounties for people reporting vulnerabilities within Mitre itself!  I'd love to see how well they enjoy the process.

BTW, two issues I'm tracking with similar Mitre issues:

https://github.com/Jermolene/TiddlyWiki5/issues/7384
https://github.com/mde/ejs/issues/720

Shockingly, Mitre responded in just 67 minutes!  I assume this guy has been instructed to mollify me after Mitre  ignored me for well over a year.

I’m sorry that your experience has been frustrating.
This was resolved from our perspective when we published the CVE record and indicated that it was disputed. This is the process for records that we publish. I apologize for our lack of timely communication regarding this outcome. We deal with many hundreds of requests and inquiries on a weekly basis so sometimes it takes us longer to reply then we like.
The quality and accuracy of vulnerability reporting is a known problem that is decades old and is not unique to the CVE program. Ecosystem-wide solutions for bad vulnerability reporting have proven elusive at scale.
I have no way of knowing what the outcome of the dispute and escalation process would be should you choose to engage it. MITRE does not control that process if the dispute is related to one of our records.  If the result indicated that the record was invalid we would reject the record at the direction of the Root organizations that would decide the matter.
Chris

Politely phrased, but it seems to be "Yeah, good luck, buddy!"
I'm polite in my response too:

Again thank you for the reply.
This was the first project on which I had such an issue.  A few months ago a second on arose on another project.  Today there was a third.  I had seen important vulnerabilities exposed through CVEs, but today's was the third false vulnerability that I was dealing with.  It was what made me try again to see what you could do.
As to the decades-old problem, it sounds like it's time to find as way of addressing it.  I don't know who sponsors bounties for finding vulnerabilities, but shutting those down sounds like a good start.  Or at least modifying them so that there has to be substantive confirmation and chance for rebuttal before a bounty is awarded.
I  might actually try the escalation procedure.  We'll see if I can stomach it.
Thank you for your timely response (this time 😄).
-- Scott

Okay, so maybe a little zing in the last line.  Who can blame me?

I had another exchange just before my bedtime last night:

If you have a way to do this at scale, I’m willing to listen.
We have to do this at scale. It’s a highly imperfect process.
I’m willing to talk though. If there is a better way, I’ll follow it.

to which I responded:

I'm going to have to give this some serious thought.  I don't really understand the CVE process; I've only paid attention insofar as it's affected me personally.
It may be that it's a fantastic process with only a small glitch.  But from where I stand, it looks like a gaping hole.  As a developer of open-source software, I want to be able to report that my software is secure.  But when a (possibly bad faith) actor comes along and reports a spurious vulnerability, even after I've demonstrated that this is false, there seems little recourse for me to repair the damage.
As a user of open-source software, I want to be secure in the knowledge that my security tools are properly reporting vulnerabilities, with extremely few false negative or false positives sneaking through; if we have to rework some code to remove reported vulnerabilities, then I need to know that this work is actually justified by real problems, and not pure nonsense
.
Those two requirements should not be in conflict.  But it feels like they are at the moment.

(And then a follow-up from me apologizing for typos; I really shouldn't type anything larger than a text message on my phone!)
It sounds like they might actually be willing to discuss fixes to this issue.  As I said, though, this is going to take some real thinking.

Hey @CrossEye,
I work as a security analyst at BlackDuck by Synopsys. I have been made aware of this issue and have looked into the "vulnerability". After playing about with the fiddlejs PoC we can confirm that we too believe you are correct and this is not a security vulnerability in the ramda library and is in fact the normal behaviour of JavaScript. The PoC can be recreated using just Object.assign .  Additional Objects created do not inherit polluted properties as is the dangers of Prototype Pollution.
Issues such as false positive vulnerability reports cause issues for all parties involved and especially OSS maintainers. The BlackDuck Security Advisory associated with the CVE will be updated to state that this is not a vulnerability.
Since I have no control over the CVE listing, I can only update our advisory to state that this is not a security issue. By updating it hopefully it will deflect from the claims that this is a security vulnerability.
Hopefully Mitre will follow suit and remove the CVE as it is digested by so many security tools.
TLDR: ramda is not vulnerable to Prototype Pollution as claimed in CVE-2021-42581.
mapObjIndexed is copying content from proto to a new object (same as assign) it is not setting global Object.prototype.
Also, heres a modified jsfiddle of the "PoC" that shows no global prototypes are manipuated.
https://jsfiddle.net/pd04r7j8/

@RustyButtons: Thank you.  That is fantastic news!  I'm booked pretty solid for the next two days, but I will write a note detailed response as soon as I can.

@RustyButtons:
Again, thank you.  If you've actually read this whole thread, you will know that dealing with these issues has been enough of a headache that it's mostly chased me from doing open source for more than a year.  After [fighting it out with Veracode][vc] for weeks, a few months later, we got the same problems with Mitre, who were even less responsive.  Basically crickets for over a year, until ten weeks ago, when I got a "sorry, but that's just the way it is" answer.
I'm really glad to hear that Black Duck will be addressing this.  Doubly so as BD is the tool used at my day job.
If you have a little time, I would love advice on how on how Ramda might proceed.  When Veracode did recognize that this wasn't a real issue and pulled their report, they were kind enough to write a blog post debunking the CVE.  While I can point people to that post, I don't know who to point to it.  Any insights you can offer would be much appreciated.  (And if you don't want to do it in a public forum, you can reach me at<EMAIL_ADDRESS>Again, thank you very much.  This is so refreshing!
[bp: https://www.veracode.com/blog/secure-development/yet-another-perspective-prototype-pollution
[co]: https://github.com/ramda/ramda/pull/3192#issuecomment-1741495660
[vc]: https://stackoverflow.com/questions/69936667


AKS Learn feedback: KEDA Metrics Server requirement is inaccurate

Type of issue
Missing information
Feedback
The docs currently mention the following:
Due to upstream limitations, KEDA must be the only installed metric adapter.

Only one metric server is allowed in the Kubernetes cluster. Because of that the KEDA add-on should be the only metrics server inside the cluster.

This is inaccurate and is causing confusion. This should read:
Due to upstream limitations, KEDA must be the only installed **external** metric adapter.

Only one **external** metric server is allowed in the Kubernetes cluster. Because of that the KEDA add-on should be the only **external** metrics server inside the cluster.

Original issue: https://github.com/Azure/AKS/issues/4436
Sources:

https://keda.sh/docs/2.14/faq/#can-i-run-multiple-metric-servers-serving-external-metrics-in-the-same-cluster
https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-metrics-apis

Page URL
https://learn.microsoft.com/en-us/azure/aks/keda-about
Content source URL
https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/aks/keda-about.md
Author
@tomkerkhove
Document Id
2c87a036-5f1f-2f34-2243-abbcc0d3269f

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 8dbb0979-78e4-9db8-6aaf-96c6240a8043
Version Independent ID: 2c87a036-5f1f-2f34-2243-abbcc0d3269f
Content: Kubernetes Event-driven Autoscaling (KEDA) - Azure Kubernetes Service
Content Source: articles/aks/keda-about.md
Service: azure-kubernetes-service
GitHub Login: @tomkerkhove
Microsoft Alias: tomkerkhove

@rouke-broersma
Thanks for your feedback! I've assigned this issue to the author who will investigate and update as appropriate.

Thank you for your dedication to our documentation.
Unfortunately, we have been unable to review this issue in a timely manner. We sincerely apologize for the delayed response. We are closing this issue and creating an internal work item to incorporate your suggestion as time allows. If you feel that the problem persists, please respond to this issue with additional information.
Please continue to provide feedback about the documentation. We appreciate your contributions to our community.
#please-close


Side bar selection state not saved

First of all amazing app!
So I've been using this all day today and I really like the Table of content feature in the sidebar. However when I switch between notes the sidebar resets to the markdown help section. It would be great if the TOC section could be persistent.
Would love to help with the app but I have 0 experience w/Angular!

Thanks! No worries, I will try to fix that for next release.


Didn't deduplicate

I got this dedublicate warnings in my Project:

warning<EMAIL_ADDRESS>could be deduped from "1.3.5" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.1.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "0.3.2" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "0.1.3" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.0.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.0.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.1.2" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "3.5.3" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "5.0.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "11.3.2" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.1.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.1.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.0.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "3.1.2" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "0.5.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.0.2" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.5.4" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.1.12" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "5.0.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.1.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.0.3" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.0.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "3.5.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.0.2" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.2.10" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.0.10" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.0.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "7.1.3" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "4.1.15" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.0.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.7.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.0.6" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.0.3" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.3.5" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.10.3" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "3.0.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.0.2" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.0.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "3.0.3" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.0.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "5.0.2" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "10.2.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.1.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.0.4" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "4.6.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "4.5.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "4.6.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "4.5.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "4.4.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "4.1.5" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.0.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "3.0.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "0.5.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.0.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "3.8.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "4.0.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.5.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.3.2" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.0.2" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "3.0.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.1.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "6.1.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.4.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.2.3" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "3.9.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.0.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "4.1.2" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.4.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.5.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "0.1.5" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "9.5.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.0.2" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.0.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "0.12.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "6.2.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.0.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.0.7" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.0.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "4.0.3" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.0.13" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "5.2.2" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.88.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "0.12.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.6.3" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "5.1.2" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "5.6.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.0.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.1.6" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.0.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.1.3" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "6.0.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.0.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "4.4.8" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "0.2.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.3.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "0.0.6" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.1.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.1.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.0.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.5.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "3.3.2" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "3.0.4" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "3.0.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.3.1" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.6.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.4.2" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "2.0.3" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.2.0" to<EMAIL_ADDRESS>warning<EMAIL_ADDRESS>could be deduped from "1.0.2" to<EMAIL_ADDRESS>
running yarn-deduplicate yarn.lock has no effect.
This is my package.json:

{
  "dependencies": {
    "@babel/runtime": "^7.3.4",
    "fbjs": "^0.8.17",
    "lodash": "^4.17.11",
    "lodash.isequal": "^4.5.0",
    "metro-react-native-babel-preset": "^0.52.0",
    "native-base": "^2.12.0",
    "npm": "^6.8.0",
    "prop-types": "^15.6.1",
    "react": "16.6.3",
    "react-devtools": "^3.2.1",
    "react-native": "0.58.5",
    "react-native-cacheable-image": "^2.0.0",
    "react-native-fast-image": "^5.1.2",
    "react-native-firebase": "^4.3.8",
    "react-native-grid-list": "^1.0.9",
    "react-native-image-zoom-viewer": "^2.2.23",
    "react-native-modal-dropdown": "^0.6.2",
    "react-native-render-html": "^3.9.3",
    "react-native-safe-area-view": "^0.7.0",
    "react-native-scrolling-menu": "experiment322/react-native-scrolling-menu",
    "react-native-transformable-image": "https://github.com/xstable/react-native-transformable-image.git",
    "react-native-vector-icons": "^6.1.0",
    "react-native-video": "tranvinhtruong/react-native-video",
    "react-native-video-player": "https://github.com/tranvinhtruong/react-native-video-player",
    "react-native-youtube": "^1.1.0",
    "react-navigation": "^1.5.11",
    "reactotron-react-native": "^1.14.0",
    "webpack": "^4.5.0"
  },
  "devDependencies": {
    "@babel/core": "^7.0.0",
    "@babel/preset-flow": "^7.0.0",
    "@babel/register": "^7.0.0",
    "babel-core": "^7.0.0-bridge.0",
    "babel-eslint": "^9.0.0",
    "babel-jest": "^23.4.2",
    "babel-plugin-transform-remove-console": "^6.9.2",
    "eslint": "^5.12.1",
    "eslint-config-airbnb": "^17.1.0",
    "eslint-plugin-import": "^2.14.0",
    "eslint-plugin-jsx-a11y": "^6.1.1",
    "eslint-plugin-react": "^7.11.1",
    "eslint-plugin-react-native": "^3.2.1",
    "jest": "23.6.0",
    "react-test-renderer": "16.6.1"
  },
  "jest": {
    "preset": "react-native"
  }
}

Any idea, why deduplication didn't work?

After yarn-deduplicate, please run yarn again. Or yarn check may print above warnings.

I've figured out. that I don't need this package for the App. So I only removed it.
Ticket can be closed.


[Feat]: Use Flags enums instead of number in typings

Tell us what problem the feature would solve
Currently in a bunch of places, such as DiscordUser we use number on the flags and public_flags. However, discord does document what are the possibile flags, for the user flags (public and not) it is on the User object user flags
Describe the solution you'd like
Use/create the enums for the flags for there values
Describe alternatives you've considered
Manually use the enum that exists with the exiting number type, however this does not guarantee the use of the currenct enum
Additional Info
No response

We already have ToggleBitfield (reference: https://github.com/discordeno/discordeno/tree/main/packages/bot/src/transformers/toggles), so yeah a flags and public_flags toggles would be nice

We already have ToggleBitfield (reference: https://github.com/discordeno/discordeno/tree/main/packages/bot/src/transformers/toggles), so yeah a flags and public_flags toggles would be nice

From what i understand the toggleBitfield are used to avoid having to store a considerable amount of booleans, not for flags. Correct me if i'm wrong

Oh wait I'm dumb smh
But yeah a enum, something like the Intents enum would be nice

Wait aren't we already have that? https://github.com/discordeno/discordeno/blob/ad7e74c4cd3f704442acea38dd890018ab0d1f86/packages/types/src/shared.ts#L19

Wait aren't we already have that? https://github.com/discordeno/discordeno/blob/ad7e74c4cd3f704442acea38dd890018ab0d1f86/packages/types/src/shared.ts#L19

In some cases we don't use them (user) in some we don't have it (member, idr if we merged that but still)

We will add the enums, but we will keep the number typing, so this issue can be closed


PostProcessing + VR + Vulkan = Crash

Vulkan has a "operation not supported" crash when trying to use Post Processing + VR. Looks like CommandBuffer.CopyRegion call on ForwardRenderer.cs line 703 kicks off the crash. Some buffer is expected to be "Staging" during the CopyRegion call, and when it isn't, an exception is called @ CommandList.Vulkan.cs line 1107.

fixed with https://github.com/phr00t/xenko/commit/e51f75d30fc7e3c1666a840b4fac295679c8957e


Use 'mousetime' to recognize multi clicks

Use the value of the Vim mousetime setting to recognize multi clicks. MacVim currently uses the mouse event property clickCount to recognize mulit clicks.

From what I can tell, this makes MacVim ignore the OS settings for double-click threshold, which may be undesirable for some users. If so, I'd expect this kind of behavioral change to be toggled via an option, rather than replace the existing behavior wholesale.

Yes, it ignores the OS settings and relies on mousetime instead. I agree that this change might catch some users off-guard. Here are a couple of ways to handle it:

Add a preference to either use the OS settings or mousetime like @jpetrie suggested
Use the OS settings if mousetime is set to it's default value (500) and/or a negative number

The reason I want MacVim to support mousetime is to be able to dynamically disable multi clicks through vimscript. Here's my use case:
map <silent> <LeftMouse>
    \ <LeftMouse>:<C-u>if &filetype ==# 'vimfiler' \|
        \ set mousetime=0 \|
        \ let cursorchar = matchstr(getline('.'), '\%' . col('.') . 'c.') \|
        \ if (cursorchar ==# g:vimfiler_tree_opened_icon) \|\|
           \ (cursorchar ==# g:vimfiler_tree_closed_icon) \|
            \ execute "normal 0\<Plug>(vimfiler_expand_tree)" \|
        \ else \|
            \ execute "normal 0\<Plug>(vimfiler_cd_or_edit)" \|
        \ endif \|
        \ unlet cursorchar \|
    \ else \|
        \ set mousetime=500 \|
    \ endif<CR>

This disables multi clicks in all vimfiler windows by setting mousetime to 0.

I definitely think this needs preference toggle (and should default to off to preserve existing behavior). There's examples of adding these sorts of preferences in the recent ligature pull request you could base the work off of.

I was thumbs-down on this, but now I think I may have turned 180 degrees.  Is it the case that: mousetime is supposed to govern gVim's double-clicking threshold for all GUI implementations, but our implementation happens to not obey this?  :help 'mousetime' suggests so.
If that is the case, then this PR should be merged[1] and there should be a new entry under :help macvim explaining that MacVim, like all gVims and indeed like console Vim, is supposed to ignore your system's thresholds.
And, there should be either no preference option to toggle this, or at worst, if we're going to include yet another divergence from Vim behavior, I would strongly favor @djjcast's idea "2".
Since Vim in the console (including the Vim buried in MacVim when run in console mode) already obeys mousetime at the expense of the system threshold, I see no reason to default MacVim to doing anything else.  The worst option to me appears to be to make this a GUI preference checkbox that defaults to ignoring mousetime altogether.  To be unpleasantly surprised by the change this PR introduces, a user would have to (a) be the sort of person who uses the mouse with Vim, and specifically, for double-clicking, (b) not have mousetime set in vimrc, and (c) have the system threshold set to significantly less than 500 milliseconds.  I doubt the number who meet all three of these is great enough warrant making a bugfix an opt-in affair, especially when it would be so easy to opt-out.
[1] Subject, of course, to this being the right way to make MacVim obey mousetime, and subject to there being no hidden technical reasons why Bjorn didn't just make MacVim obey mousetime in the first place way back when.  I have zero qualifications to comment on that.

I think :help mousetime implies that all GUI implementations should respect mousetime. It seems wrong to ignore mousetime or favor the GUI toolkit's interpretation of double-clicks.
There isn't a consensus between the core GUI implementations on how to interpret double-clicks - some use mousetime while others rely on the GUI toolkit.
The GTK+ version uses mousetime in favor of the GDK GDK_2BUTTON_PRESS event. Maybe mousetime wasn't considered when the other GUI implementations were developed - it's an obscure setting that's easy to overlook.
Also, this README outlines how the GUI implementations should work as a "clever terminal".

Hm, the mousetime documentation does make it sound like mousetime should apply in a GUI context.
But at the same time, there's a lot of (I would argue correct) divergence between vim, gvim and MacVim when it comes to GUI-related options; much of that divergence is based on things that the Windows and Mac GUIs don't do or which aren't idiomatic or sensible in the context of being a reasonably well-behaved and convention-conforming application. And for the GUI variants like gVim and MacVim I'd argue that being "well behaved" in the appropriate OS context is an important feature.
I don't see what's so special about vim that it gets to dictate an override to my double-click speed; I've always been annoyed by gVim's adherence to mousetime with no way to disable it. So one way or another I feel very strongly that MacVim should allow fallback to the OS double-click interval somehow.
I feel less strongly that such fallback should be the default (although MacVim already jumps through a lot of engineering hoops to try to preserve previously-existing behavior, so I'd say there is convention in place for doing so).
I feel even less strongly about how the fallback should be enabled. It's true MacVim has a growing number of preference toggles that exist outside the realm of the vimrc/gvimrc and that is somewhat concerning. It would probably be better if mouse click behavior could be entirely configured in one's vimrc. I don't think @djjcast's suggestion of "use the OS default if mousetime is 500" is a great idea, but falling back to the previous behavior if mousetime is negative might be. The documentation doesn't say what effect a negative mousetime has, so it's possibly at some point it might change to have meaning, but that seems unlikely.
Another option would be to look at how the antialias option is plumbed through, as that appears to be one of the few OS X-only options you can set in vim.

But at the same time, there's a lot of (I would argue correct) divergence between vim, gvim and MacVim when it comes to GUI-related options; much of that divergence is based on things that the Windows and Mac GUIs don't do or which aren't idiomatic or sensible in the context of being a reasonably well-behaved and convention-conforming application. And for the GUI variants like gVim and MacVim I'd argue that being "well behaved" in the appropriate OS context is an important feature.

I don't see what's so special about vim that it gets to dictate an override to my double-click speed; I've always been annoyed by gVim's adherence to mousetime with no way to disable it. So one way or another I feel very strongly that MacVim should allow fallback to the OS double-click interval somehow.

👍🏻

@djjcast could you check #168?


Add build status pages to root README.md.

The badges won't appear until a build completes after recent piper changes.


Merged URIs should resolve directly even if merged with other entities

currently URIs from merged entities are not directly resolveable

this is a possible duplicate of #240

solved in 4c3c5aa50f5e2aaf7d491e9ed8528a7162573168 for the entity uris that are created in the new versions eg https://mpr.acdh.oeaw.ac.at/entity/8243/ needs though still to be solved for the api2 uris, I open another issue for that


BUG: do not raise IndexError for identity slice in array.vindex

This closes #3211. This PR ensures that x is x.vindex[:] for a Dask array x. This works for any identity indexing slice, not only 1D (e.g., x[:, :] or x[:, :, :]).

[x] Tests added: test_vindex_identity.

This performs makes several assertions for two dimensions. I deliberately left this expanded for readability.
I test the edge cases: off by one (x[:n - 1] or x[1:]) and slices with a stride of 2 (x[0:n:2]).

[x] Passes flake8 dask (well, warns on a bunch but not on this diff).

A couple tiny style comments, but otherwise this looks good to me.  Thanks @stsievert !

ping

Updated. Thanks for the review.

Fixes #3211

This is in.  Thanks @stsievert !