Log_20200526

Sync documentation
- https://dev.pep.foundation/Engine/KeySync
- https://dev.pep.foundation/Engine/TrustSync
z/OS OpenPGP backend
- https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.csdd100/abstract.htm
switch to p≡p MIME
leaving JIRA
KeyReset docs: https://dev.pep.foundation/Engine/KeyResetOverview
Krista still needs to call/mail Ben
Krista will split and document OpenPGP header
Krista has contacted Ben - we’ll chat tomorrow
OpenPGP header still not split because Krista’s still working on key import (this need for knowing changed keys touches way more code than it should - hopefully the slowdown of traversing data structures isn’t too much)
Message 2.1 doc - Kelly is supposed to be available today post-move to discuss it. I think that’s probably a little ambitious on her part, but am ready to discuss it
Heck solved the adapter/engine pass-mismatch problem (this should allow the release of meaningful version numbers with binary releases - format is <major>.<minor>.<engine_patch>.<adapter_patch> - Devan seems to agree it’s workable
Neal wants to know if we have a test to “ensure we’re sending out the public key/private key when we say we are and not the other one”; he wrote the driver and tests, so I guess I’m going to have to do something to ensure that’s tested. Which makes me nervous. Will do it as part of current work.

Heck

During the last weeks, some ideas/wishes for changes in the current JNI Adapter came up in the SWIFT team. These include:
- Exception handling
- threading model
- general abstraction level
Heck loves that the app wants to drive possibly API breaking improvements.
- Heck proposes additionally:
  - Engine “all” methods could/should be static => Volker says: “definitely not”
  - pEpJNIAdapter Design considerations (sorry its just notes) https://codimd.pep.security/pEpJNIAdapter-design-considerations
fdik: need to be static:
- getVersion()
- getProtocolVersion()

On another note:
* can we hire a requirement engineer?