Hacker News

> The one place in my usage where it doesn't match Samba rsync is with the following:

> openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services

This appears to match "normal" `rsync` behavior as well. I think you need a trailing slash after `services` to sync only the contents.

EDIT: actually my "normal" rsync is openrsync on macOS...

Was there already a /tmp/services directory on the dest?

One of the biggest points of confusion with rsync is how directories and trailing slashes are handled.

> I would expect openrsync to create a remote file /tmp/services, but instead it creates /tmp/services/services.

As someone who has also suffered uncountable years of abuse from rsync, I understand the impulse, but I think it makes a lot more sense (and is a safer default) to create a second ”services”.

If we have a chance to change rsync defaults to something less insane and save future generations from this mess I think we should.

If you use a trailing slash on the source it copies from the directory, if you omit the trailing slash it copies the directory itself. AFAIK this is pretty standard across POSIX tools

Was it 15.0? I seem to recall it coming in one of the minor point releases in the 15.x line - and I remember it breaking some scripts mysteriously.

EDIT: ah, fun: they did include it in 15.0, but they decided to save the breaking change that removed backwards compatibility for 15.4. https://apple.stackexchange.com/a/479297

Linux has no such features as pledge or unveil, nor capsicum. it has cgroups, namespaces and a mess ofnother things u need to combine to try and do similar things. (it was built iteratively as many systems interacting and being combined to form 'sandboxing' or isolation/limiting of capabilities rather than specific isolation as an entire concept with specific system calls and kernel paths to enable it).

there might be newer stuff in linux land now i see comments about landlock but i assume those will build on the linux primitives rather than whole new ones. - total assumption there but it would seem logical to reuse rather than make new.

part of likely what they mean by 'mess' is that its all over the place. many different ways to try and lock things down. hard to pick what is best etc. without thoroughly diving into the different subsystems entirely. (as opposed to just have 1 or 2 relatively simple system calls)

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 to see pledge/unveil on (upstream) Linux - but I'm not holding my breath.

that quote seems to be a bit of an oversimplification to the point of being completely wrong.

> Without them, your system accepts arbitrary data from the public network.

Neither of these features change if you are accepting arbitrary data from the public network. They limit what an exploited process can do. It's explained properly in the 'Security' section, so I'm not sure where this came from.

I feel bad for people with the real name Claude.

Thanks for the heads-up! I wasn't aware that Tridge is using Claude. I shall use Openrsync from now on.

How about the attempt to avoid things that use AI promiscuously and start exhibiting bugs? :-(

Wasting their precious limited time on this planet for performative hand wringing.

AI is only going to get better and better. Eventually manually writing software by hand with programming languages will be thought of as the punch-card phase of software development.

Do these people think we'll be writing software in 200 years time? That anybody will be maintaining rsync, let alone this "moral human hands only" version of it?

The anti-AI lot are trying to make all AI content wear a Scarlett letter. I wish they would wear one themselves so that we could filter them from our timeline.

This "effort" is entirely wasted.

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 your rsync is hostile, you probably have bigger problems!

I disagree. While rsync is most often used to transfer data between "friendly" systems, it's inherently crossing a security boundary. It's important to make sure that an attacker can't leverage it to transform the breach of one system into the breach of multiple systems.

> 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.

https://social.treehouse.systems/@thesamesam/116662824873341...

My understanding is that much of the point of openrsync is to create a second implementation of a protocol so the standards bodies don't balk at including it in their standards.

Or to put it more concretely, people working on the rpki standard(who happened to also be openbsd devs) wanted to use rsync to transfer bulk data. The standards body was hesitant, while rsync is ostensibly a documented protocol, there was only one implementation. So in true openbsd fashion they rolled up their sleeves and wrote that second implementation.

On use, there is nothing wrong with openrsync, however it may never hit feature parity with rsync, that is not a goal of the project, they want a specific subset of rsync features to support their rpki needs. If anyone else finds this useful that is great. So I suspect users will be those who want a bsd licensed rsync(apple) or them who are willing to give up features for openbsd quality code(myself).

samba is different topic

it's tridge rsync; samba is another project by the same guy. (rsync was originally a PhD thesis...)

Somewhat ironic Postfix has a record of no root/RCE in the default install, where opensmptd hasn't (CVE-2020-7247). Time will tell if it stays that way.

Where do you see that about Postfix? I followed the links and the only thing I see is that AI is being used to find bugs, not write code.

Exclude is very commonly used in automation jobs to avoid duplicating big git repos and other big files. I think that would be a show stopper for a number of people.

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

Many projects closely associated with OpenBSD start with "open"... openssh, openbgpd, openntpd, opensmtpd etc.

> The only way to stop this is for the original author(s) to release this under a BSD license.

Would that stop it? My understanding was that at least OpenBSD tended do redo things for technical reasons, not just licensing

The only option should not to be to take away user freedoms. BSD licenses are popular with proprietary software writers because they can use it without any of the restrictions that seek to preserve the rights of the end user. Instead you get proprietary software stacks like Apple and Android that seek to lock the users out of anything not granted by the company.

The correct way to stop this is to file bugs against the software for not matching the de-facto standard of the copied software.

It's really no different than every other BSD utility (and SysV utility, if you're running one of those) being different than the GNU ones. We've coped with it for fifty years at this point.

Basically like GNU Tar/CPIO and BSD Tar/CPIO. I've largely standardised towards using the bsd variant everywhere (especially since now even Windows ships it and it handles lots of other archive formats using the `tar` command) but it's always a pain to install it everywhere

> Apple and Android will prefer it,

My thought upon reading this is why would Apple or Android bother including rsync? I've noticed that I've needed to install it manually on fresh installs of Debian, FreeBSD...

But then, I just checked a recent Mac that I don't use much and haven't put much on, and it's installed.