cron.py TypeError: memoryview: a bytes-like object is required, not 'str' #63

When trying to run the cronjob I get error:

Traceback (most recent call last):
  File "/usr/local/bin/gpgmw-cron.py", line 83, in <module>
    if GnuPG.confirm_key(row[0], row[2]):
  File "/usr/local/lib/python3.9/dist-packages/GnuPG/__init__.py", line 87, in confirm_key
    result = p.communicate(input=content)[1]
  File "/usr/lib/python3.9/subprocess.py", line 1134, in communicate
    stdout, stderr = self._communicate(input, endtime, timeout)
  File "/usr/lib/python3.9/subprocess.py", line 1961, in _communicate
    input_view = memoryview(self._input)
TypeError: memoryview: a bytes-like object is required, not 'str'

I've pushed a change that should fix it - please give it a try and let me know if it works now. I've only modified cron.py to make it work. I'll clean it up with a separate change.

Now I'm getting the following error from the cron.py script:

Traceback (most recent call last):
  File "/opt/lacre/gpg-mailgate-web/cron.py", line 138, in <module>
    send_msg( "PGP key registration failed", "registrationError.md", row[2] )
  File "/opt/lacre/gpg-mailgate-web/cron.py", line 77, in send_msg
    authenticate_maybe(smtp)
  File "/opt/lacre/gpg-mailgate-web/cron.py", line 61, in authenticate_maybe
    smtp.login(cfg['smtp']['username'], cfg['smtp']['password'])
  File "/usr/lib/python3.9/smtplib.py", line 734, in login
    raise last_exception
  File "/usr/lib/python3.9/smtplib.py", line 723, in login
    (code, resp) = self.auth(
  File "/usr/lib/python3.9/smtplib.py", line 646, in auth
    raise SMTPAuthenticationError(code, resp)
smtplib.SMTPAuthenticationError: (535, b'5.7.8 Error: authentication failed: UGFzc3dvcmQ6')

@muppeth: could you take a look and give me a hint what is going on?

I've set debuglevel=999 for smtplib in cron.py (line 77) to investigate but I'm lost. I suspect it'll make more sense to you @muppeth.

With the mail part working, I've tried debugging it again and found that in confirm_key, we need to set permissions for the temporary directory.

This issue (and some others) have been fixed with #64.