similar to: [Bug 1890] TLS for rsync protocol

from a security perspective this is bad. think of a backup provider who wants to make rsyncd modules available to the end users so they can push backups to the server. do you think that such server is secure if all users are allowed to open up an ssh shell to secure their rsync transfer ? ok, you can restrict the ssh connection, but you open up a hole and you need to think twice to make it secure

> The benefit of rsync over ssh secured by rrsync is that it is more > like what rsync users are already used to. i don`t like rsync over ssh in an environemt with users you can?t trust. from a security perspective, i think such setup is broken by design. it`s a little bit like giving a foreigner the key to your front door and then hope that the door in the corridor to your room will be

Hi, i`m wondering - can't THIS one http://gitweb.samba.org/?p=rsync-patches.git;a=blob;f=openssl-support.diff be completely replaced with THIS one ? http://dozzie.jarowit.net/trac/wiki/RsyncSSL http://dozzie.jarowit.net/git?p=rsync-ssl.git;a=tree Isn`t RsyncSSL (wrap rsync with stunnel via stdin/out) the better solution ? (as it is using a mature external program for the SSL stuff)

https://bugzilla.samba.org/show_bug.cgi?id=1890 devzero at web.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |devzero at web.de ------- Comment #3 from devzero at web.de 2009-08-07 05:11 CST ------- wouldn`t it be better to give up on that effort

rsync in daemon mode is very powerful, yet it comes with one big disadvantage: data is sent in plain. The workarounds are not really satisfying: - use VPN - one needs to set up an extra service, not always possible - use stunnel - as above - use SSH - is not as powerful as in daemon mode (i.e. read only access, chroot, easy way of adding/modifying users and modules etc.) Why was encrypted

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As far as a backup provider goes I wouldn't expect them to use rsync over SSL unless that were built into rsync in the future (and has been around long enough that most users would have it). I would expect them to either use rsync over ssh secured by rrsync or rsyncd over ssh with them managing the rsyncd.conf file. Either way the server side

https://bugzilla.samba.org/show_bug.cgi?id=1890 marineam@osuosl.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marineam@osuosl.org ------- Comment #2 from marineam@osuosl.org 2006-08-06 02:39 MST ------- (In reply to comment #1) > There is a

https://bugzilla.samba.org/show_bug.cgi?id=1890 Summary: TLS for rsync protocol Product: rsync Version: 2.6.3 Platform: All URL: http://metastatic.org/source/rsync-ssl.patch OS/Version: Linux Status: NEW Severity: enhancement Priority: P3 Component: core AssignedTo: wayned@samba.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Try it without any --delete options. On 03/27/2015 09:31 AM, Aron Rotteveel wrote: > I am now running with --delete --numeric-ids --relative but the > problem still persists. > > -- Best regards / Met vriendelijke groet, > > Aron Rotteveel > > 2015-03-27 14:22 GMT+01:00 Kevin Korb <kmk at sanitarium.net >

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Try also removing --delete-excluded. Without those two options there should be no reason for rsync to require gigs of RAM. Well, unless the other system has rsync 2.x. On 03/27/2015 07:29 AM, Aron Rotteveel wrote: > Yes, I removed "--no-inc-recursive", without success. > > -- Best regards / Met vriendelijke groet, > >

Hi Bryan, thanks for your kind reply but it happend only with some fonts not all font file, (email with attachment is under verification by admin, so i resend this without attachment file) here i attach 2 screenshot one original folder and second backup folder, you can notice that the font .otf, .ttf, .dfont have no problem in rsync it copied as it is but the font that not show extension (Font

what is the source and destination filesystem? here is some report that rsync has some problem with HFS+ filesystems and "ressource forks": http://quesera.com/reynhout/misc/rsync+hfsmode/ but as you are using ubuntu and not osx i`m curious what`s the problem, so i think we need more information here. regards roland > Gesendet: Freitag, 12. Dezember 2014 um 15:31 Uhr > Von:

On 6/13/21 3:36 PM, Jim Klimov via Nut-upsdev wrote: > Haven't got many ideas on this today, preoccupied with other > house-work, but can share a couple :) > > Regarding two implementations - I believe NSS and OpenSSL are licensed > differently and/or are (initially were?) available non-overlapping on > different OSes. A quick googling now showed that they both were >

https://bugzilla.samba.org/show_bug.cgi?id=14328 Bug ID: 14328 Summary: usleep() is obsolete, use nanosleep() Product: rsync Version: 3.1.3 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayne at opencoder.net Reporter:

On June 13, 2021 9:02:46 PM GMT+03:00, Tim Dawson <tadawson at tpcsvc.com> wrote: >Let's not overlook the simple fact that a lot of deployments are behind >secure firewalls, on secure networks, and on servers and lans that no >users have access to (physical ormotherwise), and thus have negligible >security requirements beyond what the environment already provides. >Yes,

https://bugzilla.samba.org/show_bug.cgi?id=13147 Bug ID: 13147 Summary: inconsistent behaviour regaring vanished files information Product: rsync Version: 3.0.9 Hardware: x64 OS: Mac OS X Status: NEW Severity: minor Priority: P5 Component: core Assignee:

https://bugzilla.samba.org/show_bug.cgi?id=10322 Summary: Slow Performance over Network rsync Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: Joerg.Grube at Gmx.De

https://bugzilla.samba.org/show_bug.cgi?id=10527 Summary: Rsync Deadlock when copying files Product: rsync Version: 3.1.0 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: dah4k0r at gmail.com

On Wed, 14 Nov 2018, Aki Tuomi wrote: >> I'm providing IMAP+Starttls on port 143 for users with legacy MUA. So >> I've to enable TLS1.0 up to TLS1.3 For IMAPS / port 993 I like to >> enable TLS1.2 and TLS1.3 only. >> >> Is this possible with dovecot-2.2.36 / how to setup this? > > Not possible I'm afraid. ("Not possible" = challenge!)

https://bugzilla.samba.org/show_bug.cgi?id=1890 wayned@samba.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From wayned@samba.org 2004-10-08 14:49 ------- There is a diff in the patches directory named