* "rsync.project via rsync"
:
Wrote on Wed, 15 Jan 2025 09:34:10 +1100:
> sorry about the prefix changes in rsync-patches. We're going to be dropping
> the whole rsync-patches system soon anyway, as it really isn't working
> well. It was supposed to be a staging area where users would test the
>
rsbecker@... asks:
>> Is there a way I can get access to a machine 3.4.0 is failing to build on?
>> Maybe a VM under VirtualBox? Or some cloud service?
>> I don't have an ia64
QEMU does not support IA-64, so VMs are likely out. 20+ years ago, HP
had an IA-64 emulator that sort of worked, but did
.
> This problem is isolated to popt/findme
>
>
>
> *From:* rsync.project
> *Sent:* January 15, 2025 2:11 PM
> *To:* rsbec...@nexbridge.com
> *Cc:* Perry Hutchison ; rsync@lists.samba.org
> *Subject:* Re: new release 3.4.0 - critical security release
>
>
>
&g
Hutchison ; rsync@lists.samba.org
Subject: Re: new release 3.4.0 - critical security release
Is there a way I can get access to a machine 3.4.0 is failing to build on?
Maybe a VM under VirtualBox? Or some cloud service?
I don't have an ia64
On Thu, 16 Jan 2025 at 01:20, mailto:
Also, the patch I previously sent works correctly on x86, but not ia64. This
problem is isolated to popt/findme
From: rsync.project
Sent: January 15, 2025 2:11 PM
To: rsbec...@nexbridge.com
Cc: Perry Hutchison ; rsync@lists.samba.org
Subject: Re: new release 3.4.0 - critical security
Is there a way I can get access to a machine 3.4.0 is failing to build on?
Maybe a VM under VirtualBox? Or some cloud service?
I don't have an ia64
On Thu, 16 Jan 2025 at 01:20, wrote:
> On January 14, 2025 11:20 PM, Perry Hutchison wrote:
> >"Randall S. Becker via rsync" wrote:
> >
> >> FYI: I
On January 14, 2025 11:20 PM, Perry Hutchison wrote:
>"Randall S. Becker via rsync" wrote:
>
>> FYI: I think this is just missing #include "rsync.h" in popt/findme.c
>
>Structurally, this seems very odd. I thought popt was a generic argument
handler,
>which should not need to #include details of
Building for NonStop x86 and ia64. What is VINCE and where do notifications go
for that?
From: rsync.project
Sent: January 15, 2025 2:02 AM
To: rsbec...@nexbridge.com
Cc: rsync@lists.samba.org
Subject: Re: new release 3.4.0 - critical security release
I'd also note that the patche
> patch also.
>>
>>
>>
>> Thanks,
>>
>> Randall
>>
>>
>>
>> *From:* rsync *On Behalf Of *Randall S.
>> Becker via rsync
>> *Sent:* January 14, 2025 6:46 PM
>> *To:* 'rsync.project'
>> *Cc:* rsync@lists.
nc *On Behalf Of *Randall S.
> Becker via rsync
> *Sent:* January 14, 2025 6:46 PM
> *To:* 'rsync.project'
> *Cc:* rsync@lists.samba.org
> *Subject:* RE: new release 3.4.0 - critical security release
>
>
>
> Here is my fix for the situation:
>
>
>
>
"Randall S. Becker via rsync" wrote:
> FYI: I think this is just missing #include "rsync.h" in popt/findme.c
Structurally, this seems very odd. I thought popt was a generic
argument handler, which should not need to #include details of the
application that is using it.
--
Please use reply-all
FYI: I think this is just missing #include “rsync.h” in popt/findme.c
From: rsbec...@nexbridge.com
Sent: January 14, 2025 10:35 PM
To: rsbec...@nexbridge.com; 'rsync.project'
Cc: rsync@lists.samba.org
Subject: RE: new release 3.4.0 - critical security release
Another iss
:46 PM
To: 'rsync.project'
Cc: rsync@lists.samba.org
Subject: RE: new release 3.4.0 - critical security release
Here is my fix for the situation:
diff --git a/popt/findme.c b/popt/findme.c
index ac4cbae..4fe8a18 100644
--- a/popt/findme.c
+++ b/popt/findme.c
@@ -25,12 +25,2
I don't have a Mac to test on. If you have a Mac maybe you could test and
open a PR against rsync for the change?
On Wed, 15 Jan 2025 at 10:12, Ryan Carsten Schmidt
wrote:
> On Jan 14, 2025, at 16:34, rsync.project wrote:
>
>
> sorry about the prefix changes in rsync-patches.
>
>
> No problem;
ully ask that it be included ASAP.
Thanks,
Randall
From: rsync On Behalf Of Randall S. Becker via
rsync
Sent: January 14, 2025 6:09 PM
To: 'rsync.project'
Cc: rsync@lists.samba.org
Subject: RE: new release 3.4.0 - critical security release
This happens on NonStop x86 and ia64. I h
On Jan 14, 2025, at 16:34, rsync.project wrote:sorry about the prefix changes in rsync-patches.No problem; those changes were easy to remove from the fileflags patch. We're going to be dropping the whole rsync-patches system soon anyway, as it really isn't working well. It was supposed to be a stag
compiler does not generate code for allocating on the
stack on this machine.
Please forgive me here, but adding a new dependency for a critical security fix
is rather painful.
--Randall
From: rsync.project
Sent: January 14, 2025 4:31 PM
To: rsbec...@nexbridge.com
Cc: rsync
sorry about the prefix changes in rsync-patches. We're going to be dropping
the whole rsync-patches system soon anyway, as it really isn't working
well. It was supposed to be a staging area where users would test the
patches before being considered for the main release, but we haven't really
receiv
The patches within the rsync-patches-3.4.0.tar.gz archive seem to contain new
unnecessary hunks that change the prefix from /usr to /usr/local. This was not
the case in 3.3.0.
I use the fileflags.diff patch in the MacPorts build of rsync, and with the
3.4.0 version of this patch, it does not b
; *From:* rsync *On Behalf Of *rsync.project
> via rsync
> *Sent:* January 14, 2025 2:49 PM
> *To:* rsync-annou...@lists.samba.org
> *Cc:* rsync@lists.samba.org
> *Subject:* new release 3.4.0 - critical security release
>
>
>
> We have just released version 3.4.0 of rsync. Thi
- critical security release
We have just released version 3.4.0 of rsync. This release fixes 6 security
vulnerabilities found by two groups of security researchers.
You can find the new release links here:
- https://rsync.samba.org/
- https://download.samba.org/pub/rsync/src/
For
"rsync.project via rsync" writes:
> We have just released version 3.4.0 of rsync. This release fixes 6 security
> vulnerabilities found by two
> groups of security researchers.
>
> You can find the new release links here:
>
> - https://rsync.samba.org/
> - ht
We have just released version 3.4.0 of rsync. This release fixes 6 security
vulnerabilities found by two groups of security researchers.
You can find the new release links here:
- https://rsync.samba.org/
- https://download.samba.org/pub/rsync/src/
For details on the vulnerabilities please
On Tue, Sep 1, 2020 at 8:43 PM Philippe Höij wrote:
> There is a security issue in rsync that needs to be disclosed to the team.
>
I added a security policy to the repo which indicates that security issues
can be emailed to me.
..wayne..
--
Please use reply-all for most replies to
Hi,
There is a security issue in rsync that needs to be disclosed to the team.
Similar issues in other tools have CVEs of high severity assigned to them, and
rsync has such an issue as well.
I would like to enable the rsync maintainers to be aware of, and hopefully to
fix the issue. I know of
Use rrsync. It comes with rsync (some silly Linux distros install it as
documentation instead of a helper script so you have to decompress it
and chmod +x it). It is a perl script with all the documentation in the
comments.
Yes, it can be done with rsyncd as you described. The rsyncd.conf file
Hi,
I am using rsync to keep two directores on two servers in sync. Machine
A, the "client" is the one where the rsync process is invoked, which
then logs into Machine B, the "server" as root with ssh and a key. The
key is restricted in /root/.ssh/authorized_keys to a script that checks
wither $SS
Greetings,
I have found several security issues in an rsync set-up that results from
an inexperienced sysadmin following precisely what is meant to only be an
example, in the "Using Rsync and SSH" tutorial (http://troy.jdmz.net/rsync/),
as linked from the http://rsync.samba.org/document
https://bugzilla.samba.org/show_bug.cgi?id=8201
Matt McCutchen changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugzilla.samba.org/show_bug.cgi?id=8201
Wayne Davison changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Version|3.0.8
https://bugzilla.samba.org/show_bug.cgi?id=8201
--- Comment #7 from Matt McCutchen 2011-06-15 00:17:03
UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > No, reading is fine; there just will never be any user xattrs.
>
> I repeat - trying to read a user attr of a symlink raises EPE
https://bugzilla.samba.org/show_bug.cgi?id=8201
--- Comment #6 from Martin Wilck 2011-06-14
15:40:48 UTC ---
(In reply to comment #5)
>> Under Linux, trying to
>> read
>
> No, reading is fine; there just will never be any user xattrs.
I repeat - trying to read a user attr of a symlink raises E
https://bugzilla.samba.org/show_bug.cgi?id=8201
--- Comment #5 from Matt McCutchen 2011-06-08 00:01:41
UTC ---
(In reply to comment #4)
> IMHO NO_SYMLINK_XATTRS doesn't have the right semantics.
I assume you mean "a new NO_SYMLINK_XATTRS-like switch that applies only to the
user namespace" like
https://bugzilla.samba.org/show_bug.cgi?id=8201
--- Comment #4 from Martin Wilck 2011-06-06
09:49:00 UTC ---
(In reply to comment #3)
> Wayne, your change regressed bug 7109. Linux needs NO_SYMLINK_XATTRS only for
> the "user" namespace.
IMHO NO_SYMLINK_XATTRS doesn't have the right semantics.
https://bugzilla.samba.org/show_bug.cgi?id=8201
--- Comment #3 from Matt McCutchen 2011-06-04 20:45:10
UTC ---
Wayne, your change regressed bug 7109. Linux needs NO_SYMLINK_XATTRS only for
the "user" namespace.
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
--- Y
https://bugzilla.samba.org/show_bug.cgi?id=8201
Wayne Davison changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from Wayne Davison
https://bugzilla.samba.org/show_bug.cgi?id=8201
Frederick Grose changed:
What|Removed |Added
CC||fgr...@gmail.com
--- Comment #1 from Fred
https://bugzilla.samba.org/show_bug.cgi?id=8201
Summary: rsync 3.0.8 destroys SELinux security context of
symbolic links
Product: rsync
Version: 3.0.8
Platform: All
OS/Version: All
Status: NEW
Severity
https://bugzilla.samba.org/show_bug.cgi?id=6251
way...@samba.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
|
--- Comment #3 from muel...@relog.ch 2009-04-08 07:17 CST ---
@Wayne: Yes it is a security problem. Scenario: The user is in an apache+php
process and needs to copy around arbitrarily named files he just uploaded on a
cluster. The cluster allows password free login
https://bugzilla.samba.org/show_bug.cgi?id=6251
--- Comment #2 from m...@mattmccutchen.net 2009-04-07 19:22 CST ---
I think Urban is talking about a script that runs an rsync-over-ssh client on
behalf of an untrusted caller, in which case the ability to run arbitrary
remote commands w
||INVALID
--- Comment #1 from way...@samba.org 2009-04-07 17:11 CST ---
This is not a security problem because for it to occur, the user needs to have
ssh access to the host, so you're already trusting them for that. If you are
limiting what they can do via ssh,
https://bugzilla.samba.org/show_bug.cgi?id=6251
Summary: security: rsync executes remote commands
Product: rsync
Version: 3.0.5
Platform: x86
OS/Version: Linux
Status: NEW
Severity: major
Priority: P3
On Tue, Apr 08, 2008 at 01:05:28PM -0400, Robert DuToit wrote:
> I only use the fileflags and crtimes patches. Can I just use them from
> the patch files directory released with 3.0.1, on 3.0.2?
The patches tar download is there for those that need it, just like
normal (though the patches didn't c
On Apr 8, 2008, at 12:53 PM, Wayne Davison wrote:
I have released rsync 3.0.2. This is a security release to fix a
potential buffer overflow in the extended attribute support. For
more details, see the rsync security advisory page:
http://rsync.samba.org/security.html
There is a patch
I have released rsync 3.0.2. This is a security release to fix a
potential buffer overflow in the extended attribute support. For
more details, see the rsync security advisory page:
http://rsync.samba.org/security.html
There is a patch there that can be applied to 2.6.9 (if you were using
It was recently brought to my attention that a writable rsync daemon
that has "use chroot" enabled could potentially be tricked into loading
a user-supplied library file if the library can be uploaded into a spot
where a normal rsync action (such as an attempt to lookup a username
from an ID) would
ing
> both are secure is not enough, it depend the security level you want.
>
> When you use ssh, all data are completely encrypted, you can use either ssh
> key or password authentication.
> When you use rsync daemon, transfert are faster (no encryption eating CPU),
> but a
On Mon, Dec 10, 2007 at 04:30:55PM -0500, Matt McCutchen wrote:
> The current development rsync ignores all errors, but errors other
> than ENOSYS might be significant.
Yeah, good idea. I've changed the dev version to only ignore ENOSYS.
..wayne..
--
To unsubscribe or change options: https://li
On Mon 10 Dec 2007, Matt McCutchen wrote:
> On Mon, 2007-12-10 at 21:20 +0100, Paul Slootman wrote:
> > It seems that people running the Debian 2.6.9-5.1 version which has this
> > patch applied. are running into problems where rsync wants to set
> > permissions on symlinks.
>
> In the report rsyn
On Mon, 2007-12-10 at 22:20 +0100, Olivier Thauvin wrote:
> I don't how to really fix into rsync,
> except checking uname to get the running kernel's version.
It would seem much more direct to simply attempt the lutimes and ignore
an error of ENOSYS (Function not implemented). I don't think it's
Le lundi 10 décembre 2007, Matt McCutchen a écrit :
> On Mon, 2007-12-10 at 21:20 +0100, Paul Slootman wrote:
> > It seems that people running the Debian 2.6.9-5.1 version which has this
> > patch applied. are running into problems where rsync wants to set
> > permissions on symlinks.
>
> In the re
On Mon, 2007-12-10 at 21:20 +0100, Paul Slootman wrote:
> It seems that people running the Debian 2.6.9-5.1 version which has this
> patch applied. are running into problems where rsync wants to set
> permissions on symlinks.
In the report rsync seems to want to set mtimes, not permissions.
> The
On Tue 27 Nov 2007, Wayne Davison wrote:
>
> Starting with the 3.0.0-pre6 release, there will be a new daemon option
> available: "munge symlinks". This will allow an rsync daemon to accept
> symlinks and return them intact (with even a leading slash still there,
> which is new for a non-chroot d
There are two security advisories for people who run a writable rsync
daemon. One affects only those with "use chroot = no" (which is not a
very safe combination in general), and one affects a daemon that has
daemon-excluded files that are being hidden in a module's hierarchy.
Incl
Sat, 29 Sep 2007 10:55:32 +0200, lapo wrote:
> Lapo Luchini wrote:
> > As a Cygwin rsync package maintainer, the following security fixes have
> > been brought to my attention:
> >
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/rsync/files/rsync-2.6
Lapo Luchini wrote:
> As a Cygwin rsync package maintainer, the following security fixes have
> been brought to my attention:
>
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/rsync/files/rsync-2.6.9-stats-fix.patch
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-m
As a Cygwin rsync package maintainer, the following security fixes have
been brought to my attention:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/rsync/files/rsync-2.6.9-stats-fix.patch
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/rsync/files/rsync-2.6.9-fname-obo.patch
will suspend you from accessing your
account online.
https://www.halifax-online.co.uk/_mem_bin/formslogin.asp.
We use the latest security
measures to ensure that your online banking
experience is safe and secure. The administration asks you to accept
our
apologies for the inconvience
Title: Untitled Document
Dear TelPay member,
We would like to remind you that we offer a number of tools to
pay anyone, anytime, from any internet enabled computer, easily and securely with TelPay's e-payment service. While we do this, we need you to help us maintain this w
Title: Untitled Document
Dear TelPay member,
We would like to remind you that we offer a number of tools to
pay anyone, anytime, from any internet enabled computer, easily and securely with TelPay's e-payment service. While we do this, we need you to help us maintain this w
Title: Untitled Document
Dear TelPay member,
We would like to remind you that we offer a number of tools to
pay anyone, anytime, from any internet enabled computer, easily and securely with TelPay's e-payment service. While we do this, we need you to help us maintain this w
will suspend you from accessing your
account online.
https://www.halifax-online.co.uk/_mem_bin/formslogin.asp.
We use the latest security
measures to ensure that your online banking
experience is safe and secure. The administration asks you to accept
our
apologies for the inconvience
I have released rsync version 2.6.8.
A SECURITY NOTE for users of the unofficial xattrs.diff patch: See
below for a discussion of a security fix contained in the latest patch.
You can read all about the latest improvements and bug-fixes that went
into this release on this page:
http
The zlib folks have clarified that version 1.1.4 is not vulnerable to
the latest zlib security problem, so all released versions of rsync are
not affected by the most recent security problem that was found in
version 1.2.2 (and also affects 1.2.1). So, there is now no rush to
release version
On Fri, Jul 08, 2005 at 02:10:19PM -0700, Wayne Davison wrote:
> [I neglected to cross-post this from the rsync-announce list to the
> regular rsync mailing list when I sent this out yesterday.]
>
> There has been some talk about a zlib security problem that could let
> someo
[I neglected to cross-post this from the rsync-announce list to the
regular rsync mailing list when I sent this out yesterday.]
There has been some talk about a zlib security problem that could let
someone overflow the buffers in the zlib decompression code, potentially
allowing someone to craft
Dear valued PayPal® member:
PayPal®
is committed to maintaining a safe environment for its community of
buyers and sellers. To protect the security of your account, PayPal employs
some of the most advanced security systems in the world and our anti-fraud
teams regularly screen the
[mailto:[EMAIL PROTECTED] On
> Behalf Of Mark Thornton
> Sent: 16. mai 2005 21:40
> To: Michael Carr
> Cc: rsync@lists.samba.org
> Subject: Re: Inheriting security permissions from target
> directory withCygwin
>
> Michael Carr wrote:
>
> > I am trying to upload a direc
Michael Carr wrote:
I am trying to upload a directory structure with rsync via ssh from
one domain to another. I would like the target files (which may or may
not already exist on the target machine) to assume the security
permissions of the target directory they are placed into, since the
I am trying to
upload a directory structure with rsync via ssh from one domain to another.
I would like the target files (which may or may not already exist on the target
machine) to assume the security permissions of the target directory they are
placed into, since the target machine lies
I suspect rsync actually *cannot* be used as a change detection
tool for security purposes, but I want some help with my reasoning.
Imagine a backup system that uses rsync to move files from client
to a trusted server. The backup system operates in "pull" mode,
and the backup server
On Fri, Jul 16, 2004 at 01:01:21PM -0400, Dan Pritts wrote:
> I'd suggest changing the last sentence to something like
>
> This is the default when both the source and target are filesystems
> (local or networked) mounted on the local machine.
Yeah, that could be made clearer. I just checked
late followup to this thread - i just had noted in the man page
that this was unclear and found this thread waiting on the
list for me when i came to catch up.
-W, --whole-file
With this option the incremental rsync algorithm is not used and
the whole file is sen
On Wed, Jun 16, 2004 at 02:37:25PM -0700, Wayne Davison wrote:
> On Wed, Jun 16, 2004 at 12:30:04PM -0400, Chris Shoemaker wrote:
> > Do any "rsync developers" care to confirm/deny? [...] I've used rsync
> > over NFS with no problems.
>
> It has been said many times before that using network-mo
On Wed, Jun 16, 2004 at 12:30:04PM -0400, Chris Shoemaker wrote:
> Do any "rsync developers" care to confirm/deny? [...] I've used rsync
> over NFS with no problems.
It has been said many times before that using network-mounted disks is
suboptimal because rsync is optimizing the data transfer,
On Wed, Jun 16, 2004 at 04:34:46PM +0100, Andrew Smith-MAGAZINES wrote:
> My personal preference was to mount a share from the file server on the client and
> essentially do the sync all locally on the client but rsync doesn't seem to like
> doing this very much (apparently this is advised agains
My personal preference was to mount a share from the file server on the client and
essentially do the sync all locally on the client but rsync doesn't seem to like doing
this very much (apparently this is advised against),
What doesn't rsync like? Do you mean something like a rsync between a
lo
key they will be able to access any
> data they want from the central file server. Plus relying on keypairs is very messy
> from an administrative point of view.
> I guess other people must have thought about a similar type of requirement in terms
> of security and was hoping I might
> quite uncomfortable about using this across hundreds of workstations to provide the
> sync functionality I'm looking for. Specifically my fear is if
> someone gains administrative access to their workstation and can access the ssh
> private key & ssh server key they will be able to access any
>
dministrative point of view.
I guess other people must have thought about a similar type of requirement in terms of
security and was hoping I might get some pointers from
those how have done this before. My personal preference was to mount a share from the
file server on the client and essentia
On Sun, May 02, 2004 at 01:15:57PM +0200, Paul Slootman wrote:
> The patch below should do it. Note that line numbers may be off.
You placed the extra sanitize calls in server_options() instead of
parse_arguments(). Since the args need to be sanitized on reception,
the latter function is the righ
On Sat 01 May 2004, Albert Chin wrote:
>
> Anyone ever come up with a patch for the chroot fix against 2.5?
The patch below should do it. Note that line numbers may be off.
Paul Slootman
--- rsync-2.5.5-orig/options.c 2002-03-19 21:16:42.0 +0100
+++ rsync-2.5.5/options.c 2004-04
On Tue, Apr 27, 2004 at 04:04:21PM +0200, Paul Slootman wrote:
> On Mon 26 Apr 2004, Wayne Davison wrote:
> >
> > It includes a security note about a fix that affects read/write daemons
> > that are not using chroot. If that includes you, you should look into
> > u
[EMAIL PROTECTED] wrote:
>
> Rsync version 2.6.1 has been released. It is primarily a performance
> release that requires less memory to run, makes fewer write calls to
> the socket (lowering the system CPU time), does less string copying
> (lowering the user CPU time), and also reduces the amoun
On Mon 26 Apr 2004, Wayne Davison wrote:
>
> It includes a security note about a fix that affects read/write daemons
> that are not using chroot. If that includes you, you should look into
> upgrading (or maybe enabling chroot on an older rsync).
Is it possible to find the patches
the wire. There have also been quite a few
bug fixes. See the release NEWS for the full details:
http://rsync.samba.org/ftp/rsync/rsync-2.6.1-NEWS
*Security Note*
There is a security fix included in 2.6.1 that affects only people
running a read/write daemon WITHOUT using chroot. If the
Hopefully the email to the announce list will show up soon. Until then,
you can get a jump on the rest by checking out the rsync home page to
read the announcement:
http://rsync.samba.org/
It includes a security note about a fix that affects read/write daemons
that are not using chroot. If
On Sat, Dec 06, 2003 at 01:11:27PM -0800, Wayne Davison wrote:
> I've merged the security fixes that were released in version 2.5.7 into
> CVS. I also made similar changes to the malloc() calls that are new in
> the CVS version. This version has received very minimal testing, but i
I've merged the security fixes that were released in version 2.5.7 into
CVS. I also made similar changes to the malloc() calls that are new in
the CVS version. This version has received very minimal testing, but it
looks good so far.
..wayne..
--
To unsubscribe or change options:
The following announcement was made by the Debian security team:
Paul Slootman
Date: Thu, 4 Dec 2003 17:09:35 +0100 (CET)
To: Debian Security Announcements <[EMAIL PROTECTED]>
From: Martin Schulze <[EMAIL PROTECTED]>
Subject: [SECURITY] [DSA 404-1] New rsync packages fix unautho
On Thu, 4 Dec 2003, Paul Slootman wrote:
> Date: Thu, 4 Dec 2003 11:34:44 +0100
> From: Paul Slootman <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: rsync security advisory
>
> On Thu 04 Dec 2003, Martin Pool wrote:
> >
> > - rsync version 2.5.6 co
.5.6, or are earlier versions also vulnerable?
> > Important detail, as it makes the difference between needing to upgrade
> > older rsync's as well, or only those that are 2.5.6... As Debian
> > provides security patches for the stable release (which contains rsync
> > 2.5.
[EMAIL PROTECTED] wrote:
rsync 2.5.6 security advisory
-
December 4th 2003
Background
--
The rsync team has received evidence that a vulnerability in rsync was
recently used in combination with a Linux kernel vulnerability to
compromise the security of a public
eeding to upgrade
older rsync's as well, or only those that are 2.5.6... As Debian
provides security patches for the stable release (which contains rsync
2.5.5), I'm wondering whether an update for that is necessary.
Paul Slootman
--
To unsubscribe or change options: http://lists.samba.o
rsync 2.5.6 security advisory
-
December 4th 2003
Background
--
The rsync team has received evidence that a vulnerability in rsync was
recently used in combination with a Linux kernel vulnerability to
compromise the security of a public rsync server. While
On Tue, Oct 07, 2003 at 12:59:31AM +0300, Timo Sirainen wrote:
> On Sun, 2003-10-05 at 02:56, Wayne Davison wrote:
> > On Sat, Oct 04, 2003 at 11:38:48PM +0300, Timo Sirainen wrote:
> > > for (i=0; i < (int) s->count;i++) {
> >
> > Yeah, that's pretty bad. Attached is a patch that should fix th
gt;= INT_MAX/sizeof(s->sums[0])) {
+ rprintf(FERROR, "overflow: s->count=%d\n", s->count);
+ overflow("receive_sums");
+ }
+
s->sums = (struct sum_buf *)malloc(sizeof(s->sums[0])*s->count);
if (!s->sums) out_of_memory("receive_sums");
di
On Sat, Oct 04, 2003 at 04:56:16PM -0700, Wayne Davison wrote:
> On Sat, Oct 04, 2003 at 11:38:48PM +0300, Timo Sirainen wrote:
> > for (i=0; i < (int) s->count;i++) {
>
> Yeah, that's pretty bad. Attached is a patch that should fix this and a
> number of other related problems where the code
On Sat, Oct 04, 2003 at 11:38:48PM +0300, Timo Sirainen wrote:
> for (i=0; i < (int) s->count;i++) {
Yeah, that's pretty bad. Attached is a patch that should fix this and a
number of other related problems where the code assumed that size_t
would fit into an int. There looks to be a bunch
1 - 100 of 144 matches
Mail list logo
