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.

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

Multipart mime 3487 v18 #9424

Closed
wants to merge 8 commits into from

Conversation

catenacyber
Copy link
Contributor

@catenacyber catenacyber commented Aug 31, 2023

Link to redmine ticket:
https://redmine.openinfosecfoundation.org/issues/3487

Describe changes:

  • convert HTTP to use new rust mime parser
  • convert SMTP to use new rust mime parser

Follows #9038 with rebase and squash

Still to do by me :

  • check the QA
SV_BRANCH=pr/1369

SV tests from unit tests in OISF/suricata-verify#1369

@suricata-qa
Copy link

ERROR:

ERROR: QA failed on SURI_TLPW1_files_sha256.

Pipeline 15791

@@ -0,0 +1,605 @@
/* Copyright (C) 2021 Open Information Security Foundation
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2023? Or did you write this initially in 2021?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wrote it in 2021 ...

escaping = true;
} else {
if input[i] == b'"' && !escaping {
return Ok((&input[i + 1..], &input[..i]));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could unicode mess with this. I recently ran into this: jasonish/suricatax-rule-parser-rs@d77c4e3

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a buffer &[u8] not a string, so there is no need to worry about unicode, right ?

@jasonish
Copy link
Member

We should probably think about the name space in new code. The rs_ prefix has got to go for extern functions. These form the externally linkable API (public or not) and should live behind a consistent prefix. While that discussion seems a bit ongoing, SC is in common use now.

Also, since these Rust functions are part of the C API, they should probably follow the convention of SCSomeTitleCase.

But maybe we should wait for some further discussion on this.

@catenacyber
Copy link
Contributor Author

We should probably think about the name space in new code. The rs_ prefix has got to go for extern functions. These form the externally linkable API (public or not) and should live behind a consistent prefix. While that discussion seems a bit ongoing, SC is in common use now.

Also, since these Rust functions are part of the C API, they should probably follow the convention of SCSomeTitleCase.

But maybe we should wait for some further discussion on this.

Let me know if I need to do more renaming :-)

@catenacyber
Copy link
Contributor Author

Replaced by #9436

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants