Add a few checks for unsupported cases

mark docker unsupported 131
check apt-get is stable
re-add license key in the config

@brushknight , or @cristianciutea , could you re-create this PR on the open-install-library repository, so that the end to end tests can run with the repo's secret and give us confidence we'll have no regression?

this PR was recreated here: https://github.com/newrelic/open-install-library/pull/449


Getting Started: Auto-loading agda-mode

haha, a thousand edits 'cuz your editor trims trailing whitespaces

can you change OS X users to Aquamacs users?

Thank you, Orestis!


update by id function in audit mixin makes 3 db calls

Describe the bug
In the below code there are 3 db transactions, one for before, one for updation and another one for fetching the updated data post the update transaction, i feel this can be reduced to two considering we have the before value and the update value, we can make a union of the two values, this has performance impact on the application.
Considering negative scenarios of unwanted values, the update operation should be sufficient enough invalidate those values.
  async updateById(
     id: ID,
     data: DataObject<M>,
     options?: AuditOptions,
   ): Promise<void> {
     if (options?.noAudit) {
       return super.updateById(id, data, options);
     }
     const before = await this.findById(id);
     // loopback repository internally calls updateAll so we don't want to create another log
     if (options) {
       options.noAudit = true;
     } else {
       options = {noAudit: true};
     }
     await super.updateById(id, data, options);
     const after = await this.findById(id);

Fixed now


fix memory leak based from 2018 patch on parse_ie_keyword_arg()

Affected versions of this package are vulnerable to Out-of-bounds Read via the function Sass::Prelexer::exactly() which could be leveraged by an attacker to disclose information or manipulated to read from unmapped memory causing a denial of service.

Thanks, but we can't modify the libsass subtree directly. Follow https://github.com/sass/node-sass/issues/2685 for updates for bumping libsass version


distance to assets test

@mfunk please review and merge

@pHill5136 We all good to go here?

We're ready

@pHill5136 Ok done. Go ahead and delete the branch when you're ready.


GH-40652: [C++] Enlarge dest buffer according to dest offset for CopyBitmap benchmark

Rationale for this change

CopyBitmap benchmark doesn't make dest buffer large enough wrt. the possible dest offset, causing memory issues like when accessing the trailing bytes.
What changes are included in this PR?

Make the dest buffer wrt. dest offset.
Are these changes tested?

The fix itself is test (benchmark).
Are there any user-facing changes?

None.

GitHub Issue: #40652

cc @amoeba @pitrou

The Boost download failures on CI are unrelated. I'm restarting those builds a last time, but otherwise I'll merge.


e2e testing

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
What type of PR is this?

Special notes for your reviewer:
Does this PR introduce a user-facing change? Then add your Release Note here:

Documentation:

/test pull-kubeone-e2e-openstack-centos-install-containerd-external-v1.27.3

/test pull-kubeone-e2e-openstack-centos-install-containerd-external-v1.27.3

Recent e2e install tests worked


[DRAFT/WIP] Enabling vulkan in CI

WIP

We already have vulkan build as part of the CI process.
However, vulkan running itself is not enabled because my previous tests of nvidia docker does not seems to support it out of the box (thus the current CI error of incomaptible driver).
We can revisit and see what is the status now, and see if it is possible to get a vulkan compatible docker driver. Note that because vulkan is tied to display it might be hard

Close for now due to the PR is not yet actionable atm, feel free to reopen another one


🐛 Bug Report: Searching for 'EntityPage' in docs yields nothing

📜 Description
When looking for information on how to use the provided EntityPage the documentation search shows no useful results:

👍 Expected behavior
A core feature like EntityPage should at least have something describing how it is intended to be used in the documentation.
👎 Actual Behavior with Screenshots
See above
👟 Reproduction steps
See the screenshot above
📃 Provide the context for the Bug.
No response
🖥 Your Environment
No response
👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
Yes I am willing to submit a PR!

Gonna close this one as a duplicate of #26985, let's focus the discussion there


Add DebugView for Array and Dictionary, based of the DebugView from the .NET Foundation

Closes https://github.com/godotengine/godot-proposals/issues/6969

I am working on reimplementing the debug view for the C# runtime. Initially, I was creating a new debug view. Then, I incorporate the debug view from the .NET Foundation. This approach ensures consistency between the C# runtime’s enumerable and the GODOT enumerable.
This is why the comment of MIT license of the .net Foundation.

What's the actual source for this DebugView.cs file? The versions I found on Google all have "All rights reserved." but seem to be older versions.

The source of this debug view is the .net runtime, debug view of the ICollectionDebugView.cs, IDictionaryDebugView.cs and DebugViewDictionaryItem.cs.

I force pushed to divide the commit in two and change the indentation.
In this way if it is considered that the license does not apply I would just remove the last commit.

Thanks for the links!
I think this is trivial enough to not require attribution, so I think we can drop the second commit.

Ok, i drop it


v1.8: Vendor in google/protobuf/wrappers.proto

In the v1.8 branch, we vendor in all protobuf dependencies that we
need to generate the Hubble gRPC Go bindings. If they are not vendored
in, then protoc will fall back on the definitions present on the system.
If they are not present on the system, then the generation will fail.
When 7cc298c75420 was backported, we did not pull in the new protobuf
dependency on google/protobuf/wrappers.proto, causing the
api/v1/Makefile to fall back on the definition on the system. This
commit fixes this by vendoring in the missing file for protoc.
This commit does not affect any of the generated definitions and
therefore as no user impact. It will however ensure that developers can
rebuild the Hubble gRPC Go bindings without requiring them to have
protobuf definitions present on the system.
Starting with v1.9, we rely on the hubble-proto container (which
contains the correct version of the pulled-in proto dependencies) to
generate the gRPC Go bindings, therefore this PR targets v1.8 only.
Fixes: 7cc298c75420 ("api/observer: add new fields to inform about nodes status")
Signed-off-by: Sebastian Wicki<EMAIL_ADDRESS>

This does not need CI, as mentioned above this does not affect the generated code or any code run in CI at all.


Viva insights - Timestamp which email was written still visible

Regarding to: https://learn.microsoft.com/en-us/viva/insights/personal/use/schedule-send
I observed a minor issue that should be fixed:

Even with delay delivery, it is still possible to see the timestamp in which the email was written.
Both timestamps should be the scheduled moment.

Hello @20211048
Thanks for the feedback, however, here, we are limited to documentation changes and fixes, for your inquiry the best would be to open a support request or feedback portal https://feedbackportal.microsoft.com/feedback/forum/e59fb6ba-1d1c-ec11-b6e7-0022481f8472


Fix lxml default parser

Overview
This PR configures the lxml default parser to avoid security issues.
For example the default lxml parser replaces entities in the XML request with the content of local system files.

https://lxml.de/parsing.html#parser-options
https://pypi.org/project/defusedxml/#python-xml-libraries

Changes:

Added xml_util.py with a configured lxml parser for lxml.etree.fromstring and lxml.etree.parse.
Added test for xml_util.py.
Adjust to  werkzeug deprecation warnings:

use werkzeug.Response
use markupsafe

Cleaned up imports.

Related Issue / Discussion
Additional Information
This PR is not using defusedxml.lxml since it is deprecated:
https://pypi.org/project/defusedxml/#defusedxml-lxml
Contribution Agreement
(as per https://github.com/geopython/pywps/blob/master/CONTRIBUTING.rst#contributions-and-licensing)

[ ] I'd like to contribute [feature X|bugfix Y|docs|something else] to PyWPS. I confirm that my contributions to PyWPS will be compatible with the PyWPS license guidelines at the time of contribution.
[x ] I have already previously agreed to the PyWPS Contributions and Licensing Guidelines

Coverage remained the same at 0.0% when pulling 6896931b926d81b2debe8f907495dd742d705c6c on cehbrecht:fix-lxml-parser into 711219792be8b3d6a175a81152282dc5046d412b on geopython:pywps-4.4.


Don't fail empty results if failOnError is False

This also changes how the check is created, failing the check on failing tests. This resolves #217 and also resolves #161.
If people would actually still like the check itself to pass on failing tests, I would recommend adding that as an additional parameter to the action (failCheckOnFailure ?), but I don't trust my own TS skills enough to do that. However, my guess is that #214 was a misunderstanding of what #161 wanted to do, and not many people actually want what #214 adds.

Is it even a failure if no test results have been found? It should rather be a warning in my opinion.
This behavior already caused issues for me in the past, because I'm using a reusable workflow for my CI purposes. One of the projects did not have any tests (because it was just an autogenerated wrapper for something else) and the test report step failed because of this. On the other hand, I definitely want "failOnError" enabled in general for my projects.
My proposal is to change this error to a warning regardless of the "failOnError" value (cc @dorny). Not even sure if it's worth increasing complexity with a new "failIfNoTestsFound" input, but that might be something to consider if one really need to fail in this case. I don't see a valid usecase for this at the moment, but maybe I'm missing a valid point.

When you say "this behavior", which do you mean?
We have two kinds of failures we can report on here.

Failure of the action
Failure of a test in the test report.

And we have two places we can report them

In the action step
On the check

I believe its best to keep these clearly separate. 1 with 1 and 2 with 2. Then, For example, if no test results are found, because perhaps the file name was misspelled or so, i think it is good if the action marks itself as failed. Then, if you're unhappy with that behavior, its best to use the continue-on-error flag available to any GitHub workflow step.
For case 2-2, that is where you may need an additional flag to control  when you want that to fail.
I actually just tried  continue-on-error and it works for my use case, so, with "failOnError" set to true, i dont need this PR any more. So this PR can be closed but, it may still be worth thinking about.

For example, if no test results are found, because perhaps the file name was misspelled or so, i think it is good if the action marks itself as failed. Then, if you're unhappy with that behavior, its best to use the continue-on-error flag available to any GitHub workflow step.

This is the behavior I slightly disagree with 😓 If the file is misspelled, this might indicate a bug in the CI workflow, but might as well be perfectly fine (like in the scenario I described in my previous comment). Therefore I think we should change this to a "warning".
I can live with using the continue-on-error option, but this will as well suppress actual errors (e.g. sometimes some API calls do fail).

Hi guys,
thanks both for this discussion.
Is any of you changed his mind ?

Guys,
I merge this PR https://github.com/dorny/test-reporter/pull/243.
It's with choice. Anyone is happy :)


integrations: Add Rundeck webhook integration.

This PR adds a new integration - Rundeck.
It supports the following events related to Jobs:

Started
Succeded
Failed
Running Long
Scheduled Job Started

Special Thanks to @jjblack for working on this at #21234.

The PR originally had some conflicts due to the addition of other integrations.
Changed the webhook's type for payload from Dict[str, Sequence[Dict[str, Any]]] to WildValue, which is more typesafe and consistent with most webhooks.
Changed the Logo of the Integration to something more minimal. CZO Link.
Also had some minor issues with the documentation of the integration, fixed that as well.

Self-review checklist

[X] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[ ] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[X] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[X] Each commit is a coherent idea.
[X] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[ ] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[ ] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

@timabbott I have made the requested changes and have updated the PR. I think it's ready for another round of review.

This lgtm, but I'm a bit confused by the author name you have -- it looks like both the author and the co-authored-by are @jjblack, so if I merge this as written, you won't be credited. I think what you want to do is change the co-authored-by line to yourself; I guess I can do that while merging.

Thanks, for merging this and also fixing this author and co-author thing. :heart:
I am not sure what is the thing behind the author and co-author,  but I'll read up on it so I can get it right next time.


use cert apis from ibm cert mgr operator

CVE-2024-36537 - github.com/cert-Manager/cert-manager reports a high sev vulnerability which states that Insecure permissions in cert-manager v1.14.4 allows attackers to access sensitive data and escalate privileges by obtaining the service account's token. Resolution would be to change the reference to CRs from CS cert-manager rather than jetstack which was followed by ibm-commonui-operator priorly.
Fix - https://github.ibm.com/IBMPrivateCloud/roadmap/issues/64509

I replaced the iam-operator image and restarted the platform pods. Post that I ran regression with this change and observed an expected number of failures.
Regression - 1 failure
Scim - 22 failures
latest-reg.pdf
scim.pdf
There were no restarts seen in the iam-operator pod
security-test-automation % oc get pods | grep iam
iam-config-job-slq5d                                             0/1     Completed   0          23h
ibm-iam-operator-56d8f9654-nvlwd                                 1/1     Running     0          3h18m
security-test-automation %


[pulsar-server] add broker-configuration for relative dispatch throttling

Motivation
As we discussed at #5797, adding broker level relative dispatch-throttling-config.

Can we move this to 2.6.0 or 2.5.1?

run java8 tests

run java8 tests


New Sample: Statistical query (group and sort)

@dg0yal Please review this new sample

@nixta I've addressed all your comments. Also, I've fixed all other forced-unwrapped situations. Thank you for the review.

Looks great. Thanks @njarecha.


Basic HTTP Proxy Implementation [Reopens #8]

Http#via and Http#through are the primary methods. They basically transform an array into a dictionary of pieces of proxy software `{proxy_address: addr, proxy_port: port, etc}. Specs need work, but oughta stop us from breaking the functionality.
Usage:
Http.via("<IP_ADDRESS>", 8080, "username", "password").get("http://git.io/")

I don't see how this actually uses a proxy, but it does at least appear to be forward progress so I'm merging it


getTransferExtrinsicsFromBlock Error

network : testnet
FullNodeEndpoint : wss://knox-1.dock.io
block hash : 0x62919abf9a48df1a7ea819065f504d75505e16b383898355b2906efc4d254ff3
block number : 188301
network : mainnet
FullNodeEndpoint : wss://mainnet-node.dock.io
block hash : 0x070c5900391dc335367223accf8e9a825f02f0339a14178bf4cbc9b00f112b5a
block number : 11339035
code :
await getTransferExtrinsicsFromBlock(api, blockNumberOrHash, 'main', true, false)

Error: Decoding 39f3cMz2bbVohRqhdTL3xBemi6gJNB5Rot53hNGZDKk1KuVo: Expected non-null, non-empty base58 string input
How can I resolve this error?
Thanks

@SamHellawell
SDK version: 2.2.0

I have asked @lovesh to take look when he has a bit of time. In the meantime, is it possible for you to create/share a repository with example code for easier reproduction?

I can reproduce this issue. Looking into it.

@ygcool Can you please try again with the most recent commit e81d20dab302a994ca247cb0f34ed37930dbfad0?

@lovesh yes, It's working.  Great, thank you!

good to hear! will close out this issue :)


Implement Push Notifications for Watching Changes to the Users Resource

This creates two new datastore entities: Notification and NotificationChannels.
Currently, when we receive a notification, we simply log it in the datastore. I wasn't sure if we wanted to go all out and actually respect these notifications yet, so I kept it simple to start. Similarly, when we subscribe for a channel of notifications, the metadata for that channel is stored in the datastore for reference and so that we can unsubscribe later on if necessary.
The sync module has several handlers for accepting push notifications, viewing the notifications and channels in the datastore, subscribing for notifications, and unsubscribing from notifications. In order to receive notifications, the receiving address must use https. However, we cannot use oauth on that channel as directory services does not perform an auth before sending the message. Thus, the handler receiving these notifications is insecure and unauthenticated. I separated this handler out under /receive, whereas all other handler are under /sync which does require security and authentication.
To make this process more secure, in the future I can add support for generating a random token on the server and passing that to directory services when we subscribe. Directory services will then include that token in a header when sending post notifications. This isn't as good as real authentication, but it is at least something that would make it harder for a malicious user to spoof.
Finally, I added several docstrings to the datastore module while implementing tests for this to help incrementally clean that up. Overall, this has improved our landscape.io health check to 89% at last check which should only continue to rise.

Awesome overall!  Just some nits. :+1:

Reviewed 7 of 12 files at r1, 5 of 5 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved.

datastore.py, line 269 [r1] (raw file):
Done.

datastore.py, line 271 [r1] (raw file):
Done.

datastore_test.py, line 379 [r1] (raw file):
Done.

datastore_test.py, line 401 [r1] (raw file):
Done.

Comments from the review on Reviewable.io

And glad to see our code health going way up!


fix: profile stats

Thank you for your contribution to the KodaDot - One Stop Shop for Polkadot NFTs.
👇 __ Let's make a quick check before the contribution.
PR Type

[x] Bugfix
[ ] Feature
[ ] Refactoring

Context

[x] Closes #9474

Did your issue had any of the "$" label on it?

[x] My DOT address: Payout

Screenshot 📸

[ ] My fix has changed UI

Thanks!
pay 30 usd

😍 Perfect, I’ve sent the payout
💵 $30 @ 10.29 USD/DOT ~ 2.915 $DOT
🧗 1xjvRADwdJcnmUCLWerEHR4iGCT5EBTm4D4fzLLg4LcAC9p
🔗 0x19124493404f05b8c4c4265f31b1a9d2fb2914d80f751f1c98aa7d68b6d0d005
🪅 Let’s grab another issue and get rewarded!
🪄 github.com/kodadot/nft-gallery/issues


Support smallint for Redshift

Read this ticket for more info https://github.com/datafold/data-diff/issues/475
TLDR
Used to have the following error when comparing MySQL <> Redshift
  File "/Users/mattdelacour/Documents/src/coinlist/pipo/.venv/lib/python3.10/site-packages/data_diff/hashdiff_tables.py", line 99, in _validate_and_adjust_columns
    raise TypeError(f"Incompatible types for column '{c1}':  {col1} <-> {col2}")
TypeError: Incompatible types for column 'converted_from_additional_allocation':  Integer(precision=0, python_type=<class 'int'>) <-> UnknownColType(text='smallint')

And my full python script works once I add the support for smallint for Redshift

Smallint isn't unique to redshift. Postgresql also supports smallint. Perhaps it should be added there instead.

Smallint isn't unique to redshift. Postgresql also supports smallint. Perhaps it should be added there instead.

Done

Great! Please rebase into one commit, force push, and I'll merge it in.

Great! Please rebase into one commit, force push, and I'll merge it in.

done


kubernetes secret sync without creating pod

Describe the solution you'd like
Hello,
currently we have to create a secret provider class and a pod so that a k8s object gets created
would it be possible to have a controller which sync automatically azure keyvault with k8s secrets without going through the pod creation step?
the current solution works fine so this is suggestion is a nice to have feature (if possible of course)

Duplicate of https://github.com/kubernetes-sigs/secrets-store-csi-driver/issues/298
I've added few comments in the issue. Please feel free to chime in there.


Add more tunables for cpu hog scenario

Description
This commit exposes the flags to tweak the number of cores and node
count to hog during the node-cpu-hog scenario.

LGTM


fix: npm run test succeeds

resolves multiple errors of error TS2307: Cannot find module 'mdast' or its corresponding type declarations.

Where are you seeing this failing?


Don't use spaces in regexp

Fixes #2

FWIW, no tests added since there's nothing there right now. Haven't updated the readme either. Tests right now invalidly load mocha and should when they aren't needed. There's a typo on the readme too.
Since this changes the way matches occur, I didn't want to turn it into a conversion about the test implementation I use or anything else. But why isn't this tested or have CI?

@tunnckoCore What's with the default max length too?

Tests right now invalidly load mocha and should when they aren't needed.

Because the template that I use.

For a 1.0 library this is quite bad.

And yea, my fault. As you can see, last weeks I no longer publish v1 without tests and strictly review the readme and misc stuff, like links, typos and etc.

What for max length? It reasonable.

I don't think this is right. I know it fixes #2 but I think this regex in general needs a lot of work.

What for max length?

I think it should be hard-coded at the max length of twitter screen names. I can't remember what it is, I think 15 but not sure. consider making it longer if you get a request with a good use case. otherwise it's overhead.

@jonschlinkert 20, my is 21 and I remember it. Yea I work on. :)

Btw, it should have spaces.

yeah, it's 15. here it is: http://blog.justunfollow.com/2014/03/13/10-twitter-limits-any-smart-user-should-know/.

Btw, it should have spaces.

why? I've never seen @ mentions allow spaces. that seems like a terrible delimiter. I don't think they should be allowed.

why? I've never seen @ mentions allow spaces.

I mean, around the mention.

But my idea is to provide options to configure this needs.

@tunnckoCore That's why I'm using \b

I don't think this is right. I know it fixes #2 but I think this regex in general needs a lot of work.

Agreed, and if that infrastructure existed I would.

That isn't the solution. Yea, won't match emails, but will match things like @tunn@ckoCore which actually isn't proper mention. For this its necessary to use \s and optional configs for this.
assert.strictEqual(regex().test('github @tunnckoCore'), true);
assert.strictEqual(regex().test('@tunnckoCore some'), true);
assert.strictEqual(regex().test('@tunnckoCore'), true);
assert.strictEqual(regex().test('@tunn@ckoCore'), true);
assert.strictEqual(regex().test('email@dot.com'), false);

Because of that I think its better to have options for startSpace and endSpace.
And then if you want to just regex.test('@tunnckoCore') , you should set startSpace and endSpace to false.
var regex = /\s+@([a-z0-9_]{1,30})\s+/i;
assert.strictEqual(regex().test('github @tunnckoCore'), false);
assert.strictEqual(regex({endSpace: false}).test('@tunnckoCore some'), true);
assert.strictEqual(regex({startSpace: false, endSpace: false}).test('@tunnckoCore'), true);
assert.strictEqual(regex().test('@tunn@ckoCore'), false);
assert.strictEqual(regex().test('email@dot.com'), false);

@tunnckoCore Did you actually run the test or look up what \b is? It works perfectly.

Yea, I did.

I wouldn't expect to know whether it's surrounded by spaces or not, that's the point of this library.

agreed. I think this lib (and all of the regex libs) should provide consistent, reliable results. IMO, consistency and predictability are far more important and attractive to users than flexibility.

I wouldn't expect to know whether it's surrounded by spaces or not

Yea, u have right guys. I think we should choose @jonschlinkert's solution, but with options. Are you okey with that, @blakeembrey ?

but with options.

what options would there be? the only other options were whitespace (which should never be allowed in screen names) and length, which IMHO is a useless option. there should be a strict length limit or none at all. this is something the user shouldn't be asked to decide as there are already well-established conventions for screen names and parsing them. I think most implementors would find twitter's guidelines to be a reasonable model to follow.
the other thing is runtime compilation. with options we have to pass a dynamically created string to the RegExp constructor, which is much slower than a regex literal. (I wish I could tell this to myself 18 mos ago).
@tunnckoCore, I'm not trying to beat you over the head with my opinion, do what you think is best for what you need. I just think it's more likely to be used if it it's clear and specific
just my 2c

Actually, I agree with you and understand you. But I think should have option for length, its reasonable to have. We should not force implementors to have some strict length.
But the case can be solved with single if opts.length then dynamically generate regex, else literal.

But the case can be solved with single if opts.length then dynamically generate regex, else literal.

yeah, that's a good compromise.

Haha, okey.. This (your) solution is cool.
http://regexr.com/3acq0 /(?!\b)@([0-9A-Za-z]{1,15})/
abc @abc foo
@ abc@foo xyz
abc @ abc
abc<EMAIL_ADDRESS>far
abc @dce
abc @goo.gl
abc @xyz!os
abc @qux*dex
abc @ubu^ntu
abc @foo!bar
abc @hash#tag
abc @musta{che
abc @@foobar   // should not match
abc @@pub@sub  // should not match
abc @#tag ok   // should match
abc@qux*dex
invalid @\\os
invalid @*inv

But we should think for these cases @@foobar, @@pub@sub and @#tag which differs from twitter's.

Ooookey, 100% twitter compatible, lol, but not github compatible.. And because the name of the package is mentions-regex I think we should provide some config options, its not twitter-mention-regex.
But yea, its a good thing to follow giants when you want to have same functionality :) And yea, its a good starting point to cover at least twitter cases :)
More use/edge cases @regexps/owners?
var regexDot = /(?:^|[^a-zA-Z0-9_@＠])(@|＠)(?!\.)([a-zA-Z0-9_\.]{1,15})(?:\b(?!@)|$)/;
var regexNoDot = /(?:^|[^a-zA-Z0-9_@＠])(@|＠)([a-zA-Z0-9_]{1,15})(?:\b(?!@)|$)/;

fixtures
// should match `bar`, when opts.dot `bar.baz`
foo @bar.baz qux

foo @bar_baz qux // should match `bar_baz`
foo @_bar // should match `_bar`
foo @2bar // should match `2bar`

// should match `google`, when opts.dot `google.com`
foo @google.com
foo .@bar

// should not match even opts.dot
foo @.bar
foo<EMAIL_ADDRESS>foo git@github.com:tunnckoCore/is-glob

// should not match
foo @bar@baz
foo @!bar
foo @@bar
foo @@bar@baz
foo @@bar!qux
foo @#bar

// should match only `bar`
foo @bar baz
foo @bar!baz qux
foo @bar#baz qux
foo @bar$baz qux
foo @bar%baz qux
foo @bar^baz qux
foo @bar&baz qux
foo @bar*baz qux
foo @bar(baz qux
foo @bar)baz qux
foo @bar{baz qux
foo @bar}baz qux
foo @bar<baz qux
foo @bar>baz qux
foo @bar[baz qux
foo @bar]baz qux
foo @bar=baz qux
foo @bar+baz qux
foo @bar-baz qux
foo @bar`baz qux
foo @bar/baz qux
foo @bar\baz qux
foo @bar:baz qux
foo @bar;baz qux
foo @bar?baz qux
foo @bar~baz qux
foo @bar|baz qux
foo @bar"baz qux
foo @bar'baz qux

@regexps/owners ping, thoughts?

@jonschlinkert ?

really have no idea, I personally would probably follow an established convention for it, like what I said in https://github.com/regexps/mentions-regex/pull/3#issuecomment-73537348

I think most implementors would find twitter's guidelines to be a reasonable model to follow.

would probably follow an established convention for it

latest regex (and examples) follow them.. as you said there 15 characters, no options nothing.
the question is are you okey with this matching, more use cases? I directly paste these on a tweet and it is 100% okey.

okey I've just update it more will commit up ASAP!
Thanks for the thoughts, discussion and ideas!

you're doing great. if you're good with it I'm good with it

damn ddos attacks...
Last 1 hour I playing with regex in twitter and finalize it totally :) its awesome now
http://regexr.com/3an0h , I dont like very much regexr.com because it highlights "the whole match" and more info and details and capturing groups are in the tooltip when hover the highlight.

I dont like very much regexr.com

I like it quite a bit. I use it all the time. everyone has their own taste, maybe this will be better for you https://www.regex101.com/r/aD4oV1/1

nice work, looks great

maybe this will be better for you

doh yea, I forgot it! :)

nice work, looks great

thanks!
but this ddos delay me. i forget what im doing ;d

yep, also npm is ddos-ed, damn


backtrace command wouldn't print full call stack like byebug or pry-byebug

in pry-shell, only print one line like "From: xxxxxxx"
is this normal?

This should be fixed by #17.
/close


Parse more than one URL encoded variable

When I try to pass more than just one variable to the webhook, it does not work, as only the first variable is received.
Could someone tell me how to make something like:
#!/bin/sh

echo "Hello ${name}, do you want to ${command}?"

Work?
curl localhost:8080/scriptname?name=Max&command=play
does not work unfortunately.
Thanks in advance

It should work... Here, your example works without a hitch:

Do you use quotation marks for the CURL URL?  Without quotation marks, '&' can be a problem for your Shell.

Well, thanks for the info. Indeed, with quotations it works. I'm impressed with the fact that I did not think of such a basic thing. Wow.


Temporary Tester Version

Docker Compose File the I hope should work and I will make adjustments to it if necessary. Closes #14

does it work with docker-compose up? if not, then let's hold off merging to main until it does

does it work with docker-compose up? if not, then let's hold off merging to main until it does

Yes! Now it does

Alright I think it should be good now but please do have a look at it. Closes #14. Closes #50

named volumes:
https://nickjanetakis.com/blog/docker-tip-28-named-volumes-vs-path-based-volumes#:~:text=Named volumes look like this,running docker volume create postgres .

Closes #50.

Issue #50 includes Nginx, does Nginx work as well?


Delay of ~60ms in point cloud calculation with multiple cameras in querying RS2_OPTION_DEPTH_UNITS

Required Info

Camera Model
D400

Firmware Version
<IP_ADDRESS>

Operating System & Version
Win 10 x64, Ubuntu 18.04 (same behavior)

Kernel Version (Linux Only)
4.9

Platform
PC, NVIDIA Jetson Xavier AGX

SDK Version
2 (master)

Language
C++

Segment
Robot

Issue Description
I am using two cameras streaming depth and using librealsense's point cloud conversion. Since the issue may (or may not) be related to the way I am accessing the two cameras, I've also included information about that below.
The actual issue
Occasionally, with >1 camera, the point cloud conversion will take ~60ms (usually it takes ~200-1000us). After building librealsense and putting in profiling code, I have narrowed down this "hiccup" to this block in proc/pointcloud.cpp
        if (!_depth_units)
        {
            auto sensor = ((frame_interface*)depth.get())->get_sensor().get();
            _depth_units = sensor->get_option(RS2_OPTION_DEPTH_UNITS).query();
            found_depth_units = true;
        }

Replacing that with _depth_units = 0.001; (that's what I'm setting the depth units to) "fixes" the issue.

Is there any API to specify to librealsense::pointcloud that we know what the depth units are so it doesn't query them?
I'd also like to understand why it's having this hiccup. On the Jetson with the cameras pointed at what we want to see it seems to happen regularly. On my PC with the cameras just pointed at the ceiling, it seems to happen when I physically move one of the cameras around (?). The behavior is the same whether connected to separate USB3 ports to the CPU or through a hub.

How I am sampling the cameras
The way I would like to use the two cameras is to have a vision thread that (at 90hz, the selected sample rate) "pushes" new (processed) point clouds after combining the data from all cameras. The way I'm doing this now is:
	for (size_t i=0; i<Ndev_; ++i) {
		bool got_frame = false;
		// First camera: try_wait; other cameras: check for latest frame
		if (i > 0)
			got_frame = pipelines_[i].poll_for_frames(&framesets_[i]);
		// If i>0 cameras poll fails; also try_wait to make sure we get frames from all
		if (i == 0 || !got_frame)
			got_frame = pipelines_[i].try_wait_for_frames(&framesets_[i], 500); // timeout in ms

		if (!got_frame) {
			// error (camera unplugged or something)
		}
	}

Though this has been working as expected, I assume there may be a better way of doing this, so I included this information.

Hi @avikde  The default Depth Unit Scale value of 400 Series cameras is 0.001 so this is an appropriate value to use.
Although the depth unit scale value can be retrieved in real-time from a camera using an SDK programming instruction, this is mainly useful if you expect the scale to be changed during the application's use.  The value does not change unless deliberately altered, and so in the majority of cases a fixed hard-coded value can be used for equations that use the depth scale.
For example, multiplying the raw 16-bit depth value of the camera by 0.001 (the default 400 Series depth scale value) can convert the depth into a real-world distance in meters without having to query the camera to retrieve the depth scale.
An easy way to find the default depth unit scale value of a particular RealSense camera model is to launch the RealSense Viewer tool and go to the Controls category of the Stereo Module options in the Viewer's side-panel.  Locate the Depth Units option and read the value that is displayed in the text box.

In regard to the issue of why the point cloud slows when the camera is moved, there is a detailed discussion of this phenomenon and potential solutions in the link below.
https://github.com/IntelRealSense/librealsense/issues/4958

Thanks @MartyG-RealSense - since the code that retrieves the depth units is in librealsense/src/proc/pointcloud.cpp I was wondering if there's something I can do in my usage of librealsense that can ask it to not query for depth units. For now I can use a "patched" version but I'm assuming this is happening because I'm doing something wrong.

Hi @avikde  Do you require further assistance with this case, please?  Thanks!

For now the workaround of modifying the librealsense sources and hardcoding the depth units in pointcloud.cpp is working for me, so I guess we can close this issue for now. However, I haven't made any progress toward an actual fix, so potentially this will come back in the future and at that point I'll have to open another issue I guess. Thanks for the help.

I'm pleased to hear that you found a workaround @avikde - thanks very much for the update, and please do feel free to open cases in the future when the need arises.


add SMS challenge handler

Quick fix, to handle an SMS challenge only via the cli.

What is "SMS challenge"?
I have never been seen this.

During the auth process when something wrong is detected (bot, special user-agent, new connection Ip ...), a new verification flow appears, to check if you are the correct owner. (2 steps authentication).
You can either be called, get a pin code via text message ... and maybe more options, just to check that your not an account stealer.
In this PR, I included one of this verification step, that I had and caused the issue #196, the SMS one (text message verification).

Ok, no problem I understand


2.7.2 has warnings / The warning doesn't accur 2.7.1

I used nativebase 2.7.1 / but today I updated nativebase to 2.7.2 and It makes warnings like below..
3 warnings..
is it my fault? or just bugs in 2.7.2 version?

I'm getting these warnings as well and I'm on 2.3.5.
Invalid props.style key NativeBasesupplied toView. Bad object: {   "NativeBase": {     "Label": {       ".focused": {         "width": 0       },       "fontSize": 17     },     "Icon": {       "fontSize": 30,       "color": "#000"     },     "IconNB": {       "fontSize": 30,       "color": "#000"     },     "Input": {       ".multiline": {         "height": null       },       "height": 50,       "color": "#000",       "paddingLeft": 5,       "paddingRight": 5,       "flex": 1,       "fontSize": 17     }   },   "borderLeftWidth": 0,   "borderRightWidth": 0,   "borderTopWidth": 0,   "borderBottomWidth": 2,   "borderColor": "#D9D5DC",   "backgroundColor": "transparent",   "flexDirection": "row",   "alignItems": "center",   "marginLeft": 2,   "opacity": 1 } Valid keys: [   "display",   "width",   "height",   "start",   "end",   "top",   "left",   "right",   "bottom",   "minWidth",   "maxWidth",   "minHeight",   "maxHeight",   "margin",   "marginVertical",   "marginHorizontal",   "marginTop",   "marginBottom",   "marginLeft",   "marginRight",   "marginStart",   "marginEnd",   "padding",   "paddingVertical",   "paddingHorizontal",   "paddingTop",   "paddingBottom",   "paddingLeft",   "paddingRight",   "paddingStart",   "paddingEnd",   "borderWidth",   "borderTopWidth",   "borderStartWidth",   "borderEndWidth",   "borderRightWidth",   "borderBottomWidth",   "borderLeftWidth",   "position",   "flexDirection",   "flexWrap",   "justifyContent",   "alignItems",   "alignSelf",   "alignContent",   "overflow",   "flex",   "flexGrow",   "flexShrink",   "flexBasis",   "aspectRatio",   "zIndex",   "direction",   "shadowColor",   "shadowOffset",   "shadowOpacity",   "shadowRadius",   "transform",   "transformMatrix",   "decomposedMatrix",   "scaleX",   "scaleY",   "rotation",   "translateX",   "translateY",   "backfaceVisibility",   "backgroundColor",   "borderColor",   "borderTopColor",   "borderRightColor",   "borderBottomColor",   "borderLeftColor",   "borderStartColor",   "borderEndColor",   "borderRadius",   "borderTopLeftRadius",   "borderTopRightRadius",   "borderTopStartRadius",   "borderTopEndRadius",   "borderBottomLeftRadius",   "borderBottomRightRadius",   "borderBottomStartRadius",   "borderBottomEndRadius",   "borderStyle",   "opacity",   "elevation" ]     in View (at createAnimatedComponent.js:154)     in AnimatedComponent (at TouchableOpacity.js:247)     in TouchableOpacity (at Item.js:292)     in Item (at connectStyle.js:384)     in Styled(Item) (at Home.js:106)     in RCTView (at View.js:60)     in View (at Home.js:105)     in RCTView (at View.js:60)     in View (at Home.js:103)     in Home (at SceneView.js:17)     in SceneView (at CardStack.js:466)     in RCTView (at View.js:60)     in View (at createAnimatedComponent.js:154)     in AnimatedComponent (at Card.js:12)     in Card (at PointerEventsContainer.js:39)     in Container (at CardStack.js:498)     in RCTView (at View.js:60)     in View (at CardStack.js:414)     in RCTView (at View.js:60)     in View (at CardStack.js:413)     in CardStack (at CardStackTransitioner.js:67)     in RCTView (at View.js:60)     in View (at Transitioner.js:142)     in Transitioner (at CardStackTransitioner.js:19)     in CardStackTransitioner (at StackNavigator.js:41)     in Unknown (at createNavigator.js:13)     in Navigator (at createNavigationContainer.js:226)     in NavigationContainer (at App.js:10)     in RCTView (at View.js:60)     in View (at Root.js:13)     in Root (at connectStyle.js:384)     in Styled(Root) (at App.js:9)     in App (at renderApplication.js:33)     in RCTView (at View.js:60)     in View (at AppContainer.js:102)     in RCTView (at View.js:60)     in View (at AppContainer.js:122)     in AppContainer (at renderApplication.js:32)

Did you found any solution?
I'm getting these warnings on 2.6.1

I can't find anything yet

+1 (Only 'supplied to ScrollView')
In my case I got a warning after putting the  tag in component.
After re-creating the project in 2.7.1, warning disappeared.

Same error.
    in View (at createAnimatedComponent.js:154)
    in AnimatedComponent (at TouchableOpacity.js:247)
    in TouchableOpacity (at Item.js:292)
    in Item (at connectStyle.js:384)
    in Styled(Item) (at HomeScreen.js:59)

My use of Item:
          <Form>
            <Item>
              <Input
                placeholder="Username"
                autoCapitalize="none"
                onChangeText={username => this.setState({ username })}
                value={this.state.username}
              />
            </Item>

Somehow the "Invalid props.style key NativeBase supplied to ScrollView....  appeared today...
my project:
react-native init app1 ; cd app1
npm install --save redux react-redux redux-thunk moment react-navigation react-native-vector-icons native-base
npm install
react-native link
react-native link react-native-vector-icons

Updated npm which fixed the issue for me..
nvm install-latest-npm

  "dependencies": {
    "color": "1.0.3",
    "lodash": "4.13.1",
    "moment": "2.13.0",
    "native-base": "2.7.2",
    "react": "16.4.1",
    "react-native": "0.56.0",
    "react-navigation": "1.5.0"
  }

I tried NativeBase KitchenSink with these dependencies, no warnings

let me know how I can help here

Closing this due no response

I've got the same problem. I tried to revert to 2.7.1 and got the same error. After a few tries, this is what worked on windows 10 for me:

change version of native-base in package.json to 2.7.1
delete node-modules folder & package-lock.json
in windows power shell do npm install

I'm not sure what the problem was(Version, cmd or something else), i may test it later when my project is finished.

Its difficult to fix issue, unless its reproducible @k-neo @abonander @nixidee
I have shared my response above
If this still happens, then try putting this on snack, and try to reproduce

Have the same issue, it just popped out suddenly on one of my projects , I'm on "native-base": "^2.7.2",

I mentioned this in my previous comments that

If this still happens, then try putting this on snack, and try to reproduce

rm -r node_modules && yarn did the job for me. I was getting the "Invalid props.style key NativeBase supplied to ScrollView" warning.

Like @SupriyaKalghatgi already mentioned, this is hard to reproduce. It's a very strange bug.
I was getting this error on multiple components. The error is a little misleading because in one instance, the only way to clear warning was to remove button completely.
Tried changing versions, clearing caches, node_modules and removing styles on affected components.
Eventually fixed by deleting package-lock.json


ENH: support QIIME 1 demux FASTA format

i.e. the "seqs.fna" format described here:
http://qiime.org/documentation/file_formats.html#demultiplexed-sequences
Adds the SampleData[Sequences] semantic type, which has QIIME1DemuxFormat as its canonical format.
Fixes #106.

Thanks @ebolyen, I addressed your comments in a squash commit! :jack_o_lantern:


Move to saz limits

In an attempt to move to mature, 3rd party, modules this PR covers a possible migration from harden::limits to saz/limits. It should produce the same settings as using Harden but with each value in its own files, and none bunched in to limits.conf
The story is located at https://trello.com/c/nVs0krua

==> backend-2.backend: Error: Cannot alias File[/etc/security/limits.d/] to ["/etc/security/limits.d"] at /var/govuk/govuk-puppet/vendor/modules/limits/manifests/init.pp:12; resource ["File", "/etc/security/limits.d"] already declared at /var/govuk/govuk-puppet/vendor/modules/harden/manifests/init.pp:54

when run under vagrant

This PR should also remove the old copy of the vendored puppet-harden module.

@deanwilson It'd be good to say in your commit messages and/or PR description if this change makes any functional difference; are any new limits set which weren't previously?

I've updated the PR to mention the functional side. Nothing should really change but the harden module was inconsistent in how it set things so there will be a minor change as settings break out in to individual files to be consistent with all the other usages of limits.

Thanks @deanwilson :+1: It makes it easier for people to test if they know what to look for.

Must have missed one, which vendored file needs to be removed?

You can find it using the old SHA from the Puppetfile.lock, it's:
vendor/puppet/source/fa2c51e994b87e71e7b424b6c0048b70c2df36b0.tar.gz

Removed the old file. Thanks.

LGTM, are you able to test @rjw1's comment in Vagrant?

:+1: lgtm


Fix laravel 5.4

It's not a fix, please see #187 .

Ok! Sorry :(
Thanks for the info :)

very appreciate


WIP: Feature/add forex

Adding forex search
Closes https://github.com/zackurben/alphavantage/issues/25

Coverage remained the same at 100.0% when pulling 39d6377d2b232cade527c77ab5e22bb508a9e472 on feature/add-forex into 3f9f96035db8878b34cf76ffc482d1ab6c9b1b0e on master.

Coverage remained the same at 100.0% when pulling adbb01ecbdc8068ecd0564c70e38d9d90acc815c on feature/add-forex into 3f9f96035db8878b34cf76ffc482d1ab6c9b1b0e on master.

Coverage remained the same at 100.0% when pulling adbb01ecbdc8068ecd0564c70e38d9d90acc815c on feature/add-forex into 3f9f96035db8878b34cf76ffc482d1ab6c9b1b0e on master.

Coverage remained the same at 100.0% when pulling adbb01ecbdc8068ecd0564c70e38d9d90acc815c on feature/add-forex into 3f9f96035db8878b34cf76ffc482d1ab6c9b1b0e on master.

Coverage remained the same at 100.0% when pulling adbb01ecbdc8068ecd0564c70e38d9d90acc815c on feature/add-forex into 3f9f96035db8878b34cf76ffc482d1ab6c9b1b0e on master.


Added bootargs variable to KERNEL_ARGS

This is required for Mender's 'mender-persist-systemd-machine-id' feature to work properly, but in my opinion it should be added to meta-tegra so anyone using 'bootargs' will be able to use them as expected.

Looks good.  Thanks!

Thanks @nielsavonds for sharing. I think I shoudl make mender-persist-systemd-machine-id setting the default on meta-mender-community zeus branch.  I've added it in a warrior branch for now.  I've also verified this patch on top of the warrior branch of meta-tegra.  Will verify with zeus on master as well later today.
@madisongh would you prefer separate PRs for warrior and master branches or are you already planning to cherry pick there as well?

@dwalkes I've cherry-picked this to master, warrior, and zeus.


Clear a target's content from the DOM

Introduce a little helper to clear the content of a target in the DOM. This is useful eg when you are closing a modal
Before:
<turbo-stream action="replace" target="message_1">
  <template>
    <div id="message_1">
    </div>
  </template>
</turbo-stream>

After:
<turbo-stream action="clear" target="message_1">
</turbo-stream>

--
Originally opened a PR in https://github.com/hotwired/turbo-rails/pull/131

You can already do this with the update stream action and an empty body:
<turbo-stream action="update" target="message_1">
  <template></template>
</turbo-stream>

The idea is that the following becomes a bit more succinct:
Before:
# create.turbo_stream.erb
<%= turbo_stream.update :modal, "" %>

Or a bit more natural to read:
# create.turbo_stream.erb
<%= turbo_stream.update :modal %>

After:
# create.turbo_stream.erb
<%= turbo_stream.clear :modal %>

But I understand it's a fine line between what to add as API and what not


Document serverside RUI

Got added with https://github.com/R2Northstar/NorthstarMods/pull/435
Assigning to @F1F7Y who wrote the feature

Among

Not gonna release v1.10 until we have RUI docs >:)

https://github.com/R2Northstar/ModdingDocs/pull/96
https://github.com/R2Northstar/ModdingDocs/pull/95
choose one

choose wisely


Storage returns un-exported error when a bucket already exists

Right now I have
bkt := client.Bucket(someBucket)
err := bkt.Create(ctx, projectID, nil)
if err != nil && !strings.Contains(err.Error(), "409") {
  // Handle real error
}

It would be much less brittle, and much nicer in general to be able to write something like
bkt := client.Bucket(someBucket)
err := bkt.Create(ctx, projectID, nil)
if err != nil && err != storage.ErrConflict {
  // Handle real error
}

Or bkt.Exists(someBucket)
Is there already a way to handle this?  Why are errors not exported?

Hi @jimmiebtlr, our errors are standardized using https://godoc.org/google.golang.org/api/googleapi and you can use http status codes to categorize error types. For your given code, you could do the following:
bkt := client.Bucket(someBucket)
err := bkt.Create(ctx, projectID, nil)
if err2, ok := err.(*googleapi.Error); ok {
	if err2.Code == http.StatusConflict {
		// Handle conflict
	}
} else {
	// Handle err
}

Thanks

Definitely better than what I had.  I'm still not a fan of this though.
Would something along the lines of this be better?
bkt := client.Bucket(someBucket)
err := bkt.Create(ctx, projectID, nil)
if err != nil && err != gcloud.ErrConflict {
  // handle it
}

The current way of handling it seems much more complex than it needs to be?

I agree that the errors are not ideal. Aside from breaking compatibility, the reason your idea won't work is that the errors have more than just the HTTP status code. For one thing, they have the body of the result, which often contains useful information.


add an extra 0 to accuracy display

This makes it so that on the accuracy display, It adds an extra 0 when the accuracy reaches numbers that reach a length of 4 (87.50%)
So, generally, by adding a 0, this fixes the accuracy display a bit, here's a few examples:
(87.6% > 87.60%)
(44.4% > 44.40%)
(99.9% > 99.90%)

Not happening when it comes to those like (85.51%)

idk not trying to be rude but this is kinda useless tho

idk not trying to be rude but this is kinda useless tho

I mean, is it weird to not have that one either though?
Games like osu! and Etterna have this sort of thing.

Nah

is that really necessary to close that?


Use propagator wrapper instead of new middleware

Hi @brancz :wave:
I stumbled on this repo, which is really cool, and saw the http/grpc middleware for setting the pprof labels.  I think it can be done in a simpler way using the propagator interface instead, which should work for all of the existing instrumentation libraries.
I didn't remove the existing otelgrpcprofiling or otelhttpprofiling modules (not sure if you want to deprecate those first), but I can add that if you like the changes.
I didn't test this, but can if you can give me a quick way to do it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Ah, makes sense.  Thanks for the explanation.


Cluster-level testing skipped

https://github.com/influxdb/influxdb/pull/5055
This will need to be fixed by 0.10.0.

@corylanou @dgnorton


why not support response headers has content-encoding: br??

if response headers   has content-encoding: br,
response body can't   JSON.parse

Don't think you provided enough information for anyone to help you. Are you having this problem in browser or node app? Browser-wise, you checked compatibility? If it's your client code making the call, perhaps use shrink-ray. See also Desaulniers "Better than Gzip Compression with Brotli" article.

Duplicate of https://github.com/request/request/issues/2866

Its a valid issue, why is it closed. The dup issue also has not provided a valid solution.

request is in maintenance mode and we’re not accepting any new features. for what it’s worth, I did implement this in bent.


Import package doesn't work: Cannot read properties of undefined

Describe the bug
Importing the library (with webpack) throw an error Uncaught TypeError: Cannot read properties of undefined (reading 'Chart')
versions:

dragdata => 2.2.5
chartjs => 3.9.1

To Reproduce
// application.js
import Chart from "chart.js/auto"
import "chartjs-plugin-dragdata"

Hi @skyporter, I finally found time to look at this recently but can't reproduce this with a clean Webpack setup, neither using 2.2.5 nor the current master. Could you provide a MRE repo?

Closing this as non-reproducible, but I'll reopen this provided an MRE is provided.


Update discord-rare-drop-notificater plugin for RL version 1.7.0

@MasterKenth are you still alive / do you care if someone else takes maintainership over this?

@MasterKenth are you still alive / do you care if someone else takes maintainership over this?

I do not mind at all! I'm not currently actively playing and sadly don't have time to work on this. If anyone would like to take over please feel free to do so, and if anything else is required from me to make that happen please inform me and I'll deal with it asap 🙂.

@MasterKenth
Thanks for responding :) Would you mind adding me as a collaborate in the main repo or transfer it if you don't expect to work on it anymore? I'll make sure to keep your name / credits in place.
Would make it easier for me to handle the current issues placed :)

@MasterKenth
Thanks for responding :) Would you mind adding me as a collaborate in the main repo or transfer it if you don't expect to work on it anymore? I'll make sure to keep your name / credits in place.
Would make it easier for me to handle the current issues placed :)

I don't expect to work on it any time soon, however I was unable to transfer the repo as you already have a fork of it with the same name. I've invited you as a collaborator in the meantime.

@MasterKenth
Thanks for responding :) Would you mind adding me as a collaborate in the main repo or transfer it if you don't expect to work on it anymore? I'll make sure to keep your name / credits in place.
Would make it easier for me to handle the current issues placed :)

I don't expect to work on it any time soon, however I was unable to transfer the repo as you already have a fork of it with the same name. I've invited you as a collaborator in the meantime.

Could you try it again now? Just deleted the fork after the PR :)

@MasterKenth
Thanks for responding :) Would you mind adding me as a collaborate in the main repo or transfer it if you don't expect to work on it anymore? I'll make sure to keep your name / credits in place.
Would make it easier for me to handle the current issues placed :)

I don't expect to work on it any time soon, however I was unable to transfer the repo as you already have a fork of it with the same name. I've invited you as a collaborator in the meantime.

Could you try it again now? Just deleted the fork after the PR :)

Seems to be working now! After you've accepted it should be yours 👍 .


CIM disables man on FreeBSD

MANPATH should not be set on FreeBSD.

It couldn't  represented on my environment.


Obtain tf-opt and flatbuffer_translate without compiling from source

Issue type
Feature Request
Have you reproduced the bug with TensorFlow Nightly?
Yes
Source
source
TensorFlow version
2.14
Custom code
No
OS platform and distribution
No response
Mobile device
No response
Python version
No response
Bazel version
No response
GCC/compiler version
No response
CUDA/cuDNN version
No response
GPU model and memory
No response
Current behavior?
tf-opt and flatbuffer_translate are not found in the standard pip package. Those need to be compiled from source.
Standalone code to reproduce the issue
$ pip install -U tensorflow
$ which tf-opt

Relevant log output
No response

@Kuree,
Could you please elaborate about your Feature. Also, please specify the Use Cases for this feature to understand in the effective way. Thank you!

We have a custom compiler that takes tflite models and convert them into some custom MLIR dialect. To do so, we use flatbuffer_translate and tf-opt to obtain MLIR in standard dialects (TODA + Linalg). So the compilation flow looks something like this:

Call flatbuffer_translate to get MLIR in TFL dialect
Call tf-opt to lower the dialect to TOSA and Linalg
Call the custom compiler to continue the compilation

Our compiler users have to compile tensorflow from source to obtain those two binaries. It would be great if those two can be shipped with standard tensorflow distribution. It doesn't have to be in the main python wheel, but can be included as extra dependency, e.g. pip install tensorflow[mlir].
Please let me know if you have additional questions.

Hi @Kuree,
These are C++ binaries which generally I don't think we want to install with TF, though as a custom option this might make sense. @terryheo Can you please take a look? Thanks.

We have a custom compiler that takes tflite models and convert them into some custom MLIR dialect. To do so, we use flatbuffer_translate and tf-opt to obtain MLIR in standard dialects (TODA + Linalg). So the compilation flow looks something like this:

Call flatbuffer_translate to get MLIR in TFL dialect
Call tf-opt to lower the dialect to TOSA and Linalg
Call the custom compiler to continue the compilation

Our compiler users have to compile tensorflow from source to obtain those two binaries. It would be great if those two can be shipped with standard tensorflow distribution. It doesn't have to be in the main python wheel, but can be included as extra dependency, e.g. pip install tensorflow[mlir].
Please let me know if you have additional questions.

It would be really great if all the tools from /tensorflow/compiler/mlir are shipped with tensorflow.

Hi, @Kuree
Thanks for raising this issue. Are you aware of the migration to LiteRT? This transition is aimed at enhancing our project's capabilities and providing improved support and focus for our users. As we believe this issue is still relevant to LiteRT we are moving your issue there. Please follow progress here: https://github.com/google-ai-edge/LiteRT/issues/119
Let us know if you have any questions. Thanks.


feat: Add tags to all resources

All resources should be tagged. This is one of the policies in my company and I guess in others too. And it is a AWS best practice.

Hey @kayman-mk good to see you here.
Can we also add tags to aws_sns_topic and aws_iam_policy ?
Unrelated: You might also find our ClickOps module useful.

I've fixed up and added these changes as part of #31


Convert Atmel SAM Watchdog driver to new API

We have a new driver API for watchdog, the old API has been deprecated for several releases now.  We need to convert the driver to use the API or remove it.

Hi Kumar,
I have done in it PR #10828. Can you please take a look at it.

@subbu147 thanks for the update.  I've made some cleanups and enhancements.  Take a look, and if you can test it out, that would be great.

addressed by PR #10828. This issue can be closed.

Resolved by merge of #10828


convertible_observable_vector::IndexOf slows debugging because it uses exceptions in a non-exceptional case

We have a scenario where some code in XAML repeatedly calls IObservableVector::IndexOf, where value is a different type than the container items. That causes hresult_no_interface to be thrown and caught internally within cppwinrt many times in this code.
All of these exceptions cause ~1s pauses in the debugger and make it difficult for the developer to be productive if they have first-chance exceptions turned on.
It appears that since #695 was merged, IInspectable.try_as is equivalent (?) to unbox_value and could be used in the implementation of IndexOf to avoid this. (Is that true, or did I miss some nuance there?)

@oldnewthing

Something like this should avoid the exception:
bool IndexOf(Windows::Foundation::IInspectable const& value, uint32_t& index) const
{
    auto unbox = value.try_as<T>();

    if (unbox)
    {
        return IndexOf(unbox.value(), index);
    }
    else
    {
        return false;
    }
}

I played around with this a bit more and ran into two nuances:

The auto-returning version of  try_as<T>  can return std::optional<T>  or a reference type for T. One has .value(), the other doesn't. The only uniform way to get a T out in both cases is to use the bool-returning version of try_as<T>.
value can be null, and that's a case where try_as returns false but we need to search the collection anyway.

So the result ends up a little uglier, maybe something like this...
if constexpr(std::is_convertible_v<std::nullptr_t, T>)
{
    if (!value)
    {
        return IndexOf(T{nullptr}, index);
    }
}

T unboxedValue;
if (value.try_as(unboxedValue))
{
    return IndexOf(unboxedValue, index);
}
else
{
    index = 0;
    return false;
}

Of course, the following should cover both cases:
bool IndexOf(Windows::Foundation::IInspectable const& value, uint32_t& index) const
{
    if constexpr (is_com_interface_v<T>)
    {
        return IndexOf(value.try_as<T>(), index);
    }
    else
    {
        if (auto box = value.try_as<T>())
        {
            return IndexOf(box.value(), index);
        }
        else
        {
            return false;
        }
    }
}

It's a little more complicated but here's a fix with some tests to cover the different scenarios: #1017

2.0.210913.7 has now been published with this fix.


Kubernetes plugin appends output if it is run twice

If you run the Kubernetes plugin twice, the output to Kubernetes resource files (deployment, service) is appended also twice.

Fixed bz a61a9906776271d118d49e334357b2ad66ce111e


Add reattempt on parse err flag to AtatCmd

This can be useful when modem does throw out some not need information at initialization. For example my after unlocking the SIM card PIN throws out after short delay +CPIN: READY\r\n\r\n+QUSIM: 1\r\n\r\n+QIND: SMS DONE\r\n.
That breaks the next command I run, if I just use the reattempt_on_parse_err flag that command is repeated and works fine.
I could add all the stuff it does output after +CPIN to Urc but I don't need that in this case, would only clatter my enum.
I think this can be also useful for any transmissions errors on the serial if someone has an unstable connection.

Is there any reason not to have this default enabled?

They only reason I made it disable by default is that it isn't present currently , so when an user updates the behavior doesn't change if the code stays the same. If you are fine with making that default I am all for it too, for most commands I would prefer to have it enabled in my case.

I think for all the cases I can think of, it would probably make sense to have it enabled.
What would the behavior be if it keeps failing parsing?

sounds reasonable :+1:


Update bedrock.py

Thank you for contributing to the Cohere Toolkit!

[ ] PR title: "area: description"

Where "area" is whichever of interface, frontend, model, tools, backend, etc. is being modified. Use "docs: ..."  for CI changes.
Example: "deployment: add Azure model option"

[ ] PR message: Delete this entire checklist and replace with

Description: a description of the change
Issue: the issue # it fixes, if applicable
Dependencies: any dependencies required for this change

[ ] Add tests and docs: Please include testing and documentation for your changes

[ ] Lint and test: Run make lint and make run-tests

AI Description

This pull request updates the BedrockDeployment class in bedrock.py by removing hardcoded models from the BedrockClient initialization.
File Changes

src/backend/model_deployments/bedrock.py

Code Changes

Removes the hardcoded values for chat_model, embed_model, and generate_model from the BedrockClient initialization in the __init__ method of the BedrockDeployment class.

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

Project coverage is 77.10%. Comparing base (f9ec818) to head (637a1f4).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #665   +/-   ##
=======================================
  Coverage   77.10%   77.10%
=======================================
  Files         238      238
  Lines       10455    10455
=======================================
  Hits         8061     8061
  Misses       2394     2394

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


warning when connection is lost

This was a problem for the 2016 tournament. Network connectivity at sports facilities is less-than-optimal. Several times the laptop being used for admin updates had lost connectivity and the only way we were able to figure that out is because the client side was not receiving the score updates.
Need a way to communicate to the admin when they have lost their network connection. I think re-vamping the admin side using sockets would help here.

This is fixed for 2017.


Is vcpkg resetting the CRT option?

LNK2038	mismatch detected for 'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value 'MTd_StaticDebug' in StripeMeshDecomposition.obj	xxxProject C:\xxx\libspqrd.lib(SuiteSparseQR.cpp.obj

I encounter this issue when trying to use suitesparse installed from vcpkg.
my triplet is: x64-windows.
Clearly, in my VS project settings, the Code Generation is set to "MT/MTd" by default, and if I changed it to "MD/MDd", things will work fine.
However, when I tried to set the cmake generation to MD/MDd with information from here:
https://cmake.org/cmake/help/latest/variable/CMAKE_MSVC_RUNTIME_LIBRARY.html#variable:CMAKE_MSVC_RUNTIME_LIBRARY
It doens't work. The settings in VS is always "MT/MTd" though cmake-gui shows the cxx_flag is MD/MDd.
Then I'm confused that it seems the only possibility is vcpkg is setting these commands internally, and don't allow users to change it.
But the default x64-windows triplet file shows:
set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE dynamic)

So why VS is always showing MT/MTd by default? Everytime I re-run cmake, I need to reset those parts from inside VS and this became very annoying....
Would someone give some hint please?

set(VCPKG_CRT_LINKAGE dynamic) -> means dynamic runtime which is always MD
use
set(VCPKG_CRT_LINKAGE static) -> to change it to MT
see also scripts/toolchains/windows.cmake
CMAKE_MSVC_RUNTIME_LIBRARY only matters for your personal projects.

Yes, I understand this part.
The problem is even when I use x64-windows and setting CMAKE_MSVC_RUNTIME_LIBRARY to dynamic or not set at all, all my own projects will still be set to MT(d) by default and conflicts with some lib compiled with vcpkg (suitesparse in my case).

@xarthurx Please create a new triple file (eg x64-windows-md.cmake) in VCPKG_PATH / triplets and write the following code:
set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE static)
set(VCPKG_LIBRARY_LINKAGE dynamic)

Then build port using command ./vcpkg install suitesparse:x64-windows-md.
Thanks.

@JackBoosY Thanks for the commends.
Will vcpkg search automatically for the newly added triplet file? Or I need to modify some port files for the support? Cos I remember last time I tried to do sth like this and need to manually change one by one in the cmake-gui for the correct folder.

And one more question, is vcpkg related to the problem that all my projects created with vcpkg will have a MT(d) by default no matter how I modify the cmakelist file?

And one more question, is vcpkg related to the problem that all my projects created with vcpkg will have a MT(d) by default no matter how I modify the cmakelist file?

as far as I know the toolchain file vcpkg.cmake is not doin anything to compiler flags. But you might want to take a look yourself.
Did you set CMAKE_MSVC_RUNTIME_LIBRARY before any project() call in your CMakeLists.txt?

@Neumann-A Thanks for the reply.

Yes, I tried various positions to place that command, but none of them works as expected, so I guess there must be sth that I miss.

I'm using newest cmake (3.15.5).

Note Call the cmake_minimum_required() command at the beginning of the top-level CMakeLists.txt file even before calling the project() command. It is important to establish version and policy settings before invoking other commands whose behavior they may affect. See also policy CMP0000.

If you do net use cmake_minimum_required as a first line in your main cmakelists.txt it will not behave like 3.15.5

@xarthurx You need to create a new triplet file. We must declare the CRT linkage type(VCPKG_CRT_LINKAGE[1]) in triplet file.
[1]. VCPKG_CRT_LINKAGE STREQUAL dynamic -> MD/MDd, static -> MT/MTd.

@xarthurx You need to create a new triplet file. We must declare the CRT linkage type(VCPKG_CRT_LINKAGE[1]) in triplet file.
[1]. VCPKG_CRT_LINKAGE STREQUAL dynamic -> MD/MDd, static -> MT/MTd.

Thank you everyone, problem solved by increasing the cmake_mininum_required version...
Closing this issue.


Drop OpenStack failure domain configuration from ControlPlaneMachineSet

Having had a discussion with the OpenStack team, we aren't going to support OpenStack in 4.12 as they are currently redesigning how Machines are spread across failure domains.
This API was introduced in 4.12 and therefore has not shipped yet. We will add a new version of this part of the API once the OpenStack team have stabilised their failure domain design/feature for 4.13.

This project is not a part of the no-FF process
/label px-approved
/label docs-approved
/label qe-approved

/approve


add responsive design 'Footer' and "About adoption"

"Footer" and "About adoption" parameters for max-width 990px were added. Please merge.

1 . I've changed branch to development(was - master)
2. what happened to pages menu in footer?
3. footer looks very strange - it gets empty space down


Add more features

Would be great to have a demo wirh all features that API allows, like payments, transfers and others

Hey!
Thanks for the suggestion, this is something we would definitely like to add in the future. I'll forward this request to our product team.


[cephfs] admin and user capabilities issue in shared cephfs

Hi,
I'm wondering why is the mds 'allw r path=/' required for the admin client and for the pv client.
Using capabilities [caps1] the following way:
client.adminK8s
    key : [...]==
    caps: [mon] allow rwx
    caps: [osd] allow rw tag cephfs data=cephfs
    caps: [mds] allow r path=/, allow rwp path=kubernetes/myFolder

Everything works fine.
But using the following capabilities [caps2] fails:
client.adminK8s
    key : [...]
    caps: [mon] allow rwx
    caps: [osd] allow rw tag cephfs data=cephfs
    caps: [mds] allow rwp path=kubernetes/myFolder

with error:
E1113 10:22:04.202580       1 cephfs-provisioner.go:158] failed to provision share "kubernetes-dynamic-pvc-[...]" for "kubernetes-dynamic-user-[...]", err: exit status 1, output: Traceback (most recent call last):
  File "/usr/local/bin/cephfs_provisioner", line 364, in <module>
    main()
  File "/usr/local/bin/cephfs_provisioner", line 358, in main
    print cephfs.create_share(share, user, size=size)
  File "/usr/local/bin/cephfs_provisioner", line 228, in create_share
    volume = self.volume_client.create_volume(volume_path, size=size, namespace_isolated=not self.ceph_namespace_isolation_disabled)
  File "/usr/local/bin/cephfs_provisioner", line 112, in volume_client
    self._volume_client.connect(None)
  File "/lib/python2.7/site-packages/ceph_volume_client.py", line 471, in connect
    self.fs.mount()

By the way, using [caps2] still allows the user to mount the folder correctly
$ sudo mount -t ceph -oname=kubernetes-dynamic-user-[...],secret=[...] monitor1:/kubernetes/myFolder /mnt/test1
$ ls test1
test.txt
$ sudo mount -t ceph -oname=kubernetes-dynamic-user-[...],secret=[...] monitor1:/ /mnt/test2
mount error 13 = Permission denied

In a shared cephfs cluster, such capabilities [cap1] might lead to data leakage since any client can mount the whole cephfs volume and then at least access to other's data. Furthermore, this capability doesn't seam required since the folder creation can be within a dedicated mount in the declared volume_group
file:ceph_provisioner.py@create_share
        volume_path = ceph_volume_client.VolumePath(self.volume_group, path)

        # Create the CephFS volume
        volume = self.volume_client.create_volume(volume_path, size=size, namespace_isolated=not self.ceph_namespace_isolation_disabled)

Am I missing something? Is there an alternative to ensure multi-tenancy in a shared cephfs?

I think this is a consequence of how the python client works, it has to mount the whole fs here https://github.com/ceph/ceph/blob/master/src/pybind/ceph_volume_client.py#L479 and  http://docs.ceph.com/docs/mimic/cephfs/client-auth/ says "Note that if a client’s read access is restricted to a path, they will only be able to mount the filesystem when specifying a readable path in the mount command (see below)." The allow r path=/  cap is only for the admin secret for the provisioner I don't think any non-provisioner client cant use it. Also, individual volumes should be restricted by some UUID by this code here https://github.com/kubernetes-incubator/external-storage/blob/master/ceph/cephfs/cephfs_provisioner/cephfs_provisioner.py#L240

I missed about the pv client, I only talked about admin client in the above comment. I am not sure if PV client needs allow r path=/ as well, will need to investigate some more


Sdk 0.4.01 - update documents and versioning

update the installing source branch to master, and update versioning to v0.4.00

Coverage remained the same at 53.843% when pulling 22560ef73fc49f202c5066123409cc7efb4471dd on sdk-0.4.01 into e73e78046ba1cac545324c1253aab0c60d372fd0 on master.

Coverage remained the same at 53.843% when pulling 22560ef73fc49f202c5066123409cc7efb4471dd on sdk-0.4.01 into e73e78046ba1cac545324c1253aab0c60d372fd0 on master.

Coverage remained the same at 53.843% when pulling 22560ef73fc49f202c5066123409cc7efb4471dd on sdk-0.4.01 into e73e78046ba1cac545324c1253aab0c60d372fd0 on master.

All changes will be rebased/cherry picked to master later. So we don't need to merge the branch into master now.


[Snyk] Fix for 17 vulnerabilities

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to fix one or more vulnerable packages in the `pip` dependencies of this project.
Changes included in this PR

Changes to the following files to upgrade the vulnerable dependencies to a fixed version:

requirements.txt

⚠ Warning
jinja2 3.1.4 has requirement MarkupSafe>=2.0, but you have MarkupSafe 1.1.0.
aiohttp-session 2.7.0 requires aiohttp, which is not installed.
aiohttp-jinja2 1.1.0 requires aiohttp, which is not installed.

Vulnerabilities that will be fixed
By pinning:

Severity
Priority Score (*)
Issue
Breaking Change
Exploit Maturity

435/1000  Why? Has a fix available, CVSS 4.2
Open Redirect SNYK-PYTHON-AIOHTTP-1079232
No
No Known Exploit

686/1000  Why? Proof of Concept exploit, Has a fix available, CVSS 7.3
HTTP Header Injection SNYK-PYTHON-AIOHTTP-1584144
No
Proof of Concept

586/1000  Why? Proof of Concept exploit, Has a fix available, CVSS 5.3
HTTP Request Smuggling SNYK-PYTHON-AIOHTTP-5798483
No
Proof of Concept

414/1000  Why? Has a fix available, CVSS 4
Inconsistent Interpretation of HTTP Messages SNYK-PYTHON-AIOHTTP-6057352
No
No Known Exploit

586/1000  Why? Proof of Concept exploit, Has a fix available, CVSS 5.3
HTTP Request Smuggling SNYK-PYTHON-AIOHTTP-6057353
No
Proof of Concept

591/1000  Why? Proof of Concept exploit, Has a fix available, CVSS 5.4
Improper Input Validation SNYK-PYTHON-AIOHTTP-6091621
No
Proof of Concept

591/1000  Why? Proof of Concept exploit, Has a fix available, CVSS 5.4
Improper Input Validation SNYK-PYTHON-AIOHTTP-6091622
No
Proof of Concept

539/1000  Why? Has a fix available, CVSS 6.5
HTTP Request Smuggling SNYK-PYTHON-AIOHTTP-6091623
No
No Known Exploit

616/1000  Why? Proof of Concept exploit, Has a fix available, CVSS 5.9
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') SNYK-PYTHON-AIOHTTP-6209406
No
Proof of Concept

646/1000  Why? Proof of Concept exploit, Has a fix available, CVSS 6.5
HTTP Request Smuggling SNYK-PYTHON-AIOHTTP-6209407
No
Proof of Concept

449/1000  Why? Has a fix available, CVSS 4.7
Cross-site Scripting (XSS) SNYK-PYTHON-AIOHTTP-6645291
No
No Known Exploit

661/1000  Why? Recently disclosed, Has a fix available, CVSS 7.5
Infinite loop SNYK-PYTHON-AIOHTTP-6808823
No
No Known Exploit

524/1000  Why? Has a fix available, CVSS 6.2
Resource Exhaustion SNYK-PYTHON-IDNA-6597975
No
No Known Exploit

586/1000  Why? Proof of Concept exploit, Has a fix available, CVSS 5.3
Regular Expression Denial of Service (ReDoS) SNYK-PYTHON-JINJA2-1012994
No
Proof of Concept

554/1000  Why? Has a fix available, CVSS 6.8
Sandbox Escape SNYK-PYTHON-JINJA2-174126
No
No Known Exploit

484/1000  Why? Has a fix available, CVSS 5.4
Cross-site Scripting (XSS) SNYK-PYTHON-JINJA2-6150717
No
No Known Exploit

556/1000  Why? Recently disclosed, Has a fix available, CVSS 5.4
Cross-site Scripting (XSS) SNYK-PYTHON-JINJA2-6809379
No
No Known Exploit

(*) Note that the real score may have changed since the PR was raised.
Some vulnerabilities couldn't be fully fixed and so Snyk will still find them when the project is tested again. This may be because the vulnerability existed within more than one direct dependency, but not all of the affected dependencies could be upgraded.
Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
🛠 Adjust project settings
📚 Read more about Snyk's upgrade and patch logic
[//]: # 'snyk:metadata:{"customTemplate":{"variablesUsed":[],"fieldsUsed":[]},"dependencies":[{"name":"aiohttp","from":"3.5.3","to":"3.9.4"},{"name":"idna","from":"2.8","to":"3.7"},{"name":"jinja2","from":"2.10","to":"3.1.4"}],"env":"prod","issuesToFix":[{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-AIOHTTP-1079232","priority_score":435,"priority_score_factors":[{"type":"exploit","label":"Unproven","score":11},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"4.2","score":210},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Open Redirect"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-AIOHTTP-1584144","priority_score":686,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"7.3","score":365},{"type":"scoreVersion","label":"v1","score":1}],"severity":"high","title":"HTTP Header Injection"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-AIOHTTP-5798483","priority_score":586,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"5.3","score":265},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"HTTP Request Smuggling"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-AIOHTTP-6057352","priority_score":414,"priority_score_factors":[{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"4","score":200},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Inconsistent Interpretation of HTTP Messages"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-AIOHTTP-6057353","priority_score":586,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"5.3","score":265},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"HTTP Request Smuggling"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-AIOHTTP-6091621","priority_score":591,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"5.4","score":270},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Improper Input Validation"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-AIOHTTP-6091622","priority_score":591,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"5.4","score":270},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Improper Input Validation"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-AIOHTTP-6091623","priority_score":539,"priority_score_factors":[{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"6.5","score":325},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"HTTP Request Smuggling"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-AIOHTTP-6209406","priority_score":616,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"5.9","score":295},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-AIOHTTP-6209407","priority_score":646,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"6.5","score":325},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"HTTP Request Smuggling"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-AIOHTTP-6645291","priority_score":449,"priority_score_factors":[{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"4.7","score":235},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Cross-site Scripting (XSS)"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-AIOHTTP-6808823","priority_score":661,"priority_score_factors":[{"type":"freshness","label":true,"score":71},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"7.5","score":375},{"type":"scoreVersion","label":"v1","score":1}],"severity":"high","title":"Infinite loop"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-AIOHTTP-1079232","priority_score":435,"priority_score_factors":[{"type":"exploit","label":"Unproven","score":11},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"4.2","score":210},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Open Redirect"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-AIOHTTP-1584144","priority_score":686,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"7.3","score":365},{"type":"scoreVersion","label":"v1","score":1}],"severity":"high","title":"HTTP Header Injection"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-AIOHTTP-5798483","priority_score":586,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"5.3","score":265},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"HTTP Request Smuggling"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-AIOHTTP-6057352","priority_score":414,"priority_score_factors":[{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"4","score":200},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Inconsistent Interpretation of HTTP Messages"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-AIOHTTP-6057353","priority_score":586,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"5.3","score":265},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"HTTP Request Smuggling"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-AIOHTTP-6091621","priority_score":591,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"5.4","score":270},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Improper Input Validation"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-AIOHTTP-6091622","priority_score":591,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"5.4","score":270},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Improper Input Validation"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-AIOHTTP-6091623","priority_score":539,"priority_score_factors":[{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"6.5","score":325},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"HTTP Request Smuggling"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-AIOHTTP-6209406","priority_score":616,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"5.9","score":295},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-AIOHTTP-6209407","priority_score":646,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"6.5","score":325},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"HTTP Request Smuggling"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-AIOHTTP-6645291","priority_score":449,"priority_score_factors":[{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"4.7","score":235},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Cross-site Scripting (XSS)"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-AIOHTTP-6808823","priority_score":661,"priority_score_factors":[{"type":"freshness","label":true,"score":71},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"7.5","score":375},{"type":"scoreVersion","label":"v1","score":1}],"severity":"high","title":"Infinite loop"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-AIOHTTP-1079232","priority_score":435,"priority_score_factors":[{"type":"exploit","label":"Unproven","score":11},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"4.2","score":210},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Open Redirect"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-AIOHTTP-1584144","priority_score":686,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"7.3","score":365},{"type":"scoreVersion","label":"v1","score":1}],"severity":"high","title":"HTTP Header Injection"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-AIOHTTP-5798483","priority_score":586,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"5.3","score":265},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"HTTP Request Smuggling"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-AIOHTTP-6057352","priority_score":414,"priority_score_factors":[{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"4","score":200},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Inconsistent Interpretation of HTTP Messages"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-AIOHTTP-6057353","priority_score":586,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"5.3","score":265},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"HTTP Request Smuggling"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-AIOHTTP-6091621","priority_score":591,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"5.4","score":270},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Improper Input Validation"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-AIOHTTP-6091622","priority_score":591,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"5.4","score":270},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Improper Input Validation"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-AIOHTTP-6091623","priority_score":539,"priority_score_factors":[{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"6.5","score":325},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"HTTP Request Smuggling"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-AIOHTTP-6209406","priority_score":616,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"5.9","score":295},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-AIOHTTP-6209407","priority_score":646,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"6.5","score":325},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"HTTP Request Smuggling"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-AIOHTTP-6645291","priority_score":449,"priority_score_factors":[{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"4.7","score":235},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Cross-site Scripting (XSS)"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-AIOHTTP-6808823","priority_score":661,"priority_score_factors":[{"type":"freshness","label":true,"score":71},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"7.5","score":375},{"type":"scoreVersion","label":"v1","score":1}],"severity":"high","title":"Infinite loop"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-IDNA-6597975","priority_score":524,"priority_score_factors":[{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"6.2","score":310},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Resource Exhaustion"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-IDNA-6597975","priority_score":524,"priority_score_factors":[{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"6.2","score":310},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Resource Exhaustion"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-IDNA-6597975","priority_score":524,"priority_score_factors":[{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"6.2","score":310},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Resource Exhaustion"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-IDNA-6597975","priority_score":524,"priority_score_factors":[{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"6.2","score":310},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Resource Exhaustion"},{"exploit_maturity":"Proof of Concept","id":"SNYK-PYTHON-JINJA2-1012994","priority_score":586,"priority_score_factors":[{"type":"exploit","label":"Proof of Concept","score":107},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"5.3","score":265},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Regular Expression Denial of Service (ReDoS)"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-JINJA2-174126","priority_score":554,"priority_score_factors":[{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"6.8","score":340},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Sandbox Escape"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-JINJA2-6150717","priority_score":484,"priority_score_factors":[{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"5.4","score":270},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Cross-site Scripting (XSS)"},{"exploit_maturity":"No Known Exploit","id":"SNYK-PYTHON-JINJA2-6809379","priority_score":556,"priority_score_factors":[{"type":"freshness","label":true,"score":71},{"type":"fixability","label":true,"score":214},{"type":"cvssScore","label":"5.4","score":270},{"type":"scoreVersion","label":"v1","score":1}],"severity":"medium","title":"Cross-site Scripting (XSS)"}],"prId":"320b9436-d6d8-4a0c-aa0a-f34b87898edc","prPublicId":"320b9436-d6d8-4a0c-aa0a-f34b87898edc","packageManager":"pip","priorityScoreList":[435,686,586,414,586,591,591,539,616,646,449,661,524,586,554,484,556],"projectPublicId":"9969afed-fa03-4929-909a-c59114884541","projectUrl":"https://app.snyk.io/org/armorcode-partner/project/9969afed-fa03-4929-909a-c59114884541?utm_source=github&utm_medium=referral&page=fix-pr","prType":"fix","templateFieldSources":{"branchName":"default","commitMessage":"default","description":"default","title":"default"},"templateVariants":["pr-warning-shown","priorityScore"],"type":"auto","upgrade":[],"vulns":["SNYK-PYTHON-AIOHTTP-1079232","SNYK-PYTHON-AIOHTTP-1584144","SNYK-PYTHON-AIOHTTP-5798483","SNYK-PYTHON-AIOHTTP-6057352","SNYK-PYTHON-AIOHTTP-6057353","SNYK-PYTHON-AIOHTTP-6091621","SNYK-PYTHON-AIOHTTP-6091622","SNYK-PYTHON-AIOHTTP-6091623","SNYK-PYTHON-AIOHTTP-6209406","SNYK-PYTHON-AIOHTTP-6209407","SNYK-PYTHON-AIOHTTP-6645291","SNYK-PYTHON-AIOHTTP-6808823","SNYK-PYTHON-IDNA-6597975","SNYK-PYTHON-JINJA2-1012994","SNYK-PYTHON-JINJA2-174126","SNYK-PYTHON-JINJA2-6150717","SNYK-PYTHON-JINJA2-6809379"],"patch":[],"isBreakingChange":false,"remediationStrategy":"vuln"}'

Note: This is a default PR template raised by Snyk. Find out more about how you can customise Snyk PRs in our documentation.
Learn how to fix vulnerabilities with free interactive lessons:
🦉 Open Redirect
🦉 Improper Input Validation
🦉 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
🦉 More lessons are available in Snyk Learn

Checkmarx One – Scan Summary & Details – 42b58b62-37a3-42f9-a902-5225f0794f2c
Fixed Issues

Severity
Issue
Source File / Package

CVE-2019-10906
Python-Jinja2-2.10

CVE-2019-8341
Python-Jinja2-2.10

CVE-2023-47627
Python-aiohttp-3.5.3

CVE-2024-23334
Python-aiohttp-3.5.3

Passwords And Secrets - Generic Password
/dev.yaml: [3](https://github.com/TheRedHatter/dvpwa/blob/snyk-fix-0322c78a97680bd50ab278549c572e31//config/dev.yaml# L3)

CVE-2020-28493
Python-Jinja2-2.10

CVE-2021-21330
Python-aiohttp-3.5.3

CVE-2023-47641
Python-aiohttp-3.5.3

CVE-2023-49081
Python-aiohttp-3.5.3

CVE-2023-49082
Python-aiohttp-3.5.3

CVE-2024-22195
Python-Jinja2-2.10

CVE-2024-23829
Python-aiohttp-3.5.3

Host Namespace is Shared
/docker-compose.yml: [4](https://github.com/TheRedHatter/dvpwa/blob/snyk-fix-0322c78a97680bd50ab278549c572e31//docker-compose.yml# L4)

Host Namespace is Shared
/docker-compose.yml: [14](https://github.com/TheRedHatter/dvpwa/blob/snyk-fix-0322c78a97680bd50ab278549c572e31//docker-compose.yml# L14)

Host Namespace is Shared
/docker-compose.yml: [11](https://github.com/TheRedHatter/dvpwa/blob/snyk-fix-0322c78a97680bd50ab278549c572e31//docker-compose.yml# L11)

Networks Not Set
/docker-compose.yml: [14](https://github.com/TheRedHatter/dvpwa/blob/snyk-fix-0322c78a97680bd50ab278549c572e31//docker-compose.yml# L14)

Networks Not Set
/docker-compose.yml: [4](https://github.com/TheRedHatter/dvpwa/blob/snyk-fix-0322c78a97680bd50ab278549c572e31//docker-compose.yml# L4)

Networks Not Set
/docker-compose.yml: [11](https://github.com/TheRedHatter/dvpwa/blob/snyk-fix-0322c78a97680bd50ab278549c572e31//docker-compose.yml# L11)