Re: [agi] Can symbolic approach entirely replace NN approach?

[Rob Freeman]

James,

For relevance to type theories in programming I like Bartosz
Milewski's take on it here. An entire lecture series, but the part
that resonates with me is in the introductory lecture:

"maybe composability is not a property of nature"

Cued up here:

Category Theory 1.1: Motivation and Philosophy
Bartosz Milewski
https://youtu.be/I8LbkfSSR58?si=nAPc1f0unpj8i2JT=2734

Also Rich Hickey, the creator of Clojure language, had some nice
interpretations in some of his lectures, where he argued for the
advantages of functional languages over object oriented languages.
Basically because, in my interpretation, the "objects" can only ever
be partially "true".

Maybe summarized well here:

https://twobithistory.org/2019/01/31/simula.html

Or here:

https://www.flyingmachinestudios.com/programming/the-unofficial-guide-to-rich-hickeys-brain/

Anyway, the code guys are starting to notice it too.

-Rob

On Fri, May 17, 2024 at 7:25 AM James Bowery  wrote:
>
> First, fix quantum logic:
>
> https://web.archive.org/web/20061030044246/http://www.boundaryinstitute.org/articles/Dynamical_Markov.pdf
>
> Then realize that empirically true cases can occur not only in multiplicity 
> (OR), but with structure that includes the simultaneous (AND) measurement 
> dimensions of those cases.
>
> But don't tell anyone because it might obviate the risible tradition of 
> so-called "type theories" in both mathematics and programming languages 
> (including SQL and all those "fuzzy logic" kludges) and people would get 
> really pissy at you.

--
Artificial General Intelligence List: AGI
Permalink: 
https://agi.topicbox.com/groups/agi/T682a307a763c1ced-Mea3f554271a532a282d58fa0
Delivery options: https://agi.topicbox.com/groups/agi/subscription

[jira] [Resolved] (CXF-9014) org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH OpenJDK

[Freeman Yue Fang (Jira)]

 [ 
https://issues.apache.org/jira/browse/CXF-9014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Freeman Yue Fang resolved CXF-9014.
---
Fix Version/s: 4.1.0
   Resolution: Fixed

> org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH 
> OpenJDK
> 
>
> Key: CXF-9014
> URL: https://issues.apache.org/jira/browse/CXF-9014
> Project: CXF
>  Issue Type: Test
>Affects Versions: 4.0.4
>Reporter: Jamie Mark Goodyear
>Assignee: Freeman Yue Fang
>Priority: Minor
> Fix For: 4.1.0
>
> Attachments: bob-modified.jks, request-with-comment.xml, 
> request-with-trailing-whitespace.xml
>
>
> org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH 
> OpenJDK.
> In a full build of CXF 4.1.x (main) the SignatureWhitespaceTest suite will 
> fail when built on RH OpenJDK.
> Likely due to certs/algorithms supported by RH (see CXF-9006).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9014) org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH OpenJDK

[Freeman Yue Fang (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-9014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846667#comment-17846667
 ] 

Freeman Yue Fang commented on CXF-9014:
---

PR is
https://github.com/apache/cxf/pull/1875

> org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH 
> OpenJDK
> 
>
> Key: CXF-9014
> URL: https://issues.apache.org/jira/browse/CXF-9014
> Project: CXF
>  Issue Type: Test
>Affects Versions: 4.0.4
>Reporter: Jamie Mark Goodyear
>Assignee: Freeman Yue Fang
>Priority: Minor
> Attachments: bob-modified.jks, request-with-comment.xml, 
> request-with-trailing-whitespace.xml
>
>
> org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH 
> OpenJDK.
> In a full build of CXF 4.1.x (main) the SignatureWhitespaceTest suite will 
> fail when built on RH OpenJDK.
> Likely due to certs/algorithms supported by RH (see CXF-9006).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (CXF-9014) org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH OpenJDK

[Freeman Yue Fang (Jira)]

 [ 
https://issues.apache.org/jira/browse/CXF-9014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Freeman Yue Fang reassigned CXF-9014:
-

Assignee: Freeman Yue Fang

> org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH 
> OpenJDK
> 
>
> Key: CXF-9014
> URL: https://issues.apache.org/jira/browse/CXF-9014
> Project: CXF
>  Issue Type: Test
>Affects Versions: 4.0.4
>Reporter: Jamie Mark Goodyear
>Assignee: Freeman Yue Fang
>Priority: Minor
> Attachments: bob-modified.jks, request-with-comment.xml, 
> request-with-trailing-whitespace.xml
>
>
> org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH 
> OpenJDK.
> In a full build of CXF 4.1.x (main) the SignatureWhitespaceTest suite will 
> fail when built on RH OpenJDK.
> Likely due to certs/algorithms supported by RH (see CXF-9006).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9014) org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH OpenJDK

[Freeman Yue Fang (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-9014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846625#comment-17846625
 ] 

Freeman Yue Fang commented on CXF-9014:
---

Thanks [~jgoodyear] for the confirmation, I will send PR soon

Freeman

> org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH 
> OpenJDK
> 
>
> Key: CXF-9014
> URL: https://issues.apache.org/jira/browse/CXF-9014
> Project: CXF
>  Issue Type: Test
>Affects Versions: 4.0.4
>Reporter: Jamie Mark Goodyear
>Priority: Minor
> Attachments: bob-modified.jks, request-with-comment.xml, 
> request-with-trailing-whitespace.xml
>
>
> org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH 
> OpenJDK.
> In a full build of CXF 4.1.x (main) the SignatureWhitespaceTest suite will 
> fail when built on RH OpenJDK.
> Likely due to certs/algorithms supported by RH (see CXF-9006).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (CXF-9014) org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH OpenJDK

[Freeman Yue Fang (Jira)]

 [ 
https://issues.apache.org/jira/browse/CXF-9014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Freeman Yue Fang updated CXF-9014:
--
Attachment: bob-modified.jks
request-with-comment.xml
request-with-trailing-whitespace.xml

> org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH 
> OpenJDK
> 
>
> Key: CXF-9014
> URL: https://issues.apache.org/jira/browse/CXF-9014
> Project: CXF
>  Issue Type: Test
>Affects Versions: 4.0.4
>Reporter: Jamie Mark Goodyear
>Priority: Minor
> Attachments: bob-modified.jks, request-with-comment.xml, 
> request-with-trailing-whitespace.xml
>
>
> org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH 
> OpenJDK.
> In a full build of CXF 4.1.x (main) the SignatureWhitespaceTest suite will 
> fail when built on RH OpenJDK.
> Likely due to certs/algorithms supported by RH (see CXF-9006).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9014) org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH OpenJDK

[Freeman Yue Fang (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-9014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846455#comment-17846455
 ] 

Freeman Yue Fang commented on CXF-9014:
---

Hi [~jgoodyear],

Thanks for reporting this, I believe this is because in bob-modified.jks(used 
in SignatureWhitespaceTest) it use Subject Public Key Algorithm: 1024-bit RSA 
key (weak) and isn't allowed in modern JDK versions. So I regenerated 
bob-modified.jks with with RSA 2048/sha256. 

Please see attached affected files, could you please override the those in 
systests/ws-security/src/test/resources/org/apache/cxf/systest/ws/action folder 
and retest it?

Thanks!
Freeman

> org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH 
> OpenJDK
> 
>
> Key: CXF-9014
> URL: https://issues.apache.org/jira/browse/CXF-9014
> Project: CXF
>  Issue Type: Test
>Affects Versions: 4.0.4
>Reporter: Jamie Mark Goodyear
>Priority: Minor
> Attachments: bob-modified.jks, request-with-comment.xml, 
> request-with-trailing-whitespace.xml
>
>
> org.apache.cxf.systest.ws.action.SignatureWhitespaceTest test fail on RH 
> OpenJDK.
> In a full build of CXF 4.1.x (main) the SignatureWhitespaceTest suite will 
> fail when built on RH OpenJDK.
> Likely due to certs/algorithms supported by RH (see CXF-9006).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [gentoo-user] Encrypted drives, password generation and management howto, guide.

[Rich Freeman]

On Tue, May 14, 2024 at 7:28 AM Dale  wrote:
>
> First, I needed to generate a password.

Honestly, I'd stop right there, and think about WHY you're encrypting
your disks, and WHY you need a password to decrypt them.  There are
many use cases and threat models to consider.

I have a whole bunch of encrypted drives on my Ceph cluster, and none
of them have a traditional "password" and I couldn't tell you what any
of them are.  They're keys stored in files on the OS drive, and I do
have a backup of them as well.  I don't have to go looking up anything
to do anything because the file is referenced in crypttab and so LUKS
just does its thing during boot.

Obviously anybody who has physical access to the host can decrypt the
drives.  The OS disks aren't even encrypted.  So why bother? Well, my
threat model is this - I have huge amounts of data on disks, and disks
eventually fail, and they're a real pain to wipe, especially if
they've failed.  With my solution, those physical disks are completely
unreadable when separated from the OS drive.  There is no risk of
brute-force attacks as there is no memorable passphrase to crack -
they're just random keys, so it is a basic brute force attack on AES
itself.  When things need rebooting I don't need to be present to type
anything in, and I don't need any fancy TPM-based solutions to make
that possible either.

The more traditional approach uses memorable passphrases, and for that
you can use pwgen, or xkcdpass.  Or you can just come up with
something memorable but not likely to be guessed, with plenty of
rounds.

The most common approach (outside of Linux) is to use a TPM to manage
the key with verified boot.  This is possible on Linux, but no distro
I'm aware of other than maybe ChromeOS does it (and ChromeOS doesn't
really do it the traditional way).  This lets you have a desktop that
makes the disk unreadable when separated from the PC, and it can only
be read if the disk is booted normally.  It is a very elegant
solution, assuming you trust the security of the TPM, but without
distro support I probably wouldn't mess with it.  On Windows it is
very common, and on ChromeOS it isn't even optional - they all do it.

-- 
Rich

Re: [agi] α, αGproton, Combinatorial Hierarchy, Computational Irreducibility and other things that just don't matter to reaching AGI

[Rob Freeman]

In the corporate training domain, you must have come across Edward de
Bono? I recall he also focuses on discontinuous change and novelty.

Certainly I would say there is broad scope for the application of,
broadly quantum flavoured, AI based insights about meaning in broader
society. Not just project management. But not knowing how your
"Essence" works, I can't comment how much that coincides with what I
see.

There's a lot of woo woo which surrounds quantum, so I try to use
analogies sparingly. But for ways to present it, you might look at Bob
Coecke's books. I believe he has invented a whole visual,
diagrammatic, system for talking about quantum systems. He is proud of
having used it to teach high school students. The best reference for
that might be his book "Picturing Quantum Processes".

Thanks for your interest in reading more about the solutions I see. I
guess I've been lazy in not putting out more formal presentations.
Most of what I have written has been fairly technical, and directed at
language modeling.

The best non-technical summary might be an essay I posted on substack, end '22:

https://robertjohnfreeman.substack.com/p/essay-response-to-question-which

That touches briefly on the broader social implications of subjective
truth, and how a subjective truth which is emergent of objective
structural principles, might provide a new objective social consensus.

On quantum indeterminacy emerging from the complexity of combinations
of perfectly classical and observable elements, I tried to present
myself in contrast to Bob Coecke's top-down quantum grammar approach,
on the Entangled Things podcast:

https://www.entangledthings.com/entangled-things-rob-freeman

You could look at my Facebook group, Oscillating Networks for AI.
Check out my Twitter, @rob_freeman.

Technically, the best summary is probably still my AGI-21
presentation. Here's the workshop version of that, with discussion at
the end:

https://www.youtube.com/watch?v=YiVet-b-NM8

On Fri, May 10, 2024 at 9:18 PM Quan Tesla  wrote:
>
> Rob.
>
> Thank you for being candid. My verbage isn't deliberate. I don't seek 
> traction, or funding for what I do. There's no real justification for your 
> mistrust.
>
> Perhaps, let me provide some professional background instead. As an 
> independent researcher, I follow scientific developments among multiple 
> domains, seeking coherence and sense-making for my own scientific endeavor, 
> spanning 25 years. AGI has been a keen interest of mine since 2013. For AGI, 
> I advocate pure machine consciousness, shying away from biotech approaches.
>
> My field of research interest stems from a previous career in cross-cultural 
> training, and the many challenges it presented in the 80's. As 
> designer/administrator/manager and trainer, one could say I fell in love with 
> optimal learning methodologies and associated technologies.
>
> Changing careers, I started in mainframe operating to advance to programming, 
> systems analysis and design, information and business engineering and 
> ultimately contracting consultant. My one, consistent research area remained 
> knowledge engineering, especialky tacit-knowledge engineering. Today, I 
> promote the idea for a campus specializing in quantum systems engineering. 
> I'm generally regarded as being a pracademic of sorts.
>
> Like many of us practitioners here, I too was fortunate to learn with a 
> number of founders and world-class methodologists.
>
> In 1998, my job in banking was researcher/architect to the board of a 5-bank 
> merger, today part of the Barclays Group. As futurist architect and peer 
> reviewer, I was introduced to quantum physics. Specifically, in context of 
> the discovery of the quark.
>
> I realized that future, exponential complexity was approaching, especially 
> for knowledge organizations. I researched possible solutions worldwide, but 
> found none at that time, which concerned me deeply.
>
> Industries seemed to be rushing into the digital revolution without a 
> rekiable, methodological management foundation in place. As architect, I had 
> nothing to offer as a useful, 10-year futures outlook either. I didn't feel 
> competent to be the person to address that apparent gap.
>
> A good colleague of mine was a proven IE methodologist and consultant to IBM 
> Head Office. I approached him twice with my concerns, asking him to adapt his 
> proven IE methodogy to address the advancing future. He didn't take my 
> concerns seriously at all.
>
> For the next year, the future seemed ever-more clearer to me, yet I couldn't 
> find anyone to develop a future aid for enterprises as a roadmap toolkit, or 
> a coping mechanism for a complex-adaptive reality.  The world was hung up on 
> UML and Object oriented technologies.
>
> In desperation, I decided h

Re: [agi] α, αGproton, Combinatorial Hierarchy, Computational Irreducibility and other things that just don't matter to reaching AGI

[Rob Freeman]

Quan. You may be talking sense, but you've got to tone down the
buzzwords by a whole bunch. It's suspicious when you jam so many in
together.

If you think there's a solution there, what are you doing about it in practice?

Be more specific. For instance, within the span of what I understand
here I might guess at relevance for Coecke's "Togetherness":

>From quantum foundations via natural language meaning to a theory of everything
https://arxiv.org/pdf/1602.07618.pdf

Or Tomas Mikolov's (key instigator of word2vec?) attempts to get
funding to explore evolutionary computational automata.

Tomas Mikolov - "We can design systems where complexity seems to be
growing" (Another one from AGI-21. It can be hard to motivate yourself
to listen to a whole conference, but when you pay attention, there can
be interesting stuff on the margins.)
https://youtu.be/CnsqHSCBgX0?t=10859

There's also an Artificial Life, ALife, community. Which seems to be
quite big in Japan. A group down in Okinawa under Tom Froese, anyway.
(Though they seem to go right off the edge and focus on some kind of
community consciousness.) But also in the ALife category I think of
Bert Chan, recently moved to Google(?).

https://biofish.medium.com/lenia-beyond-the-game-of-life-344847b10a72

All of that. And what Dreyfus called Heideggerian AI. Associated with
Rodney Brooks, and his "Fast, Cheap, and Out of Control", Artificial
Organism bots. It had a time in Europe especially, Luc Steels, Rolf
Pfeifer? The recently lost Daniel Dennett.

Why Heideggerian AI failed and how fixing it would require making it
more Heideggerian☆
Hubert L.Dreyfus
https://cid.nada.kth.se/en/HeideggerianAI.pdf

How would you relate what you are saying to all of these?

I'm sympathetic to them all. Though I think they miss the insight of
predictive symmetries. Which language drives you to. And what LLMs
stumbled on too. And that's held them up. Held them up for 30 years or
more.

ALife had a spike around 1995. Likely influencing Ben and his Chaotic
Logic book, too. They had the complex system idea back then, they just
didn't have a generative principle to bring it all together.

Meanwhile LLMs have kind of stumbled on the generative principle.
Though they remain stuck in the back-prop paradigm, and unable to
fully embrace the complexity.

I put myself in the context of all those threads. Though I kind of
worked back to them, starting with the language problem, and finding
the complexity as I went. As I say, language drives you to deal with
predictive symmetries. I think ALife has stalled for 30 years because
it hasn't had a central generative principle. What James might call a
"prior". Language offers a "prior" (predictive symmetries.) Combine
that with ALife complex systems, and you start to get something.

But that's to go off on my own tangent again.

Anyway, if you can be more specific, or put what you're saying in the
context of something someone else is doing, you might get more
traction.

On Thu, May 9, 2024 at 3:10 PM Quan Tesla  wrote:
>
> Rob, not butting in, but rather adding to what you said (see quotation below).
>
> The conviction across industries that hierachy (systems robustness) persist 
> only in descending and/or ascending structures, though true, can be proven to 
> be somewhat incomplete.
>
> There's another computational way to derive systems-control hierarchy(ies) 
> from. This is the quantum-engineering way (referred to before), where 
> hierachy lies hidden within contextual abstraction, identified via case-based 
> decision making and represented via compound functionality outcomes. 
> Hierarchy as a centre-outwards, in the sense of emergent, essential 
> characteristic of a scalable system. Not deterministically specified.
>
> In an evolutionary sense, hierarchies are N-nestable and self discoverable. 
> With the addition of integrated vectors, knowledge graphs may also be 
> derived, instead of crafted.
>
> Here, I'm referring to 2 systems hierarchies in particular. 'A', a hierarchy 
> of criticality (aka constraints) and 'B', a hierarchy of priority (aka 
> systemic order).
>
> Over the lifecycles of a growing system, as it mutates and evolve in 
> relevance (optimal semantics), hierarchy would start resembling - without 
> compromising -NNs and LLMs.
>
> Yes, a more-holistic envelope then, a new, quantum reality, where 
> fully-recursive functionality wasn't only guaranteed, but correlation and 
> association became foundational, architectural principles.
>
> This is the future of quantum systems engineering, which I believe quantum 
> computing would eventually lead all researchers to. Frankly, without it, 
> we'll remain stuck in the quagmire of early 1990s+ functional 
> analysis-paralysis, by any name.
>
> I'll hold out hope for that one, enlightened developer to make that quant

Re: [gentoo-user] Hard drive and PWDIS or pin 3 power disable/reset.

[Rich Freeman]

On Thu, May 9, 2024 at 5:12 PM Dale  wrote:
>
> I'm looking at buying another drive.  I'm trying to avoid buying one
> with the PWDIS pin.  I'm looking at the specs to see if it says anything
> about the feature, there or not there.  I'm not seeing anything.  This
> is what I'm looking at.
>
> https://www.seagate.com/files/www-content/datasheets/pdfs/exos-x16-DS2011-1-1904US-en_US.pdf
>
> Can someone tell me how to know when a drive has PWDIS and when it
> doesn't?  Is there some term for it that shows in the specs and I'm
> missing it?  Or is there no way to really know?

I think it would be labeled as such.  That is for a genuine retail
version of the drive with retail labeling.

So if you get the drive and it has the pretty Exos logo and green
colors and the model number that matches the datasheet and all that
stuff, then it probably won't have issues.

However, if you're buying something off ebay, and the drive just has a
plain white label, and a model number that doesn't actually match the
datasheet, but some random webpage or reddit post assures you that it
is the same thing, well, it probably is the same thing, but it might
very well have that power issue.

Those shucked drives generally come from USB enclosures, and the drive
on the inside might be a rebranded Exos with alternative firmware/etc,
but the label isn't going to actually say that, and the package will
say "EasyStore USB Drive" or whatever it is sold as.  If you use it
the way it is sold, then you again won't have issues since its
internal USB HBA will do the right thing.  It is just that when you
rip open the box that all bets are off.

The actual drives sold for enterprise use generally aren't sold in
retail packaging as I understand it.  To get one of those officially
you need to buy them through a server vendor or some other
enterprise-oriented partner, who probably has a nice sales person who
will treat you to a free lunch while you talk about the PWDIS
requirements of the $10M pallet of drives you're about to buy.

-- 
Rich

[gentoo-commits] repo/gentoo:master commit in: sys-process/systemd-cron/

[Richard Freeman]

commit: 650a30d52a41b06a9b5687c43d9e075f58066710
Author: Richard Freeman  gentoo  org>
AuthorDate: Thu May  9 10:50:57 2024 +
Commit: Richard Freeman  gentoo  org>
CommitDate: Thu May  9 10:52:44 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=650a30d5

sys-process/systemd-cron: stabilize 2.4.0 for amd64

Bug: https://bugs.gentoo.org/931626
Signed-off-by: Richard Freeman  gentoo.org>

 sys-process/systemd-cron/systemd-cron-2.4.0.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sys-process/systemd-cron/systemd-cron-2.4.0.ebuild 
b/sys-process/systemd-cron/systemd-cron-2.4.0.ebuild
index 00738f1c0e07..293661ce4869 100644
--- a/sys-process/systemd-cron/systemd-cron-2.4.0.ebuild
+++ b/sys-process/systemd-cron/systemd-cron-2.4.0.ebuild
@@ -10,7 +10,7 @@ 
SRC_URI="https://github.com/systemd-cron/${PN}/archive/v${PV}.tar.gz -> systemd-
 
 LICENSE="MIT"
 SLOT="0"
-KEYWORDS="~amd64 ~arm ~arm64 ~hppa ~ia64 ~ppc ~ppc64 ~riscv ~sparc ~x86"
+KEYWORDS="amd64 ~arm ~arm64 ~hppa ~ia64 ~ppc ~ppc64 ~riscv ~sparc ~x86"
 IUSE="cron-boot etc-crontab-systemd minutely +runparts setgid yearly"
 # We can't run the unshare tests within sandbox/with low privs, and the
 # 'test-nounshare' target just does static analysis (shellcheck etc).

Re: [agi] α, αGproton, Combinatorial Hierarchy, Computational Irreducibility and other things that just don't matter to reaching AGI

[Rob Freeman]

On Thu, May 9, 2024 at 6:15 AM James Bowery  wrote:
>
> Shifting this thread to a more appropriate topic.
>
> -- Forwarded message -
>>
>> From: Rob Freeman 
>> Date: Tue, May 7, 2024 at 8:33 PM
>> Subject: Re: [agi] Hey, looks like the goertzel is hiring...
>> To: AGI 
>
>
>> I'm disappointed you don't address my points James. You just double
>> down that there needs to be some framework for learning, and that
>> nested stacks might be one such constraint.
> ...
>> Well, maybe for language a) we can't find top down heuristics which
>> work well enough and b) we don't need to, because for language a
>> combinatorial basis is actually sitting right there for us, manifest,
>> in (sequences of) text.
>
>
> The origin of the Combinatorial Hierarchy thence ANPA was the Cambridge 
> Language Research Unit.

Interesting tip about the Cambridge Language Research Unit. Inspired
by Wittgenstein?

But this history means what?

> PS:  I know I've disappointed you yet again for not engaging directly your 
> line of inquiry.  Just be assured that my failure to do so is not because I 
> in any way discount what you are doing -- hence I'm not "doubling down" on 
> some opposing line of thought -- I'm just not prepared to defend Granger's 
> work as much as I am prepared to encourage you to take up your line of 
> thought directly with him and his school of thought.

Well, yes.

Thanks for the link to Granger's work. It looks like he did a lot on
brain biology, and developed a hypothesis that the biology of the
brain split into different regions is consistent with aspects of
language suggesting limits on nested hierarchy.

But I don't see it engages in any way with the original point I made
(in response to Matt's synopsis of OpenCog language understanding.)
That OpenCog language processing didn't fail because it didn't do
language learning (or even because it didn't attempt "semantic"
learning first.) That it was somewhat the opposite. That OpenCog
language failed because it did attempt to find an abstract grammar.
And LLMs succeed to the extent they do because they abandon a search
for abstract grammar, and just focus on prediction.

That's just my take on the OpenCog (and LLM) language situation.
People can take it or leave it.

Criticisms are welcome. But just saying, oh, but hey look at my idea
instead... Well, it might be good for people who are really puzzled
and looking for new ideas.

I guess it's a problem for AI research in general that people rarely
attempt to engage with other people's ideas. They all just assert
their own ideas. Like Matt's reply to the above... "Oh no, the real
problem was they didn't try to learn semantics..."

If you think OpenCog language failed instead because it didn't attempt
to learn grammar as nested stacks, OK, that's your idea. Good luck
trying to learn abstract grammar as nested stacks.

Actual progress in the field stumbles along by fits and starts. What's
happened in 30 years? Nothing much. A retreat to statistical
uncertainty about grammar in the '90s with HMMs? A first retreat to
indeterminacy. Then, what, 8 years ago the surprise success of
transformers, a cross-product of embedding vectors which ignores
structure and focuses on prediction. Why did it succeed? You, because
transformers somehow advance the nested stack idea? Matt, because
transformers somehow advance the semantics first idea?

My idea is that they advance the idea that a search for an abstract
grammar is flawed (in practice if not in theory.)

My idea is consistent with the ongoing success of LLMs. Which get
bigger and bigger, and don't appear to have any consistent structure.
But also their failures. That they still try to learn that structure
as a fixed artifact.

Actually, as far as I know, the first model in the LLM style of
indeterminate grammar as a cross-product of embedding vectors, was
mine.

***If anyone can point to an earlier precedent I'd love to see it.***

So LLMs feel like a nice vindication of those early ideas to me.
Without embracing the full extent of them. They still don't grasp the
full point. I don't see reason to be discouraged in it.

And it seems by chance that the idea seems consistent with the
emergent structure theme of this thread. With the difference that with
language, we have access to the emergent system, bottom-up, instead of
top down, the way we do with physics, maths.

But everyone is working on their own thing. I just got drawn in by
Matt's comment that OpenCog didn't do language learning.

-Rob

--
Artificial General Intelligence List: AGI
Permalink: 
https://agi.topicbox.com/groups/agi/Teaac2c1a9c4f4ce3-Mc80863f9a44a6d34f3ba12a6
Delivery options: https://agi.topicbox.com/groups/agi/subscription

[jira] [Commented] (CXF-9011) WSDLTo JAXWS Frontend service.vm Velocity template uses deprecated URL constructor

[Freeman Yue Fang (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-9011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844771#comment-17844771
 ] 

Freeman Yue Fang commented on CXF-9011:
---

Hi [~fjmateo],

Thanks for reporting this! A patch is welcome to address it!

Freeman

> WSDLTo JAXWS Frontend service.vm Velocity template uses deprecated URL 
> constructor
> --
>
> Key: CXF-9011
> URL: https://issues.apache.org/jira/browse/CXF-9011
> Project: CXF
>  Issue Type: Bug
>  Components: Soap Binding
>Affects Versions: 4.0.4
>Reporter: Francisco Mateo
>Priority: Minor
>
> The URL constructors were deprecated in Java 20 
> [https://bugs.openjdk.org/browse/JDK-8294241].
> The template uses the deprecated constructor: 
> [https://github.com/apache/cxf/blob/cxf-4.0.4/tools/wsdlto/frontend/jaxws/src/main/java/org/apache/cxf/tools/wsdlto/frontend/jaxws/template/service.vm#L123]
> This becomes an issue when applications compile with warnings enabled, for 
> example {{-Xlint:all -Werror}}
> Seems we could just switch to using {{URI.create(...).toURL()}} in the 
> template since that has been available since Java 1.4



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [agi] Hey, looks like the goertzel is hiring...

[Rob Freeman]

Is a quantum basis fractal?

To the extent you're suggesting some kind of quantum computation might
be a good implementation for the structures I'm suggesting, though,
yes. At least, Bob Coecke thinks quantum computation will be a good
fit for his quantum style grammar formalisms, which kind of parallel
what I'm suggesting in some ways. That's what they are working on with
their Quantinuum, Honeywell and Cambridge Quantum spin-off (recently
another 300 million from JP Morgan.) Here's a recent paper from their
language formalism team (Stephen Clark a recent hire from DeepMind, I
think, though I think Coecke did the original quantum and category
theoretic combinatorial semantics papers with him when they were
together at Oxford back from 2008 or so.)

>From Conceptual Spaces to Quantum Concepts:
Formalising and Learning Structured Conceptual Models
Sean Tull, Razin A. Shaikh, Sara Sabrina Zemljiˇc and Stephen Clark
https://browse.arxiv.org/pdf/2401.08585

Personally I think they've gone off on the wrong tangent with that. I
like the fact that Coecke has recognized a quantum indeterminacy to
natural language grammar. But I think it is pointless to try to
actually apply a quantum formalization to it. If it emerges, just let
it emerge. You don't need to formalize it at all. It's pointless to
bust a gut pushing the data into a formalism. And then bust a gut
picking the formalism apart again to "collapse" it into something
observable at run time.

But these maths guys love their formalisms. That's the approach they
are taking. And they think they need the power of quantum computation
to pull it apart again once they do it. So there's quantum computation
as a natural platform for that, yes.

For the rest of what you've written, I don't well understand what you
are saying. But if you're talking about the interpretability of the
kind of self structuring sequence networks I'm talking about,
paradoxically, allowing the symmetry groupings to emerge chaotically,
should result in more "visible" and "manageable" structure, not less.
It should give us nice, interpretable, cognitive hierarchies, objects,
concepts, etc, that you can use to do logic and reasoning, much like
the nodes of one of OpenCogs hypergraphs (it's just you need an on the
fly structuring system like I'm talking about to get adequate
representation for the nodes of an OpenCog hypergraph. They don't
exist as "primitives". Though Ben's probably right they could emerge
on top of whatever nodes he does have. But he's never had either the
computing power, or, actually the LLM like relational parameters, to
even start doing that.) So I see it as the answer for
interpretability, logic, "truthiness", and all the problems we have
now with LLMs (as well as the novelty, creativity, new "ideas" bit
associated with the complex system side.) You only get the quantum
like woo woo when you insist on squeezing the variability into a
single global formalism. Practically, the whole system should resolve
from moment to moment as clearly as the alternative perspectives of an
Escher sketch appear to us. One or the other. Clear in and of
themselves. Just that they would be able to flip to another state
discontinuously depending on context (and essentially both be there at
the same time until they are resolved.)

On Wed, May 8, 2024 at 1:00 PM Quan Tesla  wrote:
>
> If I understood your assertions correctly, then I'd think that a 
> quantum-based (fractal), evolutionary (chemistry-like) model would be 
> suitable for extending the cohesive cognition to x levels.
>
>  If the boundaried result emerges as synonymous with an LLM, or NN, then it 
> would be useful. However, if it emerges as an as-of-yet unnamed, 
> recombinatory lattice, it would be groundbreaking.
>
> My primary thought here relates to inherent constraints in visualizing 
> quantum systems. Once the debate between simple and complex systems end 
> (e.g., when an absolutist perspective is advanced), then the observational 
> system stops learning. Volume does not equate real progress.
>
> With an evolutionary model, "brainsnaps in time" may be possible. This 
> suggests  that scaling would be managable within relativistic and relevance 
> boundaries/targets.
>
> In the least, trackable evolutionary pathways and predictability of the 
> pattern of tendency of a system should become visible, and manageability 
> would be increased.

--
Artificial General Intelligence List: AGI
Permalink: 
https://agi.topicbox.com/groups/agi/Tb63883dd9d6b59cc-M210f900801eb7251599971d1
Delivery options: https://agi.topicbox.com/groups/agi/subscription

Re: [agi] Hey, looks like the goertzel is hiring...

[Rob Freeman]

I'm disappointed you don't address my points James. You just double
down that there needs to be some framework for learning, and that
nested stacks might be one such constraint.

I replied that nested stacks might be emergent on dependency length.
So not a constraint based on actual nested stacks in the brain, but a
"soft" constraint based on the effect of dependency
 length on groups/stacks generated/learned from sequence networks.

BTW just noticed your "Combinatorial Hierarchy, Computational
Irreducibility and other things that just don't matter..." thread.
Perhaps that thread is a better location to discuss this. Were you
positing in that thread that all of maths and physics might be
emergent on combinatorial hierarchies? Were you saying yes, but it
doesn't matter to the practice of AGI, because for physics we can't
find the combinatorial basis, and in practice we can find top down
heuristics which work well enough?

Well, maybe for language a) we can't find top down heuristics which
work well enough and b) we don't need to, because for language a
combinatorial basis is actually sitting right there for us, manifest,
in (sequences of) text.

With language we don't just have the top-down perception of structure
like we do with physics (or maths.) Language is different to other
perceptual phenomena that way. Because language is the brain's attempt
to generate a perception in others. So with language we're also privy
to what the system looks like bottom up. We also have the, bottom up,
"word" tokens which are the combinatorial basis which generates a
perception.

Anyway, it seems like my point is similar to your point: language
structure, and cognition, might be emergent on combinatorial
hierarchies.

LLMs go part way to implementing that emergent structure. They succeed
to the extent they abandon an explicit search for top-down structure,
and just allow the emergent structure to balloon. Seemingly endlessly.
But they are a backwards implementation of emergent structure.
Succeeding by allowing the structure to grow. But failing because
back-prop assumes the structure will somehow not grow too. That there
will be an end to growth. Which will somehow be a compression of the
growth it hasn't captured yet... Actually, if it grows, you can't
capture it all. And in particular, back-prop can't capture all of the
emergent structure, because, like physics, that emergent structure
manifests some entanglement, and chaos.

In this thesis, LLMs are on the right track. We just need to replace
back-prop with some other way of finding emergent hierarchies of
predictive symmetries, and do it generatively, on the fly.

In practical terms, maybe, as I said earlier, the variational
estimation with heat of Extropic. Or maybe some kind of distributed
reservoir computer like LiquidAI are proposing. Otherwise just
straight out spiking NNs should be a good fit. If we focus on actively
seeking new variational symmetries using the spikes, and not
attempting to (mis)fit them to back-propagation.

On Tue, May 7, 2024 at 11:32 PM James Bowery  wrote:
>...
>
> At all levels of abstraction where natural science is applicable, people 
> adopt its unspoken presumption which is that mathematics is useful.  This is 
> what makes Solomonoff's proof relevant despite the intractability of proving 
> that one has found the ideal mathematical model.  The hard sciences are 
> merely the most obvious level of abstraction in which one may recognize this.
>...
>
> Any constraint on the program search (aka search for the ultimate algorithmic 
> encoding of all data in evidence at any given level of abstraction) is a 
> prior.  The thing that makes the high order push down automata (such as 
> nested stacks) interesting is that it may provide a constraint on program 
> search that evolution has found useful enough to hard wire into the structure 
> of the human brain -- specifically in the ratio of "capital investment" 
> between sub-modules of brain tissue.  This is a constraint, the usefulness of 
> which, may be suspected as generally applicable to the extent that human 
> cognition is generally applicable.

--
Artificial General Intelligence List: AGI
Permalink: 
https://agi.topicbox.com/groups/agi/Tb63883dd9d6b59cc-M321384a83da19a33df5ba986
Delivery options: https://agi.topicbox.com/groups/agi/subscription

[jira] [Resolved] (CXF-9006) TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red Hat OpenJDK on PPC64LE

[Freeman Yue Fang (Jira)]

 [ 
https://issues.apache.org/jira/browse/CXF-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Freeman Yue Fang resolved CXF-9006.
---
Fix Version/s: 4.1.0
   Resolution: Fixed

> TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red 
> Hat OpenJDK on PPC64LE
> -
>
> Key: CXF-9006
> URL: https://issues.apache.org/jira/browse/CXF-9006
> Project: CXF
>  Issue Type: Test
>Affects Versions: 4.0.4, 4.1.0
> Environment: Java version: 17.0.6, vendor: Red Hat, Inc., runtime: 
> /usr/lib/jvm/java-17-openjdk-17.0.6.0.10-3.el9.ppc64le
> OS name: "linux", version: "5.14.0-378.el9.ppc64le", arch: "ppc64le", family: 
> "unix"
>Reporter: Jamie Mark Goodyear
>Priority: Minor
> Fix For: 4.1.0
>
> Attachments: wss40.cer, wss40CA.cer, wss40CACRL.cer, wss40rev.cer
>
>
> {{TrustedAuthorityValidatorCRLTest#testIsCertChainValid}} failing when using 
> Red Hat OpenJDK 17. The error revealed when using 
> {{-Djava.security.debug=certpath}} is that the JVM can not find a valid 
> certification path to the requested target -- note: this unit test works on 
> Bellsoft, Temurin, IBM, Corretto, Zulu, on other platforms, and is confirmed 
> to work with Semeru/Temurin Java on PPC64LE.
> Given this is restricted to one particular JVM distribution/platform, would 
> this be a candidate for a skip test?
> {{sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target at 
> java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
>  at 
> java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
>  at 
> java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297) 
> at 
> org.apache.cxf.xkms.x509.validator.TrustedAuthorityValidator.isCertificateChainValid(TrustedAuthorityValidator.java:84)}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9006) TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red Hat OpenJDK on PPC64LE

[Freeman Yue Fang (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844311#comment-17844311
 ] 

Freeman Yue Fang commented on CXF-9006:
---

No, I dropped my PR 
https://github.com/apache/cxf/pull/1842
without merging it as I realized your PR has it, anyway, I just merged your PR
https://github.com/apache/cxf/pull/1836

Please try it again. Sorry for the confusion.

Freeman

> TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red 
> Hat OpenJDK on PPC64LE
> -
>
> Key: CXF-9006
> URL: https://issues.apache.org/jira/browse/CXF-9006
> Project: CXF
>  Issue Type: Test
>Affects Versions: 4.0.4, 4.1.0
> Environment: Java version: 17.0.6, vendor: Red Hat, Inc., runtime: 
> /usr/lib/jvm/java-17-openjdk-17.0.6.0.10-3.el9.ppc64le
> OS name: "linux", version: "5.14.0-378.el9.ppc64le", arch: "ppc64le", family: 
> "unix"
>Reporter: Jamie Mark Goodyear
>Priority: Minor
> Attachments: wss40.cer, wss40CA.cer, wss40CACRL.cer, wss40rev.cer
>
>
> {{TrustedAuthorityValidatorCRLTest#testIsCertChainValid}} failing when using 
> Red Hat OpenJDK 17. The error revealed when using 
> {{-Djava.security.debug=certpath}} is that the JVM can not find a valid 
> certification path to the requested target -- note: this unit test works on 
> Bellsoft, Temurin, IBM, Corretto, Zulu, on other platforms, and is confirmed 
> to work with Semeru/Temurin Java on PPC64LE.
> Given this is restricted to one particular JVM distribution/platform, would 
> this be a candidate for a skip test?
> {{sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target at 
> java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
>  at 
> java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
>  at 
> java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297) 
> at 
> org.apache.cxf.xkms.x509.validator.TrustedAuthorityValidator.isCertificateChainValid(TrustedAuthorityValidator.java:84)}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9006) TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red Hat OpenJDK on PPC64LE

[Freeman Yue Fang (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844307#comment-17844307
 ] 

Freeman Yue Fang commented on CXF-9006:
---

Hi [~jgoodyear],

It's wired, the attached cer validity is until 2034
{code}
Not After : Mar 11 22:46:11 2034 GMT
{code}

Probably somehow you still use the old certificates? I noticed that your PR
https://github.com/apache/cxf/pull/1836
not merged yet.

Freeman

> TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red 
> Hat OpenJDK on PPC64LE
> -
>
> Key: CXF-9006
> URL: https://issues.apache.org/jira/browse/CXF-9006
> Project: CXF
>  Issue Type: Test
>Affects Versions: 4.0.4, 4.1.0
> Environment: Java version: 17.0.6, vendor: Red Hat, Inc., runtime: 
> /usr/lib/jvm/java-17-openjdk-17.0.6.0.10-3.el9.ppc64le
> OS name: "linux", version: "5.14.0-378.el9.ppc64le", arch: "ppc64le", family: 
> "unix"
>Reporter: Jamie Mark Goodyear
>Priority: Minor
> Attachments: wss40.cer, wss40CA.cer, wss40CACRL.cer, wss40rev.cer
>
>
> {{TrustedAuthorityValidatorCRLTest#testIsCertChainValid}} failing when using 
> Red Hat OpenJDK 17. The error revealed when using 
> {{-Djava.security.debug=certpath}} is that the JVM can not find a valid 
> certification path to the requested target -- note: this unit test works on 
> Bellsoft, Temurin, IBM, Corretto, Zulu, on other platforms, and is confirmed 
> to work with Semeru/Temurin Java on PPC64LE.
> Given this is restricted to one particular JVM distribution/platform, would 
> this be a candidate for a skip test?
> {{sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target at 
> java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
>  at 
> java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
>  at 
> java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297) 
> at 
> org.apache.cxf.xkms.x509.validator.TrustedAuthorityValidator.isCertificateChainValid(TrustedAuthorityValidator.java:84)}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [gentoo-user] Hard drive and PWDIS or pin 3 power disable/reset.

[Rich Freeman]

On Tue, May 7, 2024 at 6:04 AM Michael  wrote:
>
> On Tuesday, 7 May 2024 08:50:26 BST Dale wrote:
> >
> > I'm aware of what it is and the cable part.  I was curious what it looks
> > like to BIOS and the OS when one is connected and that pin has the drive
> > disabled.  From what I've read in some places, the drive doesn't power
> > up at all.
>
> I don't have a drive like this, but as I understand it when the drive receives
> voltage on pin 3 it powers down.  This requires a MoBo and firmware which
> supports such a function - probably unlikely to be found on consumer kit.

I have had these drives.  If the drive is connected to many ATX power
supplies via a standard cable, the drive simply will not be detected
by the computer.  With some power supplies it will work fine.  It all
depends on whether the power supply follows the original SATA spec, or
was designed to be compatible with enterprise drives which use the
revised spec, which isn't backwards compatible (I don't know who the
genius was who had that idea).

In order to actually toggle the reset line you need SOMETHING able to
switch the line in-between the drive and the PSU.  That might be a
motherboard (especially with the newer trend towards running all the
power through the motherboard), or some other accessory card.  Unless
the HBA provides the power it won't be there.

However, you don't need any fancy hardware for the drive to just work
- that is only needed to send the hardware reset to the drive.  All
you need is to not have that pin powered.  That just means the right
power supply, the right cable, the right adapter, or some improvised
solution (tape over the pin is a common one).

In any case, if the pin is the problem, the drive simply won't be
detected.  Your SATA issues are due to something else.  It might be a
bad drive, an incompatibility (maybe the drive isn't in the
smartmontools database yet), or maybe an issue with the HBA (for USB
HBAs in particular you often need to pass command line parameters as
there apparently isn't a standard way to pass these commands over
USB).  I doubt the power line is your problem.

As far as shucked drives go - that is typically indicated by the
label/model.  If it isn't branded in any way it may have been shucked.
That shouldn't be a problem as long as you don't have the power issue
- the drive might simply be bad.

-- 
Rich

Re: [agi] Hey, looks like the goertzel is hiring...

[Rob Freeman]

Addendum: another candidate for this variational model for finding
distributions to replace back-prop (and consequently with the
potential to capture predictive structure which is chaotic attractors.
Though they don't appreciate the need yet.) There's Extropic, which is
proposing using heat noise. And, another, LiquidAI. If it's true
LiquidAI have nodes which are little reservoir computers, potentially
that might work on a similar variational estimation/generation of
distributions basis. Joscha Bach is involved with that. Though I don't
know in what capacity.

James: "Physics Informed Machine Learning". "Building models from data
using optimization and regression techniques".

Fine. If you have a physics to constrain it to. We don't have that
"physics" for language.

Richard Granger you say? The brain is constrained to be a "nested stack"?

https://www.researchgate.net/publication/343648662_Toward_the_quantification_of_cognition

Language is a nested stack? Possibly. Certainly you get a (softish)
ceiling of recursion starting level 3. The famous, level 2: "The rat
the cat chased escaped" (OK) vs. level 3: "The rat the cat the dog bit
chased escaped." (Borderline not OK.)

How does that contradict my assertion that such nested structures must
be formed on the fly, because they are chaotic attractors of
predictive symmetry on a sequence network?

On the other hand, can fixed, pre-structured, nested stacks explain
contradictory (semantic) categories, like "strong tea" (OK) vs
"powerful tea" (not OK)?

Unless stacks form on the fly, and can contradict, how can we explain
that "strong" can be a synonym (fit in the stack?) for "powerful" in
some contexts, but not others?

On the other hand, a constraint like an observation of limitations on
nesting, might be a side effect of the other famous soft restriction,
the one on dependency length. A restriction on dependency length is an
easier explanation for nesting limits, and fits with the model that
language is just a sequence network, which gets structured (into
substitution groups/stacks?) on the fly.

On Mon, May 6, 2024 at 11:06 PM James Bowery  wrote:
>
> Let's give the symbolists their due:
>
> https://youtu.be/JoFW2uSd3Uo?list=PLMrJAkhIeNNQ0BaKuBKY43k4xMo6NSbBa
>
> The problem isn't that symbolists have nothing to offer, it's just that 
> they're offering it at the wrong level of abstraction.
>
> Even in the extreme case of LLM's having "proven" that language modeling 
> needs no priors beyond the Transformer model and some hyperparameter 
> tweaking, there are language-specific priors acquired over the decades if not 
> centuries that are intractable to learn.
>
> The most important, if not conspicuous, one is Richard Granger's discovery 
> that Chomsky's hierarchy elides the one grammar category that human cognition 
> seems to use.

--
Artificial General Intelligence List: AGI
Permalink: 
https://agi.topicbox.com/groups/agi/Tb63883dd9d6b59cc-Me078486d3e7a407326e33a8a
Delivery options: https://agi.topicbox.com/groups/agi/subscription

[fluid-dev] channel filter

[Freeman Gilmore]

Can the cut off frequency of the channel built in high or low pass filter
be programmed to be manipulated by midi?

On Sat, May 4, 2024 at 3:11 PM Freeman Gilmore 
wrote:

> I would like to add a low or high pass channel filter that I can control
> by midi.   It is not listed as a feather but it is listed as a in the
> library functions, Synthesizer, Effect - IIR Filter.. I do not want to
> disable the synthesizer of its fonction if it is used for sound fonts.
> Also i could not find how to use the Library function.
> Thank you, fg
>
___
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev

Re: [agi] Hey, looks like the goertzel is hiring...

[Rob Freeman]

On Sat, May 4, 2024 at 4:53 AM Matt Mahoney  wrote:
>
> ... OpenCog was a hodgepodge of a hand coded structured natural language 
> parser, a toy neural vision system, and a hybrid fuzzy logic knowledge 
> representation data structure that was supposed to integrate it all together 
> but never did after years of effort. There was never any knowledge base or 
> language learning algorithm.

Good summary of the OpenCog system Matt.

But there was a language learning algorithm. Actually there was more
of a language learning algorithm in OpenCog than there is now in LLMs.
That's been the problem with OpenCog. By contrast LLMs don't try to
learn grammar. They just try to learn to predict words.

Rather than the mistake being that they had no language learning
algorithm, the mistake was OpenCog _did_ try to implement a language
learning algorithm.

By contrast the success, with LLMs, came to those who just tried to
predict words. Using a kind of vector cross product across word
embedding vectors, as it turns out.

Trying to learn grammar was linguistic naivety. You could have seen it
back then. Hardly anyone in the AI field has any experience with
language, actually, that's the problem. Even now with LLMs. They're
all linguistic naifs. A tragedy for wasted effort for OpenCog. Formal
grammars for natural language are unlearnable. I was telling Linas
that since 2011. I posted about it here numerous times. They spent a
decade, and millions(?) trying to learn a formal grammar.

Meanwhile vector language models which don't coalesce into formal
grammars, swooped in and scooped the pool.

That was NLP. But more broadly in OpenCog too, the problem seems to be
that Ben is still convinced AI needs some kind of symbolic
representation to build chaos on top of. A similar kind of error.

I tried to convince Ben otherwise the last time he addressed the
subject of semantic primitives in this AGI Discussion Forum session
two years ago, here:

March 18, 2022, 7AM-8:30AM Pacific time: Ben Goertzel leading
discussion on semantic primitives
https://singularitynet.zoom.us/rec/share/qwLpQuc_4UjESPQyHbNTg5TBo9_U7TSyZJ8vjzudHyNuF9O59pJzZhOYoH5ekhQV.2QxARBxV5DZxtqHQ?startTime=164761312

Starting timestamp 1:24:48, Ben says, disarmingly:

"For f'ing decades, which is ridiculous, it's been like, OK, I want to
explore these chaotic dynamics and emergent strange attractors, but I
want to explore them in a very fleshed out system, with a rich
representational capability, interacting with a complex world, and
then we still haven't gotten to that system ... Of course, an
alternative approach could be taken as you've been attempting, of ...
starting with the chaotic dynamics but in a simpler setting. ... But I
think we have agreed over the decades that to get to human level AGI
you need structure emerging from chaos. You need a system with complex
chaotic dynamics, you need structured strange attractors there, you
need the system's own pattern recognition to be recognizing the
patterns in these structured strange attractors, and then you have
that virtuous cycle."

So he embraces the idea cognitive structure is going to be chaotic
attractors, as he did when he wrote his "Chaotic Logic" book back in
1994. But he's still convinced the chaos needs to emerge on top of
some kind of symbolic representation.

I think there's a sunken cost fallacy at work. So much is invested in
the paradigm of chaos appearing on top of a "rich" symbolic
representation. He can't try anything else.

As I understand it, Hyperon is a re-jig of the software for this
symbol based "atom" network representation, to make it easier to
spread the processing load over networks.

As a network representation, the potential is there to merge insights
of no formal symbolic representation which has worked for LLMs, with
chaos on top which was Ben's earlier insight.

I presented on that potential at a later AGI Discussion Forum session.
But mysteriously the current devs failed to upload the recording for
that session.

> Maybe Hyperon will go better. But I suspect that LLMs on GPU clusters will 
> make it irrelevant.

Here I disagree with you. LLMs are at their own dead-end. What they
got right was to abandon formal symbolic representation. They likely
generate their own version of chaos, but they are unaware of it. They
are still trapped in their own version of the "learning" idea. Any
chaos generated is frozen and tangled in their enormous
back-propagated networks. That's why they exhibit no structure,
hallucinate, and their processing of novelty is limited to rough
mapping to previous knowledge. The solution will require a different
way of identifying chaotic attractors in networks of sequences.

A Hyperon style network might be a better basis to make that advance.
It would have to abandon the search for a symbolic representation.
LLMs can show the way there. Make prediction not representation the
focus. Just start with any old (sequential) tokens. But in contrast to
LLMs, 

[jira] [Created] (CXF-9008) FIPS support

[Freeman Yue Fang (Jira)]

Freeman Yue Fang created CXF-9008:
-

 Summary: FIPS support
 Key: CXF-9008
 URL: https://issues.apache.org/jira/browse/CXF-9008
 Project: CXF
  Issue Type: New Feature
Reporter: Freeman Yue Fang


The goal of this ticket is to ensure we can run CXF with FIPS compliant 
security algorithm on FIPS enabled machines.

We should ensure all security related tests(unless those tests specifically 
test algos which are not allowed in FIPS mode) can also pass in FIPS mode



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (CXF-9008) FIPS support

[Freeman Yue Fang (Jira)]

 [ 
https://issues.apache.org/jira/browse/CXF-9008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Freeman Yue Fang reassigned CXF-9008:
-

Assignee: Freeman Yue Fang

> FIPS support
> 
>
> Key: CXF-9008
> URL: https://issues.apache.org/jira/browse/CXF-9008
> Project: CXF
>  Issue Type: New Feature
>    Reporter: Freeman Yue Fang
>    Assignee: Freeman Yue Fang
>Priority: Major
>
> The goal of this ticket is to ensure we can run CXF with FIPS compliant 
> security algorithm on FIPS enabled machines.
> We should ensure all security related tests(unless those tests specifically 
> test algos which are not allowed in FIPS mode) can also pass in FIPS mode



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[fluid-dev] channel filter

[Freeman Gilmore]

I would like to add a low or high pass channel filter that I can control by
midi.   It is not listed as a feather but it is listed as a in the library
functions, Synthesizer, Effect - IIR Filter.. I do not want to disable the
synthesizer of its fonction if it is used for sound fonts.Also i could
not find how to use the Library function.
Thank you, fg
___
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev

[Birdnews]Sad news: Bruce Falls has passed away at age 100

[Lynne Freeman via birdnews]

Hello dear birding community,

Bruce Falls has passed away.  Such sad news for all who knew him, and a
loss for the birding community. He was instrumental in founding NCC and
Birds Canada. He was the first president of Ontario Nature and the editor
of the first atlas. He was humble and funny and so generous with everyone.

Here is the obit:

https://necrocanada.com/obituaries-2023/canada-ontario-toronto-dr-j-bruce-falls-oc/

Lynne
-- 
Lynne Freeman (she/her/hers)
lynnef...@gmail.com
--
Ontbirds and Birdnews are moderated email Listservs provided by the Ontario 
Field Ornithologists (OFO) as a service to all birders in Ontario.

Birdnews is reserved for announcements, location summaries, first of year 
reports, etc. To post a message on Birdnews, send an email to: 
birdnews@ontbirds.ca.

If you have any questions or concerns, contact the Birdnews Moderators by email 
at birdn...@ofo.ca. Please review posting rules and guidelines at 
http://ofo.ca/site/content/listserv-guidelines

During the COVID-19 pandemic, all Ontario birders should be taking extra 
precautions and following local, provincial, and federal regulations regarding 
physical distancing and non-essential travel.

To find out more about OFO, please visit our website at ofo.ca or Facebook page 
at https://www.facebook.com/OntarioFieldOrnithologists.

[gentoo-commits] repo/gentoo:master commit in: sys-process/systemd-cron/

[Richard Freeman]

commit: 9650ada19875e027a46c5ce23dc1bd0044d0
Author: Richard Freeman  gentoo  org>
AuthorDate: Tue Apr 30 11:45:05 2024 +
Commit: Richard Freeman  gentoo  org>
CommitDate: Tue Apr 30 12:51:00 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9650ada1

sys-process/systemd-cron: add 2.4.0

Bug: https://bugs.gentoo.org/930950
Signed-off-by: Richard Freeman  gentoo.org>

 sys-process/systemd-cron/Manifest  |  1 +
 sys-process/systemd-cron/systemd-cron-2.4.0.ebuild | 93 ++
 2 files changed, 94 insertions(+)

diff --git a/sys-process/systemd-cron/Manifest 
b/sys-process/systemd-cron/Manifest
index 06b7f8013a30..830f4e8bbd72 100644
--- a/sys-process/systemd-cron/Manifest
+++ b/sys-process/systemd-cron/Manifest
@@ -1,2 +1,3 @@
 DIST systemd-cron-2.2.0.tar.gz 55825 BLAKE2B 
ca4b02fdea5084439aa56b3f04603000d811f21922c11cd26a22ea6387e4b54575587ff4e1eb7fc7a3260d2f656ea0eb91365942c135982f4bd26aead1a080f1
 SHA512 
f26c7d7e2da7eb5cd5558f352aff852585bfefd961de6ecc2409a4a53b63f82662a89bdbf71f739ea8e44ef9e3e1fdec15cdc63ce1e90c289fb0e636ff679ca0
 DIST systemd-cron-2.3.4.tar.gz 58458 BLAKE2B 
594fff8f7cc126aa33b1dcbf74293a39b5939576203c11f8f0fc300285462f266c35503a6cfe46ee797e5e617e54e09b92dd6ba8a4044f962d1efd2822f0a87c
 SHA512 
2a9743df6d0e1a83b65d15609e47b901fde1d77d1207c4cc0617395be8d9e94daece91aec9a3398c3d09f86383e01cfff301614df727ca598efe873453f5a3c9
+DIST systemd-cron-2.4.0.tar.gz 60462 BLAKE2B 
6a4450637b69ed9c32ea5711018be9265db96a6bf19896bb72c13184817750e7d64d2fdd00ac885d5ae3393b671c04c89d1bf46f73fbb817c1b1798a4809b955
 SHA512 
88ce99307101d33e6fc6a5dfa25f16db9754785809b44da78c6b05b52592385c9a957770ee781b97a248ab475304bd7eb234bffa47114031bd804e2aa5f79c06

diff --git a/sys-process/systemd-cron/systemd-cron-2.4.0.ebuild 
b/sys-process/systemd-cron/systemd-cron-2.4.0.ebuild
new file mode 100644
index ..00738f1c0e07
--- /dev/null
+++ b/sys-process/systemd-cron/systemd-cron-2.4.0.ebuild
@@ -0,0 +1,93 @@
+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+inherit systemd toolchain-funcs
+
+DESCRIPTION="systemd units to create timers for cron directories and crontab"
+HOMEPAGE="https://github.com/systemd-cron/systemd-cron/;
+SRC_URI="https://github.com/systemd-cron/${PN}/archive/v${PV}.tar.gz -> 
systemd-cron-${PV}.tar.gz"
+
+LICENSE="MIT"
+SLOT="0"
+KEYWORDS="~amd64 ~arm ~arm64 ~hppa ~ia64 ~ppc ~ppc64 ~riscv ~sparc ~x86"
+IUSE="cron-boot etc-crontab-systemd minutely +runparts setgid yearly"
+# We can't run the unshare tests within sandbox/with low privs, and the
+# 'test-nounshare' target just does static analysis (shellcheck etc).
+RESTRICT="test"
+
+BDEPEND="virtual/pkgconfig"
+RDEPEND="
+   !sys-process/cronie[anacron]
+   acct-user/_cron-failure
+   acct-group/_cron-failure
+   app-crypt/libmd:=
+   sys-process/cronbase
+   >=sys-apps/systemd-255[-split-usr(-)]
+   !etc-crontab-systemd? ( !sys-process/dcron )
+   runparts? ( sys-apps/debianutils )
+"
+DEPEND="
+   dev-libs/openssl:=
+   sys-process/cronbase
+"
+
+src_prepare() {
+   sed -i \
+   -e 's/^crontab/crontab-systemd/' \
+   -e 's/^CRONTAB/CRONTAB-SYSTEMD/' \
+   -- "${S}/src/man/crontab."{1,5}".in" || die
+
+   if use etc-crontab-systemd
+   thensed -i \
+   -e "s!/etc/crontab!/etc/crontab-systemd!" \
+   -- "${S}/src/man/crontab."{1,5}".in" \
+   "${S}/src/bin/systemd-crontab-generator.cpp" \
+   "${S}/test/test-generator" || die
+   fi
+
+   default
+}
+
+my_use_enable() {
+   if use ${1}; then
+   echo --enable-${2:-${1}}=yes
+   else
+   echo --enable-${2:-${1}}=no
+   fi
+}
+
+src_configure() {
+   tc-export PKG_CONFIG CXX CC
+
+   ./configure \
+   --prefix="${EPREFIX}/usr" \
+   --mandir="${EPREFIX}/usr/share/man" \
+   --unitdir="$(systemd_get_systemunitdir)" \
+   --generatordir="$(systemd_get_systemgeneratordir)" \
+   $(my_use_enable cron-boot boot) \
+   $(my_use_enable minutely) \
+   $(my_use_enable runparts) \
+   $(my_use_enable yearly) \
+   $(my_use_enable yearly quarterly) \
+   $(my_use_enable yearly semi_annually) || die
+
+   export CRONTAB=crontab-systemd
+}
+
+src_compile() {
+   emake PCH=
+}
+
+src_install() {
+   emake DESTDIR="${D}" PCH= install
+   rm -f "${ED}"/usr/lib/sysusers.d/systemd-cron.conf
+}
+
+pkg_postinst() {
+   elog "This package now support

[jira] (CXF-9006) TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red Hat OpenJDK on PPC64LE

[Freeman Yue Fang (Jira)]

[ https://issues.apache.org/jira/browse/CXF-9006 ]


Freeman Yue Fang deleted comment on CXF-9006:
---

was (Author: ffang):
Send PR to upgrade the cer files
https://github.com/apache/cxf/pull/1842

> TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red 
> Hat OpenJDK on PPC64LE
> -
>
> Key: CXF-9006
> URL: https://issues.apache.org/jira/browse/CXF-9006
> Project: CXF
>  Issue Type: Test
>Affects Versions: 4.0.4, 4.1.0
> Environment: Java version: 17.0.6, vendor: Red Hat, Inc., runtime: 
> /usr/lib/jvm/java-17-openjdk-17.0.6.0.10-3.el9.ppc64le
> OS name: "linux", version: "5.14.0-378.el9.ppc64le", arch: "ppc64le", family: 
> "unix"
>Reporter: Jamie Mark Goodyear
>Priority: Minor
> Attachments: wss40.cer, wss40CA.cer, wss40CACRL.cer, wss40rev.cer
>
>
> {{TrustedAuthorityValidatorCRLTest#testIsCertChainValid}} failing when using 
> Red Hat OpenJDK 17. The error revealed when using 
> {{-Djava.security.debug=certpath}} is that the JVM can not find a valid 
> certification path to the requested target -- note: this unit test works on 
> Bellsoft, Temurin, IBM, Corretto, Zulu, on other platforms, and is confirmed 
> to work with Semeru/Temurin Java on PPC64LE.
> Given this is restricted to one particular JVM distribution/platform, would 
> this be a candidate for a skip test?
> {{sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target at 
> java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
>  at 
> java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
>  at 
> java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297) 
> at 
> org.apache.cxf.xkms.x509.validator.TrustedAuthorityValidator.isCertificateChainValid(TrustedAuthorityValidator.java:84)}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-9006) TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red Hat OpenJDK on PPC64LE

[Freeman Yue Fang (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842138#comment-17842138
 ] 

Freeman Yue Fang commented on CXF-9006:
---

Send PR to upgrade the cer files
https://github.com/apache/cxf/pull/1842

> TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red 
> Hat OpenJDK on PPC64LE
> -
>
> Key: CXF-9006
> URL: https://issues.apache.org/jira/browse/CXF-9006
> Project: CXF
>  Issue Type: Test
>Affects Versions: 4.0.4, 4.1.0
> Environment: Java version: 17.0.6, vendor: Red Hat, Inc., runtime: 
> /usr/lib/jvm/java-17-openjdk-17.0.6.0.10-3.el9.ppc64le
> OS name: "linux", version: "5.14.0-378.el9.ppc64le", arch: "ppc64le", family: 
> "unix"
>Reporter: Jamie Mark Goodyear
>Priority: Minor
> Attachments: wss40.cer, wss40CA.cer, wss40CACRL.cer, wss40rev.cer
>
>
> {{TrustedAuthorityValidatorCRLTest#testIsCertChainValid}} failing when using 
> Red Hat OpenJDK 17. The error revealed when using 
> {{-Djava.security.debug=certpath}} is that the JVM can not find a valid 
> certification path to the requested target -- note: this unit test works on 
> Bellsoft, Temurin, IBM, Corretto, Zulu, on other platforms, and is confirmed 
> to work with Semeru/Temurin Java on PPC64LE.
> Given this is restricted to one particular JVM distribution/platform, would 
> this be a candidate for a skip test?
> {{sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target at 
> java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
>  at 
> java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
>  at 
> java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297) 
> at 
> org.apache.cxf.xkms.x509.validator.TrustedAuthorityValidator.isCertificateChainValid(TrustedAuthorityValidator.java:84)}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[gentoo-commits] repo/gentoo:master commit in: app-backup/duplicity/

[Richard Freeman]

commit: 0f5b07d5d4f94d5088198ddd207dd664fae9ea27
Author: Richard Freeman  gentoo  org>
AuthorDate: Mon Apr 29 19:15:52 2024 +
Commit: Richard Freeman  gentoo  org>
CommitDate: Mon Apr 29 19:17:34 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0f5b07d5

app-backup/duplicity: stabilize 2.2.3 for amd64

Signed-off-by: Richard Freeman  gentoo.org>

 app-backup/duplicity/duplicity-2.2.3.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/app-backup/duplicity/duplicity-2.2.3.ebuild 
b/app-backup/duplicity/duplicity-2.2.3.ebuild
index 71908351c86d..0594bd819a43 100644
--- a/app-backup/duplicity/duplicity-2.2.3.ebuild
+++ b/app-backup/duplicity/duplicity-2.2.3.ebuild
@@ -13,7 +13,7 @@ HOMEPAGE="https://duplicity.gitlab.io/;
 
 LICENSE="GPL-3"
 SLOT="0"
-KEYWORDS="~amd64 ~x86 ~amd64-linux ~x86-linux ~x64-macos"
+KEYWORDS="amd64 ~x86 ~amd64-linux ~x86-linux ~x64-macos"
 IUSE="s3 test"
 
 CDEPEND="

[jira] [Commented] (CXF-9006) TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red Hat OpenJDK on PPC64LE

[Freeman Yue Fang (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842022#comment-17842022
 ] 

Freeman Yue Fang commented on CXF-9006:
---

Hi [~jgoodyear],

Could you please copy the cer files I attached here to
services/xkms/xkms-x509-handlers/src/test/resources/trustedAuthorityValidator/
folder to override the old ones and rerun the test against the JDKs you are 
testing?

These new cer files are RSA2048 instead the previous DSA1024.

Thanks
Freeman

> TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red 
> Hat OpenJDK on PPC64LE
> -
>
> Key: CXF-9006
> URL: https://issues.apache.org/jira/browse/CXF-9006
> Project: CXF
>  Issue Type: Test
>Affects Versions: 4.0.4, 4.1.0
> Environment: Java version: 17.0.6, vendor: Red Hat, Inc., runtime: 
> /usr/lib/jvm/java-17-openjdk-17.0.6.0.10-3.el9.ppc64le
> OS name: "linux", version: "5.14.0-378.el9.ppc64le", arch: "ppc64le", family: 
> "unix"
>Reporter: Jamie Mark Goodyear
>Priority: Minor
> Attachments: wss40.cer, wss40CA.cer, wss40CACRL.cer, wss40rev.cer
>
>
> {{TrustedAuthorityValidatorCRLTest#testIsCertChainValid}} failing when using 
> Red Hat OpenJDK 17. The error revealed when using 
> {{-Djava.security.debug=certpath}} is that the JVM can not find a valid 
> certification path to the requested target -- note: this unit test works on 
> Bellsoft, Temurin, IBM, Corretto, Zulu, on other platforms, and is confirmed 
> to work with Semeru/Temurin Java on PPC64LE.
> Given this is restricted to one particular JVM distribution/platform, would 
> this be a candidate for a skip test?
> {{sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target at 
> java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
>  at 
> java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
>  at 
> java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297) 
> at 
> org.apache.cxf.xkms.x509.validator.TrustedAuthorityValidator.isCertificateChainValid(TrustedAuthorityValidator.java:84)}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (CXF-9006) TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red Hat OpenJDK on PPC64LE

[Freeman Yue Fang (Jira)]

 [ 
https://issues.apache.org/jira/browse/CXF-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Freeman Yue Fang updated CXF-9006:
--
Attachment: wss40.cer
wss40CA.cer
wss40CACRL.cer
wss40rev.cer

> TrustedAuthorityValidatorCRLTest#testIsCertChainValid fails when using Red 
> Hat OpenJDK on PPC64LE
> -
>
> Key: CXF-9006
> URL: https://issues.apache.org/jira/browse/CXF-9006
> Project: CXF
>  Issue Type: Test
>Affects Versions: 4.0.4, 4.1.0
> Environment: Java version: 17.0.6, vendor: Red Hat, Inc., runtime: 
> /usr/lib/jvm/java-17-openjdk-17.0.6.0.10-3.el9.ppc64le
> OS name: "linux", version: "5.14.0-378.el9.ppc64le", arch: "ppc64le", family: 
> "unix"
>Reporter: Jamie Mark Goodyear
>Priority: Minor
> Attachments: wss40.cer, wss40CA.cer, wss40CACRL.cer, wss40rev.cer
>
>
> {{TrustedAuthorityValidatorCRLTest#testIsCertChainValid}} failing when using 
> Red Hat OpenJDK 17. The error revealed when using 
> {{-Djava.security.debug=certpath}} is that the JVM can not find a valid 
> certification path to the requested target -- note: this unit test works on 
> Bellsoft, Temurin, IBM, Corretto, Zulu, on other platforms, and is confirmed 
> to work with Semeru/Temurin Java on PPC64LE.
> Given this is restricted to one particular JVM distribution/platform, would 
> this be a candidate for a skip test?
> {{sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target at 
> java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
>  at 
> java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
>  at 
> java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297) 
> at 
> org.apache.cxf.xkms.x509.validator.TrustedAuthorityValidator.isCertificateChainValid(TrustedAuthorityValidator.java:84)}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (WSS-711) Introduce a system property "fips.enabled" so that WSS4J can work easier in FIPS mode

[Freeman Yue Fang (Jira)]

Freeman Yue Fang created WSS-711:


 Summary: Introduce a system property "fips.enabled" so that WSS4J 
can work easier in FIPS mode
 Key: WSS-711
 URL: https://issues.apache.org/jira/browse/WSS-711
 Project: WSS4J
  Issue Type: New Feature
Reporter: Freeman Yue Fang
Assignee: Colm O hEigeartaigh


Currently WSS4J has some default security algo settings which are not 
applicable on FIPS machine.

For example AES_CBC, RSA-OAEP and PBEWithMD5AndTripleDES are not FIPS 
compliant, while  we should use AES_GCM, RSA-1_5 and 
PBEWithHmacSHA512AndAES_256 on FIPS machine.

So I propose to introduce a system property "fips.enabled", when this property 
set as true, the FIPS compliant algos will be used accordingly, and this new 
introduced system propery won't affect current default behaviour.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

Re: [NWRUG] Getting Into Rails Development

[Paul Bennett-Freeman]

> Is this normal or am I doing something wrong?

Oh, it’s absolutely “normal”.

In particular never turn down another offer until you’ve got a signed
contract from a company and not just a verbal offer via a recruiter.



On Sat, 20 Apr 2024 at 10:19, DAZ  wrote:

> Also, you mentioned recruiters and they do seem quite soulless ... I've
> already come across a few that seem to have 'led me on' and then completely
> ghosted me - not even replying to my emails for updates. Is this normal or
> am I doing something wrong?
>
> --
> You received this message because you are subscribed to the Google Groups
> "North West Ruby User Group (NWRUG)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nwrug-members+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/nwrug-members/30a69172-7d1e-4371-83ea-5dc943cd765bn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"North West Ruby User Group (NWRUG)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nwrug-members+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/nwrug-members/CAPNVErqkWLUbSdsyuQ7xBHTUe01%2B135orqP3Kz19M1fyCxJz9w%40mail.gmail.com.

Re: [NWRUG] Getting Into Rails Development

[Paul Bennett-Freeman]

> I'm currently working on building a portfolio, but is there anything I
should focus on in particular?

Since you've changed careers, is there anything you could build the plays
on that? Something you can spin a narrative around of "As a teacher, I
always wanted to do X, and so I built this tool that does it."

Something like "Every term, I'd need to log on to the school web site and
copy a pupils grades one by one into a spreadsheet, so I built a web
scraper that does that automatically"

When it comes to interviewing, being able to demonstrate you have
transferable skills and experience you can apply can give you the edge over
another junior developer who might be able to code as well as you, but has
nothing else to offer - that's a bit blunt, but recruiters are soulless
monsters mostly.

>From a more personal perspective, and definitely more controversial, so
take this as one person's option: Frontend in Rails (Turbo and Hotwire) is
a hot mess and very few companies actually use it. Learning some React, and
building against APIs you've written, or other people's APIs is a much more
transferable skill set. I'd recommend Noel Rappin's Modern Front-End
Development for Rails

which
covers all bases by including Turbo, Stimulus, React, and TypeScript. That
has a more balanced approach than a random person on the internet screaming
"Hotwire sucks!" ;)



On Thu, 18 Apr 2024 at 12:47, DAZ  wrote:
>
> Hi everyone,
>
> I've been a long time member of this group and been coding in Ruby since
Rails first came out, but it's only ever been a hobby for me.
>
> I've recently decided to have a career change from teaching to web
development and would like to get into Rails development, preferably in
Manchester or remote.
>
> I know a lot of you on here are already working as Rails devs - does
anybody have any tips about what the best things I should be doing? I'm
currently working on building a portfolio, but is there anything I should
focus on in particular? And any tips about the best way to find Rails
vacancies or opportunities?
>
> I'd also be interested to hear if anyone knows of any opportunities just
to get any unpaid Rails development experience.
>
> Thanks,
>
> Daz
>
> --
> You received this message because you are subscribed to the Google Groups
"North West Ruby User Group (NWRUG)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to nwrug-members+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
https://groups.google.com/d/msgid/nwrug-members/16950019-53fa-4139-a45d-6ba94c3c587dn%40googlegroups.com
.

-- 
You received this message because you are subscribed to the Google Groups 
"North West Ruby User Group (NWRUG)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nwrug-members+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/nwrug-members/CAPNVErobv6Cg-5mTOmMdNT%3DJMHW8QBYEZ_9JHgMyhvuoz0EW7w%40mail.gmail.com.

[jira] [Resolved] (CXF-9004) Jetty12 : always use pre-saved HTTP_REQUEST from InMessage to populate SecurityContext

[Freeman Yue Fang (Jira)]

 [ 
https://issues.apache.org/jira/browse/CXF-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Freeman Yue Fang resolved CXF-9004.
---
Resolution: Fixed

> Jetty12 : always use pre-saved HTTP_REQUEST from InMessage to populate 
> SecurityContext
> --
>
> Key: CXF-9004
> URL: https://issues.apache.org/jira/browse/CXF-9004
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 4.1.0
>
>
> Ensure we use HttpServletRequest from the one saved in inMessage as this 
> could be the cachedInput one in oneway and ReplyTo is specified when 
> ws-addressing is used, which means we need to switch thread context and 
> underlying transport might discard any data on the original stream.
> So always retrieve the pre-saved HTTP_REQUEST from InMessage, so this could 
> be the original HttpServletRequest or the Cached HttpServletRequest when it's 
> necessary



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (CXF-9004) Jetty12 : always use pre-saved HTTP_REQUEST from InMessage to populate SecurityContext

[Freeman Yue Fang (Jira)]

Freeman Yue Fang created CXF-9004:
-

 Summary: Jetty12 : always use pre-saved HTTP_REQUEST from 
InMessage to populate SecurityContext
 Key: CXF-9004
 URL: https://issues.apache.org/jira/browse/CXF-9004
 Project: CXF
  Issue Type: Bug
  Components: Transports
Reporter: Freeman Yue Fang
Assignee: Freeman Yue Fang
 Fix For: 4.1.0


Ensure we use HttpServletRequest from the one saved in inMessage as this could 
be the cachedInput one in oneway and ReplyTo is specified when ws-addressing is 
used, which means we need to switch thread context and underlying transport 
might discard any data on the original stream.

So always retrieve the pre-saved HTTP_REQUEST from InMessage, so this could be 
the original HttpServletRequest or the Cached HttpServletRequest when it's 
necessary



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [gentoo-user] NAS box and switching from Phenom II X6 1090T to FX-6300

[Rich Freeman]

On Wed, Apr 17, 2024 at 9:33 AM Dale  wrote:
>
> Rich Freeman wrote:
>
> > All AM5 CPUs have GPUs, but in general motherboards with video outputs
> > do not require the CPU to have a GPU built in.  The ports just don't
> > do anything if this is lacking, and you would need a dedicated GPU.
> >
>
> OK.  I read that a few times.  If I want to use the onboard video I have
> to have a certain CPU that supports it?  Do those have something so I
> know which is which?  Or do I read that as all the CPUs support onboard
> video but if one plugs in a video card, that part of the CPU isn't
> used?  The last one makes more sense but asking to be sure.

To use onboard graphics, you need a motherboard that supports it, and
a CPU that supports it.  I believe that internal graphics and an
external GPU card can both be used at the same time.  Note that
internal graphics solutions typically steal some RAM from other system
use, while an external GPU will have its own dedicated RAM (and those
can also make use of internal RAM too).

The 7600X has a built-in RDNA2 GPU.   All the original Ryzen zen4 CPUs
had GPU support, but it looks like they JUST announced a new line of
consumer zen4 CPUs that don't have it - they all end in an F right
now.

In any case, if you google the CPU you're looking at it will tell you
if it supports integrated graphics.  Most better stores/etc have
filters for this feature as well (places like Newegg or PCPartPicker
or whatever).

If you don't play games, then definitely get integrated graphics.
Even if the CPU costs a tiny bit more, it will give you a free empty
16x PCIe slot at whatever speed the CPU supports (v5 in this case -
which is as good as you can get right now).

> That could mean a slight price drop for the things I'm looking at then.
> One can hope.  Right???

Everything comes down in price eventually...

>
> I might add, simply right clicking on the desktop can take sometimes 20
> or 30 seconds for the menu to pop up.  Switching from one desktop to
> another can take several seconds, sometimes 8 or 10.  This rig is
> getting slower.  Actually, the software is just getting bigger.  You get
> my meaning tho.  I bet the old KDE3 would be blazingly fast compared to
> the rig I ran it on originally.

That sounds like RAM but I couldn't say for sure.  In any case a
modern system will definitely help.

> Given the new rig can have 128GBs, I assume it comes in 32GB sticks.

Consumer DDR5 seems to come as large as 48GB, though that seems like
an odd size.

> I'd get 32GBs at first.  Maybe a month or so later get another 32GB.
> That'll get me 64Gbs.  Later on, a good sale maybe, buy another 32GB or
> a 64GB set and max it out.

You definitely want to match the timings, and you probably want to
match the sticks themselves.  Also, you generally need to be mindful
of how many channels you're occupying, though as I understand it DDR5
is essentially natively dual channel.  If you just stick one DDR4
stick in a system it will not perform as well as two sticks of half
the size.  I forget the gory details but I believe it comes down to
the timings of switching between two different channels vs moving
around within a single one.  DDR RAM timings get really confusing, and
it comes down to the fact that addresses are basically grouped in
various ways and randomly seeking from one address to another can take
a different amount of time depending on how the new address is related
to the address you last read.  The idea of "seeking" with RAM may seem
odd, but recent memory technologies are a bit like storage, and they
are accessed in a semi-serial manner.  Essentially the latencies and
transfer rates are such that even dynamic RAM chips are too slow to
work in the conventional sense.  I'm guessing it gets into a lot of
gory details with reactances and so on, and just wiring up every
memory cell in parallel like in the old days would slow down all the
voltage transitions.

> I've looked at server type boards.  I'd like to have one.  I'd like one
> that has SAS ports.

So, I don't really spend much time looking at them, but I'm guessing
SAS is fairly rare on the motherboards themselves.  They probably
almost always have an HBA/RAID controller in a PCIe slot.  You can put
the same cards in any PC, but of course you're just going to struggle
to have a slot free.  You can always use a riser or something to cram
an HBA into a slot that is too small for it, but then you're going to
suffer reduced performance.  For just a few spinning disks though it
probably won't matter.

Really though I feel like the trend is towards NVMe and that gets into
a whole different world.  U.2 allows either SAS or PCIe over the bus,
and there are HBAs that will handle both.  Or if you only want NVMe it
looks like you can use bifurcation-based solutions to more cheaply
break slots out.

I'm kinda thinking about going that direct

Re: [gentoo-user] NAS box and switching from Phenom II X6 1090T to FX-6300

[Rich Freeman]

On Wed, Apr 17, 2024 at 6:33 AM Dale  wrote:
>
> On the AM5 link, I found a mobo that I kinda like.  I still wish it had
> more PCIe slots tho.

AM5 has 28 PCIe lanes.  Anything above that comes from a switch on the
motherboard.

0.1% of the population cares about having anything on their
motherboard besides a 16x slot for the GPU.  So, that's what all the
cheaper boards deliver these days.  The higher end boards often have a
switch and will deliver extra lanes, and MAYBE those will go into
another PCIe slot (probably not wired for 16x but it might have that
form factor), and more often those go into additional M.2 slots and
USB3 ports.  (USB3 is very high bandwidth, especially later
generations, and eats up PCIe lanes as a result.)

Keep in mind those 28 v5 lanes have the bandwidth of over 100 v3
lanes, which is part of why the counts are being reduced.  The problem
is that hardware to do that conversion is kinda niche right now.  It
is much easier to bifurcate a larger slot, but that doesn't buy you
more lanes.

> It supports not only the Ryzen 9
> series but also supports Ryzen 5 series.

That is because the 9 and 5 are branding and basically convey no
information at all besides the price point.

The Ryzen 7 1700X has about half the performance of the Ryzen 5 7600X,
and that would be because the first chip came out in 2017, and the
second came out in 2022 and is three generations newer.

Likewise the intel branding of "i3" or "i7" and so on also conveys no
information beyond the general price level they were introduced at.
You can expect the bigger numbers to offer more performance/features
than the smaller ones OF THE SAME GENERATION.  The same branding keeps
getting re-applied to later generations of chips, and IMO it is
intentionally confusing.

> I looked up the Ryzen 5 7600X
> and 8600G.  I think the X has no video and the G has video support.

Both have onboard graphics.  The G designates zen1-3 chips with a GPU
built in, and all zen4 CPUs have this as a standard feature.  The
7600X is zen4.

See what I mean about the branding getting confusing?

> I
> haven't researched yet to see if the mobo requires the G since it has
> video ports, two to be more precise which is the minimum I need.

All AM5 CPUs have GPUs, but in general motherboards with video outputs
do not require the CPU to have a GPU built in.  The ports just don't
do anything if this is lacking, and you would need a dedicated GPU.

> Anyway, those two CPUs are cheaper than the Ryzen 9 I was looking at.  I
> could upgrade later on as prices drop.  I'm sure a new Ryzen is lurking
> around the corner.

Zen5 is supposedly coming out later this year.  It will be very
expensive.  Zen4 is still kinda expensive I believe though I haven't
gone looking recently at prices.  I have a zen4 system and it was
expensive (particularly the motherboard, and the DDR5 is more
expensive, and if you want NVMe that does v5 that is more expensive as
well).

 > I have a FX-8350 8 core CPU now.  Would the Ryzen 5's mentioned above be
> a good bit faster, a lot, a whole lot?

So, that very much depends on what you're doing.

Single-thread performance of that 7600X is 2-3x faster.  Total
performance is almost 5x faster.  The 7600X will use moderately less
power at full load, and I'm guessing WAY less power at less than full
load.  It will also have much better performance than those numbers
reflect for very short bursts of work, since modern CPUs can boost.

That's just pure CPU performance.

The DDR5 performance of the recent CPU is MUCH better than that of the
DDR3 you're using now.  Your old motherboard might be PCIe v2 (I think
the controller for that was on the motherboard back then?).  If so
each lane delivers 8x more bandwidth on the recent CPU, which matters
a great deal for graphics, or for NVMe performance if you're using an
NVMe that supports it and have a workload that benefits from it.

Gaming tends to be a workload that benefits the most from all of these
factors.  If your system is just acting as a NAS and all the storage
is on hard drives, I'm guessing you won't see much of a difference at
all, except maybe in boot time, especially if you put the OS on an
NVMe.

If this is just for your NAS I would not drop all that money on zen4,
let alone zen5.  I'd look for something older, possibly used, that is
way cheaper.

> Still, I need more memory too.  32GBs just isn't much when running
> Seamonkey, three Firefox profiles and torrent software.

Ok, if this is for a desktop you'll benefit more from a newer CPU.
RAM is really expensive though these days.  Getting something
off-lease is going to save you a fortune as the RAM is practically
free in those.  You can get something with 32GB of DDR4 for $150 or
less in a SFF PC.

> I'm not running
> out but at times, it's using a lot of it.  I was hoping for a mobo that
> would handle more than 128GB but that is a lot of memory.

Any recent motherboard will handle 128GB.  You'll just need to use
large DIMMs as 

[gentoo-commits] repo/gentoo:master commit in: sys-process/systemd-cron/files/, sys-process/systemd-cron/

[Richard Freeman]

commit: 46d48ef3f778d1ec33a8115b17f8cd0a53b60b51
Author: Richard Freeman  gentoo  org>
AuthorDate: Tue Apr 16 15:08:08 2024 +
Commit: Richard Freeman  gentoo  org>
CommitDate: Tue Apr 16 15:16:01 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=46d48ef3

sys-process/systemd-cron: drop 1.16.7-r1, 2.3.0-r1, 2.3.0-r2

Signed-off-by: Richard Freeman  gentoo.org>

 sys-process/systemd-cron/Manifest  |   2 -
 .../files/systemd-cron-2.3.0-pch.patch |  46 -
 .../systemd-cron/systemd-cron-1.16.7-r1.ebuild |  95 --
 .../systemd-cron/systemd-cron-2.3.0-r1.ebuild  |  92 --
 .../systemd-cron/systemd-cron-2.3.0-r2.ebuild  | 106 -
 5 files changed, 341 deletions(-)

diff --git a/sys-process/systemd-cron/Manifest 
b/sys-process/systemd-cron/Manifest
index 06aa4d41d515..06b7f8013a30 100644
--- a/sys-process/systemd-cron/Manifest
+++ b/sys-process/systemd-cron/Manifest
@@ -1,4 +1,2 @@
-DIST systemd-cron-1.16.7.tar.gz 37887 BLAKE2B 
a900058cef1cd02ac464d3ecdd43ce2f264bdba386f349ef82f0a915104302b1e88d94331d5fbaabe2c54f526900f3e1ac65ea6bdc2f27a6464e6d7514561a19
 SHA512 
d65d641fd449cdc0e91db3ae6ebe464bc4e24027c501b30a8ab17e7cc40de290cc6141bfb7880a724d97248861587e6f5fea113a6aa6e468d971aff3a13b056f
 DIST systemd-cron-2.2.0.tar.gz 55825 BLAKE2B 
ca4b02fdea5084439aa56b3f04603000d811f21922c11cd26a22ea6387e4b54575587ff4e1eb7fc7a3260d2f656ea0eb91365942c135982f4bd26aead1a080f1
 SHA512 
f26c7d7e2da7eb5cd5558f352aff852585bfefd961de6ecc2409a4a53b63f82662a89bdbf71f739ea8e44ef9e3e1fdec15cdc63ce1e90c289fb0e636ff679ca0
-DIST systemd-cron-2.3.0.tar.gz 56873 BLAKE2B 
3efe8adc1b735ed5eb91c64d0936edceec50ff476d42ba5c1e9941c196a7bc8c777b0c293c8ed71894dae31c5b721a45a2876cab0143298e1b1ab3e82fcb7ceb
 SHA512 
abb7c34d6901160395d64cfc4e5124887909b963bcfee027f64642b25bb138b3f085eb45595197a380faf39b7f5980e32c50d083be6307d7c985a55057962565
 DIST systemd-cron-2.3.4.tar.gz 58458 BLAKE2B 
594fff8f7cc126aa33b1dcbf74293a39b5939576203c11f8f0fc300285462f266c35503a6cfe46ee797e5e617e54e09b92dd6ba8a4044f962d1efd2822f0a87c
 SHA512 
2a9743df6d0e1a83b65d15609e47b901fde1d77d1207c4cc0617395be8d9e94daece91aec9a3398c3d09f86383e01cfff301614df727ca598efe873453f5a3c9

diff --git a/sys-process/systemd-cron/files/systemd-cron-2.3.0-pch.patch 
b/sys-process/systemd-cron/files/systemd-cron-2.3.0-pch.patch
deleted file mode 100644
index e27f253a62ca..
--- a/sys-process/systemd-cron/files/systemd-cron-2.3.0-pch.patch
+++ /dev/null
@@ -1,46 +0,0 @@
-https://bugs.gentoo.org/917646
-https://github.com/systemd-cron/systemd-cron/issues/141
-https://github.com/systemd-cron/systemd-cron/commit/1662b899b206f00face30b9d4671551427262b07
-
-From 1662b899b206f00face30b9d4671551427262b07 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= 
-Date: Tue, 21 Nov 2023 19:40:05 +0100
-Subject: [PATCH] Add PCH= for broken compilers like #141
-
 a/Makefile.in
-+++ b/Makefile.in
-@@ -1,6 +1,7 @@
- CFLAGS ?= -O2
- SHELLCHECK ?= shellcheck
- CRONTAB ?= crontab
-+PCH ?= y
- 
- version   := @version@
- schedules := @schedules@
-@@ -208,12 +209,12 @@ $(builddir)/include/%.hpp: $(srcdir)/include/%.hpp
- CXXVER := $(shell $(CXX) --version | { read -r l; echo "$$l"; })
- ifneq "$(findstring clang,$(CXXVER))" ""
-   # clang doesn't use PCHs automatically
--  PCH_ARG := -include-pch $(builddir)/include/libvoreutils.hpp.gch 
-Wno-gcc-compat
-+  PCH_ARG := $(if $(PCH),-include-pch 
$(builddir)/include/libvoreutils.hpp.gch) -Wno-gcc-compat
- else
-   PCH_ARG :=
- endif
- 
--common_headers := $(builddir)/include/configuration.hpp 
$(builddir)/include/libvoreutils.hpp.gch $(builddir)/include/util.hpp
-+common_headers := $(builddir)/include/configuration.hpp 
$(builddir)/include/libvoreutils.hpp$(if $(PCH),.gch) 
$(builddir)/include/util.hpp
- CFLAGS += -Wall -Wextra -fno-exceptions -Wno-psabi
- $(builddir)/include/libvoreutils.hpp.gch : 
$(builddir)/include/libvoreutils.hpp
-   $(CXX) $(CFLAGS) $(CPPFLAGS) -std=c++20 -I $(builddir)/include  
  $< -o $@
 a/README.md
-+++ b/README.md
-@@ -146,6 +146,8 @@ without the override, the jobs would run twice since 
native-timer detection woul
- If there is already a perfect 1:1 mapping between `/etc/cron./` 
and `/usr/lib/systemd/system/.timer`,
- then it is not needed to add an entry to these tables.
- 
-+If your compiler's [PCH compilation is 
broken](https://github.com/systemd-cron/systemd-cron/issues/141), build with 
`make PCH=`.
-+
- ### Caveat
- 
- Your package should also run these extra commands before starting cron.target
-

diff --git a/sys-process/systemd-cron/systemd-cron-1.16.7-r1.ebuild 
b/sys-process/systemd-cron/systemd-cron-1.16.7-r1.ebuild
deleted file mode 100644
index b779832b971b..
--- a/sys-process/systemd-cron/systemd-cron-1.16.7-r1.ebuild
+++ /dev/null
@@ -1,95 +0,

[gentoo-commits] repo/gentoo:master commit in: sys-process/systemd-cron/

[Richard Freeman]

commit: 641c536fe4afa656f34ebb656bf1e8bca8bd87bc
Author: Richard Freeman  gentoo  org>
AuthorDate: Tue Apr 16 15:14:12 2024 +
Commit: Richard Freeman  gentoo  org>
CommitDate: Tue Apr 16 15:16:02 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=641c536f

sys-process/systemd-cron: Require split-usr in deps and no longer die.

Closes: https://bugs.gentoo.org/928893
Signed-off-by: Richard Freeman  gentoo.org>

 ...{systemd-cron-2.3.4.ebuild => systemd-cron-2.3.4-r1.ebuild} | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/sys-process/systemd-cron/systemd-cron-2.3.4.ebuild 
b/sys-process/systemd-cron/systemd-cron-2.3.4-r1.ebuild
similarity index 90%
rename from sys-process/systemd-cron/systemd-cron-2.3.4.ebuild
rename to sys-process/systemd-cron/systemd-cron-2.3.4-r1.ebuild
index 32892c37b102..00738f1c0e07 100644
--- a/sys-process/systemd-cron/systemd-cron-2.3.4.ebuild
+++ b/sys-process/systemd-cron/systemd-cron-2.3.4-r1.ebuild
@@ -23,7 +23,7 @@ RDEPEND="
acct-group/_cron-failure
app-crypt/libmd:=
sys-process/cronbase
-   >=sys-apps/systemd-253
+   >=sys-apps/systemd-255[-split-usr(-)]
!etc-crontab-systemd? ( !sys-process/dcron )
runparts? ( sys-apps/debianutils )
 "
@@ -32,14 +32,6 @@ DEPEND="
sys-process/cronbase
 "
 
-pkg_pretend() {
-   if use runparts && ! [ -x /usr/bin/run-parts ] ; then
-   eerror "Please complete the migration to merged-usr."
-   eerror "https://wiki.gentoo.org/wiki/Merge-usr;
-   die "systemd-cron no longer supports split-usr"
-   fi
-}
-
 src_prepare() {
sed -i \
-e 's/^crontab/crontab-systemd/' \

[jira] [Resolved] (CAMEL-20683) camel-spring-boot-examples/soap-cxf: use spring-boot-starter-undertow as the embedded servlet server and demonstrate how to configure undertow handlers

[Freeman Yue Fang (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-20683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Freeman Yue Fang resolved CAMEL-20683.
--
Resolution: Fixed

> camel-spring-boot-examples/soap-cxf: use spring-boot-starter-undertow as the 
> embedded servlet server and demonstrate how to configure undertow handlers
> ---
>
> Key: CAMEL-20683
> URL: https://issues.apache.org/jira/browse/CAMEL-20683
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-spring-boot
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 4.x
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CAMEL-20683) camel-spring-boot-examples/soap-cxf: use spring-boot-starter-undertow as the embedded servlet server and demonstrate how to configure undertow handlers

[Freeman Yue Fang (Jira)]

[ 
https://issues.apache.org/jira/browse/CAMEL-20683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837745#comment-17837745
 ] 

Freeman Yue Fang commented on CAMEL-20683:
--

By implementing WebServerFactoryCustomizer we 
can demonstrate how to configure undertow handlers in this example

> camel-spring-boot-examples/soap-cxf: use spring-boot-starter-undertow as the 
> embedded servlet server and demonstrate how to configure undertow handlers
> ---
>
> Key: CAMEL-20683
> URL: https://issues.apache.org/jira/browse/CAMEL-20683
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-spring-boot
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 4.x
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (CAMEL-20683) camel-spring-boot-examples/soap-cxf: use spring-boot-starter-undertow as the embedded servlet server and demonstrate how to configure undertow handlers

[Freeman Yue Fang (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-20683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Freeman Yue Fang updated CAMEL-20683:
-
Fix Version/s: 4.x

> camel-spring-boot-examples/soap-cxf: use spring-boot-starter-undertow as the 
> embedded servlet server and demonstrate how to configure undertow handlers
> ---
>
> Key: CAMEL-20683
> URL: https://issues.apache.org/jira/browse/CAMEL-20683
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-spring-boot
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 4.x
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (CAMEL-20683) camel-spring-boot-examples/soap-cxf: use spring-boot-starter-undertow as the embedded servlet server and demonstrate how to configure undertow handlers

[Freeman Yue Fang (Jira)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-20683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Freeman Yue Fang reassigned CAMEL-20683:


Assignee: Freeman Yue Fang

> camel-spring-boot-examples/soap-cxf: use spring-boot-starter-undertow as the 
> embedded servlet server and demonstrate how to configure undertow handlers
> ---
>
> Key: CAMEL-20683
> URL: https://issues.apache.org/jira/browse/CAMEL-20683
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-spring-boot
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (CAMEL-20683) camel-spring-boot-examples/soap-cxf: use spring-boot-starter-undertow as the embedded servlet server and demonstrate how to configure undertow handlers

[Freeman Yue Fang (Jira)]

Freeman Yue Fang created CAMEL-20683:


 Summary: camel-spring-boot-examples/soap-cxf: use 
spring-boot-starter-undertow as the embedded servlet server and demonstrate how 
to configure undertow handlers
 Key: CAMEL-20683
 URL: https://issues.apache.org/jira/browse/CAMEL-20683
 Project: Camel
  Issue Type: Improvement
  Components: camel-spring-boot
Reporter: Freeman Yue Fang






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [gentoo-user] NAS box and switching from Phenom II X6 1090T to FX-6300

[Rich Freeman]

On Sat, Apr 13, 2024 at 8:20 AM Dale  wrote:
>
> Right now, I have a three drive setup in a removable cage for the NAS
> box.

If you only need three drives I'm sure you can find cheap used
hardware that will handle that.  Odds are it will use way less power
and perform better than whatever you're going to upgrade your system
to.

> I'm not familiar with Ceph but I've seen it mentioned before.

Do NOT deploy Ceph with three drives on one host.

Ceph is what you think about using when you are tired of stacking HBAs
to cram a dozen SATA ports in a single host.  It isn't what you'd use
for backup/etc storage.

Honestly, if you're just looking for backup drives I'd consider USB3
drives you just plug into a host and run in a zpool or whatever.
Export the filesystem and unplug the drives and you're done.  That is
how I backup Ceph right now (k8s job that runs restic against ceph
dumping it on a zpool).

-- 
Rich

Re: [gentoo-user] NAS box and switching from Phenom II X6 1090T to FX-6300

[Rich Freeman]

On Sat, Apr 13, 2024 at 8:11 AM Dale  wrote:
>
> My biggest thing right now, finding a mobo with plenty of PCIe slots.
> They put all this new stuff, wifi and such, but remove things I do need,
> PCIe slots.

PCIe and memory capacity seem to have become the way the
server/workstation and consumer markets are segmented.

AM5 gets you 28x v5 lanes.  SP5 gets you 128x v5 lanes.  The server
socket also has way more memory capacity, though I couldn't quickly
identify exactly how much more due to the ambiguous way in which DDR5
memory channels are referenced all over the place.  Suffice it to say
you can put several times as many DIMMs into a typical server
motherboard, especially if you have two CPUs on it (two CPUs likewise
increases the PCIe capacity).

IT would be nice if there were switches out there that would let you
take a v5 PCIe slot on newer consumer hardware and break it out into a
bunch of v3/4 NVMe adapters (U.2, M.2, PCIe, whatever).

-- 
Rich

Re: [gentoo-user] NAS box and switching from Phenom II X6 1090T to FX-6300

[Rich Freeman]

On Sat, Apr 13, 2024 at 3:58 AM Dale  wrote:
>
> Given the FX-6300 has a higher clocks speed, 3.8GHz versus 3.2GHz for
> the Phenom, I'd think the FX would be a upgrade, quite a good one at
> that.  More L2 cache too.  Both are 6 cores according to what I found.
> Anyone know something I don't that would make switching to the FX-6300 a
> bad idea?

The most obvious issue is that you're putting money into a very obsolete system.

Obviously hardware of this generation is fairly cheap, but it isn't
actually the best bang for the buck, ESPECIALLY when you factor in
power use.  Like most AMD chips of that generation (well, most chips
in general when you get that old), that CPU uses quite a bit of power
at idle, and so that chip which might cost you $35 even at retail
might cost you double that amount per year just in electricity.

If your goal is to go cheap you also need to consider alternatives.
You can get used hardware from various places, and most of it is 3-5
years old.  Even commodity hardware of that age is far more powerful
than a 15 year old CPU socket and often it starts at $100 or so - and
that is for a complete system.  Often you can get stuff that is
ex-corporate that has a fair bit of RAM as well, since a lot of
companies need to deal with compatibility with office productivity
software that might be a little RAM hungry.  RAM isn't cheap these
days, and they practically give it away when they dispose of old
hardware.

The biggest issue you're going to have with NAS is finding something
with the desired number of drive bays, as a lot of used desktop
hardware is SFF (but also super-low-power, which is something
companies consider in their purchasing decisions when picking
something they're going to be buying thousands of).

Right now most of my storage is on Ceph on SFF PCs.  I do want to try
to get future expansion onto NVMe but even used systems that support
much of that are kinda expensive still (mostly servers since desktop
CPUs have so few PCIe lanes, and switches aren't that common).  One of
my constraints using Ceph though is I need a lot of RAM, which is part
of why I'm going the SFF route - for $100 you can get one with 32GB of
RAM and 2-3 SATA ports, plus USB3 and an unused 4-16x PCIe slot.  That
is a lot of RAM/IO compared to most options at that price point (ARM
in particular tends to lack both - not that it doesn't support it, but
rather nobody makes cheap ARM hardware with PCIe+DIMM slots).

-- 
Rich

Re: [PROPOSAL] Branch of 4.0.x, move main to 4.1.x (Jakarta EE 10)

[Freeman Fang]

+1 to move main branch to CXF 4.1.x, thanks Andriy!

Freeman

On Thu, Apr 11, 2024 at 7:48 AM Andriy Redko  wrote:

> Hey Folks,
>
> I would like to resume the discussion regarding 4.1.x (Jakarta EE 10): the
> Jakarta EE 9.x was a transitional release, most (if not all) already
> jumped off.
> From the CXF side, quite a lot of work has been done already on 4.1.x
> (Jakarta EE 10),
> streamlining it would definitely help. So far only @Francesco responded
> (thanks a lot)
> but would be great to hear from others. Thanks!
>
> Best Regards,
> Andriy Redko
>
> > +1 thanks Andriy
>
> > Regards.
>
> > On 09/07/23 20:29, Andriy Redko wrote:
> >> Hey Folks,
>   >>> The work on Jakarta EE 10 had started already (so far the progress
> was a bit slower
> >> than desired but the things should accelerate I hope). It becomes
> increasingly difficult
> >> to keep the separate pull request [1] intact (particularly, dependabot
> is constantly trying
> >> to update to latest specs). To ease the implementation efforts, I would
> like to propose
> >> to:
> >>   - branch of 4.0.x-fixes from main
> >>   - move main to 4.1.x
> >>   - work on [1] to be ready for merge with main
> >>  From the maintenance perspective, that would increase a bit the amount
> of work required:
> >>   - 3.5.x and 3.6.x: those are the last (hopefully) branches for
> javax.* to maintain
> >>   - 4.0.x and 4.1.x (upcoming): those are the ones to support going
> forward for jakarta.* to maintain
> >> Any feedback / thoughts / suggestions are very welcome!
> >> Thanks!
> >> [1] https://issues.apache.org/jira/browse/CXF-8671
> >> [2] https://github.com/apache/cxf/pull/1201
> >> Best Regards,
> >>  Andriy Redko
>
>

WWW: missing link to plus75.html on plus74.html

[Ryan Freeman]

Quickly reviewed other plusXX.html pages, only plus74.html seems to omit it.

Index: plus74.html
===
RCS file: /cvs/www/plus74.html,v
diff -u -p -r1.3 plus74.html
--- plus74.html 4 Oct 2023 15:06:06 -   1.3
+++ plus74.html 10 Apr 2024 04:31:28 -
@@ -91,6 +91,7 @@ For changes in other releases, click bel
 7.1,
 7.2,
 7.3,
+7.5,
 current.
 

fix closing tag in plus75.html

[Ryan Freeman]

Hi, this fixes the closing  tag on the -current line.

-ryan

18:14 ryan@build-amd64:/usr/src/www$ cvs diff -uNp plus75.html
Index: plus75.html
===
RCS file: /cvs/www/plus75.html,v
diff -u -p -u -p -r1.1 plus75.html
--- plus75.html 5 Apr 2024 12:16:50 -   1.1
+++ plus75.html 10 Apr 2024 01:14:38 -
@@ -92,7 +92,7 @@ For changes in other releases, click bel
 7.2,
 7.3,
 7.4,
--current/a>.
+-current.
 
 
 

ls flag to show number of hard links

[Tony Freeman]

I seem to recall that some years ago ls -l would show the number of hard
links to a file. This may have been on an AIX system. I needed to use this
today on a red hat 8 machine but couldn't figure it out.   So I used ls -i
| sort

Am I overlooking a flag to ls that would show me the number of hard links?

[jira] [Commented] (CXF-8987) Java 21 - HttpClientHTTPConduit thread locked during shutdown

[Freeman Yue Fang (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834027#comment-17834027
 ] 

Freeman Yue Fang commented on CXF-8987:
---

Hi [~carnevalegiacomo],

Is it possible that you append a reproducer project so that we can reproduce 
this behaviour easily?

Thanks!
Freeman

> Java 21 - HttpClientHTTPConduit thread locked during shutdown 
> --
>
> Key: CXF-8987
> URL: https://issues.apache.org/jira/browse/CXF-8987
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 4.0.3, 4.0.4
> Environment: [^thdump2]
> *OpenJDK 21.0.2*
> *Apache CXF 4.0.4*
> *Apache Camel 4.4.1*
>Reporter: Giacomo Carnevale
>Priority: Blocker
> Attachments: thdump2
>
>
> Hi,
> I am using Apache CXF client via the Apache Camel CXF connector.
> After I updated frm OpenJDK 17.x to OpenJDK 21.0.2, during application 
> shutdown, the following lock occurs:
> *at java.lang.Thread.join(java.base@21.0.2/Thread.java:2072)*
>     *- locked <0x00061cd2ab80> (a 
> jdk.internal.net.http.HttpClientImpl$SelectorManager)*
>     *at java.lang.Thread.join(java.base@21.0.2/Thread.java:2200)*
>     *at 
> jdk.internal.net.http.HttpClientImpl.awaitTermination(java.net.http@21.0.2/HttpClientImpl.java:628)*
>     *at 
> java.net.http.HttpClient.{color:#de350b}close{color}(java.net.http@21.0.2/HttpClient.java:900)*
>     *at 
> jdk.internal.net.http.HttpClientFacade.{color:#de350b}close{color}(java.net.http@21.0.2/HttpClientFacade.java:192)*
>     *at 
> org.apache.cxf.transport.http.HttpClientHTTPConduit.{color:#de350b}close{color}(HttpClientHTTPConduit.java:125)*
> HttpClientHTTPConduit.close
> {code:java}
> public void close() {
> if (client instanceof AutoCloseable) {
> try {
> ((AutoCloseable)client).close();
> } catch (Exception e) {
> //ignore
> }
> } else if (client != null) {
> String name = client.toString();
> client = null;
> tryToShutdownSelector(name);
> }
> defaultAddress = null;
> super.close();
> } {code}
>  
> java.net.HttpClient.close
>  
> {code:java}
> public void close() {
> boolean terminated = isTerminated();
> if (!terminated) {
> shutdown();
> boolean interrupted = false;
> while (!terminated) {
> try {
> terminated = awaitTermination(Duration.ofDays(1L));
> } catch (InterruptedException e) {
> if (!interrupted) {
> interrupted = true;
> shutdownNow();
> if (isTerminated()) break;
> }
> }
> }
> if (interrupted) {
> Thread.currentThread().interrupt();
> }
> }
> } {code}
> My workaround
> {code:java}
> public void close() {
> if (client instanceof AutoCloseable) {
> try {
> client.shutdownNow();
> //((AutoCloseable)client).close();
> } catch (Exception e) {
> //ignore
> }
> } else if (client != null) {
> String name = client.toString();
> client = null;
> tryToShutdownSelector(name);
> }
> defaultAddress = null;
> super.close();
> } {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-8998) cxf-codegen-plugin - debug output velocity

[Freeman Yue Fang (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833655#comment-17833655
 ] 

Freeman Yue Fang commented on CXF-8998:
---

Hi [~khmarbaise],

I just quick tested samples/wsdl_first shipped with CXF 4.0.4 kit, but I can't 
see the DEBUG org.apache.velocity output there.

Any chance you can append a reproducer project so that we can take a closer 
look?

Thanks!
Freeman

> cxf-codegen-plugin - debug output velocity
> --
>
> Key: CXF-8998
> URL: https://issues.apache.org/jira/browse/CXF-8998
> Project: CXF
>  Issue Type: Improvement
>  Components: Configuration
>Affects Versions: 4.0.4
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> Currently we are using {{cxf-codegen-plugin}}, which produces allways 
> debugging output of velocity, on the console
> {code}
> 15:59:45  [INFO] 
> 15:59:45  [INFO] --- cxf-codegen:4.0.4:wsdl2java (default) @ wsdls ---
> 15:59:45  [INFO] Running code generation in fork mode...
> 15:59:45  [INFO] bin/java
> 15:59:45  [INFO] Building jar: /tmp/cxf-tmp-7/cxf-codegen.jar
> 15:59:45  [WARNING] Picked up JAVA_TOOL_OPTIONS: .
> 15:59:46  [INFO] 15:59:46.356 [main] DEBUG org.apache.velocity -- 
> Initializing Velocity, Calling init()...
> 15:59:46  [INFO] 15:59:46.360 [main] DEBUG org.apache.velocity -- Starting 
> Apache Velocity v2.3
> 15:59:46  [INFO] 15:59:46.362 [main] DEBUG org.apache.velocity -- Default 
> Properties resource: org/apache/velocity/runtime/defaults/velocity.properties
> 15:59:53  [INFO] 
> {code}
> Is there an easy way to suppress the debug output for the execution of the 
> plugin?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

[Rich Freeman]

On Sun, Mar 31, 2024 at 5:36 PM Wol  wrote:
>
> On 31/03/2024 20:38, Håkon Alstadheim wrote:
> > For commercial entities, the government could just contact the company
> > and apply pressure, no need to sneak the backdoor in. Cf. RSA .
>
> Serving a "secret compliance" notice on a third party is always fraught
> with danger. Okay, I probably can't trust my own government to protect
> me, but if the US Government served a compliance notice on me I'd treat
> it with the respect it deserved - probably use it as loo paper!

I imagine most large companies would just comply with their local
government, but there are some major limitations all the same:

1. It isn't necessarily the local government who wants to plant the
back door.  The FBI can't just call up Huawei and get the same results
they would with Google.
2. Even if the company complies, there are going to be more people who
are aware of the back door.  Some of those could be foreign agents.
If you infiltrate the company and obfuscate your code, then only your
own agents are aware there is an intrusion.
3. The methods employed in your attack might also be sensitive, and so
that's another reason to not want to disclose them.  If you have some
way of subtly compromising some encryption scheme, you might not want
any employees of the company to even know the cryptosystem weakness
even exists, let alone the fact that you're exploiting it.  When the
methods are secret in this way it is that much easier to obfuscate a
clandestine attack as well.

When you look at engineer salaries against national defense budgets,
it wouldn't surprise me if a LOT of FOSS (and other) contributors are
being paid to add back doors.  On the positive side, that probably
also means that they're getting paid to fix a lot of bugs and add
features just to give them cover.

To bomb a power plant might take the combined efforts of 1-2 dozen
military aircraft in various roles, at $100M+ each (granted, that's
acquisition cost and not operational cost).  Installing a trojan that
would cause the plant to blow itself up on command might just require
paying a few developers for a few years, for probably less than $1M
total, and it isn't even that obvious that you were involved if it
gets discovered, or even after the plant blows up.

-- 
Rich

Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

[Rich Freeman]

On Sun, Mar 31, 2024 at 10:59 AM Michael  wrote:
>
> On Sunday, 31 March 2024 13:33:20 BST Rich Freeman wrote:
> > (moving this to gentoo-user as this is really getting off-topic for -dev)
>
> Thanks for bringing this to our attention Rich.
>
> Is downgrading to app-arch/xz-utils-5.4.2 all that is needed for now, or are
> we meant to rebuilding any other/all packages, especially if we rebuilt our
> @world only a week ago as part of the move to profile 23.0?

It is not necessary to rebuild anything, unless you're doing something
so unusual that you'd already know the answer to the question.

-- 
Rich

[gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

[Rich Freeman]

(moving this to gentoo-user as this is really getting off-topic for -dev)

On Sun, Mar 31, 2024 at 7:32 AM stefan1
 wrote:
>
> Had I seen someone say that a bad actor would spend years gaining the
> trust of FOSS
> project maintainers in order to gain commit access and introduce such
> sophisticated
> back doors, I would have told them to take their meds.
> This is insane.

It makes quite a bit of sense though.  For a low-activity FOSS
project, how much manpower does it take to gain a majority share of
the governance?  In this case it is one person, but even for a big
project (such as Gentoo) I suspect that 3-4 people working full time
could probably hit upwards of 50% of the commit volume.  That doesn't
have to be 3-4 "Gentoo developers."  It could be 3-4 human beings with
1 admin assistant who manages 50 email addresses that the commits get
spread across, and they sign up as 50 Gentoo developers and get 50
votes for the Council (and probably half the positions there if they
want them), the opportunity to peer review "each other's"
contributions, and so on.

I just use Gentoo as an example as we're all familiar with it and
probably assume it couldn't happen here.  As you go on, the actual
targets are likely to be other projects...

> If this happened to something like firefox, I don't think anyone would
> have found out.
> No one bats an eye if a website loads 0.5s longer.

It seems likely that something like this has ALREADY happened to firefox.

It might also happen with commercial software, but the challenge there
is HR as you can't just pay 1 person to masquerade as 10 when they all
need to deal with payroll taxes.

We're going on almost 20 years since the Snowden revelations, and back
then the NSA was basically doing intrusion on an industrial scale.
You'd have dev teams building zero days and rootkits, sysadmin teams
who just administrate those back doors to make sure there are always
2-3 ways in just in case one gets closed, SMEs who actually make sense
of the stolen data, rooms full of engineers who receive intercepted
shipments of hardware and install backdoors on them, and so on.

We're looking at what probably only one person can do if they can
dedicate full time to something like this.  Imagine what a cube farm
full of supervised developers with a $50M budget could do, and that is
pocket change to most state actors.  The US government probably spends
more than that in a year on printer paper.

-- 
Rich

Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

[Rich Freeman]

On Sat, Mar 30, 2024 at 10:57 AM Eddie Chapman  wrote:
>
> No, this is the the bad actor *themselves* being a
> principal author of the software, working stealthily and in very
> sophisticated ways for years, to manoeuvrer themselves and their software
> into a position of trust in the ecosystem whereby they were almost able to
> pull off the mother of all security nightmares for the world.

This is entirely speculative at this point.  It isn't certain that the
author is the one behind the exploit, and if they were, it is not
known for how long their intentions were malicious, or even what their
motivations were.  It is also unclear what pseudonymous accounts with
what projects are associated with the attacker.

You could end up being right, but it probably makes sense to at least
give things a few days for more facts to become available, before
making decisions to retool the entire distro.

I think the bigger challenge is what could have been done to prevent
this sort of problem in the first place.  There are so many projects
that end up with code running as root that have one or two people
taking care of them, and if somebody does the work to become one of
those maintainers, there aren't many people looking out for problems.

I think one thing that would help here is for distros to have better
ways to ensure that the code in the scm matches the code in the
tarball.  It is pretty common for releases to be manipulated in some
way (even if only to gpg sign them, but often to switch from commit
IDs to version numbers and so on), and that can be a place where stuff
gets added.  That still says nothing about obfuscated code, which this
also involved.

-- 
Rich

Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

[Rich Freeman]

On Sat, Mar 30, 2024 at 3:06 AM Dale  wrote:
>
> when I got to the part about it not likely to affect Gentoo, my level of 
> concern dropped significantly.  If this is still true, there's no need to be 
> concerned.

"not likely" is the best way to characterize this.  The exploit has
not been fully analyzed, and it could have additional malicious
behavior, either designed by its author, or perhaps even unintended by
its author.

I just wanted to toss in that caveat, but agree that the defaults
deployed in Gentoo seem the most sensible for general use.  There is
nothing magical about xz - ANY widely-used library could have
something like this embedded in it, and the attacker exploited what
they had access to in order to go after a configuration that was going
to be widely deployed and reachable (xz+deb/rpm+systemd+openssh).  If
the attacker had an intended target that used gentoo+openrc and access
to something in our supply chain, this could have been a vulnerability
that only impacted Gentoo.

I think the big lesson here is that FOSS continues to suffer from core
dependencies that are challenged for resources, and that efforts to
fix this have to constantly keep up with the changing landscape.  xz
is going on 15 years old, but I don't think it was nearly as commonly
used until fairly recently.

libz has been a pretty well-known source of security flaws for ages
(granted, usually not intentional like this).  It isn't too surprising
that in both cases compression libraries were targeted, as these are
so widely depended on.

This is getting tangential, but part of me wonders if there is a
better way to do authentication.  Programs like ssh tend to run as
root so that they can authenticate users and then fork and suid to the
appropriate user.  Could some OS-level facility be created to allow
unprivileged processes to run the daemons and then as part of the
authentication process they can have the OS accept a controlled and
minimal set of data to create the process as the new user and hand
over the connection?  PAM already has a large amount of control over
the authentication process, so it seems like we just need to change
the security context that this runs in.  That's just
brainstorming-level thinking though - there could be obvious issues
with this that just haven't occurred to me.

-- 
Rich

[gentoo-commits] repo/gentoo:master commit in: sys-process/systemd-cron/

[Richard Freeman]

commit: 5bf8858b838e87def072cbc01927768799b7cc89
Author: Richard Freeman  gentoo  org>
AuthorDate: Fri Mar 29 11:31:04 2024 +
Commit: Richard Freeman  gentoo  org>
CommitDate: Fri Mar 29 11:31:24 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5bf8858b

sys-process/systemd-cron: add 2.3.4

Signed-off-by: Richard Freeman  gentoo.org>

 sys-process/systemd-cron/Manifest  |   1 +
 sys-process/systemd-cron/systemd-cron-2.3.4.ebuild | 101 +
 2 files changed, 102 insertions(+)

diff --git a/sys-process/systemd-cron/Manifest 
b/sys-process/systemd-cron/Manifest
index 8da4bc90b8c5..06aa4d41d515 100644
--- a/sys-process/systemd-cron/Manifest
+++ b/sys-process/systemd-cron/Manifest
@@ -1,3 +1,4 @@
 DIST systemd-cron-1.16.7.tar.gz 37887 BLAKE2B 
a900058cef1cd02ac464d3ecdd43ce2f264bdba386f349ef82f0a915104302b1e88d94331d5fbaabe2c54f526900f3e1ac65ea6bdc2f27a6464e6d7514561a19
 SHA512 
d65d641fd449cdc0e91db3ae6ebe464bc4e24027c501b30a8ab17e7cc40de290cc6141bfb7880a724d97248861587e6f5fea113a6aa6e468d971aff3a13b056f
 DIST systemd-cron-2.2.0.tar.gz 55825 BLAKE2B 
ca4b02fdea5084439aa56b3f04603000d811f21922c11cd26a22ea6387e4b54575587ff4e1eb7fc7a3260d2f656ea0eb91365942c135982f4bd26aead1a080f1
 SHA512 
f26c7d7e2da7eb5cd5558f352aff852585bfefd961de6ecc2409a4a53b63f82662a89bdbf71f739ea8e44ef9e3e1fdec15cdc63ce1e90c289fb0e636ff679ca0
 DIST systemd-cron-2.3.0.tar.gz 56873 BLAKE2B 
3efe8adc1b735ed5eb91c64d0936edceec50ff476d42ba5c1e9941c196a7bc8c777b0c293c8ed71894dae31c5b721a45a2876cab0143298e1b1ab3e82fcb7ceb
 SHA512 
abb7c34d6901160395d64cfc4e5124887909b963bcfee027f64642b25bb138b3f085eb45595197a380faf39b7f5980e32c50d083be6307d7c985a55057962565
+DIST systemd-cron-2.3.4.tar.gz 58458 BLAKE2B 
594fff8f7cc126aa33b1dcbf74293a39b5939576203c11f8f0fc300285462f266c35503a6cfe46ee797e5e617e54e09b92dd6ba8a4044f962d1efd2822f0a87c
 SHA512 
2a9743df6d0e1a83b65d15609e47b901fde1d77d1207c4cc0617395be8d9e94daece91aec9a3398c3d09f86383e01cfff301614df727ca598efe873453f5a3c9

diff --git a/sys-process/systemd-cron/systemd-cron-2.3.4.ebuild 
b/sys-process/systemd-cron/systemd-cron-2.3.4.ebuild
new file mode 100644
index ..32892c37b102
--- /dev/null
+++ b/sys-process/systemd-cron/systemd-cron-2.3.4.ebuild
@@ -0,0 +1,101 @@
+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+inherit systemd toolchain-funcs
+
+DESCRIPTION="systemd units to create timers for cron directories and crontab"
+HOMEPAGE="https://github.com/systemd-cron/systemd-cron/;
+SRC_URI="https://github.com/systemd-cron/${PN}/archive/v${PV}.tar.gz -> 
systemd-cron-${PV}.tar.gz"
+
+LICENSE="MIT"
+SLOT="0"
+KEYWORDS="~amd64 ~arm ~arm64 ~hppa ~ia64 ~ppc ~ppc64 ~riscv ~sparc ~x86"
+IUSE="cron-boot etc-crontab-systemd minutely +runparts setgid yearly"
+# We can't run the unshare tests within sandbox/with low privs, and the
+# 'test-nounshare' target just does static analysis (shellcheck etc).
+RESTRICT="test"
+
+BDEPEND="virtual/pkgconfig"
+RDEPEND="
+   !sys-process/cronie[anacron]
+   acct-user/_cron-failure
+   acct-group/_cron-failure
+   app-crypt/libmd:=
+   sys-process/cronbase
+   >=sys-apps/systemd-253
+   !etc-crontab-systemd? ( !sys-process/dcron )
+   runparts? ( sys-apps/debianutils )
+"
+DEPEND="
+   dev-libs/openssl:=
+   sys-process/cronbase
+"
+
+pkg_pretend() {
+   if use runparts && ! [ -x /usr/bin/run-parts ] ; then
+   eerror "Please complete the migration to merged-usr."
+   eerror "https://wiki.gentoo.org/wiki/Merge-usr;
+   die "systemd-cron no longer supports split-usr"
+   fi
+}
+
+src_prepare() {
+   sed -i \
+   -e 's/^crontab/crontab-systemd/' \
+   -e 's/^CRONTAB/CRONTAB-SYSTEMD/' \
+   -- "${S}/src/man/crontab."{1,5}".in" || die
+
+   if use etc-crontab-systemd
+   thensed -i \
+   -e "s!/etc/crontab!/etc/crontab-systemd!" \
+   -- "${S}/src/man/crontab."{1,5}".in" \
+   "${S}/src/bin/systemd-crontab-generator.cpp" \
+   "${S}/test/test-generator" || die
+   fi
+
+   default
+}
+
+my_use_enable() {
+   if use ${1}; then
+   echo --enable-${2:-${1}}=yes
+   else
+   echo --enable-${2:-${1}}=no
+   fi
+}
+
+src_configure() {
+   tc-export PKG_CONFIG CXX CC
+
+   ./configure \
+   --prefix="${EPREFIX}/usr" \
+   --mandir="${EPREFIX}/usr/share/man" \
+   --unitdir="$(systemd_get_systemunitdir)" \
+   --generatordir="$(systemd_get_systemgeneratordir)" \

[gentoo-commits] repo/gentoo:master commit in: app-backup/duplicity/, app-backup/duplicity/files/

[Richard Freeman]

commit: 0692ee17f584257f8e0dce50e2849c823bf02b81
Author: Richard Freeman  gentoo  org>
AuthorDate: Fri Mar 29 11:18:50 2024 +
Commit: Richard Freeman  gentoo  org>
CommitDate: Fri Mar 29 11:19:16 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0692ee17

app-backup/duplicity: add 2.2.3

Signed-off-by: Richard Freeman  gentoo.org>

 app-backup/duplicity/Manifest  |  1 +
 app-backup/duplicity/duplicity-2.2.3.ebuild| 51 ++
 .../files/duplicity-2.2.3-fix-docs-cmd.patch   | 21 +
 3 files changed, 73 insertions(+)

diff --git a/app-backup/duplicity/Manifest b/app-backup/duplicity/Manifest
index 7e9e1a4f388a..945214bd10d2 100644
--- a/app-backup/duplicity/Manifest
+++ b/app-backup/duplicity/Manifest
@@ -1,2 +1,3 @@
 DIST duplicity-2.1.1.tar.gz 1420132 BLAKE2B 
35cfa7c6c2caa647f3b2046783185973203b5d838c0d1a1a8e24982f1c7f74a1d025e0b0740c0c7bc14d516c59d3e691a2712b19b30882e9dbb411cecb90f4be
 SHA512 
fb19b1723e1e220ca72a41c3678ca29d889b2315c7fd043334d55cc2040d991e66480d71c6cc3f2ee5d17d9e1d9fb24ddc4c0ed771bbbefb6f1f6aa14cbe0347
 DIST duplicity-2.1.4.tar.gz 1556341 BLAKE2B 
d8302a7097519fd593fc05c8390101e615eaf11333e9d15e1ba7756b8ed9764709db80df41c741ee39eda0fa6de22c910b53db32d558c1ab09867c66724a056c
 SHA512 
91804c6f4dc13d700cbe4747317f9611f530996de8a22a0907d714fb6f8a7fadc3371c270a2257c24324c0233bb4501a4b7d33aea7631862568c8530f7173ef1
+DIST duplicity-2.2.3.tar.gz 1978008 BLAKE2B 
29a88eb059c3dd6faa7d08d52216cd0f9d96255eae1e613e2c5432bf8f36ad014484953e20b4a0dfaa2704dd6ac426a3285ff40a8cc82f287a8a89199df5a2c5
 SHA512 
b667092317899674c5e9d4b221815f24a7eae177d3d2b6d298f07d3e2d4a7badd6c976a6317331b7c6cea940a7885a3da397ab7197d5fd671d33278316f86916

diff --git a/app-backup/duplicity/duplicity-2.2.3.ebuild 
b/app-backup/duplicity/duplicity-2.2.3.ebuild
new file mode 100644
index ..71908351c86d
--- /dev/null
+++ b/app-backup/duplicity/duplicity-2.2.3.ebuild
@@ -0,0 +1,51 @@
+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+PYTHON_COMPAT=( python3_10 python3_11 python3_12 )
+DISTUTILS_USE_PEP517=setuptools
+DISTUTILS_EXT=1
+
+inherit distutils-r1 pypi
+
+DESCRIPTION="Secure backup system using gnupg to encrypt data"
+HOMEPAGE="https://duplicity.gitlab.io/;
+
+LICENSE="GPL-3"
+SLOT="0"
+KEYWORDS="~amd64 ~x86 ~amd64-linux ~x86-linux ~x64-macos"
+IUSE="s3 test"
+
+CDEPEND="
+   net-libs/librsync
+   app-crypt/gnupg
+   dev-python/fasteners[${PYTHON_USEDEP}]
+"
+DEPEND="${CDEPEND}
+   dev-python/setuptools[${PYTHON_USEDEP}]
+   dev-python/setuptools-scm[${PYTHON_USEDEP}]
+   test? (
+   app-arch/par2cmdline
+   dev-python/mock[${PYTHON_USEDEP}]
+   dev-python/pexpect[${PYTHON_USEDEP}]
+   )
+"
+RDEPEND="${CDEPEND}
+   dev-python/paramiko[${PYTHON_USEDEP}]
+   s3? ( dev-python/boto3[${PYTHON_USEDEP}] )
+"
+
+RESTRICT="test"
+
+PATCHES=(
+   "${FILESDIR}/${P}-fix-docs-cmd.patch"
+)
+
+python_test() {
+   esetup.py test
+}
+
+pkg_postinst() {
+   elog "Duplicity has many optional dependencies to support various 
backends."
+   elog "Currently it's up to you to install them as necessary."
+}

diff --git a/app-backup/duplicity/files/duplicity-2.2.3-fix-docs-cmd.patch 
b/app-backup/duplicity/files/duplicity-2.2.3-fix-docs-cmd.patch
new file mode 100644
index ..13e4d909f46a
--- /dev/null
+++ b/app-backup/duplicity/files/duplicity-2.2.3-fix-docs-cmd.patch
@@ -0,0 +1,21 @@
+--- a/setup.py 2024-03-29 07:04:27.847027200 -0400
 b/setup.py 2024-03-29 07:05:03.924506321 -0400
+@@ -93,18 +93,6 @@
+ "man/duplicity.1",
+ ],
+ ),
+-(
+-f"share/doc/duplicity-{Version}",
+-[
+-"CHANGELOG.md",
+-"AUTHORS.md",
+-"COPYING",
+-"README.md",
+-"README-LOG.md",
+-"README-REPO.md",
+-"README-TESTING.md",
+-],
+-),
+ ]
+ 
+ # short circuit fot READTHEDOCS

[jira] [Commented] (CXF-8990) Cxf plugins (codegen, xjc): fails in versions 4.0.4, 4.0.1

[Freeman Yue Fang (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829981#comment-17829981
 ] 

Freeman Yue Fang commented on CXF-8990:
---

You are very welcome Claus!

> Cxf plugins (codegen, xjc): fails in versions 4.0.4, 4.0.1 
> ---
>
> Key: CXF-8990
> URL: https://issues.apache.org/jira/browse/CXF-8990
> Project: CXF
>  Issue Type: Bug
>Reporter: Jiri Ondrusek
>    Assignee: Freeman Yue Fang
>Priority: Major
>
> I was building Camel right after the upgrade of plugins (cxf-codegen to 4.0.4 
> and cxf-xjc to 4.0.1) See 
> [https://github.com/apache/camel/commit/a1bc751d7d8f5fb2016ed54e0735de5e4e9ec18b]
>  
> The build failed with:
> {code:java}
> [INFO] < org.apache.camel:camel-itest 
> >
> [INFO] Building Camel :: Integration Tests 4.5.0-SNAPSHOT             
> [557/559]
> [INFO]   from tests/camel-itest/pom.xml
> [INFO] [ jar 
> ]-
> [INFO] 
> [INFO] --- clean:3.3.2:clean (default-clean) @ camel-itest ---
> [INFO] Deleting /home/jondruse/git/community/camel/tests/camel-itest/target
> [INFO] 
> [INFO] --- cxf-codegen:4.0.4:wsdl2java (generate-test-sources) @ camel-itest 
> ---
> [INFO] Running code generation in fork mode...
> [INFO] The java executable is 
> /home/jondruse/.sdkman/candidates/java/17.0.9-tem/bin/java
> [INFO] Building jar: 
> /tmp/cxf-tmp-14372731791450387841/cxf-codegen4454546328799244847.jar
> [WARNING] Exception in thread "main" 
> org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding 
> file, please check the namespace
>  {code}
> {code:java}
> ...
> ERROR] Failed to execute goal 
> org.apache.cxf:cxf-codegen-plugin:4.0.4:wsdl2java (generate-test-sources) on 
> project camel-itest: 
> [ERROR] Exit code: 1
> [ERROR] Command line was: 
> /home/jondruse/.sdkman/candidates/java/17.0.9-tem/bin/java 
> --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED 
> --add-exports=java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED 
> --add-opens java.base/java.security=ALL-UNNAMED --add-opens 
> java.base/java.net=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED 
> --add-opens java.base/java.util=ALL-UNNAMED --add-opens 
> java.base/java.util.concurrent=ALL-UNNAMED -jar 
> /tmp/cxf-tmp-14372731791450387841/cxf-codegen4454546328799244847.jar 
> /tmp/cxf-tmp-14372731791450387841/cxf-w2j15211708284601236974args
> {code}
> Issue can be simulated by building of Camel from this commit: 
> https://github.com/apache/camel/commit/a1bc751d7d8f5fb2016ed54e0735de5e4e9ec18b



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (CXF-8990) Cxf plugins (codegen, xjc): fails in versions 4.0.4, 4.0.1

[Freeman Yue Fang (Jira)]

 [ 
https://issues.apache.org/jira/browse/CXF-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Freeman Yue Fang reassigned CXF-8990:
-

Assignee: Freeman Yue Fang

> Cxf plugins (codegen, xjc): fails in versions 4.0.4, 4.0.1 
> ---
>
> Key: CXF-8990
> URL: https://issues.apache.org/jira/browse/CXF-8990
> Project: CXF
>  Issue Type: Bug
>Reporter: Jiri Ondrusek
>    Assignee: Freeman Yue Fang
>Priority: Major
>
> I was building Camel right after the upgrade of plugins (cxf-codegen to 4.0.4 
> and cxf-xjc to 4.0.1) See 
> [https://github.com/apache/camel/commit/a1bc751d7d8f5fb2016ed54e0735de5e4e9ec18b]
>  
> The build failed with:
> {code:java}
> [INFO] < org.apache.camel:camel-itest 
> >
> [INFO] Building Camel :: Integration Tests 4.5.0-SNAPSHOT             
> [557/559]
> [INFO]   from tests/camel-itest/pom.xml
> [INFO] [ jar 
> ]-
> [INFO] 
> [INFO] --- clean:3.3.2:clean (default-clean) @ camel-itest ---
> [INFO] Deleting /home/jondruse/git/community/camel/tests/camel-itest/target
> [INFO] 
> [INFO] --- cxf-codegen:4.0.4:wsdl2java (generate-test-sources) @ camel-itest 
> ---
> [INFO] Running code generation in fork mode...
> [INFO] The java executable is 
> /home/jondruse/.sdkman/candidates/java/17.0.9-tem/bin/java
> [INFO] Building jar: 
> /tmp/cxf-tmp-14372731791450387841/cxf-codegen4454546328799244847.jar
> [WARNING] Exception in thread "main" 
> org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding 
> file, please check the namespace
>  {code}
> {code:java}
> ...
> ERROR] Failed to execute goal 
> org.apache.cxf:cxf-codegen-plugin:4.0.4:wsdl2java (generate-test-sources) on 
> project camel-itest: 
> [ERROR] Exit code: 1
> [ERROR] Command line was: 
> /home/jondruse/.sdkman/candidates/java/17.0.9-tem/bin/java 
> --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED 
> --add-exports=java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED 
> --add-opens java.base/java.security=ALL-UNNAMED --add-opens 
> java.base/java.net=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED 
> --add-opens java.base/java.util=ALL-UNNAMED --add-opens 
> java.base/java.util.concurrent=ALL-UNNAMED -jar 
> /tmp/cxf-tmp-14372731791450387841/cxf-codegen4454546328799244847.jar 
> /tmp/cxf-tmp-14372731791450387841/cxf-w2j15211708284601236974args
> {code}
> Issue can be simulated by building of Camel from this commit: 
> https://github.com/apache/camel/commit/a1bc751d7d8f5fb2016ed54e0735de5e4e9ec18b



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-8990) Cxf plugins (codegen, xjc): fails in versions 4.0.4, 4.0.1

[Freeman Yue Fang (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829920#comment-17829920
 ] 

Freeman Yue Fang commented on CXF-8990:
---

Hi [~jondruse],

I just pushed the fix on camel side.
https://github.com/apache/camel/commit/c2f719109610538374003e66049a83b6f5d5b323

Freeman

> Cxf plugins (codegen, xjc): fails in versions 4.0.4, 4.0.1 
> ---
>
> Key: CXF-8990
> URL: https://issues.apache.org/jira/browse/CXF-8990
> Project: CXF
>  Issue Type: Bug
>Reporter: Jiri Ondrusek
>Priority: Major
>
> I was building Camel right after the upgrade of plugins (cxf-codegen to 4.0.4 
> and cxf-xjc to 4.0.1) See 
> [https://github.com/apache/camel/commit/a1bc751d7d8f5fb2016ed54e0735de5e4e9ec18b]
>  
> The build failed with:
> {code:java}
> [INFO] < org.apache.camel:camel-itest 
> >
> [INFO] Building Camel :: Integration Tests 4.5.0-SNAPSHOT             
> [557/559]
> [INFO]   from tests/camel-itest/pom.xml
> [INFO] [ jar 
> ]-
> [INFO] 
> [INFO] --- clean:3.3.2:clean (default-clean) @ camel-itest ---
> [INFO] Deleting /home/jondruse/git/community/camel/tests/camel-itest/target
> [INFO] 
> [INFO] --- cxf-codegen:4.0.4:wsdl2java (generate-test-sources) @ camel-itest 
> ---
> [INFO] Running code generation in fork mode...
> [INFO] The java executable is 
> /home/jondruse/.sdkman/candidates/java/17.0.9-tem/bin/java
> [INFO] Building jar: 
> /tmp/cxf-tmp-14372731791450387841/cxf-codegen4454546328799244847.jar
> [WARNING] Exception in thread "main" 
> org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding 
> file, please check the namespace
>  {code}
> {code:java}
> ...
> ERROR] Failed to execute goal 
> org.apache.cxf:cxf-codegen-plugin:4.0.4:wsdl2java (generate-test-sources) on 
> project camel-itest: 
> [ERROR] Exit code: 1
> [ERROR] Command line was: 
> /home/jondruse/.sdkman/candidates/java/17.0.9-tem/bin/java 
> --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED 
> --add-exports=java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED 
> --add-opens java.base/java.security=ALL-UNNAMED --add-opens 
> java.base/java.net=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED 
> --add-opens java.base/java.util=ALL-UNNAMED --add-opens 
> java.base/java.util.concurrent=ALL-UNNAMED -jar 
> /tmp/cxf-tmp-14372731791450387841/cxf-codegen4454546328799244847.jar 
> /tmp/cxf-tmp-14372731791450387841/cxf-w2j15211708284601236974args
> {code}
> Issue can be simulated by building of Camel from this commit: 
> https://github.com/apache/camel/commit/a1bc751d7d8f5fb2016ed54e0735de5e4e9ec18b



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (CXF-8990) Cxf plugins (codegen, xjc): fails in versions 4.0.4, 4.0.1

[Freeman Yue Fang (Jira)]

 [ 
https://issues.apache.org/jira/browse/CXF-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Freeman Yue Fang resolved CXF-8990.
---
Resolution: Not A Bug

> Cxf plugins (codegen, xjc): fails in versions 4.0.4, 4.0.1 
> ---
>
> Key: CXF-8990
> URL: https://issues.apache.org/jira/browse/CXF-8990
> Project: CXF
>  Issue Type: Bug
>Reporter: Jiri Ondrusek
>    Assignee: Freeman Yue Fang
>Priority: Major
>
> I was building Camel right after the upgrade of plugins (cxf-codegen to 4.0.4 
> and cxf-xjc to 4.0.1) See 
> [https://github.com/apache/camel/commit/a1bc751d7d8f5fb2016ed54e0735de5e4e9ec18b]
>  
> The build failed with:
> {code:java}
> [INFO] < org.apache.camel:camel-itest 
> >
> [INFO] Building Camel :: Integration Tests 4.5.0-SNAPSHOT             
> [557/559]
> [INFO]   from tests/camel-itest/pom.xml
> [INFO] [ jar 
> ]-
> [INFO] 
> [INFO] --- clean:3.3.2:clean (default-clean) @ camel-itest ---
> [INFO] Deleting /home/jondruse/git/community/camel/tests/camel-itest/target
> [INFO] 
> [INFO] --- cxf-codegen:4.0.4:wsdl2java (generate-test-sources) @ camel-itest 
> ---
> [INFO] Running code generation in fork mode...
> [INFO] The java executable is 
> /home/jondruse/.sdkman/candidates/java/17.0.9-tem/bin/java
> [INFO] Building jar: 
> /tmp/cxf-tmp-14372731791450387841/cxf-codegen4454546328799244847.jar
> [WARNING] Exception in thread "main" 
> org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding 
> file, please check the namespace
>  {code}
> {code:java}
> ...
> ERROR] Failed to execute goal 
> org.apache.cxf:cxf-codegen-plugin:4.0.4:wsdl2java (generate-test-sources) on 
> project camel-itest: 
> [ERROR] Exit code: 1
> [ERROR] Command line was: 
> /home/jondruse/.sdkman/candidates/java/17.0.9-tem/bin/java 
> --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED 
> --add-exports=java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED 
> --add-opens java.base/java.security=ALL-UNNAMED --add-opens 
> java.base/java.net=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED 
> --add-opens java.base/java.util=ALL-UNNAMED --add-opens 
> java.base/java.util.concurrent=ALL-UNNAMED -jar 
> /tmp/cxf-tmp-14372731791450387841/cxf-codegen4454546328799244847.jar 
> /tmp/cxf-tmp-14372731791450387841/cxf-w2j15211708284601236974args
> {code}
> Issue can be simulated by building of Camel from this commit: 
> https://github.com/apache/camel/commit/a1bc751d7d8f5fb2016ed54e0735de5e4e9ec18b



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-8990) Cxf plugins (codegen, xjc): fails in versions 4.0.4, 4.0.1

[Freeman Yue Fang (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829916#comment-17829916
 ] 

Freeman Yue Fang commented on CXF-8990:
---

Hi [~jondruse],

Please notice this warning in your build
{code}
[WARNING] Exception in thread "main" org.apache.cxf.tools.common.ToolException: 
Not a valid jaxb or jaxws binding file, please check the namespace
 {code}

This means the namespace in the jaxb or jaxws binding file of your build isn't 
correctly. More specifically, you should use something like (JEE9+ jakarta 
namespace)
{code}
xmlns:jaxws="https://jakarta.ee/xml/ns/jaxws;
xmlns:jxb="https://jakarta.ee/xml/ns/jaxb;
{code}
instead of 
{code}
xmlns:jaxws="https://java.sun.com/xml/ns/jaxws;
xmlns:jxb="https://java.sun.com/xml/ns/jaxb;
{code}

Cheers
Freeman

> Cxf plugins (codegen, xjc): fails in versions 4.0.4, 4.0.1 
> ---
>
> Key: CXF-8990
> URL: https://issues.apache.org/jira/browse/CXF-8990
> Project: CXF
>  Issue Type: Bug
>Reporter: Jiri Ondrusek
>Priority: Major
>
> I was building Camel right after the upgrade of plugins (cxf-codegen to 4.0.4 
> and cxf-xjc to 4.0.1) See 
> [https://github.com/apache/camel/commit/a1bc751d7d8f5fb2016ed54e0735de5e4e9ec18b]
>  
> The build failed with:
> {code:java}
> [INFO] < org.apache.camel:camel-itest 
> >
> [INFO] Building Camel :: Integration Tests 4.5.0-SNAPSHOT             
> [557/559]
> [INFO]   from tests/camel-itest/pom.xml
> [INFO] [ jar 
> ]-
> [INFO] 
> [INFO] --- clean:3.3.2:clean (default-clean) @ camel-itest ---
> [INFO] Deleting /home/jondruse/git/community/camel/tests/camel-itest/target
> [INFO] 
> [INFO] --- cxf-codegen:4.0.4:wsdl2java (generate-test-sources) @ camel-itest 
> ---
> [INFO] Running code generation in fork mode...
> [INFO] The java executable is 
> /home/jondruse/.sdkman/candidates/java/17.0.9-tem/bin/java
> [INFO] Building jar: 
> /tmp/cxf-tmp-14372731791450387841/cxf-codegen4454546328799244847.jar
> [WARNING] Exception in thread "main" 
> org.apache.cxf.tools.common.ToolException: Not a valid jaxb or jaxws binding 
> file, please check the namespace
>  {code}
> {code:java}
> ...
> ERROR] Failed to execute goal 
> org.apache.cxf:cxf-codegen-plugin:4.0.4:wsdl2java (generate-test-sources) on 
> project camel-itest: 
> [ERROR] Exit code: 1
> [ERROR] Command line was: 
> /home/jondruse/.sdkman/candidates/java/17.0.9-tem/bin/java 
> --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED 
> --add-exports=java.xml/com.sun.org.apache.xerces.internal.impl.xs=ALL-UNNAMED 
> --add-opens java.base/java.security=ALL-UNNAMED --add-opens 
> java.base/java.net=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED 
> --add-opens java.base/java.util=ALL-UNNAMED --add-opens 
> java.base/java.util.concurrent=ALL-UNNAMED -jar 
> /tmp/cxf-tmp-14372731791450387841/cxf-codegen4454546328799244847.jar 
> /tmp/cxf-tmp-14372731791450387841/cxf-w2j15211708284601236974args
> {code}
> Issue can be simulated by building of Camel from this commit: 
> https://github.com/apache/camel/commit/a1bc751d7d8f5fb2016ed54e0735de5e4e9ec18b



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] - Release Apache CXF Fediz 1.6.2

[Freeman Fang]

+1, thanks Colm!

Freeman

On Thu, Mar 21, 2024 at 6:15 AM Colm O hEigeartaigh 
wrote:

> This is a vote to release Apache CXF Fediz 1.6.2. It contains
> dependency updates as well as a bug fix for a session timeout in newer
> Tomcat instances https://issues.apache.org/jira/browse/FEDIZ-256
>
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecxf-1202/
> Git tag: https://github.com/apache/cxf-fediz/releases/tag/fediz-1.6.2
>
> +1 from me.
>
> Colm.
>

Bug#1051139: fix doas for sxmo

[Philip J Freeman]

I'm working on a fix for this bug here:

https://salsa.debian.org/DebianOnMobile-team/sxmo-utils/-/merge_requests/2

I'm not sure I like installing Sxmo's doas.conf as /etc/doas.conf.
Looking into alternatives, but it seems that Debian's doas doesn't
support a doas.d/ directory, as pointed out by Jochen Sprickerhof.

This patch (as submitted in the MR on salsa) is currently working for me
on my pinephonepro.

[jira] [Commented] (CXF-8986) Ws-security-policy: if more policies are used in the same JVM, their algorithm suites influence each other

[Freeman Yue Fang (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827563#comment-17827563
 ] 

Freeman Yue Fang commented on CXF-8986:
---

Hi [~jondruse],

This behaviour(expected) actually comes from your test, in your
custom-encrypt-sign-policy.xml
and 
encrypt-sign-policy.xml
two different policies share the same policy ID, the PoliyEngine in CXF won't 
rebuild policy again if found the Policy with same ID existent already.

So if you change your testcase like
{code}
--- 
a/integration-tests/ws-security-policy/src/main/resources/custom-encrypt-sign-policy.xml
+++ 
b/integration-tests/ws-security-policy/src/main/resources/custom-encrypt-sign-policy.xml
@@ -1,5 +1,5 @@
 
-http://www.w3.org/ns/ws-policy;
 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd;
 xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702;>
{code}

You can find it works as expected.

Freeman

> Ws-security-policy: if more policies are used in the same JVM, their 
> algorithm suites influence each other
> --
>
> Key: CXF-8986
> URL: https://issues.apache.org/jira/browse/CXF-8986
> Project: CXF
>  Issue Type: Bug
>  Components: WS-* Components
>Affects Versions: 4.0.4
>Reporter: Jiri Ondrusek
>Priority: Major
>
> I'm fixing some tests in quarkus-cxf and I found a behavior which seems to be 
> not desired. On the other hand I might be missing some information and this 
> behavior is expected.
> Reproducer:
>  # Clone and build 
> [https://github.com/JiriOndrusek/quarkus-cxf/tree/suite-influence-reprodocer]
>  # Run (with remote debug)
> {code:java}
> ./mvnw clean test -f integration-tests/ws-security-policy 
> -Dtest="EncryptSignPolicyTest#helloEncryptSign" -Dmaven.surefire.debug{code}
> Check value of effectivePolicy in this line 
> [https://github.com/apache/cxf/blob/main/rt/ws/policy/src/main/java/org/apache/cxf/ws/policy/PolicyOutInterceptor.java#L98]
> Look into
> {code:java}
> effectivePolicy->policy->policyComponents->exactlyOne->policyComponents->all->policyComponents->asymmetricBinding->alghoritnSuite->alghorithSuiteType{code}
> Value is *Basic256*
>  # Run different test by this command
> {code:java}
> ./mvnw clean test -f integration-tests/ws-security-policy 
> -Dtest="CustomEncryptSignPolicyTest#helloDefaultCustomValues" 
> -Dmaven.surefire.debug{code}
> Debug the same place and you can see, that the alghoritmSuiteType is 
> *CustomAlgorithmSuite*
>  # Now run both tests together by
> {code:java}
> ./mvnw clean test -f integration-tests/ws-security-policy 
> -Dtest="EncryptSignPolicyTest#helloEncryptSign,CustomEncryptSignPolicyTest#helloDefaultCustomValues"
>  -Dmaven.surefire.debug{code}
> The first breakpoint is triggered by
> {code:java}
> CustomEncryptSignPolicyTest#helloDefaultCustomValues{code}
> and you can see hat the alghoritmSuiteType is *CustomAlgorithmSuite*
> The second breakpoint belongs to
> {code:java}
> EncryptSignPolicyTest#helloEncryptSign{code}
> , but the value in the efectivePolicy->..->asymmetricBinding is 
> *CustomAlgorithmSuite*
> This is wrong, the correct value should be *Basic256*
> I changed test `CustomEncryptSignPolicyTest#helloDefaultCustomValues` to use 
> *Basic128Rsa15* (to verify that the culprit is not the customAlgorithmSuite) 
> and the result was wrong as with default values.
> Single execution showed *Basic128Rsa15* or *Basic256* (depends on the test), 
> but execution of both tests showed *Basic128Rsa15* in both cases.
> I think that the behavior is wrong. I have a test suite running on FIPS 
> machine. If tests are executed alone all works correctly (some tests asserts 
> success, some tests asserts failure). If I run tests together, the tests 
> which should fail, are successful.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Release CXF 3.6.3 and 3.5.8

[Freeman Fang]

Hi Team,

We have 7 +1 votes and no other votes,  so this vote passes and I will
release the artifacts soon.

Thanks all for the vote!

Freeman

On Fri, Mar 8, 2024 at 11:42 AM Jeff Genender  wrote:

> +1
>
> Jeff
>
>
> > On Mar 8, 2024, at 3:52 AM, Colm O hEigeartaigh 
> wrote:
> >
> > +1.
> >
> > Colm.
> >
> > On Fri, Mar 8, 2024 at 7:28 AM Jim Ma  wrote:
> >>
> >> +1
> >>
> >> On Fri, Mar 8, 2024 at 4:43 AM Freeman Fang 
> wrote:
> >>
> >>> Hi,
> >>>
> >>> It’s been a while since the last releases and many issues have been
> >>> addressed, so here is the VOTE for CXF 3.6.3 and 3.5.8
> >>>
> >>> Staging areas:
> >>> https://repository.apache.org/content/repositories/orgapachecxf-1198
> >>> https://repository.apache.org/content/repositories/orgapachecxf-1199
> >>>
> >>>
> >>> Tags:
> >>>
> >>>
> https://github.com/apache/cxf/commit/d6c36b4dcabade57d0266313ab3745bedf5fb57c
> >>>
> >>>
> https://github.com/apache/cxf/commit/1593a5e0e48a67f75c60a64add52b0be57bb5eb0
> >>>
> >>>
> >>> Here is my +1.
> >>>
> >>> Best Regards
> >>> Freeman
> >>>
>
>

Re: [VOTE] - Release Apache CXF XJC Utils 4.0.1 and 3.3.3

[Freeman Fang]

+1(binding)

Thanks Colm!
Freeman

On Tue, Mar 12, 2024 at 9:45 AM Colm O hEigeartaigh 
wrote:

> This is a vote to release Apache CXF XJC Utils 4.0.1 and 3.3.3. They
> both contain a fix for https://issues.apache.org/jira/browse/CXFXJC-44
> as well as various dependency updates.
>
> 4.0.1:
>
> Git tag:
> https://github.com/apache/cxf-xjc-utils/releases/tag/xjc-utils-4.0.1
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecxf-1200/
>
> 3.3.3:
>
> Git tag:
> https://github.com/apache/cxf-xjc-utils/releases/tag/xjc-utils-3.3.3
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecxf-1201/
>
> +1 from me.
>
> Colm.
>

Re: [VOTE] Release CXF 4.0.4(2nd attempt)

[Freeman Fang]

Hi Team,

We have 7 +1 votes and no other votes,  so this vote passes and I will
release the artifacts soon.

Thanks all for the vote!

Freeman


On Fri, Mar 8, 2024 at 2:27 AM Jim Ma  wrote:

> +1
>
> On Thu, Mar 7, 2024 at 8:48 AM Freeman Fang 
> wrote:
>
> > It’s been a while since the last release and many issues have been
> > addressed, so here is the VOTE for CXF 4.0.4.
> >
> > Staging area:
> > https://repository.apache.org/content/repositories/orgapachecxf-1197
> >
> >
> > Tag:
> >
> >
> https://github.com/apache/cxf/commit/40ad2263e5c080bf3b55542bf3ee052fa7465733
> >
> >
> > Here is my +1.
> >
> > Best Regards
> > Freeman
> >
>

Re: [go-nuts] govulncheck

[Colton Freeman]

Disregard. Figured out the tool (a little better). Would still love to chat
with some that has in depth experience with it though.

On Fri, Mar 8, 2024, 1:36 PM Colton Freeman 
wrote:

> good day all,
> i am not a developer and have just recently stumbled upon the
> `govulncheck` tool from golang.
> i am curious how accurate this tool is and if it should be used in a scan
> report for vulnerabilities?
> do we need to run this on the main.go and reference the go.mod file in the
> project?
> another question would be about the go.mod. does this tool only scan go
> packages `gopkg.in/yaml.v3 v3.0.1` or is it anything listed in the go.mod
> `github.com/Azure/azure-sdk-for-go/sdk/storage/azblob v1.2.0`
>
> if you need more info or have questions please feel free to ask.
>
> W/r
> Colton.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/K3PZCxo_XvY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/2fca01b6-5bc8-49ee-bb21-eba166063d35n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/2fca01b6-5bc8-49ee-bb21-eba166063d35n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKjFZFiqW6r%3D2CobPdiJVKgOKCG_9o5A0KEGwNvc4KCgDvAKzA%40mail.gmail.com.

[go-nuts] govulncheck

[Colton Freeman]

good day all,
i am not a developer and have just recently stumbled upon the `govulncheck` 
tool from golang. 
i am curious how accurate this tool is and if it should be used in a scan 
report for vulnerabilities?
do we need to run this on the main.go and reference the go.mod file in the 
project?
another question would be about the go.mod. does this tool only scan go 
packages `gopkg.in/yaml.v3 v3.0.1` or is it anything listed in the go.mod 
`github.com/Azure/azure-sdk-for-go/sdk/storage/azblob v1.2.0`

if you need more info or have questions please feel free to ask. 

W/r 
Colton.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2fca01b6-5bc8-49ee-bb21-eba166063d35n%40googlegroups.com.

[VOTE] Release CXF 3.6.3 and 3.5.8

[Freeman Fang]

Hi,

It’s been a while since the last releases and many issues have been
addressed, so here is the VOTE for CXF 3.6.3 and 3.5.8

Staging areas:
https://repository.apache.org/content/repositories/orgapachecxf-1198
https://repository.apache.org/content/repositories/orgapachecxf-1199


Tags:
https://github.com/apache/cxf/commit/d6c36b4dcabade57d0266313ab3745bedf5fb57c
https://github.com/apache/cxf/commit/1593a5e0e48a67f75c60a64add52b0be57bb5eb0


Here is my +1.

Best Regards
Freeman

[jira] [Updated] (CXF-8984) HttpClientHTTPConduit.HttpClientWrappedOutputStream throws NPE in closeInputStream()

[Freeman Yue Fang (Jira)]

 [ 
https://issues.apache.org/jira/browse/CXF-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Freeman Yue Fang updated CXF-8984:
--
Fix Version/s: 3.6.3

> HttpClientHTTPConduit.HttpClientWrappedOutputStream throws NPE in 
> closeInputStream()
> 
>
> Key: CXF-8984
> URL: https://issues.apache.org/jira/browse/CXF-8984
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 4.0.1, 4.0.2, 4.0.3
>Reporter: Thomas Egli
>Priority: Major
> Fix For: 3.6.3, 4.0.4
>
>
> The package private class {{HttpClientWrappedOutputStream in 
> org.apache.cxf.transport.http.HttpClientHTTPConduit}} implements the methods 
> _getInputStream()_ and {_}closeInputStream(){_}.
> There are several paths where _getInputStream()_ returns null. This will then 
> lead to a *NullPointerException* in _closeInputStream()_ because there is no 
> null check.
> {code:java}
>         @Override
>         protected InputStream getInputStream() throws IOException {
>             HttpResponse resp = getResponse();
>             String method = 
> (String)outMessage.get(Message.HTTP_REQUEST_METHOD);
>             int sc = resp.statusCode();
>             if ("HEAD".equals(method)) {
>                 try (InputStream in = resp.body()) {
>                     return null;
>                 }
>             }
>             if (sc == 204) {
>                 //no content
>                 return null;
>             }
>             if ("OPTIONS".equals(method) || (sc >= 300 && sc < 500)) {
>                 Optional f = 
> resp.headers().firstValue("content-length");
>                 Optional fChunk = 
> resp.headers().firstValue("transfer-encoding");
>                 if (f.isPresent()) {
>                     long l = Long.parseLong(f.get());
>                     if (l == 0) {
>                         try (InputStream in = resp.body()) {
>                             return null;
>                         }
>                     }
>                 } else if (!fChunk.isPresent() || 
> !"chunked".equals(fChunk.get())) {
>                     if (resp.version() == Version.HTTP_2) {
>                         InputStream in = resp.body();
>                         if (in.available() <= 0) {
>                             try (in) {
>                                 return null;
>                             }
>                         }
>                     } else {
>                         try (InputStream in = resp.body()) {
>                             return null;
>                         }
>                     }
>                 }
>             }
>             return new HttpClientFilteredInputStream(resp.body());
>         }
>         @Override
>         protected void closeInputStream() throws IOException {
>             getInputStream().close();
>         }
> {code}
> We encountered this issue with SOAP WS POST requests that return status 204.
> A downgrade to 4.0.0 fixed it, as {{HttpClientHTTPConduit}} was introduced 
> with 4.0.1.
>  
> The fix looks (too?) easy:
> {code:java}
>         @Override
>         protected void closeInputStream() throws IOException {
>             InputStream is = getInputStream();
>             if (is != null) {
>                 is.close();
>             }
>         }{code}
>  
> I will gladly create a PR for this, but maybe someone else can double-check 
> if this is really as simple as it looks like :)
> Version 4.0.1 was released in May 2023, and it looks unlikely to me that 
> no-one else stumbled upon this problem until now.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[VOTE] Release CXF 4.0.4(2nd attempt)

[Freeman Fang]

It’s been a while since the last release and many issues have been
addressed, so here is the VOTE for CXF 4.0.4.

Staging area:
https://repository.apache.org/content/repositories/orgapachecxf-1197


Tag:
https://github.com/apache/cxf/commit/40ad2263e5c080bf3b55542bf3ee052fa7465733


Here is my +1.

Best Regards
Freeman

[jira] [Resolved] (CXF-8984) HttpClientHTTPConduit.HttpClientWrappedOutputStream throws NPE in closeInputStream()

[Freeman Yue Fang (Jira)]

 [ 
https://issues.apache.org/jira/browse/CXF-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Freeman Yue Fang resolved CXF-8984.
---
Resolution: Fixed

> HttpClientHTTPConduit.HttpClientWrappedOutputStream throws NPE in 
> closeInputStream()
> 
>
> Key: CXF-8984
> URL: https://issues.apache.org/jira/browse/CXF-8984
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 4.0.1, 4.0.2, 4.0.3
>Reporter: Thomas Egli
>Priority: Major
> Fix For: 4.0.4
>
>
> The package private class {{HttpClientWrappedOutputStream in 
> org.apache.cxf.transport.http.HttpClientHTTPConduit}} implements the methods 
> _getInputStream()_ and {_}closeInputStream(){_}.
> There are several paths where _getInputStream()_ returns null. This will then 
> lead to a *NullPointerException* in _closeInputStream()_ because there is no 
> null check.
> {code:java}
>         @Override
>         protected InputStream getInputStream() throws IOException {
>             HttpResponse resp = getResponse();
>             String method = 
> (String)outMessage.get(Message.HTTP_REQUEST_METHOD);
>             int sc = resp.statusCode();
>             if ("HEAD".equals(method)) {
>                 try (InputStream in = resp.body()) {
>                     return null;
>                 }
>             }
>             if (sc == 204) {
>                 //no content
>                 return null;
>             }
>             if ("OPTIONS".equals(method) || (sc >= 300 && sc < 500)) {
>                 Optional f = 
> resp.headers().firstValue("content-length");
>                 Optional fChunk = 
> resp.headers().firstValue("transfer-encoding");
>                 if (f.isPresent()) {
>                     long l = Long.parseLong(f.get());
>                     if (l == 0) {
>                         try (InputStream in = resp.body()) {
>                             return null;
>                         }
>                     }
>                 } else if (!fChunk.isPresent() || 
> !"chunked".equals(fChunk.get())) {
>                     if (resp.version() == Version.HTTP_2) {
>                         InputStream in = resp.body();
>                         if (in.available() <= 0) {
>                             try (in) {
>                                 return null;
>                             }
>                         }
>                     } else {
>                         try (InputStream in = resp.body()) {
>                             return null;
>                         }
>                     }
>                 }
>             }
>             return new HttpClientFilteredInputStream(resp.body());
>         }
>         @Override
>         protected void closeInputStream() throws IOException {
>             getInputStream().close();
>         }
> {code}
> We encountered this issue with SOAP WS POST requests that return status 204.
> A downgrade to 4.0.0 fixed it, as {{HttpClientHTTPConduit}} was introduced 
> with 4.0.1.
>  
> The fix looks (too?) easy:
> {code:java}
>         @Override
>         protected void closeInputStream() throws IOException {
>             InputStream is = getInputStream();
>             if (is != null) {
>                 is.close();
>             }
>         }{code}
>  
> I will gladly create a PR for this, but maybe someone else can double-check 
> if this is really as simple as it looks like :)
> Version 4.0.1 was released in May 2023, and it looks unlikely to me that 
> no-one else stumbled upon this problem until now.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-8984) HttpClientHTTPConduit.HttpClientWrappedOutputStream throws NPE in closeInputStream()

[Freeman Yue Fang (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824130#comment-17824130
 ] 

Freeman Yue Fang commented on CXF-8984:
---

Patch applied on behalf of [~thegli] with thanks!

> HttpClientHTTPConduit.HttpClientWrappedOutputStream throws NPE in 
> closeInputStream()
> 
>
> Key: CXF-8984
> URL: https://issues.apache.org/jira/browse/CXF-8984
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 4.0.1, 4.0.2, 4.0.3
>Reporter: Thomas Egli
>Priority: Major
> Fix For: 4.0.4
>
>
> The package private class {{HttpClientWrappedOutputStream in 
> org.apache.cxf.transport.http.HttpClientHTTPConduit}} implements the methods 
> _getInputStream()_ and {_}closeInputStream(){_}.
> There are several paths where _getInputStream()_ returns null. This will then 
> lead to a *NullPointerException* in _closeInputStream()_ because there is no 
> null check.
> {code:java}
>         @Override
>         protected InputStream getInputStream() throws IOException {
>             HttpResponse resp = getResponse();
>             String method = 
> (String)outMessage.get(Message.HTTP_REQUEST_METHOD);
>             int sc = resp.statusCode();
>             if ("HEAD".equals(method)) {
>                 try (InputStream in = resp.body()) {
>                     return null;
>                 }
>             }
>             if (sc == 204) {
>                 //no content
>                 return null;
>             }
>             if ("OPTIONS".equals(method) || (sc >= 300 && sc < 500)) {
>                 Optional f = 
> resp.headers().firstValue("content-length");
>                 Optional fChunk = 
> resp.headers().firstValue("transfer-encoding");
>                 if (f.isPresent()) {
>                     long l = Long.parseLong(f.get());
>                     if (l == 0) {
>                         try (InputStream in = resp.body()) {
>                             return null;
>                         }
>                     }
>                 } else if (!fChunk.isPresent() || 
> !"chunked".equals(fChunk.get())) {
>                     if (resp.version() == Version.HTTP_2) {
>                         InputStream in = resp.body();
>                         if (in.available() <= 0) {
>                             try (in) {
>                                 return null;
>                             }
>                         }
>                     } else {
>                         try (InputStream in = resp.body()) {
>                             return null;
>                         }
>                     }
>                 }
>             }
>             return new HttpClientFilteredInputStream(resp.body());
>         }
>         @Override
>         protected void closeInputStream() throws IOException {
>             getInputStream().close();
>         }
> {code}
> We encountered this issue with SOAP WS POST requests that return status 204.
> A downgrade to 4.0.0 fixed it, as {{HttpClientHTTPConduit}} was introduced 
> with 4.0.1.
>  
> The fix looks (too?) easy:
> {code:java}
>         @Override
>         protected void closeInputStream() throws IOException {
>             InputStream is = getInputStream();
>             if (is != null) {
>                 is.close();
>             }
>         }{code}
>  
> I will gladly create a PR for this, but maybe someone else can double-check 
> if this is really as simple as it looks like :)
> Version 4.0.1 was released in May 2023, and it looks unlikely to me that 
> no-one else stumbled upon this problem until now.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-8984) HttpClientHTTPConduit.HttpClientWrappedOutputStream throws NPE in closeInputStream()

[Freeman Yue Fang (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824106#comment-17824106
 ] 

Freeman Yue Fang commented on CXF-8984:
---

Hi [~thegli], 

Thanks for reporting this issue.

Yes, please send PR and put a NPE here. FYI, I'm doing final cleanup and will 
cut CXF 4.0.4 release today, so I'd like this fix in for CXF 4.0.4, thanks!

Freeman

> HttpClientHTTPConduit.HttpClientWrappedOutputStream throws NPE in 
> closeInputStream()
> 
>
> Key: CXF-8984
> URL: https://issues.apache.org/jira/browse/CXF-8984
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 4.0.1, 4.0.2, 4.0.3
>Reporter: Thomas Egli
>Priority: Major
> Fix For: 4.0.4
>
>
> The package private class {{HttpClientWrappedOutputStream in 
> org.apache.cxf.transport.http.HttpClientHTTPConduit}} implements the methods 
> _getInputStream()_ and {_}closeInputStream(){_}.
> There are several paths where _getInputStream()_ returns null. This will then 
> lead to a *NullPointerException* in _closeInputStream()_ because there is no 
> null check.
> {code:java}
>         @Override
>         protected InputStream getInputStream() throws IOException {
>             HttpResponse resp = getResponse();
>             String method = 
> (String)outMessage.get(Message.HTTP_REQUEST_METHOD);
>             int sc = resp.statusCode();
>             if ("HEAD".equals(method)) {
>                 try (InputStream in = resp.body()) {
>                     return null;
>                 }
>             }
>             if (sc == 204) {
>                 //no content
>                 return null;
>             }
>             if ("OPTIONS".equals(method) || (sc >= 300 && sc < 500)) {
>                 Optional f = 
> resp.headers().firstValue("content-length");
>                 Optional fChunk = 
> resp.headers().firstValue("transfer-encoding");
>                 if (f.isPresent()) {
>                     long l = Long.parseLong(f.get());
>                     if (l == 0) {
>                         try (InputStream in = resp.body()) {
>                             return null;
>                         }
>                     }
>                 } else if (!fChunk.isPresent() || 
> !"chunked".equals(fChunk.get())) {
>                     if (resp.version() == Version.HTTP_2) {
>                         InputStream in = resp.body();
>                         if (in.available() <= 0) {
>                             try (in) {
>                                 return null;
>                             }
>                         }
>                     } else {
>                         try (InputStream in = resp.body()) {
>                             return null;
>                         }
>                     }
>                 }
>             }
>             return new HttpClientFilteredInputStream(resp.body());
>         }
>         @Override
>         protected void closeInputStream() throws IOException {
>             getInputStream().close();
>         }
> {code}
> We encountered this issue with SOAP WS POST requests that return status 204.
> A downgrade to 4.0.0 fixed it, as {{HttpClientHTTPConduit}} was introduced 
> with 4.0.1.
>  
> The fix looks (too?) easy:
> {code:java}
>         @Override
>         protected void closeInputStream() throws IOException {
>             InputStream is = getInputStream();
>             if (is != null) {
>                 is.close();
>             }
>         }{code}
>  
> I will gladly create a PR for this, but maybe someone else can double-check 
> if this is really as simple as it looks like :)
> Version 4.0.1 was released in May 2023, and it looks unlikely to me that 
> no-one else stumbled upon this problem until now.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (CXF-8984) HttpClientHTTPConduit.HttpClientWrappedOutputStream throws NPE in closeInputStream()

[Freeman Yue Fang (Jira)]

 [ 
https://issues.apache.org/jira/browse/CXF-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Freeman Yue Fang updated CXF-8984:
--
Fix Version/s: 4.0.4

> HttpClientHTTPConduit.HttpClientWrappedOutputStream throws NPE in 
> closeInputStream()
> 
>
> Key: CXF-8984
> URL: https://issues.apache.org/jira/browse/CXF-8984
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 4.0.1, 4.0.2, 4.0.3
>Reporter: Thomas Egli
>Priority: Major
> Fix For: 4.0.4
>
>
> The package private class {{HttpClientWrappedOutputStream in 
> org.apache.cxf.transport.http.HttpClientHTTPConduit}} implements the methods 
> _getInputStream()_ and {_}closeInputStream(){_}.
> There are several paths where _getInputStream()_ returns null. This will then 
> lead to a *NullPointerException* in _closeInputStream()_ because there is no 
> null check.
> {code:java}
>         @Override
>         protected InputStream getInputStream() throws IOException {
>             HttpResponse resp = getResponse();
>             String method = 
> (String)outMessage.get(Message.HTTP_REQUEST_METHOD);
>             int sc = resp.statusCode();
>             if ("HEAD".equals(method)) {
>                 try (InputStream in = resp.body()) {
>                     return null;
>                 }
>             }
>             if (sc == 204) {
>                 //no content
>                 return null;
>             }
>             if ("OPTIONS".equals(method) || (sc >= 300 && sc < 500)) {
>                 Optional f = 
> resp.headers().firstValue("content-length");
>                 Optional fChunk = 
> resp.headers().firstValue("transfer-encoding");
>                 if (f.isPresent()) {
>                     long l = Long.parseLong(f.get());
>                     if (l == 0) {
>                         try (InputStream in = resp.body()) {
>                             return null;
>                         }
>                     }
>                 } else if (!fChunk.isPresent() || 
> !"chunked".equals(fChunk.get())) {
>                     if (resp.version() == Version.HTTP_2) {
>                         InputStream in = resp.body();
>                         if (in.available() <= 0) {
>                             try (in) {
>                                 return null;
>                             }
>                         }
>                     } else {
>                         try (InputStream in = resp.body()) {
>                             return null;
>                         }
>                     }
>                 }
>             }
>             return new HttpClientFilteredInputStream(resp.body());
>         }
>         @Override
>         protected void closeInputStream() throws IOException {
>             getInputStream().close();
>         }
> {code}
> We encountered this issue with SOAP WS POST requests that return status 204.
> A downgrade to 4.0.0 fixed it, as {{HttpClientHTTPConduit}} was introduced 
> with 4.0.1.
>  
> The fix looks (too?) easy:
> {code:java}
>         @Override
>         protected void closeInputStream() throws IOException {
>             InputStream is = getInputStream();
>             if (is != null) {
>                 is.close();
>             }
>         }{code}
>  
> I will gladly create a PR for this, but maybe someone else can double-check 
> if this is really as simple as it looks like :)
> Version 4.0.1 was released in May 2023, and it looks unlikely to me that 
> no-one else stumbled upon this problem until now.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (CXF-8983) cxf-services-sts-core should depend on cxf-rt-rs-security-jose instead of cxf-rt-rs-security-jose-jaxrs

[Freeman Yue Fang (Jira)]

 [ 
https://issues.apache.org/jira/browse/CXF-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Freeman Yue Fang updated CXF-8983:
--
Fix Version/s: 4.0.4
   (was: 4.0.5)

> cxf-services-sts-core should depend on cxf-rt-rs-security-jose instead of 
> cxf-rt-rs-security-jose-jaxrs
> ---
>
> Key: CXF-8983
> URL: https://issues.apache.org/jira/browse/CXF-8983
> Project: CXF
>  Issue Type: Bug
>  Components: STS
>Affects Versions: 4.0.4
>Reporter: Peter Palaga
>Priority: Major
> Fix For: 4.0.4
>
>
> cxf-services-sts-core does not need to depend on 
> cxf-rt-rs-security-jose-jaxrs; cxf-rt-rs-security-jose would be enough.
> My understanding is that STS has nothing to do with JAX-RS, so there is no 
> need to pull any JAX-RS related code via cxf-rt-rs-security-jose-jaxrs. 
> cxf-services-sts-systests seem to pass when cxf-rt-rs-security-jose-jaxrs is 
> replaced by cxf-rt-rs-security-jose in cxf-services-sts-core.
> Let me send a PR.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[CANCEL][VOTE] Release CXF 4.0.4

[Freeman Fang]

Sorry team, I have to cancel this VOTE and recut a new release candidate
now.

I will send the new vote very soon!
Freeman

On Tue, Mar 5, 2024 at 4:57 PM Freeman Fang  wrote:

> It’s been a while since the last release and many issues have been
> addressed, so here is the VOTE for CXF 4.0.4.
>
> Staging area:
> https://repository.apache.org/content/repositories/orgapachecxf-1196
>
>
> Tag:
>
> https://github.com/apache/cxf/commit/f88b9bf2bc5121a8b8ed0629ff7685c2b1b447a1
>
>
> Here is my +1.
>
> Best Regards
> Freeman
>

[HEADS UP] Release Apache CXF 3.5.8 and 3.6.3

[Freeman Fang]

Hi Team,

It has been a while since the last CXF 3.5.x and CXF 3.6.x releases, so I
think we can do another release soon with a few issues addressed . If
anyone is still working on something for 3.5.8 and 3.6.3 please let me
know, otherwise I'm gonna kick off the release build for both 3.5.8 and
3.6.3 tomorrow.

Thanks
Freeman

Re: [VOTE] Release CXF 4.0.4

[Freeman Fang]

Hi Jochen,

Yes, I can cut releases for 3.5 and 3.6 and send out separate VOTE emails.

Cheers
Freeman

On Tue, Mar 5, 2024 at 5:34 PM Wilhelm, Jochen
 wrote:

> Hi
> Can we also have new releases for 3.5 and 3.6?
> Thanks and best regards
> Jochen Wilhelm
>
>

[VOTE] Release CXF 4.0.4

[Freeman Fang]

It’s been a while since the last release and many issues have been
addressed, so here is the VOTE for CXF 4.0.4.

Staging area:
https://repository.apache.org/content/repositories/orgapachecxf-1196


Tag:
https://github.com/apache/cxf/commit/f88b9bf2bc5121a8b8ed0629ff7685c2b1b447a1


Here is my +1.

Best Regards
Freeman

[jira] [Resolved] (CXF-8981) WSS4J Encyption using the Key Agreement Method with the apache-CXF

[Freeman Yue Fang (Jira)]

 [ 
https://issues.apache.org/jira/browse/CXF-8981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Freeman Yue Fang resolved CXF-8981.
---
Resolution: Fixed

> WSS4J  Encyption using the Key Agreement Method with the apache-CXF
> ---
>
> Key: CXF-8981
> URL: https://issues.apache.org/jira/browse/CXF-8981
> Project: CXF
>  Issue Type: Test
>  Components: WS-* Components
>Affects Versions: 4.0.3
>Reporter: Joze Rihtarsic
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 4.0.4
>
>
> Recently, the Santuario/XMLSEC and WSS4J libraries added the support for the 
> Key Agreement method. See the following tickets: SANTUARIO-511 and WSS-706. 
> The purpose of this task is to implement tests within the cxf library to 
> verify that the Key Agreement method for encryption with EC and XEC keys is 
> working as expected with the CXF framework.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body

[Freeman Yue Fang (Jira)]

[ 
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823393#comment-17823393
 ] 

Freeman Yue Fang commented on CXF-8962:
---

Sure [~reta], done!

Cheers
Freeman

> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty 
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.6.2, 4.0.3
>Reporter: Alonso Gonzalez
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.6.3, 4.0.4
>
>
> We call a DELETE endoint of a REST API, but the server rejects the call with 
> a client error, because CXF sends "Content-Type: text/xml" although the 
> content is empty (as suggested by RFC 9110).
>  
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}} 
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods 
> computes a "Content-Type" header if the verb is not in the list 
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although 
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a 
> client follows the RFC and sends a DELETE request with no content, CXF will 
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses 
> "text/xml" as fallback if no content type can be computed. 
> The old implementation {{URLConnectionHTTPConduit}} called a 
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method 
> allowed to omit the "Content-Type" header via the property 
> "set.content.type.for.empty.request".
>  
> The new implementation should handle DELETE requests with empty body 
> correctly or evaluate the existing property 
> "set.content.type.for.empty.request".
>  
> [1]
> {quote}Although request message framing is independent of the method used, 
> content received in a DELETE request has no generally defined semantics, 
> cannot alter the meaning or target of the request, and might lead some 
> implementations to reject the request and close the connection because of its 
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A 
> client SHOULD NOT generate content in a DELETE request unless it is made 
> directly to an origin server that has previously indicated, in or out of 
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body

[Freeman Yue Fang (Jira)]

 [ 
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Freeman Yue Fang resolved CXF-8962.
---
Resolution: Fixed

> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty 
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.6.2, 4.0.3
>Reporter: Alonso Gonzalez
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.6.3, 4.0.4
>
>
> We call a DELETE endoint of a REST API, but the server rejects the call with 
> a client error, because CXF sends "Content-Type: text/xml" although the 
> content is empty (as suggested by RFC 9110).
>  
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}} 
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods 
> computes a "Content-Type" header if the verb is not in the list 
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although 
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a 
> client follows the RFC and sends a DELETE request with no content, CXF will 
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses 
> "text/xml" as fallback if no content type can be computed. 
> The old implementation {{URLConnectionHTTPConduit}} called a 
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method 
> allowed to omit the "Content-Type" header via the property 
> "set.content.type.for.empty.request".
>  
> The new implementation should handle DELETE requests with empty body 
> correctly or evaluate the existing property 
> "set.content.type.for.empty.request".
>  
> [1]
> {quote}Although request message framing is independent of the method used, 
> content received in a DELETE request has no generally defined semantics, 
> cannot alter the meaning or target of the request, and might lead some 
> implementations to reject the request and close the connection because of its 
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A 
> client SHOULD NOT generate content in a DELETE request unless it is made 
> directly to an origin server that has previously indicated, in or out of 
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (CXF-8933) Add doPrivileged block to ProxyFactoryProxySelector.select() in HttpClientHTTPConduit

[Freeman Yue Fang (Jira)]

 [ 
https://issues.apache.org/jira/browse/CXF-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Freeman Yue Fang resolved CXF-8933.
---
Resolution: Fixed

> Add doPrivileged block to ProxyFactoryProxySelector.select() in  
> HttpClientHTTPConduit
> --
>
> Key: CXF-8933
> URL: https://issues.apache.org/jira/browse/CXF-8933
> Project: CXF
>  Issue Type: Improvement
>  Components: Transports
>Affects Versions: 4.0.3
>Reporter: Jim Ma
>Assignee: Jim Ma
>Priority: Major
> Fix For: 4.0.4
>
>
> Then the security manager is enabled, there is AccessControlException thrown 
> from HttpClientHTTPConduit. 
> {code:java}
>  Caused by: java.security.AccessControlException: Permission check failed 
> (permission "("java.net.NetPermission" "getProxySelector")" 
>    at java.base/java.net.ProxySelector.getDefault(ProxySelector.java:96)
>    at 
> org.apache.cxf.impl//org.apache.cxf.transport.http.HttpClientHTTPConduit$ProxyFactoryProxySelector.select(HttpClientHTTPConduit.java:330)
>    at 
> java.net.http/jdk.internal.net.http.HttpRequestImpl.retrieveProxy(HttpRequestImpl.java:287)
>    at 
> java.net.http/jdk.internal.net.http.HttpRequestImpl.(HttpRequestImpl.java:133)
>    at 
> java.net.http/jdk.internal.net.http.HttpClientImpl.sendAsync(HttpClientImpl.java:603)
>    at 
> java.net.http/jdk.internal.net.http.HttpClientImpl.sendAsync(HttpClientImpl.java:586)
>    at 
> java.net.http/jdk.internal.net.http.HttpClientImpl.sendAsync(HttpClientImpl.java:578)
>    at 
> java.net.http/jdk.internal.net.http.HttpClientFacade.sendAsync(HttpClientFacade.java:129)
>    at 
> org.apache.cxf.impl//org.apache.cxf.transport.http.HttpClientHTTPConduit$HttpClientWrappedOutputStream.setProtocolHeaders(HttpClientHTTPConduit.java:534)
>    at 
> org.apache.cxf.impl//org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHeadersTrustCaching(HTTPConduit.java:1373)
>    at 
> org.apache.cxf.impl//org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1409)
>  {code}
> We need another doPrivileged block to fix this.
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Plans for release 4.0.4?

[Freeman Fang]

Hi Team,

If there are no other objections, I will try to do the release the coming
Tuesday.

I will follow the document here
https://cxf.apache.org/release-management.html
And I will ask around for help if needed.

Best Regards
Freeman




On Wed, Feb 28, 2024 at 12:33 PM Andriy Redko  wrote:

> +1, thanks Freeman! Folks, I will be off till next Friday (March, 8th),
> but I should have access to email, most of the day. Sorry about that.
>
> Best Regards,
> Andriy Redko
>
> Wednesday, February 28, 2024, 12:03:35 PM, you wrote:
>
> > Thanks for releasing Santuario and WSS4J Colm!
>
> > I think we shall release CXF 4.0.4 now.
>
> > @Daniel Kulp  Could you please help release CXF 4.0.4?
>
> > Thanks so much!
> > Freeman
>
> > On Mon, Feb 19, 2024 at 5:42 AM Colm O hEigeartaigh  >
> > wrote:
>
> >> I've called a vote on Santuario today, so I'll try to release and get
> >> a WSS4J vote started by end of week.
>
> >> Colm.
> >> On Tue, Feb 13, 2024 at 11:09 PM Andriy Redko  wrote:
> >>> Hi Colm,
> >>> I think it would be good to have a release soon-ish, but by and large,
> I
> >> don't think
> >>> we have hard deadline for it, please feel free to proceed as per your
> >> judgement.
> >>> Thank you.
> >>> Best Regards,
> >>>     Andriy Redko
> >>>> Sorry it turns out I'll need to get Santuario 3.0.4 out first. Do I
> >>>> have time to do this and WSS4J before the next CXF release?
> >>>> Colm.
> >>>> On Tue, Feb 13, 2024 at 3:28 PM Freeman Fang 
> >> wrote:
> >>>>> Thanks Colm!
> >>>>> On Tue, Feb 13, 2024 at 10:18 AM Colm O hEigeartaigh <
> cohei...@apache.org>>> wrote:
> >>>>>> Yes, I'll call a vote today on WSS4J 3.0.3.
> >>>>>> Colm.
> >>>>>> On Tue, Feb 13, 2024 at 2:28 PM Freeman Fang <
> freeman.f...@gmail.com>
> >> wrote:
> >>>>>>> +1 to release Apache CXF 4.0.4
> >>>>>>> @Colm O hEigeartaigh Any chance we could have a WSS4J 3.0.3 release
> >> soon?
> >>>>>>> Thanks!
> >>>>>>> Freeman
> >>>>>>> On Tue, Feb 13, 2024 at 7:15 AM Jiri Ondrusek  >
> >> wrote:
> >>>>>>>> Hi,
> >>>>>>>> just for your information, the PR (
> >> https://github.com/apache/cxf/pull/1660)
> >>>>>>>> requires version of wss4f to be 3.0.3 (to contain
> >>>>>>>> https://issues.apache.org/jira/browse/WSS-709)
> >>>>>>>> Best regards,
> >>>>>>>> Jiri
> >>>>>>>> On Tue, Feb 13, 2024 at 10:53 AM Peter Palaga  >
> >> wrote:
> >>>>>>>>> Thanks, great to hear that, Andriy.
> >>>>>>>>> It would be great if we could get
> >>>>>>>>> https://github.com/apache/cxf/pull/1660 merged in some form
> >> before the
> >>>>>>>>> release.
> >>>>>>>>> The main motivation is to be able to run CXF on FIPS-enabled
> >> systems. If
> >>>>>>>>> the customized algo suite, that the PR proposes, is questionable,
> >> I'd be
> >>>>>>>>> also fine with introducing a couple of new suites with fixed
> >>>>>>>>> non-standard names, like already done in the past for fixing
> >> CVEs. It
> >>>>>>>>> would be nice to hear other community members' thoughts.
> >>>>>>>>> Thanks again,
> >>>>>>>>> -- Peter
> >>>>>>>>> On 13/02/2024 02:35, Andriy Redko wrote:
> >>>>>>>>>> Hi Peter,
> >>>>>>>>>> Thanks a lot for reminding, I belive we are long overdue on
> >> that, @Dan,
> >>>>>>>>> @Colm
> >>>>>>>>>> may need your help please preparing the next release train (or
> >> any
> >>>>>>>>> objection folks)?
> >>>>>>>>>> Thank you!
> >>>>>>>>>> Best Regards,
> >>>>>>>>>>  Andriy Redko
> >>>>>>>>>>> Hi,
> >>>>>>>>>>> we are preparing Quarkus CXF to release it for Quarkus 3.8
> >> which is
> >>>>>>>>> going to be a LTS (Long Term Support) release.
> >>>>>>>>>>> I wonder whether we could count on getting CXF 4.0.4 by
> >> February 21st
> >>>>>>>>> to be able to use it in that release?
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>> -- Peter
>
> >>>>>>>> --
> >>>>>>>> Jiri Ondrusek 
> >>>>>>>> Senior Software Engineer
> >>>>>>>> Red Hat Fuse
>
>

Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo

[Rich Freeman]

On Wed, Feb 28, 2024 at 1:50 PM Arthur Zamarin  wrote:
>
> I know that GitHub Copilot can be limited to licenses, and even to just
> the current repository. Even though, I'm not sure that the copyright can
> be attributed to "me" and not the "AI" - so still gray area.

So, AI copyright is a bit of a poorly defined area simply due to a
lack of case law.  I'm not all that confident that courts won't make
an even bigger mess of it.

There are half a dozen different directions I think a court might rule
on the matter of authorship and derived works, but I think it is VERY
unlikely that a court will rule that the copyright will be attributed
to the AI itself, or that the AI itself ever was an author or held any
legal rights to the work at any point in time.  An AI is not a legal
entity. The company that provides the service, its
employees/developers, the end user, and the authors and copyright
holders of works used to train the AI are all entities a court is
likely to consider as having some kind of a role.

That said, we live in a world where it isn't even clear if APIs can be
copyrighted, though in practice enforcing such a copyright might be
impossible.  It could be a while before AI copyright concerns are
firmly settled.  When they are, I suspect it will be done in a way
that frustrates just about everybody on every side...

IMO the main risk to an organization (especially a transparent one
like ours) from AI code isn't even whether it is copyrightable or not,
but rather getting pulled into arguments and debates and possibly
litigation over what is likely to be boilerplate code that needs a lot
of cleanup anyway.  Even if you "win" in court or the court of public
opinion, the victory can be pyrrhic.

--
Rich

Re: Plans for release 4.0.4?

[Freeman Fang]

Thanks for releasing Santuario and WSS4J Colm!

I think we shall release CXF 4.0.4 now.

@Daniel Kulp  Could you please help release CXF 4.0.4?

Thanks so much!
Freeman

On Mon, Feb 19, 2024 at 5:42 AM Colm O hEigeartaigh 
wrote:

> I've called a vote on Santuario today, so I'll try to release and get
> a WSS4J vote started by end of week.
>
> Colm.
>
> On Tue, Feb 13, 2024 at 11:09 PM Andriy Redko  wrote:
> >
> > Hi Colm,
> >
> > I think it would be good to have a release soon-ish, but by and large, I
> don't think
> > we have hard deadline for it, please feel free to proceed as per your
> judgement.
> > Thank you.
> >
> > Best Regards,
> > Andriy Redko
> >
> > > Sorry it turns out I'll need to get Santuario 3.0.4 out first. Do I
> > > have time to do this and WSS4J before the next CXF release?
> >
> > > Colm.
> >
> > > On Tue, Feb 13, 2024 at 3:28 PM Freeman Fang 
> wrote:
> > >> Thanks Colm!
> > >> On Tue, Feb 13, 2024 at 10:18 AM Colm O hEigeartaigh <
> cohei...@apache.org> wrote:
> > >>> Yes, I'll call a vote today on WSS4J 3.0.3.
> > >>> Colm.
> > >>> On Tue, Feb 13, 2024 at 2:28 PM Freeman Fang 
> wrote:
> > >>>> +1 to release Apache CXF 4.0.4
> > >>>> @Colm O hEigeartaigh Any chance we could have a WSS4J 3.0.3 release
> soon?
> > >>>> Thanks!
> > >>>> Freeman
> > >>>> On Tue, Feb 13, 2024 at 7:15 AM Jiri Ondrusek 
> wrote:
> > >>>>> Hi,
> > >>>>> just for your information, the PR (
> https://github.com/apache/cxf/pull/1660)
> > >>>>> requires version of wss4f to be 3.0.3 (to contain
> > >>>>> https://issues.apache.org/jira/browse/WSS-709)
> > >>>>> Best regards,
> > >>>>> Jiri
> > >>>>> On Tue, Feb 13, 2024 at 10:53 AM Peter Palaga 
> wrote:
> > >>>>>> Thanks, great to hear that, Andriy.
> >
> > >>>>>> It would be great if we could get
> > >>>>>> https://github.com/apache/cxf/pull/1660 merged in some form
> before the
> > >>>>>> release.
> > >>>>>> The main motivation is to be able to run CXF on FIPS-enabled
> systems. If
> > >>>>>> the customized algo suite, that the PR proposes, is questionable,
> I'd be
> > >>>>>> also fine with introducing a couple of new suites with fixed
> > >>>>>> non-standard names, like already done in the past for fixing
> CVEs. It
> > >>>>>> would be nice to hear other community members' thoughts.
> > >>>>>> Thanks again,
> > >>>>>> -- Peter
> > >>>>>> On 13/02/2024 02:35, Andriy Redko wrote:
> > >>>>>>> Hi Peter,
> > >>>>>>> Thanks a lot for reminding, I belive we are long overdue on
> that, @Dan,
> > >>>>>> @Colm
> > >>>>>>> may need your help please preparing the next release train (or
> any
> > >>>>>> objection folks)?
> > >>>>>>> Thank you!
> > >>>>>>> Best Regards,
> > >>>>>>>  Andriy Redko
> > >>>>>>>> Hi,
> > >>>>>>>> we are preparing Quarkus CXF to release it for Quarkus 3.8
> which is
> > >>>>>> going to be a LTS (Long Term Support) release.
> > >>>>>>>> I wonder whether we could count on getting CXF 4.0.4 by
> February 21st
> > >>>>>> to be able to use it in that release?
> > >>>>>>>> Thanks,
> > >>>>>>>> -- Peter
> > >>>>> --
> > >>>>> Jiri Ondrusek 
> > >>>>> Senior Software Engineer
> > >>>>> Red Hat Fuse
> >
>

Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo

[Rich Freeman]

On Tue, Feb 27, 2024 at 9:45 AM Michał Górny  wrote:
>
> Given the recent spread of the "AI" bubble, I think we really need to
> look into formally addressing the related concerns.

> 1. Copyright concerns.

I do think it makes sense to consider some of this.

However, I feel like the proposal is redundant with the existing
requirement to signoff on the DCO, which says:

>>> By making a contribution to this project, I certify that:

>>> 1. The contribution was created in whole or in part by me, and
>>> I have the right to submit it under the free software license
>>> indicated in the file; or

>>> 2. The contribution is based upon previous work that, to the best of
>>> my knowledge, is covered under an appropriate free software license,
>>> and I have the right under that license to submit that work with
>>> modifications, whether created in whole or in part by me, under the
>>> same free software license (unless I am permitted to submit under a
>>> different license), as indicated in the file; or

>>> 3. The contribution is a license text (or a file of similar nature),
>>> and verbatim distribution is allowed; or

>>> 4. The contribution was provided directly to me by some other person
>>> who certified 1., 2., 3., or 4., and I have not modified it.

Perhaps we ought to just re-advertise the policy that already exists?

> 2. Quality concerns.

As far as quality is concerned, I again share the concerns you raise,
and I think we should just re-emphasize what many other industries are
already making clear - that individuals are responsible for the
quality of their contributions.  Copy/pasting it blindly from an AI is
no different from copy/pasting it from some other random website, even
if it is otherwise legal.

> 3. Ethical concerns.

I think it is best to just avoid taking a stand on this.  Our ethics
are already documented in the Social Contract.

I think everybody agrees that what is right and wrong is obvious and
clear and universal.  Then we're all shocked to find that large
numbers of people have a universal perspective different from our own.
Even if 90% of contributors agree with a particular position, if we
start lopping off parts of our community 10% at a time we'll probably
find ourselves alone in a room sooner or later.  We can't make every
hill the one to die on.

> I think adding "made by real people" to the list of our advantages
> would be a good thing

Somehow I doubt this is going to help us steal market share from the
numerous other popular source-based Linux distros.  :)

To be clear, I don't think it is a bad idea to just reiterate that we
aren't looking for help from people who want to create scripts that
pipe things into some GPT API and pipe the output into a forum, bug,
issue, PR, or commit.  I've seen other FOSS projects struggling with
people trying to be "helpful" in this way.  I just don't think any of
this actually requires new policy.  If we find our policy to be
inadequate I think it is better to go back to the core principles and
better articulate what we're trying to achieve, rather than adjust it
to fit the latest fashions.

-- 
Rich

Re: [VOTE] - Release Apache WSS4J 3.0.3

[Freeman Fang]

+1 (non-binding)

Thanks Colm!
Freeman

On Thu, Feb 22, 2024 at 9:25 AM Colm O hEigeartaigh 
wrote:

> This is a vote to release Apache WSS4J 3.0.3. It contains an update to
> use XML Security for Java 3.0.4 and functionality to support key
> agreement using ECDH-ES.
>
> Release notes:
> https://issues.apache.org/jira/projects/WSS/versions/12353796
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachews-1101/
> Git tag: https://github.com/apache/ws-wss4j/releases/tag/wss4j-3.0.3
>
> +1 from me.
>
> Colm.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
> For additional commands, e-mail: dev-h...@ws.apache.org
>
>

Re: Plans for release 4.0.4?

[Freeman Fang]

Thanks so much, Colm!
Freeman

On Mon, Feb 19, 2024 at 5:42 AM Colm O hEigeartaigh 
wrote:

> I've called a vote on Santuario today, so I'll try to release and get
> a WSS4J vote started by end of week.
>
> Colm.
>
> On Tue, Feb 13, 2024 at 11:09 PM Andriy Redko  wrote:
> >
> > Hi Colm,
> >
> > I think it would be good to have a release soon-ish, but by and large, I
> don't think
> > we have hard deadline for it, please feel free to proceed as per your
> judgement.
> > Thank you.
> >
> > Best Regards,
> > Andriy Redko
> >
> > > Sorry it turns out I'll need to get Santuario 3.0.4 out first. Do I
> > > have time to do this and WSS4J before the next CXF release?
> >
> > > Colm.
> >
> > > On Tue, Feb 13, 2024 at 3:28 PM Freeman Fang 
> wrote:
> > >> Thanks Colm!
> > >> On Tue, Feb 13, 2024 at 10:18 AM Colm O hEigeartaigh <
> cohei...@apache.org> wrote:
> > >>> Yes, I'll call a vote today on WSS4J 3.0.3.
> > >>> Colm.
> > >>> On Tue, Feb 13, 2024 at 2:28 PM Freeman Fang 
> wrote:
> > >>>> +1 to release Apache CXF 4.0.4
> > >>>> @Colm O hEigeartaigh Any chance we could have a WSS4J 3.0.3 release
> soon?
> > >>>> Thanks!
> > >>>> Freeman
> > >>>> On Tue, Feb 13, 2024 at 7:15 AM Jiri Ondrusek 
> wrote:
> > >>>>> Hi,
> > >>>>> just for your information, the PR (
> https://github.com/apache/cxf/pull/1660)
> > >>>>> requires version of wss4f to be 3.0.3 (to contain
> > >>>>> https://issues.apache.org/jira/browse/WSS-709)
> > >>>>> Best regards,
> > >>>>> Jiri
> > >>>>> On Tue, Feb 13, 2024 at 10:53 AM Peter Palaga 
> wrote:
> > >>>>>> Thanks, great to hear that, Andriy.
> >
> > >>>>>> It would be great if we could get
> > >>>>>> https://github.com/apache/cxf/pull/1660 merged in some form
> before the
> > >>>>>> release.
> > >>>>>> The main motivation is to be able to run CXF on FIPS-enabled
> systems. If
> > >>>>>> the customized algo suite, that the PR proposes, is questionable,
> I'd be
> > >>>>>> also fine with introducing a couple of new suites with fixed
> > >>>>>> non-standard names, like already done in the past for fixing
> CVEs. It
> > >>>>>> would be nice to hear other community members' thoughts.
> > >>>>>> Thanks again,
> > >>>>>> -- Peter
> > >>>>>> On 13/02/2024 02:35, Andriy Redko wrote:
> > >>>>>>> Hi Peter,
> > >>>>>>> Thanks a lot for reminding, I belive we are long overdue on
> that, @Dan,
> > >>>>>> @Colm
> > >>>>>>> may need your help please preparing the next release train (or
> any
> > >>>>>> objection folks)?
> > >>>>>>> Thank you!
> > >>>>>>> Best Regards,
> > >>>>>>>  Andriy Redko
> > >>>>>>>> Hi,
> > >>>>>>>> we are preparing Quarkus CXF to release it for Quarkus 3.8
> which is
> > >>>>>> going to be a LTS (Long Term Support) release.
> > >>>>>>>> I wonder whether we could count on getting CXF 4.0.4 by
> February 21st
> > >>>>>> to be able to use it in that release?
> > >>>>>>>> Thanks,
> > >>>>>>>> -- Peter
> > >>>>> --
> > >>>>> Jiri Ondrusek 
> > >>>>> Senior Software Engineer
> > >>>>> Red Hat Fuse
> >
>

Re: Plans for release 4.0.4?

[Freeman Fang]

Thanks for the update Colm!

Please go ahead to release Santuario then WSS4J, and I believe the next CXF
release needs those changes anyway.

Best Regards
Freeman

On Tue, Feb 13, 2024 at 10:51 AM Colm O hEigeartaigh 
wrote:

> Sorry it turns out I'll need to get Santuario 3.0.4 out first. Do I
> have time to do this and WSS4J before the next CXF release?
>
> Colm.
>
> On Tue, Feb 13, 2024 at 3:28 PM Freeman Fang 
> wrote:
> >
> > Thanks Colm!
> >
> > On Tue, Feb 13, 2024 at 10:18 AM Colm O hEigeartaigh <
> cohei...@apache.org> wrote:
> >>
> >> Yes, I'll call a vote today on WSS4J 3.0.3.
> >>
> >> Colm.
> >>
> >> On Tue, Feb 13, 2024 at 2:28 PM Freeman Fang 
> wrote:
> >> >
> >> > +1 to release Apache CXF 4.0.4
> >> >
> >> > @Colm O hEigeartaigh Any chance we could have a WSS4J 3.0.3 release
> soon?
> >> >
> >> > Thanks!
> >> > Freeman
> >> >
> >> > On Tue, Feb 13, 2024 at 7:15 AM Jiri Ondrusek 
> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> just for your information, the PR (
> https://github.com/apache/cxf/pull/1660)
> >> >> requires version of wss4f to be 3.0.3 (to contain
> >> >> https://issues.apache.org/jira/browse/WSS-709)
> >> >>
> >> >> Best regards,
> >> >> Jiri
> >> >>
> >> >> On Tue, Feb 13, 2024 at 10:53 AM Peter Palaga 
> wrote:
> >> >>
> >> >> > Thanks, great to hear that, Andriy.
> >> >> >
> >> >> > It would be great if we could get
> >> >> > https://github.com/apache/cxf/pull/1660 merged in some form
> before the
> >> >> > release.
> >> >> > The main motivation is to be able to run CXF on FIPS-enabled
> systems. If
> >> >> > the customized algo suite, that the PR proposes, is questionable,
> I'd be
> >> >> > also fine with introducing a couple of new suites with fixed
> >> >> > non-standard names, like already done in the past for fixing CVEs.
> It
> >> >> > would be nice to hear other community members' thoughts.
> >> >> >
> >> >> > Thanks again,
> >> >> >
> >> >> > -- Peter
> >> >> >
> >> >> > On 13/02/2024 02:35, Andriy Redko wrote:
> >> >> > > Hi Peter,
> >> >> > >
> >> >> > > Thanks a lot for reminding, I belive we are long overdue on
> that, @Dan,
> >> >> > @Colm
> >> >> > > may need your help please preparing the next release train (or
> any
> >> >> > objection folks)?
> >> >> > > Thank you!
> >> >> > >
> >> >> > > Best Regards,
> >> >> > >  Andriy Redko
> >> >> > >
> >> >> > >> Hi,
> >> >> > >> we are preparing Quarkus CXF to release it for Quarkus 3.8
> which is
> >> >> > going to be a LTS (Long Term Support) release.
> >> >> > >> I wonder whether we could count on getting CXF 4.0.4 by
> February 21st
> >> >> > to be able to use it in that release?
> >> >> > >> Thanks,
> >> >> > >> -- Peter
> >> >> > >
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> Jiri Ondrusek 
> >> >> Senior Software Engineer
> >> >> Red Hat Fuse
>

Re: Plans for release 4.0.4?

[Freeman Fang]

Thanks Colm!

On Tue, Feb 13, 2024 at 10:18 AM Colm O hEigeartaigh 
wrote:

> Yes, I'll call a vote today on WSS4J 3.0.3.
>
> Colm.
>
> On Tue, Feb 13, 2024 at 2:28 PM Freeman Fang 
> wrote:
> >
> > +1 to release Apache CXF 4.0.4
> >
> > @Colm O hEigeartaigh Any chance we could have a WSS4J 3.0.3 release soon?
> >
> > Thanks!
> > Freeman
> >
> > On Tue, Feb 13, 2024 at 7:15 AM Jiri Ondrusek 
> wrote:
> >>
> >> Hi,
> >>
> >> just for your information, the PR (
> https://github.com/apache/cxf/pull/1660)
> >> requires version of wss4f to be 3.0.3 (to contain
> >> https://issues.apache.org/jira/browse/WSS-709)
> >>
> >> Best regards,
> >> Jiri
> >>
> >> On Tue, Feb 13, 2024 at 10:53 AM Peter Palaga 
> wrote:
> >>
> >> > Thanks, great to hear that, Andriy.
> >> >
> >> > It would be great if we could get
> >> > https://github.com/apache/cxf/pull/1660 merged in some form before
> the
> >> > release.
> >> > The main motivation is to be able to run CXF on FIPS-enabled systems.
> If
> >> > the customized algo suite, that the PR proposes, is questionable, I'd
> be
> >> > also fine with introducing a couple of new suites with fixed
> >> > non-standard names, like already done in the past for fixing CVEs. It
> >> > would be nice to hear other community members' thoughts.
> >> >
> >> > Thanks again,
> >> >
> >> > -- Peter
> >> >
> >> > On 13/02/2024 02:35, Andriy Redko wrote:
> >> > > Hi Peter,
> >> > >
> >> > > Thanks a lot for reminding, I belive we are long overdue on that,
> @Dan,
> >> > @Colm
> >> > > may need your help please preparing the next release train (or any
> >> > objection folks)?
> >> > > Thank you!
> >> > >
> >> > > Best Regards,
> >> > >  Andriy Redko
> >> > >
> >> > >> Hi,
> >> > >> we are preparing Quarkus CXF to release it for Quarkus 3.8 which is
> >> > going to be a LTS (Long Term Support) release.
> >> > >> I wonder whether we could count on getting CXF 4.0.4 by February
> 21st
> >> > to be able to use it in that release?
> >> > >> Thanks,
> >> > >> -- Peter
> >> > >
> >> >
> >> >
> >>
> >> --
> >> Jiri Ondrusek 
> >> Senior Software Engineer
> >> Red Hat Fuse
>