Function lacre.text.is_pgp_inline can return false positive #102

New Issue

Closed

opened 2022-10-22 10:41:04 +02:00 by pfm · 3 comments

pfm commented

2022-10-22 10:41:04 +02:00

Collaborator

If somebody was exchanging email about PGP encryption and included being and end markers in the body, it would be classified as encrypted and therefore would not be encrypted by Lacre.

We need to do a smarter check for inline PGP markers. Some ideas for additional verifications:

the first marker is on the first non-blank line;
only Base64 characters follow the marker.

If somebody was exchanging email about PGP encryption and included being and end markers in the body, it would be classified as encrypted and therefore would not be encrypted by Lacre. We need to do a smarter check for inline PGP markers. Some ideas for additional verifications: 1. the first marker is on the first non-blank line; 2. only Base64 characters follow the marker.

pfm added this to the Test deployment findings milestone 2022-10-22 10:41:04 +02:00

pfm added the

BUG

label 2022-10-22 10:41:04 +02:00

pfm self-assigned this 2022-10-22 10:41:04 +02:00

Onnayaku commented

2022-10-24 08:47:17 +02:00

Contributor

Hmmm.. yeah, maybe something like that:

1 -> Only one "BEGIN" marker exist and is on the first non-blank line
2 --> Only Base64 characters follow the "BEGIN" marker until the "END" marker (ex)
3 ---> Only one "END" marker exist and is on the last non-blank line

This should help in some situations when someone put an encrypted message(s) anywhere into plain text email.

But.. if someone put a plain text (of Base64 characters only) between (1) and (3) then, well.. but why someone would do that? ..quite unusual.

I mean there can be one additional "B" step between (1) and (2) for example like:

1 -> Only one "BEGIN" marker exist and is on the first non-blank line
B --> Second and third lines after the "BEGIN" marker have 64 characters per line (ex)
2 ---> Only Base64 characters follow the "BEGIN" marker until the "END" marker (ex)
3 ----> Only one "END" marker exist and is on the last non-blank line

Of course there can be a situations when someone put multiple encrypted messages into one email, but.. but I did'nt sleep last night, so maybe I'm completely lost here :P

Edit: yeah.. I forgot about the "Charset:", "Version:" and "Comment:" lines inserted by some programs, so: (ex) = Excluding lines starting with "Charset:", "Version:" and "Comment:"

Hmmm.. yeah, maybe something like that: **1 -> Only one "BEGIN" marker exist and is on the first non-blank line 2 --> Only Base64 characters follow the "BEGIN" marker until the "END" marker (ex) 3 ---> Only one "END" marker exist and is on the last non-blank line** This should help in some situations when someone put an encrypted message(s) anywhere into plain text email. But.. if someone put a plain text (of Base64 characters only) between **(1)** and **(3)** then, well.. but why someone would do that? ..quite unusual. I mean there can be one additional **"B"** step between **(1)** and **(2)** for example like: **1 -> Only one "BEGIN" marker exist and is on the first non-blank line B --> Second and third lines after the "BEGIN" marker have 64 characters per line (ex) 2 ---> Only Base64 characters follow the "BEGIN" marker until the "END" marker (ex) 3 ----> Only one "END" marker exist and is on the last non-blank line** Of course there can be a situations when someone put multiple encrypted messages into one email, but.. but I did'nt sleep last night, so maybe I'm completely lost here :P Edit: yeah.. I forgot about the "Charset:", "Version:" and "Comment:" lines inserted by some programs, so: **(ex)** = Excluding lines starting with "Charset:", "Version:" and "Comment:"

👍 1

pfm commented

2022-10-26 19:03:21 +02:00

Author

Collaborator

I've added a test that verifies if this issue is fixed (!103).