search

ros2 / sros2

tools to generate and distribute keys for SROS 2
Apache License 2.0
89 stars 44 forks source link

Use new S/MIME API in Cryptography #239

Closed kyrofa closed 4 months ago

kyrofa commented 3 years ago

Related to #234, the Cryptography library has removed the SSL bindings for S/MIME signatures in v3.1 that we're using in the SROS2 utilities, but they are working on getting a real, official S/MIME API into a future release. We're stuck on v3.0 until they release the new API, but we need an issue to track this.

ruffsl commented 3 years ago

Will this release of the python Cryptography lib make its way into what ros2 G/Rolling is targeting? Or will we have to hold on this until either upstream updates the, or tier support ratchets up to the next OS/Distro?

kyrofa commented 3 years ago

Good question. Rolling is currently targeting Focal which has v2.8 in the archive. but ROS 2 CI is installing it from pypi and ended up needing to pin 3.0. It's possible we may end up needing to carry both, which would not be great (but is doable, we have it nicely abstracted). @dirk-thomas can you shed some light on that?

clalancette commented 3 years ago

Good question. Rolling is currently targeting Focal which has v2.8 in the archive. but ROS 2 CI is installing it from pip and ended up needing to pin on 3.0. It's possible we may end up needing to carry both, which would not be great. @dirk-thomas can you shed some light on that?

The issue for Linux is that we have no way for our debian packages to rely on pip packages to be installed (and it isn't even clear this is a capability that we would want). Debian packages can only depend on other debian packages. So we're going to have to maintain some fallback to Cryptography 2.8 until we switch to Ubuntu 22.04.

kyrofa commented 3 years ago

and it isn't even clear this is a capability that we would want

Haha, I would say not.

So we're going to have to maintain some fallback to Cryptography 2.8 until we switch to Ubuntu 22.04.

I've never quite understood why CI installs the latest and greatest instead of trying to use the same version of things everywhere :man_shrugging: . It feels like this kind of pain will be constant as a result.

clalancette commented 3 years ago

I've never quite understood why CI installs the latest and greatest instead of trying to use the same version of things everywhere man_shrugging . It feels like this kind of pain will be constant as a result.

I agree to an extent. Certainly on Linux we could just go with the packages. The problem is that we still need some solution on macOS and Windows, and there it is either going to be homebrew/chocolatey packages, or the pip installed versions. We could look into always using a pinned pip installed version to match the Linux version, but we would need to do some research into what happens if a user happens to have both the homebrew package and the pip package installed.

kyrofa commented 3 years ago

We could look into always using a pinned pip installed version to match the Linux version

Yeah that's what I was thinking.

dirk-thomas commented 3 years ago

Whatever the path forward might be (only debs, pinned pip, ...) atm build.ros2.org will have only the Debian packages installed and ci.ros2.org will have the latest version installed via pip. So for now sros2 needs to support both versions of cryptography - 2.8 from deb and the latest version (hopefully soon to be released after iterating with upstream on re-adding the removed API).

ros-discourse commented 3 years ago

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/ros-2-tsc-meeting-agenda-2020-09-17/16464/1

clalancette commented 4 months ago

Fixed by #290, so closing.