Re: XZ Utils Compromised Releases

On Fri, 29 Mar 2024, Blair Zajac wrote: I’m seeing it at 5.6.1 in our GitHub repoisory: https://github.com/macports/macports-ports/blob/master/archivers/xz/Portfile Ah, OK. The 5.4.6 was based on a selfupdate from two days ago. On Mar 29, 2024, at 10:40 AM, Fred Wright wrote: CCing

Re: XZ Utils Compromised Releases

On Fri, 29 Mar 2024 18:50:35 +0100, Rainer Müller wrote: > > > In [1] they mention reverting to 5.4.5 to fix it.  It's not 100% clear > > from that whether 5.4.6 is affected, but it sounds like it's not.  Since > > MacPorts is currently at 5.4.6, the port is probably OK as long as it > > doesn't

Re: XZ Utils Compromised Releases

A friendly reminder: if there's an issue, please file a ticket! The one exception to that is if there's a vulnerability that has not been made public, in which case contacting the port maintainer and possibly portmgr privately is appropriate. Discussing issues on the mailing lists,

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

In general, the more a given system deviates from the main herd of ports, the more likely there are to be problems and the less likely they are to be fixed. To be honest, I don’t see why a new gcc port to be used only for powerpc is needed. My only question is whether to skip over gcc8-12, or

Re: XZ Utils Compromised Releases

On 29/03/2024 18.52, Blair Zajac wrote: > In https://www.openwall.com/lists/oss-security/2024/03/29/4 >  it says > > == Bug reports == > > Given the apparent upstream involvement I have not reported an upstream > bug…. > > >

Re: XZ Utils Compromised Releases

In https://www.openwall.com/lists/oss-security/2024/03/29/4 it says == Bug reports == Given the apparent upstream involvement I have not reported an upstream bug…. I suggest not waiting for an upstream release and instead revert our commit and add an epoch line. Blair > On Mar 29, 2024, at

Re: XZ Utils Compromised Releases

On 29/03/2024 18.40, Fred Wright wrote: > > On Fri, 29 Mar 2024, Frank Dean wrote: > >> I received a security announcement on the Debian mailing list [1].  It >> appears versions 5.6.0 of XY Utils and later may be compromised.  I >> also found a discussion on Openwall [2]. >> >> >> [1]: >>

Re: XZ Utils Compromised Releases

I’m seeing it at 5.6.1 in our GitHub repoisory: https://github.com/macports/macports-ports/blob/master/archivers/xz/Portfile We should roll it back to an older release and bump the epoch so everyone sees the rollback. Blair > On Mar 29, 2024, at 10:40 AM, Fred Wright wrote: > > > On Fri,

Re: XZ Utils Compromised Releases

On Fri, 29 Mar 2024, Frank Dean wrote: I received a security announcement on the Debian mailing list [1]. It appears versions 5.6.0 of XY Utils and later may be compromised. I also found a discussion on Openwall [2]. [1]:

XZ Utils Compromised Releases

I received a security announcement on the Debian mailing list [1]. It appears versions 5.6.0 of XY Utils and later may be compromised. I also found a discussion on Openwall [2]. [1]: https://lists.debian.org/debian-security-announce/2024/msg00057.html

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

Well, the PR is either merged or not merged :) I think my proposal addresses all possible rational concerns. If irrational concerns will happen to dominate, well, I can’t do anything about that. > On Mar 29, 2024, at 7:47 PM, Ken Cunningham > wrote: > > I am not a MacPorts admin, however I

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

I am not a MacPorts admin, however I believe they were pretty clear that 10.6-ppc-specific fixes belong in an overlay repo, not in macports code. If you want that changed, take it up with them. I personally agree with that decision, so I abide by it, until such time as it changes. K > On

Re: 10.5 and gcc8 x86-64 ok but ppc bails with dlerror

Ken, the last time you objected to having gcc10-bootstrap building for ppc on 10.6 in gcc13 port. Because that was extra 10 characters of code in the macro, which was too ugly to tolerate, apparently. (It was needed for 10.6.8 Rosetta just as much, of course: we cannot use clangs on any