Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add description #2

Closed
bartblaze opened this issue Dec 30, 2019 · 2 comments
Closed

Add description #2

bartblaze opened this issue Dec 30, 2019 · 2 comments

Comments

@bartblaze
Copy link
Contributor

Could a description for the repo be added? E.g. same like before but changed URL:

Malware Configuration And Payload Extraction https://capesandbox.com

Not super-important, but would be nice to add. Thank you!
@doomedraven
Copy link
Collaborator

i was looking to do that but i don't have rights, @kevoreilly can you add this?

@kevoreilly
Copy link
Owner

Done - thanks for the reminder.

@doomedraven doomedraven mentioned this issue Sep 15, 2020
Closed
4 tasks
@doomedraven doomedraven mentioned this issue Aug 22, 2021
Closed
klingerko pushed a commit to EmergingThreats/CAPEv2 that referenced this issue Oct 18, 2021
@zoomequipd
Merge pull request kevoreilly#2 from klingerko/cents_taskid
4b81537 
add link to analysis to rule reference
nbargnesi added a commit to nbargnesi/CAPEv2 that referenced this issue Feb 9, 2023
@nbargnesi
simplify update_cape_configs and update tests
23ad8f1 
Ideally key collisions across multiple configs could combine data, so
multiple values could be generated across configs.

For example, config kevoreilly#1 generates the following:
    {"cfg1": {"key": "value1"}

While config kevoreilly#2 generates:
    {"cfg1": {"key": "value2"}

And their combined config becomes:
    {"cfg1": {"key": ["value1", "value2"]}}

The existing behavior is to let the last config win on key
collisions, resulting instead in:
    {"cfg1": {"key": "value2"}}

So reflect that in the new test coverage, and simplify the config update
method by forwarding the cape_name.
nbargnesi added a commit to nbargnesi/CAPEv2 that referenced this issue Feb 9, 2023
@nbargnesi
simplify update_cape_configs and update tests
2bcb167 
Ideally key collisions across multiple configs could combine data, so
multiple values could be generated across configs.

For example, config kevoreilly#1 generates the following:
    {"cfg1": {"key": "value1"}

While config kevoreilly#2 generates:
    {"cfg1": {"key": "value2"}

And their combined config becomes:
    {"cfg1": {"key": ["value1", "value2"]}}

The existing behavior is to let the last config win on key
collisions, resulting instead in:
    {"cfg1": {"key": "value2"}}

So reflect that in the new test coverage, and simplify the config update
method by forwarding the cape_name.
doomedraven pushed a commit that referenced this issue Feb 9, 2023
@nbargnesi
add tests for config updates, simplify the update, and log the potent…
a0ef25e 
…ial for data loss (#1357)

* add config update test coverage, part 1

These tests are known to pass based on the current implementation of
update_cape_configs.

* add config update test coverage, part 2

This test is known to fail based on the current implementation of
update_cape_configs.

* run python-package workflow on all branches

* simplify update_cape_configs and update tests

Ideally key collisions across multiple configs could combine data, so
multiple values could be generated across configs.

For example, config #1 generates the following:
    {"cfg1": {"key": "value1"}

While config #2 generates:
    {"cfg1": {"key": "value2"}

And their combined config becomes:
    {"cfg1": {"key": ["value1", "value2"]}}

The existing behavior is to let the last config win on key
collisions, resulting instead in:
    {"cfg1": {"key": "value2"}}

So reflect that in the new test coverage, and simplify the config update
method by forwarding the cape_name.

* log the potential for data loss

* less ruff now

* Revert "run python-package workflow on all branches"

This reverts commit 4868ffa.

* link test coverage to #1357

---------

Co-authored-by: Nick Bargnesi
@jacker31 jacker31 mentioned this issue Aug 26, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@doomedraven @bartblaze @kevoreilly