Re: XZ Utils Compromised Releases

[Fred Wright]

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 the users list so they don't panic. :-)


That didn't work since I don't subscribe to that list.  Someone should 
post something there, since the original message was.


Fred Wright

Re: XZ Utils Compromised Releases

[Kirill A . Korinsky]

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 do any overzealous upgrading.
> 
> The xz port was updated to 5.6.1 just two days ago:
> https://github.com/macports/macports-ports/commit/784e59f99e51adbadc663b1b689d66363adf193a
> 
> Based on the current information, the risk seems low for macOS system.
> Should we still be cautious and revert to version 5.4.6 and bump the
> epoch to force a downgrade for everyone? Or do we expect a new upstream
> release soon to sort this out?
> 

Better to rollback version and communicate somehow that it is paranoia.

-- 
wbr, Kirill

Re: XZ Utils Compromised Releases

[Joshua Root]

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, commenting about them on PRs, or 
chatting about them on IRC are all fine, but none are a substitute for a 
Trac ticket. :)


- Josh

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

[Ken Cunningham]

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 include them.

If we skip over gcc8-12, we can probably have a new release that uses gcc13 as 
the primary gcc on all systems in macports done by Monday. Less maybe. Last 
time I jumped the version, it took me an hour.

And then — no more worries. Existing macports base infrastructure will just 
work as it is. Some fairly minor tweaking of what compilers are available on 
which systems will be done.

If we have to fix all the gcc versions between gcc8 and 12 — well that will 
take a bit more time to fix and to build.

For Riccardo’s bug, we always knew the gcc JIT was fragile on 32 bit systems. 
It probably needs to be disabled there by tweaking this block in the gcc8 
Portfile:

if {${subport} eq "gcc8"} {

# the jit is not building on i386 systems
# see https://trac.macports.org/ticket/61130
if {${build_arch} ne "i386"} {
lappend gcc_configure_langs jit
}

}

Maybe that’s all it needs.




Ken




> On Mar 29, 2024, at 4:50 AM, Sergio Had  wrote:
> 
> Well, the PR is either merged or not merged :)
> 

Re: XZ Utils Compromised Releases

[Rainer Müller]

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….
> 
> 
> I suggest not waiting for an upstream release and instead revert our
> commit and add an epoch line.

You are right. That is the best way as we cannot be sure what else just
has not been discovered in the backdoor-ed releases.

Joshua already pushed the downgrade to xz @5.4.6 with the epoch bumped.
Thank you!

https://trac.macports.org/ticket/69619
https://github.com/macports/macports-ports/commit/a1388aee09c9e921e3a9d47cf9d37e5d3f3c10ad

Rainer

Re: XZ Utils Compromised Releases

[Blair Zajac]

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 10:50 AM, Rainer Müller  wrote:
> 
> 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]:
>>> https://lists.debian.org/debian-security-announce/2024/msg00057.html
>>> 
>>> 
>>> [2]: https://www.openwall.com/lists/oss-security/2024/03/29/4
>>> 
>>> 
>>> 
>>> I'm afraid that's all I know.  Just a heads-up.
> 
> Wow. That's an awful story.
> 
> The exploit seems to specifically target Linux systems only ("[...] it
> is likely the backdoor can only work on glibc based systems.").
> 
>> 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 do any overzealous upgrading.
> 
> The xz port was updated to 5.6.1 just two days ago:
> https://github.com/macports/macports-ports/commit/784e59f99e51adbadc663b1b689d66363adf193a
> 
> Based on the current information, the risk seems low for macOS system.
> Should we still be cautious and revert to version 5.4.6 and bump the
> epoch to force a downgrade for everyone? Or do we expect a new upstream
> release soon to sort this out?


> 
> Rainer
> 

Re: XZ Utils Compromised Releases

[Rainer Müller]

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]:
>> https://lists.debian.org/debian-security-announce/2024/msg00057.html
>> 
>>
>> [2]: https://www.openwall.com/lists/oss-security/2024/03/29/4
>> 
>>
>>
>> I'm afraid that's all I know.  Just a heads-up.

Wow. That's an awful story.

The exploit seems to specifically target Linux systems only ("[...] it
is likely the backdoor can only work on glibc based systems.").

> 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 do any overzealous upgrading.

The xz port was updated to 5.6.1 just two days ago:
https://github.com/macports/macports-ports/commit/784e59f99e51adbadc663b1b689d66363adf193a

Based on the current information, the risk seems low for macOS system.
Should we still be cautious and revert to version 5.4.6 and bump the
epoch to force a downgrade for everyone? Or do we expect a new upstream
release soon to sort this out?

Rainer

Re: XZ Utils Compromised Releases

[Blair Zajac]

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, 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]: https://lists.debian.org/debian-security-announce/2024/msg00057.html 
>> 
>> 
>> [2]: https://www.openwall.com/lists/oss-security/2024/03/29/4 
>> 
>> 
>> 
>> I'm afraid that's all I know.  Just a heads-up.
> 
> 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 do any 
> overzealous upgrading.
> 
> CCing the users list so they don't panic. :-)
> 
> Fred Wright
> 

Re: XZ Utils Compromised Releases

[Fred Wright]

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]: https://lists.debian.org/debian-security-announce/2024/msg00057.html 


[2]: https://www.openwall.com/lists/oss-security/2024/03/29/4 



I'm afraid that's all I know.  Just a heads-up.


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 do any overzealous upgrading.


CCing the users list so they don't panic. :-)

Fred Wright

XZ Utils Compromised Releases

[Frank Dean]

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 


[2]: https://www.openwall.com/lists/oss-security/2024/03/29/4 



I'm afraid that's all I know.  Just a heads-up.

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

[Sergio Had]

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 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 Mar 29, 2024, at 04:00, Sergio Had  wrote:
>> 
>> 
>> 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 powerpc, be it released macOS or pre-released.)
>> 
>> Anyway, what I suggest is the following:
>> 
>> 1. Keep Rosetta and 10.6 ppc stuff out of existing gcc ports. Those will be 
>> only for 10.4–10.5 on PowerPC, which is what you want, AFAIU. No “spaghetti 
>> code”, which you dislike.
>> 2. I make a separate gcc-powerpc port, analogous to gcc-devel, where I can 
>> add tweaks I want, and restrict that port to PowerPC. Throw away everything 
>> unneeded from there, make it easy to maintain.
>> 
>> To that separate port I can add support for libc++ on PowerPC, fix IEEE 
>> arithmetic in Fortran, support 10.6 ppc and Rosetta, and whats not. Which 
>> will not land into any other gcc ports, unless someone else – not me – 
>> decides to pick that.
>> 
>> As I bonus I (and whomever decides to use it) can avoid unnecessary 
>> revbumps, wasting many hours of compilation time for nothing, and on the 
>> other hand revbump powerpc port without causing pain to anyone else.
>> 
>> I honestly hope this can keep everyone satisfied.
>> 
>> I also hope you can cooperate with me then to move 10.4–10.5 to libgcc13, 
>> since we should not have a disagreement anymore.
>> 
>> 
>>> On Mar 29, 2024, at 5:34 AM, Ken Cunningham 
>>>  wrote:
>>> 
>>> I was not aware that supporting the bootleg crippled 10.6 PPC pre-beta had 
>>> anything to do with why nobody had gotten around to updating the gcc 
>>> version used on older systems.
>>> 
>>> At least, it was not anywhere on my radar.
>>> 
>>> Just -- nobody did the legwork.
>>> 
>>> Ken
>>> 
>>> 
>>> On 2024-03-28, at 11:47 AM, Sergio Had wrote:
>>> 
 Let me make another, final attempt to sort this out once for all and for 
 everyone on old systems.
 
 I got an idea how to satisfy Ken’s preference of not supporting ppc builds 
 on 10.6 in gcc ports and my need to support those.
 
 That was the stopper so far, not allowing an agreement to merge.
 
 I may do this today itself: I have everything working for months, just 
 need to sort commits to make it readable and implement a solution for what 
 I want.
 
 As a bonus, you will get IEEE intrinsics in Fortran – something that never 
 existed on ppc.
 On Mar 29, 2024 at 02:36 +0800, Sergio Had , wrote:
> You should not need gcc8. I had gcc11 working on 10.5 ppc (and ppc64 
> too). I have seen people using gcc13 on 10.5 ppc following my 
> instructions from the PR.
> 
> What is the point of gcc8?
> 
> You build gcc10-bootstrap and then use it to build gcc13. Nothing else 
> needed in between.
> On Mar 28, 2024 at 23:58 +0800, Riccardo Mottola via macports-dev 
> , wrote:
>> Hi,
>> 
>> after all the talk about gcc versions, I tried to build gcc 8 here.
>> Officially it says "gcc8 is known to fail".
>> 
>> I first did just "build" on Intel 64bit and PPC 32bit - Intel 32bit
>> later, I fear my MacBook has fan issues.
>> 
>> Intel 64bit finished build! Took several hours. I thus tried to install
>> it... and it says again
>> "libgcc8 is known to fail. Try to install anyway?" and yes, it just 
>> built!
>> 
>> However then it asks about libgcc9 but I want to stay on libgcc8,
>> that was the point... am Inheriting that it will go up to gcc13?
>> 
>> 
>> On PowerPC instead build fails (and ultimate goal is to enable newer
>> gccs on PPC too, where it is needed)
>> 
>> :info:build cc1plus: warning: '-mdynamic-no-pic' overrides '-fpic',
>> '-fPIC', '-fpie' or '-fPIE'
>> :info:build
>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:
>> In member function 'gcc::jit::result*
>> gcc::jit::playback::context::dlopen_built_dso()':
>> :info:build
>> 

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

[Ken Cunningham]

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 Mar 29, 2024, at 04:00, Sergio Had  wrote:
> 
> 
> 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 powerpc, be it released macOS or pre-released.)
> 
> Anyway, what I suggest is the following:
> 
> 1. Keep Rosetta and 10.6 ppc stuff out of existing gcc ports. Those will be 
> only for 10.4–10.5 on PowerPC, which is what you want, AFAIU. No “spaghetti 
> code”, which you dislike.
> 2. I make a separate gcc-powerpc port, analogous to gcc-devel, where I can 
> add tweaks I want, and restrict that port to PowerPC. Throw away everything 
> unneeded from there, make it easy to maintain.
> 
> To that separate port I can add support for libc++ on PowerPC, fix IEEE 
> arithmetic in Fortran, support 10.6 ppc and Rosetta, and whats not. Which 
> will not land into any other gcc ports, unless someone else – not me – 
> decides to pick that.
> 
> As I bonus I (and whomever decides to use it) can avoid unnecessary revbumps, 
> wasting many hours of compilation time for nothing, and on the other hand 
> revbump powerpc port without causing pain to anyone else.
> 
> I honestly hope this can keep everyone satisfied.
> 
> I also hope you can cooperate with me then to move 10.4–10.5 to libgcc13, 
> since we should not have a disagreement anymore.
> 
> 
>> On Mar 29, 2024, at 5:34 AM, Ken Cunningham 
>>  wrote:
>> 
>> I was not aware that supporting the bootleg crippled 10.6 PPC pre-beta had 
>> anything to do with why nobody had gotten around to updating the gcc version 
>> used on older systems.
>> 
>> At least, it was not anywhere on my radar.
>> 
>> Just -- nobody did the legwork.
>> 
>> Ken
>> 
>> 
>>> On 2024-03-28, at 11:47 AM, Sergio Had wrote:
>>> 
>>> Let me make another, final attempt to sort this out once for all and for 
>>> everyone on old systems.
>>> 
>>> I got an idea how to satisfy Ken’s preference of not supporting ppc builds 
>>> on 10.6 in gcc ports and my need to support those.
>>> 
>>> That was the stopper so far, not allowing an agreement to merge.
>>> 
>>> I may do this today itself: I have everything working for months, just need 
>>> to sort commits to make it readable and implement a solution for what I 
>>> want.
>>> 
>>> As a bonus, you will get IEEE intrinsics in Fortran – something that never 
>>> existed on ppc.
 On Mar 29, 2024 at 02:36 +0800, Sergio Had , wrote:
 You should not need gcc8. I had gcc11 working on 10.5 ppc (and ppc64 too). 
 I have seen people using gcc13 on 10.5 ppc following my instructions from 
 the PR.
 
 What is the point of gcc8?
 
 You build gcc10-bootstrap and then use it to build gcc13. Nothing else 
 needed in between.
> On Mar 28, 2024 at 23:58 +0800, Riccardo Mottola via macports-dev 
> , wrote:
> Hi,
> 
> after all the talk about gcc versions, I tried to build gcc 8 here.
> Officially it says "gcc8 is known to fail".
> 
> I first did just "build" on Intel 64bit and PPC 32bit - Intel 32bit
> later, I fear my MacBook has fan issues.
> 
> Intel 64bit finished build! Took several hours. I thus tried to install
> it... and it says again
> "libgcc8 is known to fail. Try to install anyway?" and yes, it just built!
> 
> However then it asks about libgcc9 but I want to stay on libgcc8,
> that was the point... am Inheriting that it will go up to gcc13?
> 
> 
> On PowerPC instead build fails (and ultimate goal is to enable newer
> gccs on PPC too, where it is needed)
> 
> :info:build cc1plus: warning: '-mdynamic-no-pic' overrides '-fpic',
> '-fPIC', '-fpie' or '-fPIE'
> :info:build
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:
> In member function 'gcc::jit::result*
> gcc::jit::playback::context::dlopen_built_dso()':
> :info:build
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:2599:3:
> error: 'dlerror' was not declared in this scope
> :info:build dlerror ();
> :info:build ^~~
> 
> 
> Already seen this? Full build log is 6.7MB
> Should I open a ticket on this or is there already one for gcc8 efforts?
> didn't find it.
> 
> Riccardo
>> 
> 

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

[Sergio Had]

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 powerpc, be it released macOS or pre-released.)

Anyway, what I suggest is the following:

1. Keep Rosetta and 10.6 ppc stuff out of existing gcc ports. Those will be 
only for 10.4–10.5 on PowerPC, which is what you want, AFAIU. No “spaghetti 
code”, which you dislike.
2. I make a separate gcc-powerpc port, analogous to gcc-devel, where I can add 
tweaks I want, and restrict that port to PowerPC. Throw away everything 
unneeded from there, make it easy to maintain.

To that separate port I can add support for libc++ on PowerPC, fix IEEE 
arithmetic in Fortran, support 10.6 ppc and Rosetta, and whats not. Which will 
not land into any other gcc ports, unless someone else – not me – decides to 
pick that.

As I bonus I (and whomever decides to use it) can avoid unnecessary revbumps, 
wasting many hours of compilation time for nothing, and on the other hand 
revbump powerpc port without causing pain to anyone else.

I honestly hope this can keep everyone satisfied.

I also hope you can cooperate with me then to move 10.4–10.5 to libgcc13, since 
we should not have a disagreement anymore.


> On Mar 29, 2024, at 5:34 AM, Ken Cunningham  
> wrote:
> 
> I was not aware that supporting the bootleg crippled 10.6 PPC pre-beta had 
> anything to do with why nobody had gotten around to updating the gcc version 
> used on older systems.
> 
> At least, it was not anywhere on my radar.
> 
> Just -- nobody did the legwork.
> 
> Ken
> 
> 
> On 2024-03-28, at 11:47 AM, Sergio Had wrote:
> 
>> Let me make another, final attempt to sort this out once for all and for 
>> everyone on old systems.
>> 
>> I got an idea how to satisfy Ken’s preference of not supporting ppc builds 
>> on 10.6 in gcc ports and my need to support those.
>> 
>> That was the stopper so far, not allowing an agreement to merge.
>> 
>> I may do this today itself: I have everything working for months, just need 
>> to sort commits to make it readable and implement a solution for what I want.
>> 
>> As a bonus, you will get IEEE intrinsics in Fortran – something that never 
>> existed on ppc.
>> On Mar 29, 2024 at 02:36 +0800, Sergio Had , wrote:
>>> You should not need gcc8. I had gcc11 working on 10.5 ppc (and ppc64 too). 
>>> I have seen people using gcc13 on 10.5 ppc following my instructions from 
>>> the PR.
>>> 
>>> What is the point of gcc8?
>>> 
>>> You build gcc10-bootstrap and then use it to build gcc13. Nothing else 
>>> needed in between.
>>> On Mar 28, 2024 at 23:58 +0800, Riccardo Mottola via macports-dev 
>>> , wrote:
 Hi,
 
 after all the talk about gcc versions, I tried to build gcc 8 here.
 Officially it says "gcc8 is known to fail".
 
 I first did just "build" on Intel 64bit and PPC 32bit - Intel 32bit
 later, I fear my MacBook has fan issues.
 
 Intel 64bit finished build! Took several hours. I thus tried to install
 it... and it says again
 "libgcc8 is known to fail. Try to install anyway?" and yes, it just built!
 
 However then it asks about libgcc9 but I want to stay on libgcc8,
 that was the point... am Inheriting that it will go up to gcc13?
 
 
 On PowerPC instead build fails (and ultimate goal is to enable newer
 gccs on PPC too, where it is needed)
 
 :info:build cc1plus: warning: '-mdynamic-no-pic' overrides '-fpic',
 '-fPIC', '-fpie' or '-fPIE'
 :info:build
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:
 In member function 'gcc::jit::result*
 gcc::jit::playback::context::dlopen_built_dso()':
 :info:build
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/gcc8/work/gcc-8.5.0/gcc/jit/jit-playback.c:2599:3:
 error: 'dlerror' was not declared in this scope
 :info:build dlerror ();
 :info:build ^~~
 
 
 Already seen this? Full build log is 6.7MB
 Should I open a ticket on this or is there already one for gcc8 efforts?
 didn't find it.
 
 Riccardo
>