Installation Testing

Thanks a lot for the tool.
I installed singualrity and polysolver on windows machine using vagrant, virtualbox and git.
The installation went smooth, with no errors.
For the first run, some dependencies appear missing by pointing to files not available at "/home/polysolver" as the folder itself wasn't present, so I created a link to the /usr/local/libexic/polysolver" and it ran well with some warninging like the following:
perl: warning: Setting locale failed. perl: warning: Please check that your locale settings:         LANGUAGE = (unset),         LC_ALL = (unset),         LANG = "en_US.UTF-8"     are supported and installed on your system. perl: warning: Falling back to the standard locale ("C").
Currently, I trying to test that it works as expected, so I followed the instructions within the "Testing" section "3.1 Polysolver".
After running the "shell_call_hla_type" script againt "/home/polysolver/test/test.bam" and by comparing the resultant file "winners.hla.nofreq.txt" to "/home/polysolver/test/orig.winners.hla.txt", some differences appears as follow:
`diff test/winners.hla.nofreq.txt /home/polysolver/test/orig.winners.hla.txt
1,3c1,3
< -e HLA-A      -e hla_a_01_01_01_01    -e hla_a_01_01_01_01
< HLA-B -e hla_b_07_02_01       -e hla_b_07_02_01
< HLA-C -e hla_c_01_02_01       -e hla_c_01_02_01

HLA-A hla_a_24_02_01_01       hla_a_24_02_01_01
HLA-B hla_b_39_01_01_02l      hla_b_39_01_01_02l
HLA-C hla_c_07_01_05  hla_c_06_02_01_01
`

What I may do to confirm that this was a correct installation?
Thanks,

hey @alykhalifa ! I'm not familiar with this domain so I'm not sure, but a first test would be to run and compare against the original docker image:

https://hub.docker.com/r/sachet/polysolver/

and then to contact the creator of the software (sachet on Docker Hub) and find the original repo.

Thanks a lot @vsoch ,
I'll try to contact sachet.

If this is the same thing, this might be a good place to start, or at least find contacts:
http://archive.broadinstitute.org/cancer/cga/polysolver_run

Thanks Vanessa.
I've just posted the same issue as a comment on https://hub.docker.com/r/sachet/polysolver/.
Unfortunately, I couldn't find contacts wihtin the CGA webpage, so I'll wait for a while and then I may contact some one from the CGA.

Hi Vanessa,
I tried the docker image and it was needing at least 4g as RAM in order to work. Thanks for Sachet.
However, when I tried singularity of the same docker image version, it still gives unaligned test results, even on +4g RAM machines.
Did you try running testing on the singularity image? did you get the aligned test results (i.e. result file is the same as the orig.winners.hla.txt)?
I check Gregory's comment on "Limit cpus and memory in Singularity", so may be nothing can be done for limiting or specifying RAM allocation for singularity except running over a +4g RAM machine?
Thanks again Vanessa for offering it as a singularity container.
Aly

hey @alykhalifa - I'm not a trained biologist, so I don't typically do these kinds of analyses, I didn't do tests to confirm they are equivalent. I would guess that the difference has to do with differences with regard to use of memory (as you highlighted) but I don't have knowledge/advice beyond that.

Thanks @vsoch .


Crashing

Troii is crashing after 6 to 7 sec of opening. I have used "https://toriii.vercel.app/" in search bar and webapp opened
successfully. But later on scrolling down within 6 to 7 seconds it is showing something went wrong message. Check the attachment below.

well, you are trying to open torii in brave. brave does not allows 3-rd party scripts to run that's why this is happening .. try to open it in chrome.
this website would not work on private window or brave : )


Address various issues found in Code Review

Enable compiler warnings for C source files
Fix various compiler warnings (unsigned/signed comparison, unused
variables, etc.)
Remove redundant information from SCOSSL data structures
Remove redundant includes
Initialize long-lived static variables once at Engine load time,
rather than on demand to avoid race conditions when algorithms are
called concurrently without needing to introduce locking.
Check various returns for OpenSSL functions (e.g. BN_bin2bn et. al)
and gracefully error rather than potentially failing in unexpected
ways in low memory conditions
Fix memory leaks in new FFC DH implementation
Ensure all externally visible symbols have a scossl or sc_ossl prefix
(should settle on a single prefix in a followup PR)
Fallback to OpenSSL for ECDSA signatures with a specific kinv or r
Use stderr rather than stdout for error messages in debug build
Correctly set verify_init function in PKEY rsa method!
Only log error messages on signature verification error, rather than
expected signature verification failure
Remove a lot of useless work in RSA key setup
Error in RSA key import/generation if the requested public exponent is
larger than 2^64-1

// creates that structure if it doesn't already exist.

Nit: these comments are now slightly inaccurate

Refers to: SymCryptEngine/src/sc_ossl_pkey_meths.c:87 in 8f260e8. [](commit_id = 8f260e87c183bdf7365a7a750084c25af0f61cf3, deletion_comment = False)

    // return 1;

Does this code currently work without this functionality? Seems like we should either be returning an error if this path doesn't work, or if it does and the above isn't actually necessary, just remove it.

Refers to: SymCryptEngine/src/sc_ossl_hkdf.c:300 in 8f260e8. [](commit_id = 8f260e87c183bdf7365a7a750084c25af0f61cf3, deletion_comment = False)

    // return 1;

I'm completing HKDF in a follow up PR - it's currently a draft as it relies on SymCrypt API changes. We will move to something not too distant from the commented out code.

In reply to: 989306961

Refers to: SymCryptEngine/src/sc_ossl_hkdf.c:300 in 968ea7e. [](commit_id = 968ea7e1df95ac75ea8c7e986ffe860bb78a8b19, deletion_comment = False)


⚠ Jenkins Plugins Artifactory has degraded performance

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

HTTP code: 200
Response time: 1148 ms

Resolved: Jenkins Plugins Artifactory performance has improved in e2efabb after 46 minutes.


Add options to customize marker thickness and colors.

Why

The color and thickness of indentation markers are currently hard-coded based on the Replit User Interface. Although they are good default values, we should have the flexibility to configure them.
What changed

Added a new option in IndentationMarkerConfiguration called thickness that lets the user specify the thickness of the indentation marker (in pixels).
Added new options in IndentationMarkerConfiguration under the colors option that allows the user to specify the color of active and normal lines under light and dark themes.
Here's an example of the beautiful new styles you can create:

(FYI, I'm new to CodeMirror 6 and Typescript, so let me know if I'm doing something wrong)
Test plan

The new options can be applied like this:
indentationMarkers({
  thickness: 10,
  colors: {
    activeLight: 'blue',
    normalLight: 'red',
  },
})

updated the README!
Side question: should I annotate the parameter type for indentTheme()? I think I'd have to export a new interface from config.ts.

published in 6.5.0


nlohmann library

Hi,
should I install json libray first before compiling this project??
if Yes so I'll appreciate  a brief steps you used to compile it using Visual Studio.

Hi, sorry for the later answer, github didn't pop any notifications for me.
It's pretty much compile ready as I have even mistakenly missed the nlohmann folder in the .gitignore.
What you have to do is to make the library "known" to the linker.

Right click the project and click on Properties
On the left menu find the VC++ Directories option
Add the nlohmann folder to the Include Directories option

Closing this, as it has been patched.


Add voice chat for host

Add the ability to have the room host include their microphone audio in the mediastream being sent to the room.

I would like to try this.

Done in c0070a6e6f087e8827e7dbbef937fdc33dfe885c


Add some informations reguarding the files types used by Vib Ribbon

You could complete thoses using the informaitons I provided on Discord ;D
https://open-ribbon.github.io/documentation/#file-types/intro/
https://open-ribbon.github.io/documentation/#file-types/anc/
https://open-ribbon.github.io/documentation/#file-types/fsl/
https://open-ribbon.github.io/documentation/#file-types/pak/
https://open-ribbon.github.io/documentation/#file-types/tim/
https://open-ribbon.github.io/documentation/#file-types/tmd/
https://open-ribbon.github.io/documentation/#file-types/vb-vh/
OFC Somes are not identified yet, but hey, you can prolly do PAK and VB-VH for sure

Currently got TMD and PAK figured out
These remain:

Intro
ANC
ANM
FSL
TIM
VB/VH

Remaining now, as Murugo got a few more out of the way.

Intro
FSL
TIM
VB/VH

Intro
VB/VH
These are what remain I think


Launch tests on ODM on Travis CI

See:
https://github.com/liip/LiipFunctionalTestBundle/issues/169

That's too complicated: https://github.com/liip/LiipFunctionalTestBundle#non-sqlite


docs: translate Thinking in React

Translated the "Thinking in React" page to Indonesian.
Closes #374.

@mhaidarhanif @r17x @zainfathoni Ready to review.


Drag selection

Fix drag selection in GrabFrame (similar to PR 89 for full-screen).
Constrain mouse cursor during drag selection (both full-screen and grab frame).
Refactored to remove duplicate drawing of selection rectangle.

When testing this PR my mouse got stuck in a smaller area than the Fullscreen Grab or the Grab Frame. I suspect it has to do with my display scaling set to 150% on a 4k screen.

When testing this PR my mouse got stuck in a smaller area than the Fullscreen Grab or the Grab Frame. I suspect it has to do with my display scaling set to 150% on a 4k screen.

Fixed now

Because of the changes in #91 this PR now has some conflicts.

Replaced with PR #92


154 document token transfer

Description:
Create guide for transferring tokens between two accounts using metamask and associated setup script.
Related issue(s):
Closes #154

Codecov Report

Merging #173 (bafa206) into main (8b9b3f0) will not change coverage.
The diff coverage is n/a.

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

@@           Coverage Diff           @@
##             main     #173   +/-   ##
=======================================
  Coverage   67.41%   67.41%
=======================================
  Files           6        6
  Lines         534      534
  Branches       71       71
=======================================
  Hits          360      360
  Misses        154      154
  Partials       20       20

Continue to review full report at Codecov.

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


[quick accent] Rearrange symbols from key "," to more intuitive places

Description of the new feature / enhancement
In quick accent: make the keys correspond to the symbols as below:

key ", <"  | maps to: "¡", "₋", "⁻", "–", "≤"
key ". >"   | maps to: "∙", "≥"
key "/ ?"   | maps to: "¿"
key "= +" | maps to: "≠", "≈", "≙", "±", "₊", "⁺"

Scenario when this would be used?
Currently "," corresponds to a lot of characters: "¿", "¡", "∙", "₋", "⁻", "–", "≤", "≥", "≠", "≈", "≙", "±", "₊", "⁺"

This is not only unintuitive, but also causes cluttering of UI and wastes more time selecting the correct symbol.
Moreover, the rearrangement can free up more space for future appending of more symbols. (Like #26687 )
Supporting information
Should I just make a PR? (I know very little about coding though.)

duplication of #26270


MB_String appendNum not functioning correctly on Arduino UNO R4 WiFi

Describe the bug
When appendNum is called on an MB_String, the string "ld" or "lu" is appended instead of the actual number
To Reproduce
Make an MB_String and try to append a number to it on the UNO R4 WiFi
Expected behavior
The number (base 10 ascii) should be appended
Screenshots

I think there should be an extra "|| defined(ARDUINO_UNO_R4)" (not the real macro, i dont know what it is) here to check for the UNO, because I think it is assuming it's a 64-bit processor which it isn't and thus does not understand "%lld" and "%llu" in the 64 bit toStr functions.
Additional context
I fixed it by modifying the int64Str and uint64Str to "%ld" and "%lu" instead of "%lld" and "%llu". But I don't think it should be calling those functions anyway. I can't find the macro used to determine if the board is the UNO R4. It's also possible that there are other spots in the code where the UNO is assumed to have 64 bit architecture. This is the only problem I've run into that causes the library to fail for my purposes though.

I'm sorry to tell you that this library does not support Arduino UNO R4 WiFi because of stack memory provided by its core is too low and not enough for BearSSL engine to work.
I will remove it from support devices in Readme.


Implement WFP instrumentation

Hi :wave:,
In theory, this PR implements auto-instrumentation for WfP. The only part I'm unhappy about is the attribute parser, but since the parameter types are unknown, I guess it's best to keep the if's in.

Hey @DaniFoldi, what is the status of this? I really want to release a 1.0 and trying to figure out what would go in it.

Hi @evanderkoogh ,
Unfortunately it's been a while since I last had a chance to work on the library, so my memory is rather faded. I believe the instrumentation worked in its current state, but additional work is needed to support tunnelled exceptions and outbound worker params.


ERROR [internal] load metadata for docker.io/library/bake_ctx_metapkg:latest

Aleksey@iMac-apple dl_control_api % docker build -t datalens-control_api:0.2080.0 .
[+] Building 2.9s (11/11) FINISHED                                                                                docker:desktop-linux
=> [internal] load build definition from Dockerfile                                                                                0.0s
=> => transferring dockerfile: 1.01kB                                                                                0.0s
=> resolve image config for docker.io/docker/dockerfile:1.4                                                                                1.8s
=> [auth] docker/dockerfile:pull token for registry-1.docker.io                                                                                0.0s
=> CACHED docker-image://docker.io/docker/dockerfile:1.4@sha256:9ba7531bd80fb0a858632727cf7a112fbfd19b17e94c4e84ced81e24ef1a0dbc                            0.0s
=> [internal] load .dockerignore                                                                                0.0s
=> => transferring context: 2B                                                                                0.0s
=> ERROR [internal] load metadata for docker.io/library/bake_ctx_metapkg:latest                                                                             1.0s
=> CANCELED [internal] load metadata for docker.io/library/bake_ctx_base_img:latest                                                                         1.0s
=> CANCELED [internal] load metadata for docker.io/library/bake_ctx_src_lib:latest                                                                          1.0s
=> [auth] library/bake_ctx_metapkg:pull token for registry-1.docker.io                                                                                0.0s
=> [auth] library/bake_ctx_src_lib:pull token for registry-1.docker.io                                                                                0.0s
=> [auth] library/bake_ctx_base_img:pull token for registry-1.docker.io                                                                                0.0s

[internal] load metadata for docker.io/library/bake_ctx_metapkg:latest:

Dockerfile:12
10 |     # Libs & metapkg
11 |     COPY --from=bake_ctx_src_lib / /src
12 | >>> COPY --from=bake_ctx_metapkg / /src
13 |
14 |     # Sources copy
ERROR: failed to solve: pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed

Hey @Alekovmsk! Please check out the newly created "How to build" guide and let us know if there are any issues after that

Closing this issue as there is no reaction


Jenkins jobs are failing

Jenkins jobs are failing while building the packages as it seems that the appropriate github tag is not checked out so python-build is not able to find the expected source file:
https://jenkins.egi.ifca.es/blue/organizations/jenkins/Pipeline-as-Code%2Fcloud-info-provider/detail/master/57/pipeline/

Hi @orviz would you be able to provide some help with this?

sure @gwarf I'll take a look

The RPM building stage failed as a consequence of the missing python-pbr module. EPEL repository was not available in the environment so this requirement was not installed. It has been fixed in the relevant Docker image used for running this stage.
The PR above complements this fix.

Thanks @orviz !


Modal: "dismissable" does not exist in type

Describe the bug
I have the following:
<Modal bind:open outsideclose size="xl" placement="top-center" dismissable={false}>
	{#if strings}
		<Stringseditor {strings} on:save={stringsChanged}></Stringseditor>
	{/if}
	{#if query}
		<Videolist total={0} index="movies" {query}></Videolist>
	{/if}
</Modal>

I get the following error message in VSCode
Object literal may only specify known properties, and '"dismissable"' does not exist in type
This should be there right? (according to the docs)
Reproduction
None available unfortunately
Flowbite version and System Info
System:
    OS: macOS 13.4.1
    CPU: (10) arm64 Apple M1 Max
    Memory: 11.39 GB / 64.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.5.1 - /opt/homebrew/bin/node
    npm: 9.8.0 - /opt/homebrew/bin/npm
    pnpm: 8.6.12 - ~/Library/pnpm/pnpm
  Browsers:
    Safari: 16.5.2
  npmPackages:
    @sveltejs/kit: 1.23.0 => 1.23.0
    flowbite-svelte: 0.44.4 => 0.44.4
    svelte: 4.2.0 => 4.2.0
    vite: 4.4.9 => 4.4.9

I can't reproduce that. It seems Modal props are correctly inheriting from Dismissable:
interface $$Props extends ComponentProps<Frame>, Dismissable

Let me try to create a reproducible repo...

It seems that it got renamed to permanent and inverted (so dismissable={false} is permanent={true} and dismissable={true} is permanent={false}) in newer versions.

That works! It is weird, because if I look in the source code it is called dismissable....
Modal
types.ts


fix: escape paths in injected imports

Fixes #77. We can't just wrap the hotApiImport and adapterImport paths in single quotes, because any single quotes inside of them will result in invalid code being generated. I'm instead running them through JSON.stringify.
I'm unable to get the tests to run locally, so I haven't run the tests and I don't know whether this breaks anything. I haven't tried running them with older versions of Node, but it also looks like CI has been red on master for a while.
This repo is also on an old version of pnpm that does not work in Node 20.

I think if the MacOS tests are passing then you should be safe. I see them passing on Node 14 at least. I might rerun the Node 16 Mac tests to confirm it's just a flake


UI: change "Container Default Limit" label to a "Container Default Resource Limit"

As the latter is more descriptive.

Version: Master 2.2 (3/12/19) 68f13abc3245
Confirmed issue.
This has now been renamed to "Container Default Resource Limit"
From Add Namespace page:

Also checked from Add Project page.


Automator: update<EMAIL_ADDRESS>dependency in<EMAIL_ADDRESS>

Generated by Automator - 2022-07-06T14:33:09+00:00

tripped the prow job to fix the conflicts.


change community day to first Monday of the month

To my understanding, the only file to be changed was the calendars/community.yaml. All dates changed to the first Monday of the month. I have to say the new dates match around the CR workshop better. :)
Please also check https://github.com/coderefinery/coderefinery.github.io/pull/new/changed-community-day.
fixes #6.

I'm on vacation July 4th and I would not attend unless a very exciting topic. :)
I did keep it just in case. Easier to remove than add.


Update German translation

Lines 272 and 274:

Please alter "GUI" to "SailfishOS:Chum GUI App", once in line 272 and twice in line 274: That is how I deliberately phrased the English strings.
"im SSU" sound strange, closer to the original an better is "für SSU", because it is really the configuration for / of SSU which is altered.

Line 287: You did that well in  line 280, but missed the difference (only "testing"!) here.
⇒
Füge SailfishOS:Chum Testing Repository hinzu

Line 299: "Deinstallieren Paket" → Deinstalliere Paket

@black-sheep-dev, if you want to take the chance to look over these translated strings, again.  I rectified and altered a few in commit 2fbda80, so I would be glad if you review these changes.


scheduler is not running

"The scheduler does not appear to be running.
The DAGs list may not update, and new tasks will not be scheduled."
the problem is always appearance,i use "ps -ef|grep scheduler" see "scheduler" is done ,restart it ,but can not solve it ? this is why ?

@zhaobinnian If you're using sequential executor, refer to issue #422.

thank you very much
------------------ 原始邮件 ------------------
发件人<EMAIL_ADDRESS>发送时间: 2019年10月29日(星期二) 上午6:22
收件人<EMAIL_ADDRESS>抄送: "binclear"<782689111<EMAIL_ADDRESS>主题: Re: [puckel/docker-airflow] scheduler is not running (#432)
@zhaobinnian If you're using sequential executor, refer to issue #422.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Suggest closing as duplicate


Zookeeper running on 3 ports in datacenter setup

Hey guys,
I was spinning up on this on aws and zookeeper is running on all 2181, 2888, 3888 even tho I run zookeeper on 3 servers.
Should this be the case or do I need to overwrite the following:
zookeeper_ports: "-p 2181:2181 -p 2888:2888 -p 3888:3888"
with
zookeeper_ports: "-p 2181:2181"
Regards
Andrei

Ports 2888 and 3888 are used within the Zookeeper for quorum and leader elections.
See http://docs.hortonworks.com/HDPDocuments/HDP1/HDP-1.3.7/bk_using_Ambari_book/content/reference_chap2_4b_2x.html.
If you are using more than one ZK node, they are required.

Thanks :)


Feature: Deploy falcosidekick and falco server and client secrets for mTLS

What type of PR is this?
/kind feature
/kind chart-release

Any specific area of the project related to this PR?
/area falco-chart
/area falcosidekick-chart

What this PR does / why we need it:
This PR adds the capability of loading certificates dynamically via helm values, instead mounting volumes. It's structured in a way to make it easier to deploy mTLS cryptographic material for both falco and falcosidekick when http_output is enabled.
Which issue(s) this PR fixes:
N/A

Special notes for your reviewer:
There are some changes in the directories to store the certificates. It seems not to break anything, but this of course can be overridden by a local values file.
Checklist

[X] Variables are documented in the README.md

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: jgmartinez
Once this PR has been reviewed and has the lgtm label, please assign issif for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

By changing the folders for the certs, are you sure it will not create breaking change?
Moreover I'm not sure the CI will accept to merge a PR for modifications of 2 charts at once.

Hi @Issif!
You are right, changing the default values of the cert directory, in the Falco chart, could break https connections if no CA is defined. I think it would be better to leave it blank since Falco itself defaults to /etc/ssl/certs when no value is defined for ca_cert in this line. Same for client_cert and client_key.
As of Falcosidekick, I just added the falcosidekick directory name for clarity, similarly as in falco-exporter, I can rollback to the previous name if it's preferred.
Confirm if I need to open separate PRs for each chart and I'll do it when all changes are "approved" in a comment 😄
Thank you!

Split to #548 and #549 @Issif


Memory component

I will now start implementing a memory component.
In order to avoid double work I think its a good idea if we create tracking issues for the work we do.
A key problem here is howto manage the state in order to allow reversing (aka, UnClocking). We probably don't want to make history buffer containing the complete memory state for each clock cycle. A good design to solve this effectively might be re-usable for other purposes (when we later implement other stateful components, e.g., peripherals). Stateful reversal was never really correctly implemented in the original SyncSim model, with the effect that reversing interrupts never worked totally correct.
Features:
Implemented:

read/write of u8/u16/u32 [x]
alignment checking [x]
byte ordering [x]

Todo:

local history buffer [ ]
vizia GUI [ ]
egui GUI [ ]

As a comment to self, the reg_file component currently has no history.

A first POC is available in the https://github.com/perlindgren/syncrim/tree/memory_component branch.
It currently supports only u8 accesses.
Todo:s include

u8/u16/u32/u64
alignment checking
byte ordering
local history buffer

Notice, we will likely need to add un_clock, and reset to the Component trait (but this will be a separate issue/PR).
The implementation showcases how we can provide structured abstractions to inputs and outputs using num_enum. This allows to give meaning to signals (e.g., the ctrl signal being an enum of variants (None, Read, Write) etc. This will improve readability/ease of use of components.

A minimal viable implementation has been merged.

Added simple vizia frontend, with an example (data_mem).

Fixed some clippy warning and updated dependencies, will merge if passing.

Partly addressed with #78 . I think optimally you have a generic memory component with an architecture specific wrapper (exposing ports specific to some architecture). That way we can re-use most of the generic memory code and UI. Let's keep this issue around.


Update narratives on a share event

Getting reports that narratives do not update in ES when a narrative is shared. I'll see if I can reproduce and fix.

Here is an example event:

Here is an example event:


Node Filtering with Uppercase Letters

Hey awesome work! I ran into an issue with node filtering for uppercase letters.  If I have a node label 'AB12345', noticed that trying to filter for 'AB' excluded 'AB12345'.
looking at _callback_search_graph(), the condition is to find search_text in node['label'].lower(), so that searches for upper case letters fail.
Then again this does not seem to occur in your demos, so maybe i just set up the input dataframe wrong. anyway dont do this a lot but wanted to share an issue I experienced because my experience with jaal has been great so far
https://github.com/imohitmayank/jaal/blob/74a7d2cbe6195e55ad655b63d0099243712c1cda/jaal/jaal.py#L45

Thanks for sharing this @dbrosnan08 , it seems we should do search_text.lower() there.
https://github.com/imohitmayank/jaal/blob/74a7d2cbe6195e55ad655b63d0099243712c1cda/jaal/jaal.py#L45

Hi @dbrosnan08 this is fixed now, please upgrade to latest version of jaal for this to work.


Use UTC explicitly for flagext.DayValue

Fixes #23
Signed-off-by: Nick Pillitteri<EMAIL_ADDRESS>Checklist

[X] Tests updated
[ ] CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

Thanks! Since this could potentially impact downstream projects, we should document the change in the CHANGELOG.

Will do


Numba Installation Failing on Python 3.9.1

I am aware that issues like these have arisen in the past, though the ones relevant to my environment were from a few months ago, in which new version of llvmlite and numba were introduced. According to CHANGE LOG, python 39 is supported. So 3.9.x should not be the issue, I am assuming 3.9.1 is not being supported currently, and if so, do we have an expected release for this python version?

[x] I have tried using the latest released version of Numba (most recent is
visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).

`(venv) PS C:\Code\autofinance\data\historic\downloader> pip install numba
Collecting numba
Using cached numba-0.51.2-cp39-cp39-win_amd64.whl
Collecting llvmlite<0.35,>=0.34.0.dev0
Using cached llvmlite-0.34.0.tar.gz (107 kB)
Requirement already satisfied: numpy>=1.15 in c:\code\autofinance\bot\venv\lib\site-packages (from numba) (1.20.0)
Requirement already satisfied: setuptools in c:\code\autofinance\bot\venv\lib\site-packages (from numba) (53.0.0)
Building wheels for collected packages: llvmlite
Building wheel for llvmlite (setup.py) ... error
ERROR: Command errored out with exit status 1:
command: 'c:\code\autofinance\bot\venv\scripts\python.exe' -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-install-srjyb9bm\llvmlite_db81886b772c41f28323d31fd3efe66b\setup.py'"'"'; file='"'"'C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-install-srjyb9bm\llvmlite_db81886b772c41f28323d31fd3efe66b\setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(file);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' bdist_wheel -d 'C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-wheel-ru2yvob4'
cwd: C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-install-srjyb9bm\llvmlite_db81886b772c41f28323d31fd3efe66b
Complete output (24 lines):
running bdist_wheel
c:\code\autofinance\bot\venv\scripts\python.exe C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-install-srjyb9bm\llvmlite_db81886b772c41f28323d31fd3efe66b\ffi\build.py
Trying generator 'Visual Studio 15 2017 Win64'
Traceback (most recent call last):
File "C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-install-srjyb9bm\llvmlite_db81886b772c41f28323d31fd3efe66b\ffi\build.py", line 191, in
main()
File "C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-install-srjyb9bm\llvmlite_db81886b772c41f28323d31fd3efe66b\ffi\build.py", line 179, in main
main_win32()
File "C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-install-srjyb9bm\llvmlite_db81886b772c41f28323d31fd3efe66b\ffi\build.py", line 88, in main_win32
generator = find_win32_generator()
File "C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-install-srjyb9bm\llvmlite_db81886b772c41f28323d31fd3efe66b\ffi\build.py", line 76, in find_win32_generator
try_cmake(cmake_dir, build_dir, generator)
File "C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-install-srjyb9bm\llvmlite_db81886b772c41f28323d31fd3efe66b\ffi\build.py", line 28, in try_cmake
subprocess.check_call(['cmake', '-G', generator, cmake_dir])
File "C:\Users\karun_n8iupx8\AppData\Local\Programs\Python\Python39\lib\subprocess.py", line 368, in check_call
retcode = call(*popenargs, **kwargs)
File "C:\Users\karun_n8iupx8\AppData\Local\Programs\Python\Python39\lib\subprocess.py", line 349, in call
with Popen(*popenargs, **kwargs) as p:
File "C:\Users\karun_n8iupx8\AppData\Local\Programs\Python\Python39\lib\subprocess.py", line 947, in init
self._execute_child(args, executable, preexec_fn, close_fds,
File "C:\Users\karun_n8iupx8\AppData\Local\Programs\Python\Python39\lib\subprocess.py", line 1416, in _execute_child
hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
FileNotFoundError: [WinError 2] The system cannot find the file specified
error: command 'c:\code\autofinance\bot\venv\scripts\python.exe' failed with exit code 1
ERROR: Failed building wheel for llvmlite
Running setup.py clean for llvmlite
Failed to build llvmlite
Installing collected packages: llvmlite, numba
Attempting uninstall: llvmlite
Found existing installation: llvmlite 0.35.0
Uninstalling llvmlite-0.35.0:
Successfully uninstalled llvmlite-0.35.0
Running setup.py install for llvmlite ... error
ERROR: Command errored out with exit status 1:
command: 'c:\code\autofinance\bot\venv\scripts\python.exe' -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-install-srjyb9bm\llvmlite_db81886b772c41f28323d31fd3efe66b\setup.py'"'"'; file='"'"'C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-install-srjyb9bm\llvmlite_db81886b772c41f28323d31fd3efe66b\setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(file);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' install --record 'C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-record-1gy_7qhi\install-record.txt' --single-version-externally-managed --compile --install-headers 'c:\code\autofinance\bot\venv\include\site\python3.9\llvmlite'
cwd: C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-install-srjyb9bm\llvmlite_db81886b772c41f28323d31fd3efe66b
Complete output (27 lines):
running install
running build
got version from file C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-install-srjyb9bm\llvmlite_db81886b772c41f28323d31fd3efe66b\llvmlite/_version.py {'version': '0.34.0', 'full': 'c5889c9e98c6b19d5d85ebdd982d64a03931f8e2'}
running build_ext
c:\code\autofinance\bot\venv\scripts\python.exe C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-install-srjyb9bm\llvmlite_db81886b772c41f28323d31fd3efe66b\ffi\build.py
Trying generator 'Visual Studio 15 2017 Win64'
Traceback (most recent call last):
File "C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-install-srjyb9bm\llvmlite_db81886b772c41f28323d31fd3efe66b\ffi\build.py", line 191, in
main()
File "C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-install-srjyb9bm\llvmlite_db81886b772c41f28323d31fd3efe66b\ffi\build.py", line 179, in main
main_win32()
File "C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-install-srjyb9bm\llvmlite_db81886b772c41f28323d31fd3efe66b\ffi\build.py", line 88, in main_win32
generator = find_win32_generator()
File "C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-install-srjyb9bm\llvmlite_db81886b772c41f28323d31fd3efe66b\ffi\build.py", line 76, in find_win32_generator
try_cmake(cmake_dir, build_dir, generator)
File "C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-install-srjyb9bm\llvmlite_db81886b772c41f28323d31fd3efe66b\ffi\build.py", line 28, in try_cmake
subprocess.check_call(['cmake', '-G', generator, cmake_dir])
File "C:\Users\karun_n8iupx8\AppData\Local\Programs\Python\Python39\lib\subprocess.py", line 368, in check_call
retcode = call(*popenargs, **kwargs)
File "C:\Users\karun_n8iupx8\AppData\Local\Programs\Python\Python39\lib\subprocess.py", line 349, in call
with Popen(*popenargs, **kwargs) as p:
File "C:\Users\karun_n8iupx8\AppData\Local\Programs\Python\Python39\lib\subprocess.py", line 947, in init
self._execute_child(args, executable, preexec_fn, close_fds,
File "C:\Users\karun_n8iupx8\AppData\Local\Programs\Python\Python39\lib\subprocess.py", line 1416, in _execute_child
hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
FileNotFoundError: [WinError 2] The system cannot find the file specified
error: command 'c:\code\autofinance\bot\venv\scripts\python.exe' failed with exit code 1
----------------------------------------
Rolling back uninstall of llvmlite
Moving to c:\code\autofinance\bot\venv\lib\site-packages\llvmlite-0.35.0.dist-info
from C:\Code\autofinance\bot\venv\Lib\site-packages~lvmlite-0.35.0.dist-info
Moving to c:\code\autofinance\bot\venv\lib\site-packages\llvmlite
from C:\Code\autofinance\bot\venv\Lib\site-packages~lvmlite
ERROR: Command errored out with exit status 1: 'c:\code\autofinance\bot\venv\scripts\python.exe' -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-install-srjyb9bm\llvmlite_db81886b772c41f28323d31fd3efe66b\setup.py'"'"'; file='"'"'C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-install-srjyb9bm\llvmlite_db81886b772c41f28323d31fd3efe66b\setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(file);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' install --record 'C:\Users\karun_n8iupx8\AppData\Local\Temp\pip-record-1gy_7qhi\install-record.txt' --single-version-externally-managed --compile --install-headers 'c:\code\autofinance\bot\venv\include\site\python3.9\llvmlite' Check the logs for full command output.`
Thanks in advance. P.S. first time submitting a new issue on a public repo of this scale. Pardon me if I accidentally break the community guidelines.

Thanks for the report. The change log was patched and Numba tagged the 0.53.0RC1 (version 0.53.0 release candidate 1.) yesterday. Packages for the release candidate are building right now and will be available shortly for community testing. The release candidate(s) and final release will be announced on discourse: https://numba.discourse.group/c/announcements/. Hope this helps.

RE formatting in GitHub issues, for future reference triple backticks are needed around a code block (with optional language syntax specified), for example: ```python <your code> ```. GitHub also has a basic guide to its markdown syntax available here.

Thanks, @stuartarchibald, my project is under a bit of a rush right now, (yes I did take the risk of python 3.9.1). Do you have any estimates how long the build will take?

RE formatting in GitHub issues, for future reference triple backticks are needed around a code block (with optional language syntax specified), for example: ```python <your code> ```. GitHub also has a basic guide to its markdown syntax available here.

Thank you! Will keep this in mind next time!

Thanks, @stuartarchibald, my project is under a bit of a rush right now, (yes I did take the risk of python 3.9.1). Do you have any estimates how long the build will take?

Probably conda packages today or early next week, same for wheels. These are release candidate packages built so that the community driven testing process can take place, it's likely to be a few weeks before a final release as the community needs time to do the testing.

ok 👍, until then I will work on some other parts of my project. Thanks for the quick replies.

ok +1, until then I will work on some other parts of my project. Thanks for the quick replies.

No problem, do keep an eye on discourse for the release announcements.


Service worker fails to load new dynamic/code-split chunk

Is this a bug report?
Yes
Can you also reproduce the problem with npm 4.x?
Yes
Which terms did you search for in User Guide?
progressive web app service workers
Environment

node -v: 8.4.0
npm -v: 5.6.0
yarn --version (if you use Yarn):
npm ls react-scripts (if you haven’t ejected): 1.0.17

Then, specify:

Operating system: Windows 10
Browser and version (if relevant): Chrome 63

Steps to Reproduce

Set up a default CRA project
Install react-loadable to code-split a certain React component on the page
Build, serve and navigate to the page
Modify the component earlier (to change the generated hash)
Build, serve and reload the page

Expected Behavior
The new version of the code-splitted component should be loaded correctly.
Actual Behavior
The installed service worker tries to fetch the old component chunk instead of the new one, resulting in a failure to load the new chunk. This is because the hash has changed since the last time the service worker was installed. Because of this react-loadable interprets the error and refuses to display the new page, resulting in a blank page.

This is less than ideal, and the only thing I could come up is to force a reload on the homepage. This will trigger the new service worker to be installed which results in the correct component/chunk being loaded.

@TheHolyWaffle  try use the following webpack.config.js

var path = require('path');
var webpack = require('webpack');

module.exports = {
  context: path.join(__dirname, 'app'),
  entry: ['./index.html', './index.js'],
  output: {
    path: path.join(__dirname, 'dist'),
    filename: 'bundle.js'
  },
  module: {
    loaders: [
      {
        test: /.js?$/,
        loader: 'babel-loader',
        exclude: /node_modules/,
        query: {
          presets: ['es2015', 'react']
        }
      },
      {
        test: /\.html$/,
        loader: "file-loader?name=[name].[ext]",
      },
      {
        test: /\.css$/,
        loader: "style-loader!css-loader"
      },
      {
        test: /\.png$/,
        loader: "url-loader?limit=100000"
      },
      {
        test: /\.jpg$/,
        loader: "file-loader"
      }
    ]
  },
  devServer: {
    historyApiFallback: true
  }
};

@engmyahya How would that help? I see nothing special sticking out from that webpack config that would fix this issue.

@TheHolyWaffle  , kindly check this https://github.com/engmyahya/ecosystems , i uploaded a complete same with the installation which fixed this issue for me.
which was related to the webpack, and i installed the latest version, then became ok.

@jeffposnick would you be able to tell what is going wrong here?

I have the exact same issue. "Solved" it also with reloading the page. But dosn't feel like a real solution.

I don't believe that this type of failure is limited to scenarios in which there's a service worker installed. For instance, you could imagine a scenario in which a long-lived single page app not controlled by a service worker attempts to dynamically load a hashed chunk as a result of a SPA-style navigation, but the URL for that chunk is no longer valid because the assets for the site have been updated and redeployed in the interim.
So, while there are ways to avoid getting into this state by modifying the service worker's behavior[*], I wonder if it would just make more sense to address it from the perspective of solving the non-service worker scenario as well.
One approach would be to detect when there's a failure to dynamically load one of the chunks that's needed to perform an SPA-style navigation and use that as a cue to trigger a "real" navigation request, which should recreate the DOM and get the client to the point where it's expecting the hashed chunk names that correspond to what's currently on the server.
I'm not familiar with the libraries you're using to dynamically load the chunks, but perhaps someone who knows more about that would have specific guidance as to the code changes that would be needed.
[*] Setting skipWaiting: false when generating the service worker should prevent the old caches from being purged until all open tabs that are controlled by the service worker have been unloaded, but the drawback of using that config is that developers who expect to see new content when they reload an open tab will have to wait until they close and reopen the tab instead.

I went into the same scenario as TheHolyWaffle.
Calling unregister instead of register of registerServiceWorker fixed the thing, but it has broken our production for days, and recovering from this is really painful

@ugogo But again, isn't this a problem that you need to solve whenever you deploy a long-lived web app that relies on loading in chunks dynamically at runtime that might have been removed from the web server?
You mentioned that you've unregister()ed your service workers, which is fine, but what about the possibility of this occurring without service worker involvement?

@jeffposnick Yeah I think you're right, chunks were removed from the server, leading to a 404.
unregister() was only to keep our production safe before finding the correct solution 😄

The change in https://github.com/facebook/create-react-app/pull/3924/files#diff-d2bddbd3bfb7051f9381474c844674faR446 should help avoid issues with lazy-loading for developers who use service workers via create-react-app.
But as mentioned previously, independent of the service worker, this is a problem you need to deal with any time you're lazy-loading versioned assets. How would you avoid it if you're just in a scenario in which a user has a tab open for an extended period of time (without a service worker registered), and then they attempt to load a versioned asset which has been removed from the server in the interim?
Add in logic into your lazy-loading code that handles failures by, e.g., automatically performing a full-refresh, or at least showing a meaningful error to your users so that they could manually refresh, seems like it would be necessary in general.

With a service worker, you should be able to check when there is a new version, and then trigger a page load the next time someone navigates.
I'm using CRA without a service worker, is there really no way for me to catch the chunk loading error in my own code, and then i could trigger a page refresh so it feels normal when i deploy a new version while someone is on the old one?

There’s nothing stopping you from reloading the page when there is an error loading a chunk, you can just catch that error.
The only issue I could think of is that if for some reason that chunk could still not be loaded after a refresh you end up in a reload loop.

Ahh, I had done this before but since I'm using react-loadable, you can check the error prop https://github.com/facebook/create-react-app/issues/4152#issuecomment-415950842 for anyone else interested

Import itself just returns a promise so you can catch any errors just like with any other promise. See: http://2ality.com/2017/01/import-operator.html
I wouldn’t just assume that there are no other reasons for chunks to fail to load on production. If you accidentally push a chunk that contains a runtime error to production all your users will end up in a reload loop which will probably crash their browser/tab if they are not protected against it.

Last time I checked there was no way (except perhaps with some regex) to find out if the error was because the chunk was missing or there was something wrong with the chunk. Because the import will catch any runtime errors in your chunk as well.

I know it's a promise but I didn't know how to catch it when using the react-loadable abstraction :) thanks a lot. I have enough tests and linters in place where a chunk loading error shouldn't happen.
I get it's not perfect but I don't see another solution when not using a SW :/ i wish code splitting errors could cover more normal cases like this and be easier to catch!

I feel your pain. I've been thinking about it a lot but it's hard to come up with a unified solution as this is mostly an issue with the hosting providers. Using something like Cloudflare to cache all your bundles on their servers (up to a month) could help if you don't have full control over the hosting of your application.

I'm still a bit fuzzy on what to do here. When there's a new chunk how can I set up the service worker to get the new one? Anyone have a code snippet?

If you're using a service worker, heres some ideas @AustinGomez https://zach.codes/handling-client-side-app-updates-with-service-workers/
I am not trying to self-promote, but this was my thought process when I was setting up service workers for the first time and trying to auto update people on my apps. I think this can help

@zackify thanks for that. That's a cool solution!

@zackify thanks for sharing! Really helpful as this is something a lot of people run in to. Perhaps we should add a link to the post in the documentation about service workers?

Sure if you want!

Ash @jeffposnick said, talking about service workers here is just making things more confusing. Same problem, just harder to see.
Another good solution is to "cake on the built assets". Running yarn run build will wipe out any old ./build/ directory but on your server, you can keep the old files from the old deployment.
If the Monday build was:

build/static/js/main.aaa.js
build/static/js/chunk.111.js

...and someone loads main.aaa.js on that Monday but don't click the button that causes chunk.111.js to load yet.
Tuesday's build was:

build/static/js/main.bbb.js
build/static/js/chunk.222.js

So if that Monday user eventually tries to load chunk.111.js it's going to be gone. It would be better if your server (e.g. Netlify, S3, Nginx, whatever) would be available to host all of...:

build/static/js/main.aaa.js
build/static/js/chunk.111.js
build/static/js/main.bbb.js
build/static/js/chunk.222.js

that you would avoid that 404 error.
Having to reload the page just because a chunk failed feels dangerous. What if the user is in the midst of typing in their shipping address and a reloaod causes all sorts of disruption to the shopping cart checkout process.


os: Stat results in error for AF_UNIX socket on Windows

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

$ go version
go1.19.3 windows/amd64

Does this issue reproduce with the latest release?
Assume yes, because there are no changes in os.Stat between latest (1.19.4 and 1.19.3)
What operating system and processor architecture are you using (go env)?
msys2 windows mingw64 amd64
go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\User\AppData\Local\go-build
set GOENV=C:\Users\User\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\User\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\User\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\msys64\mingw64\lib\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\msys64\mingw64\lib\go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.19.3
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
set GOWORK=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=C:\msys64\tmp\go-build1291667829=/tmp/go-build -gno-record-gcc-switches

What did you do?

package main

import (
	"fmt"
	"net"
	"os"
	"time"
)

func listen(end chan<- bool) {
	addr, err := net.ResolveUnixAddr("unix", "./tmp.sock")
	if err != nil {
		fmt.Printf("Failed to resolve: %v\n", err)
		os.Exit(1)
	}

	list, err := net.ListenUnix("unix", addr)
	if err != nil {
		fmt.Printf("failed to listen: %v\n", err)
		os.Exit(1)
	}
	time.Sleep(time.Second * 2)
	list.Close()
	end <- true
}

func main() {
	end := make(chan bool, 1)
	go listen(end)
	time.Sleep(time.Second)
	_, err := os.Stat("./tmp.sock")
	if err != nil {
		fmt.Printf("Error doing stat %v", err)
	}
	<-end
}

Then build and run
go build test.go && ./test
What did you expect to see?
No error output. Like on macOS.
What did you see instead?
This prints error
Error doing stat CreateFile ./tmp.sock: The file cannot be accessed by the system

Other info
It looks like usage of CreateFile syscall should be adjusted for AF_UNIX socket scenario.

Looks like a duplicate of https://github.com/golang/go/issues/33357#issuecomment-1133411792
Sorry for noise.


[Feature Request] Allow PVC monitoring

The PVC monitoring feature of containerized AGs requires the node/metrics ressource to be added to
dynatrace-kubernetes-monitoring  ClusterRole. It is descriped in within the dynatrace documentation otherwise PVC monitoring is not possible.
I would suggest to add this so AGs deployed by the operator can be used for PVC monitoring.

Since the PVC monitoring feature is opt-in this won't be included by default in the Operator installation to adhere to security best practices.
We will be adding it as an option to the helm chart in a future version.

Will be added to the helm charts in a future release. See #859


Report on AMIs that are more than 90 days

Report on AMIs that are more than 90 days
Second commit adds logging to audit events (required large refactor due to abstract class)

Looks good, I have some comments related to AuditAnalyser but not to do with your changes.

Why go through all these refactoring efforts when getLogger() essentially returns a singleton? I'd suggest to just call getLogger() where it's needed rather than pass it around 🤔 But what am I even doing here? 😅

@achatain your right that it may not necessary but I would argue its good to keep for 3 reasons:

If gives some felxabity to change to an alternate logger in the future. i.e in the future configure_logging() could output a non standard loggger such as for JSON format logging (this makes it easier to search in logging tools that can parse JSON)
It encourages developers to log if there is already one available
We are trying embrace the principle of dependency injection here


Component defined twice in Modelica.Mechanics.Rotational.Components.Clutch

Reported by Frenkel on 7 Jun 2013 11:21 UTC
In the Model Modelica.Mechanics.Rotational.Components.Clutch the Component
  Modelica.SIunits.AngularAcceleration a_rel(start=0)
    "Relative angular acceleration (= der(w_rel))";

is defined twice because the base class Modelica.Mechanics.Rotational.Interfaces.PartialCompliantWithRelativeStates already defines
  Modelica.SIunits.AngularAcceleration a_rel(start=0)
    "Relative angular acceleration (= der(w_rel))";

Hence Modelica.Mechanics.Rotational.Components.Clutch inherit from Modelica.Mechanics.Rotational.Interfaces.PartialCompliantWithRelativeStates the second definition of a_rel is unnecessary and should be removed.

Migrated-From: https://trac.modelica.org/Modelica/ticket/1162

Comment by beutlich on 7 Jun 2013 11:42 UTC
Resolved by 6f0b68f6a69098f16290d6ce21bc15e37cd9f34c. Thanks, Jens.


Vulkan application stops responding when executed with renderdoc

Description
Hi, for some reason RenderDoc stopped working for me on Linux with my hobby vulkan application. The issue is, that when I run my applications in renderdoc, the applications stops responding at the create-Instance step.
Note that the application is written in Rust and uses the ash wrapper around vulkan. If you don't want to search for the problem, just let me know. That would be totally understandable.
However, it worked up to a point and now doesn't, so it might be some interesting bug.
I tested it on a system with ryzen1700x + AMD vega 56 as well as a intel hd4000 base Dell XPS13.
Steps to reproduce
The code can be found on the master branch as of writing the issue here (hash: 487b8dca). However, after hopefully fixing the issue the master branch will change.
Steps to reproduce:

install rust toolchain via rustup
change into marp/ directory and execute cargo run --example cube_textures --release (this will build my vulkan wrapper (marp) and execute the "textured cube" example). This should work.
copy the executable to the projects root, for instance cp target/release/examples/cube_textures run.bin
try to launch run.bin in renderdoc and observe, that the application hangs. Launching without renderdoc should still work fine.

The interesting bits are:

in marp/src/instance/mod.rs link where the vulkan call for creating the instance is issued
marp-utils/src/mod.rs first line of create_device_and_gfx_queue() link where the instance creation parameters are set

According to my print debugging it starts not responding when the createInstance call is issued.
If there is more I can do to debug the issue, just let me know.
Environment

RenderDoc version: 1.8
Operating System: ArchLinux 5.6.14
Graphics API:

AMD Vega 56 with amvlk2020.Q2.3-1 (closed source driver) and mesa
intel hd4000 with vulkan-intel 20.0.7-3

Since you're using Arch linux I assume you're using a bleeding-edge loader 1.2.140, which has a bug that causes this deadlock. Revert to the last stable loader 1.2.135 and this issue should go away.


twister: Remove newline suffix in BinaryHandler

Update the code that removes newline suffix in BinaryHandler for compatibility with python 3.8.
Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/58335

Rebase to fix merge conflict.


"Not all referenced projects are in the compiler options" assert popups in Release configuration

@dungpa I believe it started to popup after you introduced getCurrentProject. On my solution at work this dialog appears almost every time I open a file in a project no files from which are already opened.

Couldn't repro cleanly. Closing since it doesn't affect any functionality.


Removes periods from targets in pig latin task -- in progress

Removes periods from the targets, because the default output_regex selects non-period characters.  So it was impossible to get an exact_str_match of anything greater than zero on this

Nevermind, I just realized that the preferred metric for this is bleu, not exact_str_match


removing clear listener in processReadData, causing freeze on call queries

The logic to clear listeners when the data is empty was causing that queries (LoadMessages, Chats, Contacts etc) do not respond never

Tested today, agree with @houstondapaz
Commented on the PR here
https://github.com/Rhymen/go-whatsapp/pull/179#issuecomment-505999104


Update minikube documentation

This pull request updates the outdated Minikube documentation using the deprecated --vm-driver parameter, which was replaced by --driver. It also updates the driver lists in all localizations and removing xhyve which does not exist anymore.

Hi @cwansart and thanks for this PR.
To make reviewing easier, we'd like you to limit reviews to a single language.
This is partly because we probably don't have reviewers who speak all of the languages that you want to change, and mostly because we need a signoff from each language team that a PR touches before we can merge it. (The robot that decides on approval can't tell a code-only change from a change that affects the localized text).
Also, different localization teams use different branching strategies - see  https://kubernetes.io/docs/contribute/start#choose-which-git-branch-to-use
Would you be willing to save the non-English changes for the future and revise this to just change the en localization?

Hey @sftim sure, I can do that.

Done. The others will follow. I first need to check for their way of handling pull requests.

/remove-language de
/remove-language es
/remove-language fr
/remove-language ja
/remove-language ko
/remove-language ru
/remove-language vi
/remove-language zh

Non-member feedback:
/lgtm
The minikube start --driver approach worked as per the advice, in my case I tested with docker
james@ubuntu-throwaway-2:~$ minikube start --driver=docker
* minikube v1.8.2 on Ubuntu 18.04
* Using the docker driver based on user configuration
* Downloading preloaded images tarball for k8s v1.17.3 ...
    > preloaded-images-k8s-v1-v1.17.3-docker-overlay2.tar.lz4: 499.26 MiB / 499
* Creating Kubernetes in docker container with (CPUs=2) (2 available), Memory=1993MB (1993MB available) ...
* Preparing Kubernetes v1.17.3 on Docker 19.03.2 ...
  - kubeadm.pod-network-cidr=<IP_ADDRESS>/16
* Launching Kubernetes ...
* Enabling addons: default-storageclass, storage-provisioner
* Waiting for cluster to come online ...
* Done! kubectl is now configured to use "minikube"

All of the updated links, resolve accordingly and take you to the expected target references.
On a mac, I can confirm that the step for checking VMX, worked as expected
$ sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX EST TM2 SSSE3 FMA CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC MOVBE POPCNT AES PCID XSAVE OSXSAVE SEGLIM64 TSCTMR AVX1.0 RDRAND F16C

The guidance for using --driver=none also worked as expected -
james@ubuntu-throwaway-2:~$ sudo minikube start --driver=none
* minikube v1.8.2 on Ubuntu 18.04
* Using the none driver based on user configuration
* Running on localhost (CPUs=2, Memory=1993MB, Disk=63340MB) ...
* OS release is Ubuntu 18.04.2 LTS
* Preparing Kubernetes v1.17.3 on Docker 19.03.4 ...
  - kubelet.resolv-conf=/run/systemd/resolve/resolv.conf
    > kubectl.sha256: 65 B / 65 B [--------------------------] 100.00% ? p/s 0s
    > kubeadm.sha256: 65 B / 65 B [--------------------------] 100.00% ? p/s 0s
    > kubelet.sha256: 65 B / 65 B [--------------------------] 100.00% ? p/s 0s
    > kubeadm: 37.52 MiB / 37.52 MiB [---------------] 100.00% 18.59 MiB p/s 2s
    > kubectl: 41.48 MiB / 41.48 MiB [---------------] 100.00% 16.30 MiB p/s 3s
    > kubelet: 106.42 MiB / 106.42 MiB [-------------] 100.00% 26.08 MiB p/s 4s
* Launching Kubernetes ...
* Enabling addons: default-storageclass, storage-provisioner
* Configuring local host environment ...
*
! The 'none' driver provides limited isolation and may reduce system security and reliability.
! For more information, see:
  - https://minikube.sigs.k8s.io/docs/reference/drivers/none/
*
! kubectl and minikube configuration will be stored in /home/james
! To use kubectl or minikube commands as your own user, you may need to relocate them. For example, to overwrite your own settings, run:
*
  - sudo mv /home/james/.kube /home/james/.minikube $HOME
  - sudo chown -R $USER $HOME/.kube $HOME/.minikube
*
* This can also be done automatically by setting the env var CHANGE_MINIKUBE_NONE_USER=true
* Waiting for cluster to come online ...
* Done! kubectl is now configured to use "minikube"

Hope this helps the review process.

/approve
Needs a technical LGTM (I haven't checked this is accurate)

@sftim please see my recent comment, hopefully this assists on the technical review aspect.

/hold
pending v1.18 Kubernetes release

/hold cancel
/lgtm
/approve


indexer: clean up legacy snapshot codes

Description
the legacy method of updating objects_snapshot is no longer needed, thus this pr cleans it up
Test plan
ci

Release notes
Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.
For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.

[ ] Protocol:
[ ] Nodes (Validators and Full nodes):
[ ] Indexer:
[ ] JSON-RPC:
[ ] GraphQL:
[ ] CLI:
[ ] Rust SDK:
[ ] REST API:

it turns out that it is used in a graphql test command ForceObjectSnapshotCatchup
@wlmyng the context is that after having the separate snapshot processor, we no longer update snapshot table via this query and want to clean it up.


A section quite vague

In https://react.dev/learn/responding-to-events#passing-handlers-as-alternative-to-propagation

You could add more code to this handler before calling the parent onClick event handler, too. This pattern provides an alternative to propagation. It lets the child component handle the event, while also letting the parent component specify some additional behavior. Unlike propagation, it’s not automatic. But the benefit of this pattern is that you can clearly follow the whole chain of code that executes as a result of some event.

If you rely on propagation and it’s difficult to trace which handlers execute and why, try this approach instead.

It is somewhat abstract what it is talking about. "You could add more code" -- add more code for what purpose?
"This pattern provides an alternative to propagation" alternative to propagation? Why do I need to rely on propagation in the first place?  (and such that I now need an "alternative"?)
"while also letting the parent component specify some additional behavior." What additional behavior?
"But the benefit of this pattern is that you can clearly follow the whole chain of code that executes as a result of some event." Follow the chain?  What do you mean?
"If you rely on propagation and it’s difficult to trace which handlers execute and why, try this approach instead." What approach? Why do we "rely on propagation" in the first place?
Can you talk about something specific. Perhaps using an example with specific things. Right now it is quite abstract.

+1
Need some further clarification on this please.


LV2 plugin

Sointu could have a LADSPA plugin target (https://www.ladspa.org/ladspa_sdk/ladspa.h.txt).
This would enable the use of LMMS (or other, more unix-based sequencers) with Sointu.

Spying how vst2 package does it would be a good idea https://github.com/pipelined/vst2 Having a general package for making LADSPA plugins and then make sointu use that would be a good idea.

LADSPA API can not process MIDI events, only samples - LV2 is the correct choice of API here, so I'll rename the ticket.

I don't think I will have the energy to do this, but the correct approach would be to make a package similar to vst2 that bridges the calls from Go to C and vice versa. One could either do a minimal wrapper without adding any additional functionality, or perhaps similar wrapper like the LV2 C++ wrappers, which give default implementations for functionalities so one needs to only write the interesting functions.
I don't like how they decided to have LV2 plugins folders with multiple files and metadata; this complicates builds in go a lot, because go generally assumes "one executable" builds and has no build automation on its own. I really wish distributing LV2 would be as simple as "single shared object", like VST2. Apparently VST2 didn't get everything wrong (but quite many things they did).

If someone krhmkrhm is interested to take on the job, I'm happy to delegate :D

I'd be interested to write this (and also write & maintain a go module for easy access to LV2), but it may take some time until I start, because I'm busy atm with the upcoming Revision compos :)


Create Posts “query-hierarchal-data-using-tsql”

Automatically generated by Netlify CMS

👷 Deploy Preview for monetaboot processing.

Name
Link

🔨 Latest commit
db4b333b7211f9fbcb76956cb1d88aff23c76528

🔍 Latest deploy log
https://app.netlify.com/sites/monetaboot/deploys/62ec1213cc78060008306a57


Make it easier to register custom json serialisers in the REST API

If you want to use a custom json serialiser in the REST API, there is several classes to change. We need a simpler way a user can just register their serialisers with the RestJsonProvider without having to create/modify multiple classes.
An example of the current required process can be found here: https://github.com/gchq/gaffer-experimental/tree/customJsonSerialiserInRestApi/example/example-rest/src/main/java/uk/gov/gchq/gaffer/rest

Create a new RestJsonProvider class: https://github.com/gchq/gaffer-experimental/blob/customJsonSerialiserInRestApi/example/example-rest/src/main/java/uk/gov/gchq/gaffer/rest/serialisation/ExampleRestJsonProvider.java

Register it in your ApplicationConfig: https://github.com/gchq/gaffer-experimental/blob/customJsonSerialiserInRestApi/example/example-rest/src/main/java/uk/gov/gchq/gaffer/rest/application/ExampleApplicationConfig.java

Register the ApplicationConfig class in your web.xml: https://github.com/gchq/gaffer-experimental/blob/customJsonSerialiserInRestApi/example/example-rest/src/main/webapp/WEB-INF/web.xml

We should add the HyperLogLogPlusJsonSerialiser and HyperLogLogPlusJsonDeserialiser classes by default in the accumulo-rest and hbase-rest modules.

Migration Steps
JSONSerialiser is now a singleton and the methods on JSONSerialiser are now static. You will need to remove any instances you have of JSONSerialiser and instead just use the static methods on JSONSerialiser.
The behaviour of the JSONSerialiser ObjectMapper can be configured by extending the JSONSerialiser class and configuring the ObjectMapper. Child classes must has a default no argument constructor. You will then need to set the gaffer.serialiser.json.class property in your StoreProperties or as a System Property. You can also add modules to the ObjectMapper by writing an implementation of JSONSerialiserModules and registering it using the gaffer.serialiser.json.modules property in your StoreProperties or as a System Property.
Previously there were other ways of configuring the JSONSerialiser, such as in ExportToGafferResultCacheHandler and ProxyProperties. These have been removed in favour of configuring the JSONSerialiser once for the entire jvm.

Merged into develop.


Awesome books: with ES6

Hello Dear Reviewer🥳
Awesome books: with ES6 project.
In this milestone, several operations were added to the awesome book to make it more usable and professional such as:
I have set up my project by :

Creating a new directory and initializing it with git.
Using npm init -y command to create package.json file.
Creating the entry point for your JavaScript code called index.js
Creating index.css file for your styles.
Creating the main index.html file. Link your index.js and index.css files there.
Creating a directory called modules.

After this I have:

Used ES6 syntax to recreate my awesome book.
Divided my code into modules, and saved each module in a separate file in the modules dir. Imported modules in the index.js file as the more modules the better for best practices.
Kept all functionalities of the app without errors.

STATUS: APPROVED  ✔

Hi @KABIKA681 ,
Your project is complete! Great job for nailing it right on the first attempt 🥇. There is nothing else to say other than... it's time to merge it 🍾🚢 :shipit: . Congratulations!  🎉💯🌟
Good Points 👍

Project is set up properly ✔
Descriptive Pull Request ✔
ES6 and modules are sued ✔
Using the Luxon library ✔

Cheers and Happy coding! :clap: :clap: :clap:
Feel free to leave any questions or comments in the PR thread by mentioning my Github username if something is not 100% clear.

As described in the Code reviews limits policy you have 2 more limited reviews per this project. If you think that the code review was not fair, you can request a second opinion using this form.


Support authentication with ETCD

calico-containers supports this as of https://github.com/projectcalico/calico-containers/pull/654/files
The plugin should support also certificate authentication with etcd.

The documentation was lost from the CNI migration, but I believe it's already supported via
ETCD_SCHEME
ETCD_AUTHORITY
ETCD_CA_CERT_FILE
ETCD_CERT_FILE
ETCD_KEY_FILE

Yes, it is quite likely that this already works and just falls out :)
I think this issue is mostly testing / documentation rather than writing any code.

i have tested, this enviroment vars is work

Great :)


Platform/13199/fhir function dynamic message routing

This PR ...
Refactors how queue message routing happens such that the behavior (1) no longer hard coded (2) baked into the queue message itself. The trigger for changing default routing behavior is expected to be the something in the content of the message itself and thus it makes sense for the routing logic to be colocated with the content of the message itself.
Changes

QueueMessage has been updated with a "when" clause (switch/case for Java-heads) that sets default routing behavior for a given queue message type. Should a short circuit of this behavior be required the germane "when" block for that message type may be updated to route the message to a different queue topic. the queueAccess object is provided to the a new function, QueueMessage.send() to keep separation of concern in tact.  The QueueMessage object handles routing itself with routing plumbing provided by FHIRFunctions.

Checklist
Testing

[x ] Tested locally?
[x ] Ran ./prime test or ./gradlew testSmoke against local Docker ReportStream container?

@arnejduranovic I looked at the patch and I could use a 10m huddle because I think I'm missing something. If I read this right the queue name becomes a hard-coded value tied to the message type which is what I thought we were getting away from. I tied the queue name to a "when" block so we could add logic as needed to short circuit default behavior based on message content. If it's baked into the data class for a given message type then isn't it still hard coded?

copied from slack for observability

looking at the PR comment. I think I get what you're after now and yes I misunderstood the intent.
I thought the ask was to make is so a - for example - a "route" queue message could be put on the "translation" queue.
What I'm understanding now is that no we don't want that. What we want is for the "route" processing step to be able to produce different kinds of queue messages vs having the kind of queue message that results from that processing always being one thing.
NEW
[9:25]
I may still need a huddle but assuming I've got :this-forever:  right let me go back and look at the code for a bit and think on it. I can then come to you with thoughtful intelligent questions and save us both some time.
Arnej Duranović
9:26 AM
What we want is for the "route" processing step to be able to produce different kinds of queue messages vs having the kind of queue message that results from that processing always being one thing. yep, this is correct
davidholiday
9:26 AM
ok cool. apologies for the misunderstanding and I get the ask now
:raised_hands:
1
9:26
lemmie stare at the code and see what I can come up with

replaced by https://github.com/CDCgov/prime-reportstream/pull/15613. Closing.


[Snyk] Fix for 72 vulnerabilities

Snyk has created this PR to fix 72 vulnerabilities in the maven dependencies of this project.
Snyk changed the following file(s):

api/pacman-api-compliance/pom.xml

Vulnerabilities that will be fixed with an upgrade:

Issue
Score
Upgrade

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-608664
  780
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  Reachable Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-450917
  705
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found Mature

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-467015
  675
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found Mature

Denial of Service (DoS) SNYK-JAVA-COMFASTERXMLJACKSONCORE-3038426
  670
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  Reachable Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1054588
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056416
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056418
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056420
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056421
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056426
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056427
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-174736
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-548451
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-559094
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-559106
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-560762
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-561585
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found Proof of Concept

HTTP Request Smuggling SNYK-JAVA-IONETTY-543490
  600
com.amazonaws:aws-java-sdk:  1.12.234 -> 1.12.767  No Path Found Proof of Concept

HTTP Request Smuggling SNYK-JAVA-IONETTY-543669
  600
com.amazonaws:aws-java-sdk:  1.12.234 -> 1.12.767  No Path Found Proof of Concept

HTTP Request Smuggling SNYK-JAVA-IONETTY-6056419
  600
com.amazonaws:aws-java-sdk:  1.12.234 -> 1.12.767  No Path Found Proof of Concept

HTTP Request Smuggling SNYK-JAVA-IONETTY-1317097
  595
com.amazonaws:aws-java-sdk:  1.12.234 -> 1.12.767  No Path Found Mature

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1009829
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1047324
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056414
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056417
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056419
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056424
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056425
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-467016
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-560766
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-561362
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-561373
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-561586
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-561587
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-564887
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-564888
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-570625
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-572300
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-572314
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-572316
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-72448
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-72449
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-72450
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-72451
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-72882
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-72883
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-72884
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

XML External Entity (XXE) Injection SNYK-JAVA-COMFASTERXMLJACKSONCORE-1048302
  560
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1052449
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1052450
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1061931
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-455617
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-467014
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-469674
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-469676
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-471943
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-472980
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-540500
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-6056407
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

HTTP Request Smuggling SNYK-JAVA-IONETTY-469234
  550
com.amazonaws:aws-java-sdk:  1.12.234 -> 1.12.767  No Path Found Proof of Concept

Denial of Service (DoS) SNYK-JAVA-COMFASTERXMLJACKSONCORE-2421244
  525
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Denial of Service (DoS) SNYK-JAVA-COMFASTERXMLJACKSONDATAFORMAT-1047329
  525
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Allocation of Resources Without Limits or Throttling SNYK-JAVA-SOFTWAREAMAZONION-6153869
  525
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found No Known Exploit

Denial of Service (DoS) SNYK-JAVA-COMFASTERXMLJACKSONCORE-3038424
  520
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-450207
  520
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.767  No Path Found Proof of Concept

Allocation of Resources Without Limits or Throttling SNYK-JAVA-IONETTY-6483812
  490
com.amazonaws:aws-java-sdk:  1.12.234 -> 1.12.767  No Path Found Proof of Concept

Directory Traversal SNYK-JAVA-COMAMAZONAWS-2952700
  475
com.amazonaws:aws-java-sdk:  1.12.234 -> 1.12.767  No Path Found No Known Exploit

Denial of Service (DoS) SNYK-JAVA-IONETTY-1020439
  475
com.amazonaws:aws-java-sdk:  1.12.234 -> 1.12.767  No Path Found No Known Exploit

HTTP Request Smuggling SNYK-JAVA-IONETTY-2314893
  475
com.amazonaws:aws-java-sdk:  1.12.234 -> 1.12.767  No Path Found No Known Exploit

Denial of Service (DoS) SNYK-JAVA-IONETTY-5725787
  475
com.amazonaws:aws-java-sdk:  1.12.234 -> 1.12.767  No Path Found No Known Exploit

Information Disclosure SNYK-JAVA-IONETTY-1070799
  460
com.amazonaws:aws-java-sdk:  1.12.234 -> 1.12.767  No Path Found No Known Exploit

Information Disclosure SNYK-JAVA-IONETTY-1082235
  460
com.amazonaws:aws-java-sdk:  1.12.234 -> 1.12.767  No Path Found No Known Exploit

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
Max score is 1000. Note that the real score may have changed since the PR was raised.
This PR was automatically created by Snyk using the credentials of a real user.

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
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Directory Traversal
🦉 Deserialization of Untrusted Data
🦉 XML External Entity (XXE) Injection
🦉 More lessons are available in Snyk Learn

Checkmarx One – Scan Summary & Details – b90230a4-8887-49c2-8ee0-ea7d86a58ba2
New Issues

Severity
Issue
Source File / Package
Checkmarx Insight

CVE-2024-38996
Npm-ag-grid-community-29.3.5
Vulnerable Package

CVE-2023-34050
Maven-org.springframework.amqp:spring-amqp-2.0.5.RELEASE
Vulnerable Package

CVE-2024-29415
Npm-ip-1.1.9
Vulnerable Package

CVE-2024-29857
Maven-org.bouncycastle:bcprov-jdk15on-1.67
Vulnerable Package

CVE-2024-29857
Maven-org.bouncycastle:bcprov-jdk15on-1.56
Vulnerable Package

CVE-2024-30171
Maven-org.bouncycastle:bcprov-jdk15on-1.67
Vulnerable Package

CVE-2024-30171
Maven-org.bouncycastle:bcprov-jdk15on-1.56
Vulnerable Package

CVE-2024-30172
Maven-org.bouncycastle:bcprov-jdk15on-1.56
Vulnerable Package

CVE-2024-30172
Maven-org.bouncycastle:bcprov-jdk15on-1.67
Vulnerable Package

CVE-2024-37891
Python-urllib3-1.25.11
Vulnerable Package

CVE-2024-6484
Maven-org.webjars:bootstrap-3.3.2
Vulnerable Package

CVE-2024-6485
Maven-org.webjars:bootstrap-3.3.2
Vulnerable Package

Cleartext_Submission_of_Sensitive_Information
/lambda-functions/notification-es-logging-service/src/main/java/com/paladincloud/notification_log/config/AuthManager.java: 44
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/lambda-functions/notification-es-logging-service/src/main/java/com/paladincloud/notification_log/config/AuthManager.java: 44
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-rule-engine-2.0/src/main/java/com/tmobile/pacman/commons/autofix/manager/AuthManager.java: 41
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-aqua-enricher/src/main/java/com/tmobile/cso/pacman/aqua/jobs/AquaDataImporter.java: 37
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-rule-engine-2.0/src/main/java/com/tmobile/pacman/commons/autofix/manager/AuthManager.java: 41
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-rule-engine-2.0/src/main/java/com/tmobile/pacman/commons/autofix/manager/AuthManager.java: 41
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-asset/src/main/java/com/tmobile/pacman/api/asset/service/AssetServiceImpl.java: 856
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-rule-engine-2.0/src/main/java/com/tmobile/pacman/executor/PolicyExecutor.java: 141
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-rule-engine-2.0/src/main/java/com/tmobile/pacman/executor/PolicyExecutor.java: 141
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/gcp-discovery/src/main/java/com/tmobile/pacbot/gcp/inventory/auth/GCPCredentialsProvider.java: 281
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/azure-discovery/src/main/java/com/tmobile/pacbot/azure/inventory/auth/AzureCredentialProvider.java: 72
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/azure-discovery/src/main/java/com/tmobile/pacbot/azure/inventory/auth/AzureCredentialProvider.java: 67
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/gcp-discovery/src/main/java/com/tmobile/pacbot/gcp/inventory/auth/GCPCredentialsProvider.java: 281
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/azure-discovery/src/main/java/com/tmobile/pacbot/azure/inventory/auth/AzureCredentialProvider.java: 72
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/azure-discovery/src/main/java/com/tmobile/pacbot/azure/inventory/auth/AzureCredentialProvider.java: 67
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/service/AmazonCognitoConnector.java: 121
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-vulnerability/src/main/java/com/tmobile/pacman/api/vulnerability/service/VulnerabilityService.java: 973
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/gcp-discovery/src/main/java/com/tmobile/pacbot/gcp/inventory/auth/GCPCredentialsProvider.java: 281
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/azure-discovery/src/main/java/com/tmobile/pacbot/azure/inventory/auth/AzureCredentialProvider.java: 72
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/azure-discovery/src/main/java/com/tmobile/pacbot/azure/inventory/auth/AzureCredentialProvider.java: 67
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/gcp-discovery/src/main/java/com/tmobile/pacbot/gcp/inventory/auth/GCPCredentialsProvider.java: 143
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/gcp-discovery/src/main/java/com/tmobile/pacbot/gcp/inventory/auth/GCPCredentialsProvider.java: 144
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-data-shipper/src/main/java/com/tmobile/cso/pacman/datashipper/util/AssetGroupUtil.java: 391
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-data-shipper/src/main/java/com/tmobile/cso/pacman/datashipper/util/AssetGroupUtil.java: 373
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-data-shipper/src/main/java/com/tmobile/cso/pacman/datashipper/util/AssetGroupUtil.java: 391
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-data-shipper/src/main/java/com/tmobile/cso/pacman/datashipper/util/AssetGroupUtil.java: 373
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-data-shipper/src/main/java/com/tmobile/cso/pacman/datashipper/util/AssetGroupUtil.java: 391
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-data-shipper/src/main/java/com/tmobile/cso/pacman/datashipper/util/AssetGroupUtil.java: 373
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/controller/AccountsController.java: 59
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/controller/AccountsController.java: 59
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/controller/AccountsController.java: 59
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/controller/AccountsController.java: 59
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/controller/AccountsController.java: 59
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/lambda-functions/notification-template-formatter-service/src/main/java/com/paladincloud/HttpUtil.java: 154
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/lambda-functions/notification-send-email-service/src/main/java/com/paladincloud/utils/HttpUtil.java: 152
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/controller/AccountsController.java: 59
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/QualysAccountServiceImpl.java: 132
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/QualysAccountServiceImpl.java: 125
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-data-shipper/src/main/java/com/tmobile/cso/pacman/datashipper/util/AuthManager.java: 22
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AquaAccountServiceImpl.java: 125
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/TenableAccountServiceImpl.java: 119
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 20540
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 20540
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 20540
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 20540
Attack Vector

Client_Potential_XSS
/webapp/src/app/shared/searchable-dropdown/searchable-dropdown.component.ts: 142
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 21841
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 21838
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 21831
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 21828
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 21825
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 21822
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger.js: 63
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 20550
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 20547
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AbstractAccountServiceImpl.java: 111
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AbstractAccountServiceImpl.java: 106
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AbstractAccountServiceImpl.java: 111
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AbstractAccountServiceImpl.java: 106
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AquaAccountServiceImpl.java: 151
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AquaAccountServiceImpl.java: 154
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AquaAccountServiceImpl.java: 151
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AquaAccountServiceImpl.java: 154
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AquaAccountServiceImpl.java: 151
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AquaAccountServiceImpl.java: 154
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AquaAccountServiceImpl.java: 151
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AquaAccountServiceImpl.java: 154
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AbstractAccountServiceImpl.java: 111
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AbstractAccountServiceImpl.java: 106
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AbstractAccountServiceImpl.java: 111
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AbstractAccountServiceImpl.java: 106
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/controller/AccountsController.java: 59
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AbstractAccountServiceImpl.java: 89
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AwsAccountServiceImpl.java: 213
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AwsAccountServiceImpl.java: 216
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/QualysAccountServiceImpl.java: 155
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/QualysAccountServiceImpl.java: 158
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AquaAccountServiceImpl.java: 151
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AquaAccountServiceImpl.java: 154
Attack Vector

Privacy_Violation

More results are available on AST platform