patches - Re: new release 3.4.0 - critical security release

2025-01-18 Thread Madhu via rsync 
* "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
> patches before being considered for the main release, but we haven't really
> received any feedback on the patches, so not serving a useful purpose now.
> I'll probably stop updating it for the next release.

There had been no commits on the github site
https://github.com/WayneD/rsync-patches.git since 04-2024, so I
thought it was already defunct, maybe the development happens
elswewhere?  I was surprised to hear of the tarball.

fwiw I've been a staple consumer of clone-dest direct-io downdate
omit-dir-changes, at least  until 3.3.0.

> On Wed, 15 Jan 2025 at 08:57, Ryan Carsten Schmidt 
> wrote:
>
>> 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.

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: new release 3.4.0 - critical security release

2025-01-15 Thread Nelson H. F. Beebe via rsync 
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 didn't handle the
82-bit registers of IA-64.

However, I have a physical IA-64 server box that runs Red Hat
Enterprise Linux Server release 5.11 (Tikanga).  I successfully built
rsync-3.4.0 on it yesterday like this:

$ export PATH=/usr/bin:/bin:/usr/sbin:/sbin
$ ./configure --prefix=$prefix --disable-xxhash --disable-zstd 
--disable-lz4  && make all check

The three disabled compression features are not available on that
system.  Also, when I found that the patch files for 3.4.0 could not
all be installed, I abandoned any attempt at using them, and just took
the stock rsync-3.4.0 bundle.

Here is what my IA-64 version reports:

$ rsync --version
rsync  version 3.4.0  protocol version 32
Copyright (C) 1996-2025 by Andrew Tridgell, Wayne Davison, and others.
Web site: https://rsync.samba.org/
Capabilities:
64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
socketpairs, symlinks, no symtimes, hardlinks, hardlink-specials,
hardlink-symlinks, IPv6, atimes, batchfiles, inplace, append, ACLs,
xattrs, optional secluded-args, iconv, prealloc, stop-at, no crtimes
Optimizations:
no SIMD-roll, no asm-roll, openssl-crypto, no asm-MD5
Checksum list:
md5 md4 sha1 none
Compress list:
zlibx zlib none
Daemon auth list:
sha512 sha256 sha1 md5 md4
...

---
- Nelson H. F. BeebeTel: +1 801 581 5254  -
- University of Utah  -
- Department of Mathematics, 110 LCBInternet e-mail: [email protected]  -
- 155 S 1400 E RM 233   [email protected]  [email protected] -
- Salt Lake City, UT 84112-0090, USAURL: https://www.math.utah.edu/~beebe -
---

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: new release 3.4.0 - critical security release

2025-01-15 Thread rsync.project via rsync 
As you seem to be around now, could we do a call to try and get this fixed?
Are you on the rsync discord server?
https://discord.gg/zHzPNc6R
if you can't do discord, then zoom?


On Thu, 16 Jan 2025 at 06:18,  wrote:

> 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:* [email protected]
> *Cc:* Perry Hutchison ; [email protected]
> *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,  wrote:
>
> 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 the application that is using
> it.
>
> I thought so too, but it is now pulling in things from util2 and other
> areas
> needing rsync.h and ifuncs.h.
> I still have not managed to get it to link correctly on ia64 and am
> seriously considering giving up.
>
>
-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

RE: new release 3.4.0 - critical security release

2025-01-15 Thread Randall S. Becker via rsync 
Unfortunately not. We are using a guest machine that is not within our control. 
Worse, there is no VM for ia64 for this operating system. I can handle 
builds/feedback with a git repo+branch pretty fast.

 

From: rsync.project  
Sent: January 15, 2025 2:11 PM
To: [email protected]
Cc: Perry Hutchison ; [email protected]
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:[email protected]> > wrote:

On January 14, 2025 11:20 PM, Perry Hutchison wrote:
>"Randall S. Becker via rsync" <mailto:[email protected]> > 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.

I thought so too, but it is now pulling in things from util2 and other areas
needing rsync.h and ifuncs.h.
I still have not managed to get it to link correctly on ia64 and am
seriously considering giving up.

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

RE: new release 3.4.0 - critical security release

2025-01-15 Thread Randall S. Becker via rsync 
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: [email protected]
Cc: Perry Hutchison ; [email protected]
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:[email protected]> > wrote:

On January 14, 2025 11:20 PM, Perry Hutchison wrote:
>"Randall S. Becker via rsync" <mailto:[email protected]> > 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.

I thought so too, but it is now pulling in things from util2 and other areas
needing rsync.h and ifuncs.h.
I still have not managed to get it to link correctly on ia64 and am
seriously considering giving up.

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: new release 3.4.0 - critical security release

2025-01-15 Thread rsync.project via rsync 
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 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.
>
> I thought so too, but it is now pulling in things from util2 and other
> areas
> needing rsync.h and ifuncs.h.
> I still have not managed to get it to link correctly on ia64 and am
> seriously considering giving up.
>
>
-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

RE: new release 3.4.0 - critical security release

2025-01-15 Thread Randall S. Becker via rsync 
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 the application that is using
it.

I thought so too, but it is now pulling in things from util2 and other areas
needing rsync.h and ifuncs.h.
I still have not managed to get it to link correctly on ia64 and am
seriously considering giving up.


-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

RE: new release 3.4.0 - critical security release

2025-01-15 Thread Randall S. Becker via rsync 
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: [email protected]
Cc: [email protected]
Subject: Re: new release 3.4.0 - critical security release

 

I'd also note that the patches for 3.4.0 were made available to 81 different 
vendors via VINCE since 18th December (under embargo to give time for vendors 
to prepare). It is unfortunate that it didn't cover the platform you are 
building for. What platform is it btw?

 

 

On Wed, 15 Jan 2025 at 17:57, rsync.project mailto:[email protected]> > wrote:

The popt changes came from upstream popt. We have Solaris and FreeBSD CI tests, 
along with linux, but don't have a method for testing other platforms. If you 
submit a PR to fix this, please consider a way we can test the fix in CI.

Cheers, Tridge

 

On Wed, 15 Jan 2025 at 14:35, mailto:[email protected]> > wrote:

Another issue here in findme.c. strlcpy() is a BSD-only method and definitely 
not portable.

Please consider other platforms when creating patches. I can provide a patch to 
this

patch also.

 

Thanks,

Randall

 

From: rsync mailto:[email protected]> > On Behalf Of Randall S. Becker via 
rsync
Sent: January 14, 2025 6:46 PM
To: 'rsync.project' mailto:[email protected]> >
Cc: [email protected] <mailto:[email protected]> 
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,23 @@ const char * findProgramPath(const char * argv0)

 if (path == NULL) return NULL;

 

 bufsize = strlen(path) + 1;

+#if defined __TANDEM

+start = pathbuf = malloc(bufsize);

+#else

 start = pathbuf = alloca(bufsize);

+#endif

 if (pathbuf == NULL) return NULL;  /* XXX can't happen */

 strlcpy(pathbuf, path, bufsize);

 bufsize += sizeof "/" - 1 + strlen(argv0);

 buf = malloc(bufsize);

+#if defined __TANDEM

+if (buf == NULL) {

+   free(start);

+   return NULL;/* XXX can't happen */

+}

+#else

 if (buf == NULL) return NULL;  /* XXX can't happen */

+#endif

 

 chptr = NULL;

 /*@-branchstate@*/

@@ -39,8 +50,15 @@ const char * findProgramPath(const char * argv0)

*chptr = '\0';

snprintf(buf, bufsize, "%s/%s", start, argv0);

 

+#if defined __TANDEM

+   if (!access(buf, X_OK)) {

+   free(start);

+   return buf;

+   }

+#else

if (!access(buf, X_OK))

return buf;

+#endif

 

if (chptr)

start = chptr + 1;

@@ -51,5 +69,8 @@ const char * findProgramPath(const char * argv0)

 

 free(buf);

 

+#if defined __TANDEM

+free(start);

+#endif

 return NULL;

}

 

I would respectfully ask that it be included ASAP.

 

Thanks,

Randall

 

From: rsync mailto:[email protected]> > On Behalf Of Randall S. Becker via 
rsync
Sent: January 14, 2025 6:09 PM
To: 'rsync.project' mailto:[email protected]> >
Cc: [email protected] <mailto:[email protected]> 
Subject: RE: new release 3.4.0 - critical security release

 

This happens on NonStop x86 and ia64. I have been building/packaging Rsync for 
years – almost a decade in fact. I think this happened once before this year, 
in fact.

 

It is equivalent to the more portable malloc/free, which I would prefer to have 
in this series even if it has to be wrapped in a #if defined (__TANDEM) block.

 

This call is considered not portable and allocates on the stack instead of the 
heap. This can cause performance issues as memory management on the heap is 
generally given more attention by runtimes. The reason it is not supported on 
NonStop is that the c99 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 mailto:[email protected]> > 
Sent: January 14, 2025 4:31 PM
To: [email protected] <mailto:[email protected]> 
Cc: [email protected] <mailto:[email protected]> 
Subject: Re: new release 3.4.0 - critical security release

 

the alloca comes from the new popt release. What system are you having an issue 
with?

 

 

On Wed, 15 Jan 2025 at 07:16, mailto:[email protected]> > wrote:

A new dependency was added since 3.3, alloca(), which is not portable. Is there 
a way around this?

Thanks,

Randall

 

From: rsync mailto:[email protected]> > On Behalf Of rsync.project via rsync
Sent: January 14, 2025 2:49 PM
To: [email protected] <mailto:[email protected]> 
Cc:

Re: new release 3.4.0 - critical security release

2025-01-14 Thread rsync.project via rsync 
I'd also note that the patches for 3.4.0 were made available to 81
different vendors via VINCE since 18th December (under embargo to give time
for vendors to prepare). It is unfortunate that it didn't cover the
platform you are building for. What platform is it btw?


On Wed, 15 Jan 2025 at 17:57, rsync.project  wrote:

> The popt changes came from upstream popt. We have Solaris and FreeBSD CI
> tests, along with linux, but don't have a method for testing other
> platforms. If you submit a PR to fix this, please consider a way we can
> test the fix in CI.
> Cheers, Tridge
>
> On Wed, 15 Jan 2025 at 14:35,  wrote:
>
>> Another issue here in findme.c. strlcpy() is a BSD-only method and
>> definitely not portable.
>>
>> Please consider other platforms when creating patches. I can provide a
>> patch to this
>>
>> 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:* [email protected]
>> *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,23 @@ const char * findProgramPath(const char * argv0)
>>
>>  if (path == NULL) return NULL;
>>
>>
>>
>>  bufsize = strlen(path) + 1;
>>
>> +#if defined __TANDEM
>>
>> +start = pathbuf = malloc(bufsize);
>>
>> +#else
>>
>>  start = pathbuf = alloca(bufsize);
>>
>> +#endif
>>
>>  if (pathbuf == NULL) return NULL;  /* XXX can't happen */
>>
>>  strlcpy(pathbuf, path, bufsize);
>>
>>  bufsize += sizeof "/" - 1 + strlen(argv0);
>>
>>  buf = malloc(bufsize);
>>
>> +#if defined __TANDEM
>>
>> +if (buf == NULL) {
>>
>> +   free(start);
>>
>> +   return NULL;/* XXX can't happen */
>>
>> +}
>>
>> +#else
>>
>>  if (buf == NULL) return NULL;  /* XXX can't happen */
>>
>> +#endif
>>
>>
>>
>>  chptr = NULL;
>>
>>  /*@-branchstate@*/
>>
>> @@ -39,8 +50,15 @@ const char * findProgramPath(const char * argv0)
>>
>> *chptr = '\0';
>>
>> snprintf(buf, bufsize, "%s/%s", start, argv0);
>>
>>
>>
>> +#if defined __TANDEM
>>
>> +   if (!access(buf, X_OK)) {
>>
>> +   free(start);
>>
>> +   return buf;
>>
>> +   }
>>
>> +#else
>>
>> if (!access(buf, X_OK))
>>
>> return buf;
>>
>> +#endif
>>
>>
>>
>> if (chptr)
>>
>> start = chptr + 1;
>>
>> @@ -51,5 +69,8 @@ const char * findProgramPath(const char * argv0)
>>
>>
>>
>>  free(buf);
>>
>>
>>
>> +#if defined __TANDEM
>>
>> +free(start);
>>
>> +#endif
>>
>>  return NULL;
>>
>> }
>>
>>
>>
>> I would respectfully 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:* [email protected]
>> *Subject:* RE: new release 3.4.0 - critical security release
>>
>>
>>
>> This happens on NonStop x86 and ia64. I have been building/packaging
>> Rsync for years – almost a decade in fact. I think this happened once
>> before this year, in fact.
>>
>>
>>
>> It is equivalent to the more portable malloc/free, which I would prefer
>> to have in this series even if it has to be wrapped in a #if defined
>> (__TANDEM) block.
>>
>>
>>
>> This call is considered not portable and allocates on the stack instead
>> of the heap. This can cause performance issues as memory management on the
>> heap is generally given more attention by runtimes. The reason it is not
>> supported on NonStop is that the c99 compiler does not generate code for
>> allocating on the stack on this machine.
>>
&g

Re: new release 3.4.0 - critical security release

2025-01-14 Thread rsync.project via rsync 
The popt changes came from upstream popt. We have Solaris and FreeBSD CI
tests, along with linux, but don't have a method for testing other
platforms. If you submit a PR to fix this, please consider a way we can
test the fix in CI.
Cheers, Tridge

On Wed, 15 Jan 2025 at 14:35,  wrote:

> Another issue here in findme.c. strlcpy() is a BSD-only method and
> definitely not portable.
>
> Please consider other platforms when creating patches. I can provide a
> patch to this
>
> 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:* [email protected]
> *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,23 @@ const char * findProgramPath(const char * argv0)
>
>  if (path == NULL) return NULL;
>
>
>
>  bufsize = strlen(path) + 1;
>
> +#if defined __TANDEM
>
> +start = pathbuf = malloc(bufsize);
>
> +#else
>
>  start = pathbuf = alloca(bufsize);
>
> +#endif
>
>  if (pathbuf == NULL) return NULL;  /* XXX can't happen */
>
>  strlcpy(pathbuf, path, bufsize);
>
>  bufsize += sizeof "/" - 1 + strlen(argv0);
>
>  buf = malloc(bufsize);
>
> +#if defined __TANDEM
>
> +if (buf == NULL) {
>
> +   free(start);
>
> +   return NULL;/* XXX can't happen */
>
> +}
>
> +#else
>
>  if (buf == NULL) return NULL;  /* XXX can't happen */
>
> +#endif
>
>
>
>  chptr = NULL;
>
>  /*@-branchstate@*/
>
> @@ -39,8 +50,15 @@ const char * findProgramPath(const char * argv0)
>
> *chptr = '\0';
>
> snprintf(buf, bufsize, "%s/%s", start, argv0);
>
>
>
> +#if defined __TANDEM
>
> +   if (!access(buf, X_OK)) {
>
> +   free(start);
>
> +   return buf;
>
> +   }
>
> +#else
>
> if (!access(buf, X_OK))
>
> return buf;
>
> +#endif
>
>
>
> if (chptr)
>
> start = chptr + 1;
>
> @@ -51,5 +69,8 @@ const char * findProgramPath(const char * argv0)
>
>
>
>  free(buf);
>
>
>
> +#if defined __TANDEM
>
> +free(start);
>
> +#endif
>
>  return NULL;
>
> }
>
>
>
> I would respectfully 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:* [email protected]
> *Subject:* RE: new release 3.4.0 - critical security release
>
>
>
> This happens on NonStop x86 and ia64. I have been building/packaging Rsync
> for years – almost a decade in fact. I think this happened once before this
> year, in fact.
>
>
>
> It is equivalent to the more portable malloc/free, which I would prefer to
> have in this series even if it has to be wrapped in a #if defined
> (__TANDEM) block.
>
>
>
> This call is considered not portable and allocates on the stack instead of
> the heap. This can cause performance issues as memory management on the
> heap is generally given more attention by runtimes. The reason it is not
> supported on NonStop is that the c99 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:* [email protected]
> *Cc:* [email protected]
> *Subject:* Re: new release 3.4.0 - critical security release
>
>
>
> the alloca comes from the new popt release. What system are you having an
> issue with?
>
>
>
>
>
> On Wed, 15 Jan 2025 at 07:16,  wrote:
>
> A new dependency was added since 3.3, alloca(), which is not portable. Is
> there a way around this?
>
> Thanks,
>
> Randall
>
>
>
> *From:* rsync  *On Behalf Of *rsync.project
> via rsync
> *Sent:* January 14, 2025 2:49 PM
> *To:* [email protected]
> *Cc:* [email protected]
> *Subject:* new release 3.4.0 - critical security release
>
>
>
> We have just released version 3.4.0 of rsync. This release fixes 6
> security vulnera

Re: new release 3.4.0 - critical security release

2025-01-14 Thread Perry Hutchison via rsync 
"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 for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

RE: new release 3.4.0 - critical security release

2025-01-14 Thread Randall S. Becker via rsync 
FYI: I think this is just missing #include “rsync.h” in popt/findme.c

 

From: [email protected]  
Sent: January 14, 2025 10:35 PM
To: [email protected]; 'rsync.project' 
Cc: [email protected]
Subject: RE: new release 3.4.0 - critical security release

 

Another issue here in findme.c. strlcpy() is a BSD-only method and definitely 
not portable.

Please consider other platforms when creating patches. I can provide a patch to 
this

patch also.

 

Thanks,

Randall

 

From: rsync mailto:[email protected]> > On Behalf Of Randall S. Becker via 
rsync
Sent: January 14, 2025 6:46 PM
To: 'rsync.project' mailto:[email protected]> >
Cc: [email protected] <mailto:[email protected]> 
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,23 @@ const char * findProgramPath(const char * argv0)

 if (path == NULL) return NULL;

 

 bufsize = strlen(path) + 1;

+#if defined __TANDEM

+start = pathbuf = malloc(bufsize);

+#else

 start = pathbuf = alloca(bufsize);

+#endif

 if (pathbuf == NULL) return NULL;  /* XXX can't happen */

 strlcpy(pathbuf, path, bufsize);

 bufsize += sizeof "/" - 1 + strlen(argv0);

 buf = malloc(bufsize);

+#if defined __TANDEM

+if (buf == NULL) {

+   free(start);

+   return NULL;/* XXX can't happen */

+}

+#else

 if (buf == NULL) return NULL;  /* XXX can't happen */

+#endif

 

 chptr = NULL;

 /*@-branchstate@*/

@@ -39,8 +50,15 @@ const char * findProgramPath(const char * argv0)

*chptr = '\0';

snprintf(buf, bufsize, "%s/%s", start, argv0);

 

+#if defined __TANDEM

+   if (!access(buf, X_OK)) {

+   free(start);

+   return buf;

+   }

+#else

if (!access(buf, X_OK))

return buf;

+#endif

 

if (chptr)

start = chptr + 1;

@@ -51,5 +69,8 @@ const char * findProgramPath(const char * argv0)

 

 free(buf);

 

+#if defined __TANDEM

+free(start);

+#endif

 return NULL;

}

 

I would respectfully ask that it be included ASAP.

 

Thanks,

Randall

 

From: rsync mailto:[email protected]> > On Behalf Of Randall S. Becker via 
rsync
Sent: January 14, 2025 6:09 PM
To: 'rsync.project' mailto:[email protected]> >
Cc: [email protected] <mailto:[email protected]> 
Subject: RE: new release 3.4.0 - critical security release

 

This happens on NonStop x86 and ia64. I have been building/packaging Rsync for 
years – almost a decade in fact. I think this happened once before this year, 
in fact.

 

It is equivalent to the more portable malloc/free, which I would prefer to have 
in this series even if it has to be wrapped in a #if defined (__TANDEM) block.

 

This call is considered not portable and allocates on the stack instead of the 
heap. This can cause performance issues as memory management on the heap is 
generally given more attention by runtimes. The reason it is not supported on 
NonStop is that the c99 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 mailto:[email protected]> > 
Sent: January 14, 2025 4:31 PM
To: [email protected] <mailto:[email protected]> 
Cc: [email protected] <mailto:[email protected]> 
Subject: Re: new release 3.4.0 - critical security release

 

the alloca comes from the new popt release. What system are you having an issue 
with?

 

 

On Wed, 15 Jan 2025 at 07:16, mailto:[email protected]> > wrote:

A new dependency was added since 3.3, alloca(), which is not portable. Is there 
a way around this?

Thanks,

Randall

 

From: rsync mailto:[email protected]> > On Behalf Of rsync.project via rsync
Sent: January 14, 2025 2:49 PM
To: [email protected] <mailto:[email protected]> 
Cc: [email protected] <mailto:[email protected]> 
Subject: new release 3.4.0 - 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 details on the vulnerabilities please see this CERT advisory:

 

https://kb.cert.org/vuls/id/952657

 

The various distros should be doing security releases today

Many thanks to Simon Scannell, Pedro Gallegos, and Jasiel Spelman at Google 
Cloud Vulnerability Research and Aleksei Gorban (Loqpa) for discovering

RE: new release 3.4.0 - critical security release

2025-01-14 Thread Randall S. Becker via rsync 
Another issue here in findme.c. strlcpy() is a BSD-only method and definitely 
not portable.

Please consider other platforms when creating patches. I can provide a patch to 
this

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: [email protected]
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,23 @@ const char * findProgramPath(const char * argv0)

 if (path == NULL) return NULL;

 

 bufsize = strlen(path) + 1;

+#if defined __TANDEM

+start = pathbuf = malloc(bufsize);

+#else

 start = pathbuf = alloca(bufsize);

+#endif

 if (pathbuf == NULL) return NULL;  /* XXX can't happen */

 strlcpy(pathbuf, path, bufsize);

 bufsize += sizeof "/" - 1 + strlen(argv0);

 buf = malloc(bufsize);

+#if defined __TANDEM

+if (buf == NULL) {

+   free(start);

+   return NULL;/* XXX can't happen */

+}

+#else

 if (buf == NULL) return NULL;  /* XXX can't happen */

+#endif

 

 chptr = NULL;

 /*@-branchstate@*/

@@ -39,8 +50,15 @@ const char * findProgramPath(const char * argv0)

*chptr = '\0';

snprintf(buf, bufsize, "%s/%s", start, argv0);

 

+#if defined __TANDEM

+   if (!access(buf, X_OK)) {

+   free(start);

+   return buf;

+   }

+#else

if (!access(buf, X_OK))

return buf;

+#endif

 

if (chptr)

start = chptr + 1;

@@ -51,5 +69,8 @@ const char * findProgramPath(const char * argv0)

 

 free(buf);

 

+#if defined __TANDEM

+free(start);

+#endif

 return NULL;

}

 

I would respectfully 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: [email protected]
Subject: RE: new release 3.4.0 - critical security release

 

This happens on NonStop x86 and ia64. I have been building/packaging Rsync for 
years – almost a decade in fact. I think this happened once before this year, 
in fact.

 

It is equivalent to the more portable malloc/free, which I would prefer to have 
in this series even if it has to be wrapped in a #if defined (__TANDEM) block.

 

This call is considered not portable and allocates on the stack instead of the 
heap. This can cause performance issues as memory management on the heap is 
generally given more attention by runtimes. The reason it is not supported on 
NonStop is that the c99 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: [email protected]
Cc: [email protected]
Subject: Re: new release 3.4.0 - critical security release

 

the alloca comes from the new popt release. What system are you having an issue 
with?

 

 

On Wed, 15 Jan 2025 at 07:16, mailto:[email protected]> > wrote:

A new dependency was added since 3.3, alloca(), which is not portable. Is there 
a way around this?

Thanks,

Randall

 

From: rsync mailto:[email protected]> > On Behalf Of rsync.project via rsync
Sent: January 14, 2025 2:49 PM
To: [email protected] <mailto:[email protected]> 
Cc: [email protected] <mailto:[email protected]> 
Subject: new release 3.4.0 - 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 details on the vulnerabilities please see this CERT advisory:

 

https://kb.cert.org/vuls/id/952657

 

The various distros should be doing security releases today

Many thanks to Simon Scannell, Pedro Gallegos, and Jasiel Spelman at Google 
Cloud Vulnerability Research and Aleksei Gorban (Loqpa) for discovering these 
vulnerabilities and working with the rsync project to develop and test fixes.

 

Also many thanks to Wayne Davison for assisting with the release process as 
this is the first release I've done since 2002 when Wayne took over as the 
rsync maintainer.

 

Andrew Tridgell

rsync maintainer (again!)

 

 

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: new release 3.4.0 - critical security release

2025-01-14 Thread rsync.project via rsync 
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; 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 staging area where
> users would test the patches before being considered for the main release,
> but we haven't really received any feedback on the patches, so not serving
> a useful purpose now. I'll probably stop updating it for the next release.
>
>
> MacPorts has been shipping rsync to users with fileflags.diff since 2008:
>
> #15472 (rsync-3.0.3 should fully preserve Mac OS X metadata)
> 
> trac.macports.org 
> [image: macports.ico] 
> 
>
>
> How about incorporating that patch into rsync proper, once it's fixed? I
> don't want to become responsible for maintaining your patches for you.
>
> The other patch discussed in that ticket, crtimes.diff, was already
> incorporated into rsync in 3.2.3.
>


macports.ico
Description: Binary data
-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

RE: new release 3.4.0 - critical security release

2025-01-14 Thread Randall S. Becker via rsync 
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,23 @@ const char * findProgramPath(const char * argv0)

 if (path == NULL) return NULL;

 

 bufsize = strlen(path) + 1;

+#if defined __TANDEM

+start = pathbuf = malloc(bufsize);

+#else

 start = pathbuf = alloca(bufsize);

+#endif

 if (pathbuf == NULL) return NULL;  /* XXX can't happen */

 strlcpy(pathbuf, path, bufsize);

 bufsize += sizeof "/" - 1 + strlen(argv0);

 buf = malloc(bufsize);

+#if defined __TANDEM

+if (buf == NULL) {

+   free(start);

+   return NULL;/* XXX can't happen */

+}

+#else

 if (buf == NULL) return NULL;  /* XXX can't happen */

+#endif

 

 chptr = NULL;

 /*@-branchstate@*/

@@ -39,8 +50,15 @@ const char * findProgramPath(const char * argv0)

*chptr = '\0';

snprintf(buf, bufsize, "%s/%s", start, argv0);

 

+#if defined __TANDEM

+   if (!access(buf, X_OK)) {

+   free(start);

+   return buf;

+   }

+#else

if (!access(buf, X_OK))

return buf;

+#endif

 

if (chptr)

start = chptr + 1;

@@ -51,5 +69,8 @@ const char * findProgramPath(const char * argv0)

 

 free(buf);

 

+#if defined __TANDEM

+free(start);

+#endif

 return NULL;

}

 

I would respectfully 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: [email protected]
Subject: RE: new release 3.4.0 - critical security release

 

This happens on NonStop x86 and ia64. I have been building/packaging Rsync for 
years – almost a decade in fact. I think this happened once before this year, 
in fact.

 

It is equivalent to the more portable malloc/free, which I would prefer to have 
in this series even if it has to be wrapped in a #if defined (__TANDEM) block.

 

This call is considered not portable and allocates on the stack instead of the 
heap. This can cause performance issues as memory management on the heap is 
generally given more attention by runtimes. The reason it is not supported on 
NonStop is that the c99 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: [email protected]
Cc: [email protected]
Subject: Re: new release 3.4.0 - critical security release

 

the alloca comes from the new popt release. What system are you having an issue 
with?

 

 

On Wed, 15 Jan 2025 at 07:16, mailto:[email protected]> > wrote:

A new dependency was added since 3.3, alloca(), which is not portable. Is there 
a way around this?

Thanks,

Randall

 

From: rsync mailto:[email protected]> > On Behalf Of rsync.project via rsync
Sent: January 14, 2025 2:49 PM
To: [email protected] <mailto:[email protected]> 
Cc: [email protected] <mailto:[email protected]> 
Subject: new release 3.4.0 - 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 details on the vulnerabilities please see this CERT advisory:

 

https://kb.cert.org/vuls/id/952657

 

The various distros should be doing security releases today

Many thanks to Simon Scannell, Pedro Gallegos, and Jasiel Spelman at Google 
Cloud Vulnerability Research and Aleksei Gorban (Loqpa) for discovering these 
vulnerabilities and working with the rsync project to develop and test fixes.

 

Also many thanks to Wayne Davison for assisting with the release process as 
this is the first release I've done since 2002 when Wayne took over as the 
rsync maintainer.

 

Andrew Tridgell

rsync maintainer (again!)

 

 

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: new release 3.4.0 - critical security release

2025-01-14 Thread Ryan Carsten Schmidt via rsync 
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 staging area where users would test the patches before being considered for the main release, but we haven't really received any feedback on the patches, so not serving a useful purpose now. I'll probably stop updating it for the next release.MacPorts has been shipping rsync to users with fileflags.diff since 2008:#15472 (rsync-3.0.3 should fully preserve Mac OS X metadata)trac.macports.orgHow about incorporating that patch into rsync proper, once it's fixed? I don't want to become responsible for maintaining your patches for you. The other patch discussed in that ticket, crtimes.diff, was already incorporated into rsync in 3.2.3. -- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

RE: new release 3.4.0 - critical security release

2025-01-14 Thread Randall S. Becker via rsync 
This happens on NonStop x86 and ia64. I have been building/packaging Rsync for 
years – almost a decade in fact. I think this happened once before this year, 
in fact.

 

It is equivalent to the more portable malloc/free, which I would prefer to have 
in this series even if it has to be wrapped in a #if defined (__TANDEM) block.

 

This call is considered not portable and allocates on the stack instead of the 
heap. This can cause performance issues as memory management on the heap is 
generally given more attention by runtimes. The reason it is not supported on 
NonStop is that the c99 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: [email protected]
Cc: [email protected]
Subject: Re: new release 3.4.0 - critical security release

 

the alloca comes from the new popt release. What system are you having an issue 
with?

 

 

On Wed, 15 Jan 2025 at 07:16, mailto:[email protected]> > wrote:

A new dependency was added since 3.3, alloca(), which is not portable. Is there 
a way around this?

Thanks,

Randall

 

From: rsync mailto:[email protected]> > On Behalf Of rsync.project via rsync
Sent: January 14, 2025 2:49 PM
To: [email protected] <mailto:[email protected]> 
Cc: [email protected] <mailto:[email protected]> 
Subject: new release 3.4.0 - 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 details on the vulnerabilities please see this CERT advisory:

 

https://kb.cert.org/vuls/id/952657

 

The various distros should be doing security releases today

Many thanks to Simon Scannell, Pedro Gallegos, and Jasiel Spelman at Google 
Cloud Vulnerability Research and Aleksei Gorban (Loqpa) for discovering these 
vulnerabilities and working with the rsync project to develop and test fixes.

 

Also many thanks to Wayne Davison for assisting with the release process as 
this is the first release I've done since 2002 when Wayne took over as the 
rsync maintainer.

 

Andrew Tridgell

rsync maintainer (again!)

 

 

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: new release 3.4.0 - critical security release

2025-01-14 Thread rsync.project via 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
received any feedback on the patches, so not serving a useful purpose now.
I'll probably stop updating it for the next release.


On Wed, 15 Jan 2025 at 08:57, Ryan Carsten Schmidt 
wrote:

> 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 build:
>
> t_stub.c:34:14: error: redefinition of 'module_dirlen' with a different
> type: 'unsigned int' vs 'int'
> unsigned int module_dirlen = 0;
>  ^
> t_stub.c:31:5: note: previous definition is here
> int module_dirlen = 0;
> ^
> 1 error generated.
>
>
>
-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: new release 3.4.0 - critical security release

2025-01-14 Thread Ryan Carsten Schmidt via rsync 
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 build:

t_stub.c:34:14: error: redefinition of 'module_dirlen' with a different type: 
'unsigned int' vs 'int'
unsigned int module_dirlen = 0;
 ^
t_stub.c:31:5: note: previous definition is here
int module_dirlen = 0;
^
1 error generated.



-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: new release 3.4.0 - critical security release

2025-01-14 Thread rsync.project via rsync 
the alloca comes from the new popt release. What system are you having an
issue with?


On Wed, 15 Jan 2025 at 07:16,  wrote:

> A new dependency was added since 3.3, alloca(), which is not portable. Is
> there a way around this?
>
> Thanks,
>
> Randall
>
>
>
> *From:* rsync  *On Behalf Of *rsync.project
> via rsync
> *Sent:* January 14, 2025 2:49 PM
> *To:* [email protected]
> *Cc:* [email protected]
> *Subject:* new release 3.4.0 - 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 details on the vulnerabilities please see this CERT advisory:
>
>
>
> https://kb.cert.org/vuls/id/952657
>
>
>
> The various distros should be doing security releases today
>
> Many thanks to Simon Scannell, Pedro Gallegos, and Jasiel Spelman at
> Google Cloud Vulnerability Research and Aleksei Gorban (Loqpa) for
> discovering these vulnerabilities and working with the rsync project to
> develop and test fixes.
>
>
>
> Also many thanks to Wayne Davison for assisting with the release process
> as this is the first release I've done since 2002 when Wayne took over as
> the rsync maintainer.
>
>
>
> Andrew Tridgell
>
> rsync maintainer (again!)
>
>
>
>
>
-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

RE: new release 3.4.0 - critical security release

2025-01-14 Thread Randall S. Becker via rsync 
A new dependency was added since 3.3, alloca(), which is not portable. Is there 
a way around this?

Thanks,

Randall

 

From: rsync  On Behalf Of rsync.project via rsync
Sent: January 14, 2025 2:49 PM
To: [email protected]
Cc: [email protected]
Subject: new release 3.4.0 - 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 details on the vulnerabilities please see this CERT advisory:

 

https://kb.cert.org/vuls/id/952657

 

The various distros should be doing security releases today

Many thanks to Simon Scannell, Pedro Gallegos, and Jasiel Spelman at Google 
Cloud Vulnerability Research and Aleksei Gorban (Loqpa) for discovering these 
vulnerabilities and working with the rsync project to develop and test fixes.

 

Also many thanks to Wayne Davison for assisting with the release process as 
this is the first release I've done since 2002 when Wayne took over as the 
rsync maintainer.

 

Andrew Tridgell

rsync maintainer (again!)

 

 

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: new release 3.4.0 - critical security release

2025-01-14 Thread Charalampos Mitrodimas via rsync 
"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/
>  - https://download.samba.org/pub/rsync/src/
>
> For details on the vulnerabilities please see this CERT advisory:
>
> https://kb.cert.org/vuls/id/952657

The vulnerabilities note was only posted today; great job addressing it
so quickly

C. Mitrodimas
>
> The various distros should be doing security releases today
> Many thanks to Simon Scannell, Pedro Gallegos, and Jasiel Spelman at Google 
> Cloud Vulnerability Research
> and Aleksei Gorban (Loqpa) for discovering these vulnerabilities and working 
> with the rsync project to
> develop and test fixes.
>
> Also many thanks to Wayne Davison for assisting with the release process as 
> this is the first release I've
> done since 2002 when Wayne took over as the rsync maintainer.
>
> Andrew Tridgell
> rsync maintainer (again!)

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

new release 3.4.0 - critical security release

2025-01-14 Thread rsync.project via rsync 
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 see this CERT advisory:

https://kb.cert.org/vuls/id/952657

The various distros should be doing security releases today
Many thanks to Simon Scannell, Pedro Gallegos, and Jasiel Spelman at Google
Cloud Vulnerability Research and Aleksei Gorban (Loqpa) for discovering
these vulnerabilities and working with the rsync project to develop and
test fixes.

Also many thanks to Wayne Davison for assisting with the release process as
this is the first release I've done since 2002 when Wayne took over as the
rsync maintainer.

Andrew Tridgell
rsync maintainer (again!)
-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html