primefaces on maven repos have dependency on primefaces.org - jsf

I am trying to use Primefaces 5.3 with a maven build on Bluemix, using the redmond theme from the 1.0.8 primefaces extensions. However, it seems I have run into a dependency issue.
1) When I leave out the all-themes artifact from the org.primefaces.extensions group, I get an exception that the themes.css could not be found.
2) When I edit in the all-themes artifact and stay with the maven repository only, I get a dependency error, as there seems to be a dependency to an artifact that is only on primefaces.org but not on maven.org, namely at least the afterdark pom.xml seems to refer to primefaces.org
3) When I edit in the primefaces.org repository, I get a build error on Bluemix, because Bluemix does not seem to trust the SSL certificate from primefaces.org:
[ERROR] ...Could not transfer artifact org.primefaces.themes:afterdark:pom:1.0.8 from/to prime-repo (https://repository.primefaces.org/): com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
[ERROR] java.security.cert.CertPathValidatorException: The certificate issued by CN=DST Root CA X3, O=Digital Signature Trust Co. is not trusted; internal cause is:
[ERROR] java.security.cert.CertPathValidatorException: Certificate chaining error
This happens with both http or https used as repository address, so probably the afterdark pom includes the https address anyway....
So maven.org is pointing to some untrusted repository for a dependency, and Bluemix does not accept it.
So what should be the fix (and no, don't suggest not using primefaces):
- Is this fixed with any newer version of primefaces? Not sure if I will be able to spend the effort for the upgrade though
- can this be fixed in the 1.x versions of primefaces extensions?
- I guess I won't be able to change Bluemix to accept the certificate...
- is there a way to only use the redmond theme as dependency and not all-themes?
Is there anything I am missing?
Note that locally there is no problem, as maven seems to happily download code from untrusted sources.

It looks like the certificate is not available in the jvm trust store and you will need to add it to resolve the problem.

Related

Keycloak 17 logging to logstash

Does anyone have an idea on how I can do this (what the top comments suggests): Keycloak logging to logstash
But for the newest keycloak version 17+ which uses Quarkus instead of Wildfly?
Edit 1:
After I have successfully added logstash feature to my keycloak+quarkus build, and logging-gelf shows under installed features
I can still not see logs on kibana, as if the logs are not being sent but the feature is installed.
Am I correct in thinking that this configuration is a correct "replacement" for the the Wildfly cli from the link:
quarkus.log.handler.gelf.enabled=true
quarkus.log.handler.gelf.json=true
quarkus.log.handler.gelf.json.key-overrides={timestamp="#timestamp"}
quarkus.log.handler.gelf.json.exception-output-type=formatted
quarkus.log.handler.gelf.json.additional-field."appname".value=${env.LOGSTASH_APPNAME:myApplicationName}
quarkus.log.handler.gelf.json.additional-field."#version".value=1
quarkus.log.handler.gelf.host=tcp:${env.LOGSTASH_DESTINATION:someDefaultDestination}
quarkus.log.handler.gelf.port=${env.LOGSTASH_PORT:5044}
#Default vale is tcp
#quarkus.log.handler.gelf.protocol=tcp
quarkus.log.handler.gelf.block-on-reconnect=true
quarkus.log.handler.gelf.async=true
#Default value is ALL
#quarkus.log.handler.gelf.level=ALL
quarkus.log.handler.gelf.async.queue-length=${env-LOGSTASH_QUEUE:1000}
#Default value is block
#quarkus.log.handler.gelf.async.overflow=block
Or is there some configurations that I just have "made up"?
First of all: at the moment keycloak has no native support for gelf/logstash directly. That said, it is possible to do for sure using the quarkus logging gelf extension. In order for this to work, it is a bit complicated, but in general You have to:
download the jars for the quarkiverse-logging-gelf - both, the "deployment" and the runtime jar, for the quarkus version your keycloak version uses (2.7.0? Not sure, iirc I updated to 2.7.5 in 17.0.1). Also you need to download the transient dependency of this quarkus extension, namely the logstash-gelf jar in the right version. Put these jars inside the "providers" directory of your kc.
create a quarkus.properties file in the conf directory and add your desired configuration. There is a centralized log management guide on the quarkus homepage.
run a "build"
start Keycloak. Your log should now show
[io.quarkus] (main) Installed features: [..., logging-gelf, ...]
And it should work to get your logs out the way you want it.
These steps are also described with examples e.g. here.
Note: I am in the Keycloak team. There is no out of the box support right now directly, bc. we are thinking about leveraging quarkus' extension approach better (so you do not have to download the jars and transient dependencies manually), but I guess for this specific case we will do something the future :)
edit: open pr for support using keycloak config: -> https://github.com/keycloak/keycloak/pull/12843
edit 2: pr merged, firstclass support should be available from the next major version (19 i guess)

Docker security scan detects vulnerability in gradle 7.4.1

Creating a docker image with gradle 7.4.1 triggers the security scan which shows vulnerability CVE-2020-36518. How can this particular jar file within the gradle package be updated?
I would just reject the security issue, explaining that it is not possible to exploit the vulnerability as the Gradle build runs isolated on controlled input, and is not accessible by any potential attackers.
(Assuming this is the case, of cause, and you don't have a custom Gradle plugin that reads untrusted JSON documents using Jackson from the Gradle classpath. But even then, all you are risking is a denial-of-service on the build.)
Fiddling around with jar files in external tools could easily lead to problems hard to debug later. But if you like, you could create an issue for them, asking if they could bump the Jackson version to avoid unnecessary noise from security scans like this. There is an example of that here.

Downloading Dependences From Private Amazon S3 Repository with Gradle

I am looking to add Groovy support to an existing java project so that I can seemlessly compile mixed Java and Groovy code using invokedynamic so that I can get Java-like execution speed without needing to waste excessive amounts of time with verbose Java syntax
After reading that the gmaven plugin no longer supports compilation -and that the groovy eclipse compiler plugin doesn't yet support invokedynamic, I asked myself, why would I want to continue using Maven if it compiles Groovy code that is needlessly slow?
Consequently, I decided I would try scrapping maven for Gradle so that I could obtain faster code while also porting some python deployment scripts to Gradle tasks so as to only need one codebase.
I have some libraries stored on a simple password protected s3 maven repository (in order to avoid needing enterprise overkill like artifactory). After doing some basic research, I have found that Gradle has no built in support for adding in custom dependency management as determined by this stack overlow question and this support forums post.
I did manage to find a s3 plugin for gradle -but it doesn't deal with management of dependencies.
If the whole point of Gradle is to be more flexible than Maven and if the core purpose of a dependency management/ build system is to effectively manage dependencies from a variety of sources-then lack of support for custom repositories appears to be a fairly significant significant design flaw which makes any issues I have encounted with Maven thus far pale in comparison.
However, it is quite possible that I am missing something, and I have already invested several hours learning Gradle -so I figured I would see if there is some reasonable way to emulate dependency management for these s3 dependencies until Gradle developers fix this critical issue. Otherwise I will have to conclude that I am better off just using Maven and tolerating slower Groovy code until the compiler plugin supports invokedynamic.
Basically I need a solution that does the following:
Downloads dependencies and transitive dependencies to the gradle cache
Doesn't require me to hardcode the path to the gradle cache -so that my build script is platform independent.
Doesn't download the dependencies again if they are already in the cache.
Works with a multi-module project.
However, I cannot find anything in the documentation that would even give me a clue as to where to begin:
Gradle 2.4 has native support for S3 repositories. Both downloading dependencies and publishing artifacts.
To download with IAM credentials (paraphrased from the link above):
repositories {
maven {
url "s3://someS3Bucket/path/to/repo/root"
credentials(AwsCredentials) {
accessKey 'access key'
secretKey 'secret key'
}
}
}
Then specify your dependencies as usual.
You don't need any custom repository support to make this work. Just declare a maven repository with the correct URL. If the repository works when used from Maven, it will also work with Gradle. (Uploading may be a different matter.)
You can use S3 and http
repositories {
mavenCentral()
ivy {
url "https://s3-eu-west-1.amazonaws.com/my-bucket"
layout "pattern", {
artifact "[artifact]-[revision].[ext]"
m2compatible = true
}
}
}
Name the jar in S3 to name-rev.jar (joda-time-3.2.jar) in my-bucket.
Also upload a pom file.
And in S3 give all permission to Download the jar and pom.

Why are some RichFaces artifacts not in Maven Central?

In order to get the RichFaces Validator artifact org.richfaces.ui.validator:richfaces-ui-validator-ui (4.2.2 Final) in my build, I had to add https://repository.jboss.org/nexus/content/repositories/releases as repository in my POM.
I went that way after my build complained it couldn't find that artifact and a search for 'richfaces' in Maven Central did not return the "complete set" of RichFaces artifacts.
Just curious if anyone knows how RichFaces artifacts are chosen for inclusion in Maven Central.
Short answer: if you need this, you're probably doing something wrong. Maven Central should have all the dependencies required to create an app with RichFaces.
I was trying to add the ui-validator component separately (which is not deployed to Maven central) under the mistaken assumption that I needed it explicitly identified as a dependency. Including it caused me a considerable amount of pain (multiple csv.xml files in deployment).
In the end, I realized that the ui-components dependency (which is installed on Maven Central) bundles up the validation dependency (and many others).
In the end, I wasn't getting the components I was looking for anyway. I thought I needed the rich:ajaxValidator, but that was only because I was attempting to use code from the 3.x RichFaces Showcase in a 4.x app (and that tag was removed in 4.x).

Maven Security Concerns

Are there security concerns with using Maven? I use Ant today for my main project, but I do use Maven for my "samples" project where I write program spikes. I do like some parts of Maven, but have a concern with downloading my jars through the tool. Is this an unfounded concern? How secure is "http://repo1.maven.org/maven2/"? Is there a more secure way of using the tool?
Thanks.
It's pretty secure and standard. If ever the security of http://repo1.maven.org/maven2/ is compromised, there will have big repercussion in Java devs. I never heard that this site is hacked.
That said, you are not bounded by default repository. You can configure your own repository using Nexus, Artifactory and install safe artifacts manually to them. You may also block remote repositories using Nexus/Artifactory setting. Although, I never needed to do this. But look here, perhaps it's possible.
Please note that you will have to block your local repository to use "repo1", else the local repository will download artifacts from there by default.
Edit 1: added missing link

Resources