Hi,
>Is this REALLY necessary? AIUI triggers it shouldn’t, with
>the correct invocations. Please do talk to people who know
>about triggers well.
Regarding the trigger activation we have the following options:
- CI triggers (coming from the .triggers file). They are being called
from `deferred_c
On Fri, 24 Feb 2023, Vladimir Petko wrote:
>The issue is the migration procedure - those packages have to be
>published together to avoid any nasty surprises.
Yeah, we’ll have to pick a time to do that, which is after
the bookworm release anyway (it’s not okay to upload things
to unstable right n
Hi,
Thank you very much for the advice
I have tested this approach [1] and it looks good - the trigger is
called after update-alternatives in the postinstall script of the
jre-headless and this guarantees that we have a working java when we
try to import certificates.
Libreoffice has no prob
On Fri, 24 Feb 2023, Vladimir Petko wrote:
>This is possible to do if we update openjdk packaging and make it
>trigger certificates-ca-java, so that it always runs after the openjdk
We can do that easily. I maintain 8 and doko the rest (I hope).
If that’s needed, i.e. if there’s no other way, th
Hi,
This is possible to do if we update openjdk packaging and make it
trigger certificates-ca-java, so that it always runs after the openjdk
package is installed and remove postinstall update from
ca-certificates-java altogether. This will work, but we might get
several trigger calls in a row if m
On Thu, 23 Feb 2023, Vladimir Petko wrote:
>Notice that ca-certificates-java attempts to process triggers before
>default-jre is set up. This is exactly the condition we are trying to
>avoid.
It should run them again, and there’s got to be a way, but I’m
not a triggers expert and currently ill, p
Hi,
I have tried this approach[1] - switched to interest-wait in
/usr/lib/jvm trigger, replaced `update_certs` in postinstall with a
trigger invocation and tried to install libreoffice:
Unpacking libreoffice-nlpsolver (0.9+LibO7.5.0~rc3-0ubuntu1) ...
Setting up ca-certificates-java (20230103ubunt
On Wed, 22 Feb 2023, Vladimir Petko wrote:
>Alternative is to go with two packages: one for Java 11 and onwards
>that does not use Java-based import, and the other - classic
>ca-certificates-java with the trigger updated to watch Java 8?
(this also confuses me, why would 8 be special?)
bye,
//mi
On Wed, 22 Feb 2023, Vladimir Petko wrote:
>The existing trigger "interest /usr/lib/jvm" causes the import to run
Unsure, I only used triggers once, a decade ago or so myself,
but isn’t this what the interest-await trigger method is for?
bye,
//mirabilos
--
Infrastrukturexperte • tarent solutio
Hi,
I would really love to prototype the approach, but might need a little
advice here: in order to use openjdk-20 onwards we need to run the
trigger after openjdk-20 jre is installed (all files are present on
file system, all property files renamed from .dpkg_new).
The existing trigger "interest
On Wed, 22 Feb 2023, Vladimir Petko wrote:
>in sync. A possible scenario is CA being revoked, which results in an
That’s why I was suggesting to keep it down to manually vetted
relevant ones.
But if that’s unpalatable (do talk to the security people!),
ship an empty JKS keystore by default. The
Hi,
I wonder if security guys will have some reservations abouts the
pre-built root list. This will result in supplying two potentially
different sources of trust and will require maintenance to keep those
in sync. A possible scenario is CA being revoked, which results in an
update to ca-certific
On Wed, 22 Feb 2023, Vladimir Petko wrote:
>Just a small clarification, openssl itself allows importing a single
>certificate and its chain and overwrites the store in the process, so
>we need something like p11-kit.
>Another grey area is ORACLE_TrustedKeyUsage attribute - at the moment
Ugh.
How
Hi,
Just a small clarification, openssl itself allows importing a single
certificate and its chain and overwrites the store in the process, so
we need something like p11-kit.
Another grey area is ORACLE_TrustedKeyUsage attribute - at the moment
store implementation sets it on save, but it does not
Hi,
That's a great idea. I was thinking of using p11-kit [1] to generate
Java 11 + certificates [2]. I have abandoned it because
ca-certificates-java attempts to synchronize the store, keeping user's
certificates that were added for Java only.
I wonder if we can drop this requirement and declare t
Hi Vladimir,
Thank you for tackling this annoying issue.
You said that JKS was required to support OpenJDK 8, but there is no
such requirement, at the Debian level at least. What about generating a
PKCS#12 certstore with OpenSSL instead, would that work? The python
script could still be used
Hi,
I tried that:
- Having a dependency on java runtime brings us back to the same
problem that we have now: upgrade is broken [1].
- Removing dependency, drags the Python in.
If we want to keep dependencies small, maybe we can switch the package to
`Architecture Any` or supersede it with
Hi,
Yes, this is a very good point. I am a bit hesitant about dragging the
Python in myself, though the build procedure might be interesting
(building both jar and python egg).
Another option is convert the package to architecture Any (if it is
possible) and in this case we will have dependency
On Wed, 8 Feb 2023, Vladimir Petko wrote:
>This functionality can be implemented using the following Python packages:
[…]
Make that an “or” dependency then, so that people who already
have the JVM installed don’t need to pull tons of Python3
packages.
bye,
//mirabilos
--
Infrastrukturexperte •
Dear Maintainers,
Would it be possible to consider a proposal to break dependency of
ca-certificates-java on the installed JVM?
Abstract
ca-certificates-java package contains a circular dependency with Java that
causes issues during openjdk installation.
I am proposing switching the ca-certifica
20 matches
Mail list logo
