Live data from Hacker News

Openrsync: An implementation of rsync, by the OpenBSD team

github.com

51–60 of 193 posts

Re: Openrsync: An implementation of rsync, by the OpenBSD team

#51
post #28

rsync has specific running modes for the super-user. It also pumps arbitrary data from the network onto your file-system. openrsync is about 10 000 lines of C code: do you trust me not to make mistakes? No, but that's why almost nobody runs it outside of strict trust boundaries. This security section would make more sense if rsync was like curl, which routinely deals with hostile counterparties. If the other side of…

> almost nobody runs it outside of strict trust boundaries. I guess you can define "strict" however you want, but from what I saw ~10 years ago, most linux distros handled mirroring with rsync. That's a lot of usage in a pretty core part of the foundational open source ecosystem.

Many distros use rsync for that but also support unencrypted HTTP.

They’re layering on checksums and signing such that they mostly don’t think about the trustworthiness of mirrors or the networks between them.

Re: Openrsync: An implementation of rsync, by the OpenBSD team

#52
post #28

rsync has specific running modes for the super-user. It also pumps arbitrary data from the network onto your file-system. openrsync is about 10 000 lines of C code: do you trust me not to make mistakes? No, but that's why almost nobody runs it outside of strict trust boundaries. This security section would make more sense if rsync was like curl, which routinely deals with hostile counterparties. If the other side of…

> almost nobody runs it outside of strict trust boundaries. I guess you can define "strict" however you want, but from what I saw ~10 years ago, most linux distros handled mirroring with rsync. That's a lot of usage in a pretty core part of the foundational open source ecosystem.

OK, I agree, that's bad.

Re: Openrsync: An implementation of rsync, by the OpenBSD team

#54
post #29
post #18

The actual work of porting is matching the security features provided by OpenBSD's pledge(2) and unveil(2). These are critical elements to the functionality of the system. Without them, your system accepts arbitrary data from the public network. https://justine.lol/pledge/ I am not seeing pledge on Alpine Linux in edge. Have people been testing Pledge on Linux? Did I perhaps misunderstand the risk of using Openrsync…

From above your quote: > The only officially-supported operating system is OpenBSD, as this has considerable security features. And below your quote: > This is possible (I think?) with FreeBSD's Capsicum, but Linux's security facilities are a mess, and will take an expert hand to properly secure. It is portable in the sense that it compiles and runs, not in the sense that it has the same security features. I'd love t…

> I'd love to see pledge/unveil on (upstream) Linux - but I'm not holding my breath

There is Landlock now, I believe it would be possible to implement unveil and pledge on top of that.

Re: Openrsync: An implementation of rsync, by the OpenBSD team

#55
post #12
post #8

Earlier quoted context omitted.

+1 to this. Other than people's reflexive anger or fear about AI coming for their code, I don't see anything to suggest that these are bugs that are due to the inclusion of AI vs bugs in a program with a bunch of complex interop with the filesystem and network.

In any case, it's important to identify projects that are beginning to actively vibecode and clearly express position on this issue on various platforms so that authors and maintainers receive feedback. Even if this particular bug was not written by LLM in this particular case, it's not a fact that the release does not include other regressions and that subsequent vibecoded versions will not include them & new ones.

Friendly reminder that volunteer maintainers owe you literally not a single goddamn thing. I absolutely want no AI slop in my commercial products that I pay money for, but your feedback is not important to people you are not paying to develop software for you. They gave away not only their software but the source code for free; if you have a problem with it, fork it. Which is something you can do with their generous allowance, and that is an allowance any maintainer can instead choose to not bother themselves with if publishing their code for free leads themselves to dealing with entitled internet commenters harassing them with complaints.

Re: Openrsync: An implementation of rsync, by the OpenBSD team

#56

Earlier quoted context omitted.

Not many are reimplementations of existing, much more popular, already open source projects.

OpenSSH was a 'reaction' to the original SSH(.com) code getting closed source: > OpenSSH originated in 1999 as a fork of Björn Grönvall's OSSH, which derived from Tatu Ylönen's original SSH 1.2.12 release, the last version distributed under a license permitting open-source redistribution before Ylönen's subsequent software became proprietary under SSH Communications Security.[4] * https://en.wikipedia.org/wiki/OpenSS…

Is rsync going closed source? If not, how is that the same thing?

Re: Openrsync: An implementation of rsync, by the OpenBSD team

#57

Earlier quoted context omitted.

I feel bad for people with the real name Claude.

It took me quite some time to realize what an utterly presumptuous product name Claude Code actually is, but only because Shannon is rarely mentioned with his first name. It's golden calf levels of hubris, even more so if you consider how incapable it was on release. It's like renaming calc.exe Einstein. Incredibly poor taste, but entirely in line with AI tech bro mentality.

That linkage never occurred to me, or, I suspect, them. Claude use to be a reasonably common name. I have an uncle Claude. Why do you believe they named it after Shannon in particular?

Re: Openrsync: An implementation of rsync, by the OpenBSD team

#58
post #9

Earlier quoted context omitted.

OpenBSD folks would consider the GPL to be less open due to the requirement to apply the GPL to any derivative works.

And GNU folks would say the GPL is actually the more open choice because it forces the project to stay open. Two different ways of thinking about it I guess... it's nice to have choices and I don't think one is more or less "correct", more a matter of opinion/taste I guess.

It kind of reminds me of the equality of opportunity people versus the equality of outcome people. One sets the starting conditions for developers, the other the ending conditions for users.

Re: Openrsync: An implementation of rsync, by the OpenBSD team

#59

Earlier quoted context omitted.

OpenSSH was a 'reaction' to the original SSH(.com) code getting closed source: > OpenSSH originated in 1999 as a fork of Björn Grönvall's OSSH, which derived from Tatu Ylönen's original SSH 1.2.12 release, the last version distributed under a license permitting open-source redistribution before Ylönen's subsequent software became proprietary under SSH Communications Security.[4] * https://en.wikipedia.org/wiki/OpenSS…

Is rsync going closed source? If not, how is that the same thing?

No. The name only means it’s made by the OpenBSD team, nothing more. If they made their own Python port, it’d be called OpenPython, even though the original is FOSS.

Re: Openrsync: An implementation of rsync, by the OpenBSD team

#60

Earlier quoted context omitted.

OpenSSH was a 'reaction' to the original SSH(.com) code getting closed source: > OpenSSH originated in 1999 as a fork of Björn Grönvall's OSSH, which derived from Tatu Ylönen's original SSH 1.2.12 release, the last version distributed under a license permitting open-source redistribution before Ylönen's subsequent software became proprietary under SSH Communications Security.[4] * https://en.wikipedia.org/wiki/OpenSS…

Is rsync going closed source? If not, how is that the same thing?

OpenBSD didn’t get its name from NetBSD going closed source.
Post reply on HN