Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mitigating Memory Safety Issues in Open Source Software

security.googleblog.com

Post reply on HN
Print view View original

151–160 of 244 posts

Re: Mitigating Memory Safety Issues in Open Source Software

#151

Post by aaomidi »

cnfhsg wrote: post #143
chii wrote: post #49

Earlier quoted context omitted.

> control over whatever open source projects they target. but if they rewrite the project in rust, why _shouldn't_ they control that project? If other people choose to switch, then it's not wrong for them to move, and not wrong for to google gain control of those users. The original project maintainers is a third party to this whole process, and i would argue, is uninvolved tbh. It is up to the users of the project t…

If you translate an existing project into Rust, it is a derivative work and should retain the original license. If the rewritten project gets more successful than the original (perhaps due to corporate promotion), you have morally stolen the work of the original authors. If you write a project from scratch without looking, this of course does not apply. But I doubt that is how Rust rewrites actually happen, the tempt…

> If the rewritten project gets more successful than the original (perhaps due to corporate promotion), you have morally stolen the work of the original authors.

Ownership is by "moral" definition something completely arbitrary and made up.

If you work in open-source you most likely have different views on ownership than others.

Re: Mitigating Memory Safety Issues in Open Source Software

#152

Post by kbenson »

bobcallme wrote: post #150

The more pressing issue is the fact that critical tools that we depend upon are not properly funded or the incentive to properly maintain them is simply not there. Many of these projects were started as pet projects in peoples spare time. Sure, Google gives a lot of money and contributes to some of these projects but their contributions do not match how much they depend upon them. This is all compounded by the fact t…

> In the case of Rust, I am tired of people evangelizing it when it's plagued with issues that undermine its goals

Do you mind explaining what you mean here? You seem to be alluding to something different than an unstable toolchain which you mention after.

Re: Mitigating Memory Safety Issues in Open Source Software

#153

Post by Tobu »

mariusor wrote: post #100
tmotwu wrote: post #99

I wonder what implications this has for C/C++ in big tech backends. Startups, from what I've seen, have already moved away. No doubt, it will still be around in low latency or embedded. However, this is a significant cut of their market share, especially if Google, Microsoft, and Amazon retires its usage in its systems.

A big chunk of the C++ development is done in game studios. I doubt they would be willing to move away from it just for memory safety's sake.

Buggy AAA releases are currently the norm, but that takes a reputational and financial toll and doesn't make for happy developers either. Cyberpunk 2077 is the latest example.

Re: Mitigating Memory Safety Issues in Open Source Software

#154

Post by adrianN »

cnfhsg wrote: post #143
chii wrote: post #49

Earlier quoted context omitted.

> control over whatever open source projects they target. but if they rewrite the project in rust, why _shouldn't_ they control that project? If other people choose to switch, then it's not wrong for them to move, and not wrong for to google gain control of those users. The original project maintainers is a third party to this whole process, and i would argue, is uninvolved tbh. It is up to the users of the project t…

If you translate an existing project into Rust, it is a derivative work and should retain the original license. If the rewritten project gets more successful than the original (perhaps due to corporate promotion), you have morally stolen the work of the original authors. If you write a project from scratch without looking, this of course does not apply. But I doubt that is how Rust rewrites actually happen, the tempt…

Now you only need a lawyer army bigger than Google's to win your case.

Re: Mitigating Memory Safety Issues in Open Source Software

#155

Post by giantandroids »

gnfargbl wrote: post #27
lrossi wrote: post #3

What is left out of the title is that they do not provide funding to the current authors/maintainers of these open source projects. Instead, they fund an organization that will rewrite these tools. Correct me if I’m wrong, but that’s my understanding of the rather terse article. I would rather have the original maintainers funded and still in control of the many pieces that form the basis of the major Linux distribut…

The article says that Google is committing funding to the ISRG ( https://abetterinternet.org ). It isn't really clear whether that is one-off funding, or the start of an ongoing relationship. The ISRG seems to have two projects of this type mentioned on its website: an improvement to curl ( https://www.abetterinternet.org/post/memory-safe-curl/ ), in which the ISRG funded the curl author directly; and an improvement…

lets encrypt are under the ISRG

Re: Mitigating Memory Safety Issues in Open Source Software

#156

Post by giantandroids »

Radim wrote: post #24

For what it's worth, I reached out to the Open Source Security Foundation (OpenSSF) after their press release on "Securing Critical Open Source Projects" [0], because my open source project is on their "critical list" (Python top #200) [1]. After some clicking around, I was directed to the OpenSSF mailing list [2]. …where my request was left to rot, without any response. Made me wonder whether this is just a PR stunt…

> …where my request was left to rot, without any response.

Hey, I am involved in the OpenSSF and happy to take at least a look. I maintain a popular python OSS project in the security area so we have that in common. Did your email actually go through, I just searched my list archives and there is nothing for gensim. EDIT: see your email now, have msg'ed the WG in slack.

> Made me wonder whether this is just a PR stunt / corporate power grab

I would not say it is, we have folks from OWASP on the technical advisory panel and many other non profit orgs / individual developers. One thing I would keep in mind, is that being a newly founded org, a lot of time has been spent working out and agreeing how we will operate, so the working groups are all still quite fresh.

Re: Mitigating Memory Safety Issues in Open Source Software

#157

Post by iwasanewt »

nick_ wrote: post #116
praptak wrote: post #42

Earlier quoted context omitted.

Also "for rewriting popular systems in Rust" is just false. The blog is about improving memory safety and gives two pieces of software rewritten in Rust as an example. There's nothing about this effort being focused on rewriting things in Rust.

HN is like 15% pro-Rust propaganda these days.

Have you considered the possibility that people might just like it?

Re: Mitigating Memory Safety Issues in Open Source Software

#158

Post by rcxdude »

TheReverend403 wrote: post #147
cnfhsg wrote: post #143

Earlier quoted context omitted.

If you translate an existing project into Rust, it is a derivative work and should retain the original license. If the rewritten project gets more successful than the original (perhaps due to corporate promotion), you have morally stolen the work of the original authors. If you write a project from scratch without looking, this of course does not apply. But I doubt that is how Rust rewrites actually happen, the tempt…

> If you translate an existing project into Rust, it is a derivative work and should retain the original license. By this logic, WINE is a derivative of Windows and should retain their license.

WINE goes to some length to avoid any reverse engineering of windows components and certainly any glimpse of the source code (such as the leaks which have happened over the years: if you have seen any of them then WINE does not want your code). They do this to avoid any accusations of their code being a derivative work. If you re-implement an open-source project on the same terms then it does not qualify as a derivative work. However if you look at the source code and use that to develop your new implementation, then that qualifies.

Re: Mitigating Memory Safety Issues in Open Source Software

#159

Post by rcxdude »

enriquto wrote: post #6

semi-conspiracy theory: the main goal of this rewriting is to have less and less infrastructure depending on GPL and AGPL-licensed code

It will take quite a lot more effort to rewrite something so that the (A)GPL doesn't stick. To do that you would need to rebuild it from its documentation and/or a clean-room reverse engineering, as opposed to a port of the source code.

Re: Mitigating Memory Safety Issues in Open Source Software

#160

Post by kimsterv »

Radim wrote: post #24

For what it's worth, I reached out to the Open Source Security Foundation (OpenSSF) after their press release on "Securing Critical Open Source Projects" [0], because my open source project is on their "critical list" (Python top #200) [1]. After some clicking around, I was directed to the OpenSSF mailing list [2]. …where my request was left to rot, without any response. Made me wonder whether this is just a PR stunt…

Unfortunately, the openssf members haven’t come to consensus on the process for handling funding requests and the process. We’ll get there (hopefully!) but it’s looking like it’s going to take more time. -Sincerely, Google’s OpenSSF governing board rep
Post reply on HN