python-cryptography >= 3.4.0 and Rust

Allen Hewes allen@decisiv.com
Mon Feb 7 04:02:12 GMT 2022


> -----Original Message-----
> From: Cygwin-apps <cygwin-apps-bounces+allen=decisiv.com@cygwin.com>
> On Behalf Of Marco Atzeri
> Sent: Friday, February 4, 2022 4:28 PM
> To: cygwin-apps@cygwin.com
> Subject: Re: python-cryptography >= 3.4.0 and Rust
>
> On 04.02.2022 16:28, Allen Hewes wrote:
> >> -----Original Message-----
>
> >>>
> >>> Welp, then the wheels came off. I am assuming that Cygwin's python-
> >> cryptography is still at 3.3.2 b/c of this Rust issue?
> >>>
> >>
> >> Hi Allen,
> >> it is correct. I released the last version that was still on C
> >>
> >
> > It's still on C but the authors have been adding new features in Rust. They
> are using the Python Rust API bridge for the integration between the two.
> >
>
> It seems not an optional feature, without a Rust compiler it can not be built
>

Or perhaps the build process could be changed to exclude the Rust bits? I don't know if this possible or not or what it would mean to exclude them. Just thinking out loud.

> >>> Rust is making more in-roads into software I use frequently or like
> >>> to use. Is
> >> there any efforts or discussions about getting Rust able to target Cygwin?
> >>
> >> Not that I aware of.
> >> We have already problem to update clang that is already behind.
> >>
> >
> > Many of the shiny new sysadmin/sysutils are written in Rust or Go.
> >
> > The reason why I brought up python cryptography and Cygwin is that the
> current version of python cryptography doesn't support OpenSSL 3 (AFAIK).
> Only the most recent cryptography does. At some point in the future, this
> will have to be addressed, wouldn't it (IMHO)? Python cryptography is
> fundamental in the Python ecosystem. Pythonistas who use Cygwin will
> need an update to cryptography. How can this happen?
>
>    "Somebody Has To Do It"  https://cygwin.com/acronyms/#SHTDI
>
> but I do not volounteer ...
>

No suggestion to you or others to work on it was intended. I was asking more rhetorically to start a conversation about what the effort might look like b/c maybe I could contribute. If the only acceptable effort for Cygwin is to port Rust, I can't contribute in a meaningful way. But if there are other ideas (even crazy ones), I might be able to contribute.

> >> Rust and Go are purely wish, they both requires specific expertize and
> time.
> >>
> >
> > ...except for then those languages make in-roads into the bits/ecosystem
> that Cygwin has packaged/supported (for a long time in some cases). From
> what I can tell, these ecosystems think WSL/WSL2 is their "best effort" for
> Linux-y (or POSIX) on Windows.
> >
> >> Feel free to work on it
> >
> > Based on the conversation in rigrep (a Rust grepper), it sounds like it's a
> large amount of work that would not be accepted/entertained by upstream:
> > https://github.com/BurntSushi/ripgrep/issues/269
>
> in the old past we had some discussion on cmake but finally upstream
> accepted our efforts.
>

Did Cygwin maintain their own set of patchsets for cmake? If so, for how long and for how many version upgrades (until upstream accepted them)?

/allen

________________________________

Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender.


More information about the Cygwin-apps mailing list