HI version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
53% Positive
Analyzed from 2660 words in the discussion.
Trending Topics
#rsync#openrsync#services#more#open#https#software#openbsd#source#don
Discussion (113 Comments)Read Original on HackerNews
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
I would expect openrsync to create a remote file /tmp/services, but instead it creates /tmp/services/services.
Normal directory mirroring as in -av -e ssh /path/to/src/ example.com:/path/to/dst/ works as it does with Samba rsync.
> 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...
One of the biggest points of confusion with rsync is how directories and trailing slashes are handled.
Source ending in “/“: You want what’s inside. Source not ending in “/“: You want the thing (i.e. directory itself). For the destination, it does not matter whether it ends in “/“ or not, but for consistency I like adding a “/“ anyway (I want to put thing inside the directory).
No. And just to make sure, I ran a quick 'rm -rf /tmp/services' on the remote host, then re-ran openrsync on the client. Same result. This is OpenBSD 7.9 on both sides.
And I 100% agree about trailing slashes.
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.
Of the two possible worlds where in one this reimplementation matches what some see as annoyances in the interface or in another they mostly match the interface except for a few cases where the purposefully diverge (for no good technical reason), IMO the latter is far worse and causes more enexpected behavior.
At most, add a special flag to opt into different default behavior so nobody is surprised by running the same command on different systems and getting different behavior.
https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-va...
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
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 without pledge? Or is this article just for OpenBSD users?
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)
> 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.
There is Landlock now, I believe it would be possible to implement unveil and pledge on top of that.
There was a discussion here about it a few years ago: https://news.ycombinator.com/item?id=32096801
> 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.
Under Portability [1] I don't have access to update that repo. I deleted my accounts when Microsoft took over.
[1] - https://github.com/kristapsdz/openrsync
That said, every language on earth will adapt foreign words into its phonology. The alternative would be to adopt the phonology of every language that loaned a word into your language.
Ubuntu's packaged rsync, is it Samba rsync? Why reimplement it?
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'm not an rpki person so I don't know if there's some part of that problem domain that changes this equation. I'm not dunking on the project, just saying this snagged me in the README).
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.
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.
They’re layering on checksums and signing such that they mostly don’t think about the trustworthiness of mirrors or the networks between them.
I like open bsd but this just seems like burning cash
Context: https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...
I can't possibly see a correlation.
Weird how 3.4.2. didn't have a similar deluge of issue reports, though.
(EDIT: --exclude is now supported on 7.9. Not sure when that was added, nice!)
But seems avoiding "slop" is getting very hard. I saw postfix now has a bit of AI code in it.
https://mastodon.sdf.org/@mrmasterkeyboard@mastodon.social/1...
That is from the original post in the thread. Is that really due to LLM ? I do not know since I avoid AI as much as I can.
But the person also posted this link too:
https://github.com/NetBSD/src/commit/f764ddf4062e855f73fe2e3...
I have not tried using exclude in openrsync in a while, but I can see it now works on OpenBSD 7.9!
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.
GNU folks would say that the GPL does more to protect the freedom of end users by guaranteeing their right to access the source code, whereas permissive licenses allow users to receive binaries, the source code corresponding to which is unavailable to them.
I'm not trying to be idly pedantic here, but to emphasize one of things I genuinely admire about the FSF, SFC, etc.: while they do have words, concepts, and terms of art they're attached to, they're actually pretty good at always explicitly tying their positions back to a specific and well-articulated vision of software freedom. They don't usually get caught up in pure terminology ("what is maximally open?", "what is really free?"). They tend to be clear about whose rights they aim to promote and protect and why, and the bigger picture that fits into.
Whether you agree with them or not, I think it's a more defensible position than a shallow terminological squabble.
As someone that is somewhat aligned with those groups, I also want to say this: licenses are just tools for promoting freedom. It's a question of strategy and tactics. All permissively licensed free software is still free software, and the vast majority of it undeniably contributes positively to software freedom on the whole. (The only concrete exceptions I can think of are uses of permissively licensed free software code to implement things like Intel's Management Engine, DRM, maybe some Trusted Computing stuff.) OpenBSD is free software and it's good shit. We should think of licensing questions like this as a friendly dispute among people who have all given generously to support software freedom.
A true morality must be based on consent, not coercion. Humanity may not be there yet, and therein lies the argument for force (and thus copyleft); but the ultimate goal should always be to reduce its necessity.
> 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/OpenSSH
It was probably the second thing with the Open— prefix by this group of developers, OpenBSD itself being the first. They simply ran with the naming convention. OpenBGP/OSPF were developed as alternatives to Quagga (GPL).
https://www.openrsync.org/
The problem with this fragmentation of rsync is that Apple and Android will prefer it, but the Linux and greater GPL world will adhere to the original implantation due to inertia. Power users will just have to know the quirks of each version.
The only way to stop this is for the original author(s) to release this under a BSD license.
Edit: For those assuming equivalent/identical behavior, study these words carefully: "accepts only a subset of rsync's command-line arguments."
Would that stop it? My understanding was that at least OpenBSD tended do redo things for technical reasons, not just licensing
The correct way to stop this is to file bugs against the software for not matching the de-facto standard of the copied software.
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.