[pmg-devel] [PATCH pmg-api/pmg-gui v3]

[Stoiko Ivanov <s.ivanov@proxmox.com>]

This series replaces two previous patch-series.

v2->v3:
for the content-type matching based on magic infromation only two patches
were added that remove the fallback on the content-type header in case no
filetype could be found through magic.
The one place were I decided to fall back on header information was when
determining if a mime-part is an archive.

places where the content-type information was used are based on grepping
for PMX_ in the pmg-api sources.

Tested with Friedrich's swaks reproducer - the random blob was not
detected as pdf anymore.

no changes to the series for matching headers only on the top-part
(resending so that the comment that it's based on v2 of the content-type
series does not cause confusion)

original cover-letters:

for https://lore.proxmox.com/pmg-devel/20250218135416.54504-1-s.ivanov@proxmox.com/T/#t

v1->v2:
Based on Domink's feedback reworked the series - it now offers only one
optional new attribute for the content-type filter ('only-content') to
indicate that it should only compare the content-type obtained via
magic/file-conents. The other 2 match options can already be expressed
with the Filenamefilter ('application/pdf' -> '.*\.pdf') and the Match
Field filter (to match the 'Content-type' header)

original cover-letter for v1[0]:
The following patch series was started shortly after the release of PMG 8.1,
but I did not find the time to get it in shape for sending.
They follow the patches for adding 'top' and 'add_separator' to the
Disclaimer action.

The current content-type filter can sometimes surprise users (e.g.
https://bugzilla.proxmox.com/show_bug.cgi?id=5618#c2 and
https://bugzilla.proxmox.com/show_bug.cgi?id=2691#c0 ,but also a few
cases in our technical support-channels come up here and there):

It matches if any of:
* content-type header
* file-magic
* filename (extension)
match the content type, the what-object matches.
by adding an attribute for each of the sources users can restrict which
of the sources should be taken into consideration

the first patches for both repositories are independent (I just ran into
them while looking into this).

minimally tested locally, by sending a plain-text file called
testtext.pdf, and a pdf-file renamed to have a `.docx` suffix.

[0]
https://lore.proxmox.com/pmg-devel/20250212151241.91077-1-s.ivanov@proxmox.com/ 


for https://lore.proxmox.com/pmg-devel/20250218194829.80095-1-s.ivanov@proxmox.com/T/#t
based on top of:
https://lore.proxmox.com/pmg-devel/20250218135416.54504-1-s.ivanov@proxmox.com/T/#t

as I think testing both should go well together, and to avoid a trivial
merge-conflict (can of course resend on top of current master) in the
pmg-api patch

Tested minimally in my setup - more testing  would be appreciated




pmg-api:
Stoiko Ivanov (5):
  ruledb: disclaimer: simplify update-case
  utils: content-type: don't fallback to header information for magic
  pmg-smtp-filter: archive-detection: use header information as well
  ruledb: content-type: add flag for matching only based on
    magic/content
  fix #2709: ruledb: match-field: optionally restrict to top mime-part

 src/PMG/RuleDB/ArchiveFilter.pm     |  2 +-
 src/PMG/RuleDB/ContentTypeFilter.pm | 79 +++++++++++++++++++++++++----
 src/PMG/RuleDB/Disclaimer.pm        |  8 ++-
 src/PMG/RuleDB/MatchField.pm        | 47 +++++++++++++++--
 src/PMG/Utils.pm                    | 12 ++---
 src/bin/pmg-smtp-filter             |  8 ++-
 6 files changed, 129 insertions(+), 27 deletions(-)

pmg-api:
Stoiko Ivanov (3):
  rules/object: remove icon from remove button
  rules/content-typefilter: add checkbox for file content only matching
  fix #2709: rules: match-field: add top-level-only checkbox

 js/ObjectGroup.js |  3 +--
 js/Utils.js       | 17 +++++++++++++++++
 2 files changed, 18 insertions(+), 2 deletions(-)

-- 
2.39.5



_______________________________________________
pmg-devel mailing list
pmg-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel