RE: [TOPIC 01/11] Rust

[<rsbecker@nexbridge.com>]

On September 24, 2024 11:30 AM, Phillip Wood wrote:
>On 23/09/2024 13:17, rsbecker@nexbridge.com wrote:
>> On September 22, 2024 10:26 PM, Sean Allred wrote:
>>
>> The GCC dependency, which does not currently exist in git, is
>> independent of Rust. > Rust has its own rules and runtime. The issue
>> here is that the Rust team gets to decide what platforms can
>> participate, NOT the platform maintainers. No matter what my intent,
>> or resources, I cannot get the Rust team to "Allow" a port.
>> In
>> many ways, this is egregious and is a policy issue entirely on Rust, not us.
>> We
>> want to do a Rust port but are simply not allowed/approved. It is
>> their policy.
>
>I'm hearing that there is a fundamental incompatibility between some aspect of the
>NonStop platform and rust's requirements for supported platforms. Does that
>mean it is likely that rust will never be available on NonStop?

I do not know whether Rust will never be available. The policy is that the Rust
maintainers must sanction and approve any ports. I have tried to get approval
and have not been able to do so. It is not for a lack of trying. To me, this is a
serious problem because there is no "community" concept for Rust. It is either
sanctioned or denied, regardless of the desire of someone to port the code.

>> I agree that it is not a good policy to never add new dependencies.
>> However, Dependencies must be reasonable and give the platforms a
>> chance, at least, to adapt. We cannot in the case of Rust. The problem
>> is not actually that we can do without new features that are in Rust
>> but not C. The problem is when there are CVEs. Suppose a severe CVE
>> happens that is fixed in a Rust component but referenced by a C
>> component or somehow intertwined. The fix to the CVE becomes
>> unavailable and git gets thrown off the platform. That is the reality
>> of how insidious CVEs are when it meets corporate policy. I am
>> primarily trying to protect from that.
>
>In that scenario there is nothing preventing a different fix being implemented for an
>older version of git running on a platform that does not support rust. It's likely that
>such a fix would need to come from the community using that platform rather than
>upstream which would represent an additional cost for users that have previously
>been relying on the upstream to provide security updates.

This means that the community is responsible separate for CVE security fixes.
I have a major problem with that. It means that there will be separate NIST
and Mitre reports for security issues for the same case. The code will then
forever deviate and git will no longer be one product. It also means that
customers can no longer consider the official git to be available on NonStop
but will have to come from an unsanctioned community edition that will
lag behind all security fixes associated with Rust code.

>
>> Telling 10-20000 users that their core bit of infrastructure is
>> insecure and not fixable is not a tenable position. However, it is
>> hard to defend the community when the git team is hell-bent on this
>> particular decision. What do you need to understand here?
>> It is a small community with a large number of users in key financial
>> institutions that have a very conservative adoption policy and an even
>> more conservative hardware vendors.
>
>I'm struggling to understand why such a conservative community needs access to
>the latest version of git. I'd have thought that key financial institutions should be
>able to fund someone to backport security updates to their critical systems.

The community does not need access to the latest version. It *does* need
access to security fixes made in response to CVE reports. As above, being
able to backport security fixes means that git is no longer officially the
same, nor can be verified as legitimate once this is done.

>
>> Again, it is not the gcc dependency. We have been coping with c99 and
>> will have c11 shortly. It is Rust itself that is exclusionary. It
>> might be easier to write new functionality in Rust - it is easier in
>> Java, Perl, and Python too. Why Rust? Because someone wants it, not
>> because you cannot implement the functionality.
>
>It may be true in theory that anything one can write in rust could be written in C
>instead but in I'm not sure it is true in practice. In previous discussions multi-
>threading has been mentioned as an example of something that is sufficiently
>difficult to get right in C that contributors are not willing to implement whereas they
>would be happy to do so in rust.

My position, as a professional product manager, is that such changes should not
be approved.

>
>I believe that those advocating for using rust are doing so because they believe it will
>benefit both contributors and users. The problem we have to wrestle with is
>whether those benefits outweigh the cost to the relatively small proportion of users
>who do not have access to rust on their platform.

I would be very happy to have Rust on the platform. I do not control the situation
even if I have the skill to do the port. This is entirely unfair, in my opinion, to the
community maintainers, (me for one) who are going to end up doing far more
work for free than anyone else.

I am sorry to disagree, but I cannot see any way around the problem that makes
sense. I have been the NonStop maintainer since 2016, and feel like I am being
now being thrown under a bus outside of any of my control. If there is a way to
solve this, without this becoming my full time (for free) job, I would consider it.
(Note that the git license (GPL) requires me to contribute my changes, so it is
being done for free even if I find a way to charge for it.) Honestly, is that
reasonable?