Engine/EngineBreakfast/Log_20220127

Dev Meeting 27.1.2022

pEpJSONAdapter

  • roker leaving, needs new maintainer/owner

Positron takes it for now.

libpEpDatatypes

Heck is taking over this component.

https://pad.pep.security/UVrTBa6qQsKudhCNCmQM7A# -> fdik says still valid

fdik: specs were unclear and the current impl is not delivering what was expected. fdik spec example:

// std::vector<...> <-> pEp::list<::pEp_identity>

pEp::list<::pEp_identity, ::identity_list> ident;
 
ident[0].c_data; // const ::pEp_identity*
ident[0].m_data; // ::pEp_identity*
ident.m_data; // ::identity_list*

heck to clarify more spec with fdik as needed.

Windows-builds

Who will be doing windows-build for:

  • pEpEngine (used to be Thomas)
  • pEpSequoiaBackend (never had a windows build so far)
  • libpEpAdapter (used to be thomas)
  • pEpJSONServerAdapter (pEpComServerAdapter used to be thomas)
  • pEpJNIAdapter (never had a windows build so far)
  • pEpPythonAdapter (never had a windows build so far - volker wants to do that)

Antonio (Team Lead) and Alex (Andreas Team) are candidates. Components owners in need for a windows-build please ask them. Jörg might be able to take over pEpJSONServerAdapter - we need to ask him.

Version Migration Roadmaps (2.1 / 2.2 / 3.x)

  • Steps towards 3.x for each Application TBD
  • pEp4Email (currently 2.1)
  • pEp4FM (currently 2.1)
  • DPE (currently 2.1)
  • pEp4Ipsec (currently 3.2)

The apps cannot use 3.x currenly, because all tests will break and there is a lot of effort needed to port the apps to 3.x. To solve this problem, we divide it into a sub-problem called KER. We are developing a version 2.2 which is 2.1 plus KER. Apps are expected to migrate to 2.2 ASAP.

If the app needs a feature of 3.x, they need to ask for a release/RC. The apps are NOT allowed to use unreleased versions (or master branch). On 3.2 we do not have an RC yet, and currently cant provide one. That means the apps cannot use anything from 3.2 yet. They first need to go through 2.2 and the 3.2 RC needs to be ready. If they need anything from 3.2 currently, they will need to request it to be backported to 2.1 (or 2.2)

pEpJNIAdapter ASN1 Codec

  • Done in master branch (3.x)
  • DPE (huss) cant use it, because 3.x now uses pEpSequoiaBackend
    • -> Huss cant use 3.x, he will need to request ASN1 Codec to be backported (luca is creating the ticket already, actually)

pEpSequoiaBackend Delivery

  • Improves performance and memory issues
  • pEp4FM is the main use case
  • Roadmap for delivery TBD
    • pEp4FM currently on 2.1
    • Cant deliver to 2.1 because of windows-build issues
    • fdik: every component needs to support all supported platforms in order to get used.
  • Problems in the component:
    • make install missing -> needs ticket
    • https://gitea.pep.foundation/pEp.foundation/pEpEngineSequoiaBackend/issues/4 - ‘Build issues on Windows’
  • fdik: Sequoia removed their make install target.
  • fdik suggests to add make install for sequoia to the pEpEngine itself.