Page MenuHome GnuPG

encryptionjob: Propagate encryption flags
AcceptedPublic

Authored by CarlSchwan on Fri, May 9, 8:55 AM.

Details

Summary

Otherwise job->setEncryptionFlags(GpgME::Context::AddRecipient); is a

nullopt.

Test Plan

Compiles and a reencryption job now works correctly

Diff Detail

Repository
rGPGMEQT Gpgme for Qt
Branch
work/carl/propagate-encryption-flags
Lint
No Linters Available
Unit
No Unit Test Coverage

Event Timeline

CarlSchwan created this revision.

There are two other methods that also take alwaysTrust as input and that should likely also propagate the other encryption flags.

I have a hard time to parse alwaysTrust ? Context::AlwaysTrust : Context::None | encryptionFlags() & ~Context::EncryptFile due to the lack of parentheses. Please add parentheses to help readers understand this code without having to look up operator precedence.

I don't understand why we need to remove the Context::EncryptFile flag. It seems wrong/error-prone to propagate all but one flag. The caller shouldn't have set this flag in the first place. In other words: Remove the & ~Context::EncryptFile.

Please apply the same changes to QGpgMESignEncryptJob.

I don't understand why we need to remove the Context::EncryptFile flag. It seems wrong/error-prone to propagate all but one flag. The caller shouldn't have set this flag in the first place. In other words: Remove the & ~Context::EncryptFile.

Because EncryptFile is added inconditionally to the encryptionFlags here: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgmeqt.git;a=blob;f=src/encryptjob.cpp;h=1fbc5ccfb5148ad91a652e9ddf8f383846582ffa;hb=HEAD#l113 and when calling encrypt_qba with this flag, this creates an invalid value error

Propagate encryption flags in other places

I guess

alwaysTrust ? Context::AlwaysTrust : Context::None | (encryptionFlags() & ~Context::EncryptFile)

is identical to

(alwaysTrust ? Context::AlwaysTrust : Context::None) | (encryptionFlags() & ~Context::EncryptFile)

Let's use the latter so that poor me doesn't get confused. ;-) With this change the changeset is ready for merging.

This revision is now accepted and ready to land.Fri, May 9, 4:30 PM