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 • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**************************************************** /⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:  ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 a package containing a native import implementation [2].

Best Regards,
Vladimir.

[1]
https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/2003750
[2] https://github.com/vpa1977/jkt

On Wed, Feb 8, 2023 at 8:31 AM Thorsten Glaser <t.glaser@tarent.de> wrote:

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 • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

****************************************************
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
╳ HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

****************************************************

<div dir="ltr"><div>Hi, <br><br> I tried that: <br><br> - Having a dependency on java runtime brings us back to the same<br>   problem that we have now: upgrade is broken [1].<br> - Removing dependency, drags the Python in. <br><br>If we want to
keep dependencies small, maybe we can switch the package to <br>`Architecture Any` or supersede it with a package containing a native import<br>implementation [2]. <br><br>Best Regards, <br>  Vladimir.<br><br>[1] <a href="https://bugs.launchpad.net/
ubuntu/+source/ca-certificates-java/+bug/2003750">https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/2003750</a><br>[2] <a href="https://github.com/vpa1977/jkt">https://github.com/vpa1977/jkt</a><br></div></div><br><div class="gmail_
quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 8, 2023 at 8:31 AM Thorsten Glaser &lt;<a href="mailto:t.glaser@tarent.de">t.glaser@tarent.de</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px
solid rgb(204,204,204);padding-left:1ex">On Wed, 8 Feb 2023, Vladimir Petko wrote:<br>

&gt;This functionality can be implemented using the following Python packages:<br>
[…]<br>

Make that an “or” dependency then, so that people who already<br>
have the JVM installed don’t need to pull tons of Python3<br>
packages.<br>

bye,<br>
//mirabilos<br>
-- <br>
Infrastrukturexperte • tarent solutions GmbH<br>
Am Dickobskreuz 10, D-53121 Bonn • <a href="http://www.tarent.de/" rel="noreferrer" target="_blank">http://www.tarent.de/</a><br>
Telephon +49 228 54881-393 • Fax: +49 228 54881-235<br>
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941<br>
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg<br>

                        ****************************************************<br>
/⁀\ The UTF-8 Ribbon<br>
╲ ╱ Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:<br>
 ╳  HTML eMail! Also,     <a href="https://www.tarent.de/newsletter" rel="noreferrer" target="_blank">https://www.tarent.de/newsletter</a><br>
╱ ╲ header encryption!<br>
                        ****************************************************<br>
</blockquote></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 only on OpenSSL and relatively small binary?

Best Regards,
Vladimir.

On Wed, Feb 8, 2023 at 8:31 AM Thorsten Glaser <t.glaser@tarent.de> wrote:

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 • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

****************************************************
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
╳ HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

****************************************************

<div dir="ltr"><div dir="ltr">Hi, <div><br><div> 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). </div><div><br></div><div>
Another option is convert the package to architecture Any (if it is possible) and in this case we will have dependency only on OpenSSL and relatively small binary?<br></div></div><div><br></div><div>Best Regards, </div><font color="#888888"><div> 
Vladimir.</div></font></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 8, 2023 at 8:31 AM Thorsten Glaser &lt;<a href="mailto:t.glaser@tarent.de">t.glaser@tarent.de</a>&gt; wrote:<br></div><blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 8 Feb 2023, Vladimir Petko wrote:<br>

&gt;This functionality can be implemented using the following Python packages:<br>
[…]<br>

Make that an “or” dependency then, so that people who already<br>
have the JVM installed don’t need to pull tons of Python3<br>
packages.<br>

bye,<br>
//mirabilos<br>
-- <br>
Infrastrukturexperte • tarent solutions GmbH<br>
Am Dickobskreuz 10, D-53121 Bonn • <a href="http://www.tarent.de/" rel="noreferrer" target="_blank">http://www.tarent.de/</a><br>
Telephon +49 228 54881-393 • Fax: +49 228 54881-235<br>
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941<br>
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg<br>

                        ****************************************************<br>
/⁀\ The UTF-8 Ribbon<br>
╲ ╱ Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:<br>
 ╳  HTML eMail! Also,     <a href="https://www.tarent.de/newsletter" rel="noreferrer" target="_blank">https://www.tarent.de/newsletter</a><br>
╱ ╲ header encryption!<br>
                        ****************************************************<br>
</blockquote></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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-certificate-java certificate import tool to Python to break the dependency cycle.

Rationale

The certificate import tool in ca-certificate-java is written in Java.
This is a constant source of bugs [1] and requires updates (including
stable
release updates [2]) whenever a new JDK version comes out. Switching certificate import to Python will remove the maintenance load and break
a cyclic dependency.

Existing Functionality

ca-certificates-java synchronizes content of Java keystore /etc/ssl/certs/java/cacerts with trusted certificates in PEM format located
in /etc/ssl/certs using jks-keystore hook registered with ca-certificates package.

During hook invocation or post installation following actions are performed:
- ca-certificates-java checks the format of /etc/ssl/certs/java/cacerts and
attempts to convert it into legacy Java Key Store(JKS) format due to the
requirement to support OpenJDK 8.
OpenJDK 11 and up support both legacy and PKCS11 formats.
- ca-certificate-java lists all available certificates in the keystore
using
Java keytool, filters certificate aliases and compares the list with the
system certificates.
An input file containing '+debian:<certificate-file-name>' for addition
and
'-debian:<certificate-file-name>' is generated and passed to import
utility.
Import utility updates /etc/ssl/certs/java/cacerts and sets updated
certificate alias to 'debian:<certificate-file-name>'
Note: Import utility only updates certificates with
'debian:<certificate-file-name>' alias

Requirements

In order to remove dependency on Java, the certificate import tool must:
- List certificate aliases
- Add or update certificate in Java Key Store
- Convert PKCS12 store to JKS format
- Load certificate in PEM format
- Retain any user's certificates in Java Key Store

Implementation

This functionality can be implemented using the following Python packages:
- python3-pyjks: Java Key Store format support [4]. It supports loading,
manipulation and serialization of the JKS files.
It is needed for requirements 1 and 2.
- python3-oscrypto: PKCS12 and X509 support [3]. The package depends on
OpenSSL 3.0. The package supports loading PKCS12 certificate store and
extracting certificates along with SafeBag aliases.
It is needed for requirements 3 and 4.

ca-certificates-java will install the /usr/sbin/ca-certificates-java tool.

It will accept following options:
- sync <password> <input-file> - synchronize the keystore
- list <password> – list certificate aliases in the keystore
- convert <password> <oldstore> <newstore> – convert the keystore into
JKS format.

Best Regards,
Vladimir.

[1] https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java
[2]
https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1998065
[3] https://launchpad.net/ubuntu/+source/oscrypto
[4] https://launchpad.net/ubuntu/+source/pyjks

<div dir="ltr"><div>Dear Maintainers, </div><div><br></div><div>Would it be possible to consider a proposal to break dependency of ca-certificates-java on the installed JVM?</div><div><br></div>Abstract<br><br>ca-certificates-java package contains a
circular dependency with Java that<br>causes issues during openjdk installation. <br>I am proposing switching the ca-certificate-java certificate import tool to<br>Python to break the dependency cycle.<br><br>Rationale<br><br>The certificate import tool
in ca-certificate-java is written in Java. <br>This is a constant source of bugs [1] and requires updates (including stable <br>release updates [2])  whenever a new JDK version comes out. Switching <br>certificate import to Python will remove the
maintenance load and break<br>a cyclic dependency.<br><br>Existing Functionality<br><br>ca-certificates-java synchronizes content of Java keystore <br>/etc/ssl/certs/java/cacerts with trusted certificates in PEM format located <br>in /etc/ssl/certs using
jks-keystore hook registered with ca-certificates<br>package. <br><br>During hook invocation or post installation following actions are performed:<br>- ca-certificates-java checks the format of /etc/ssl/certs/java/cacerts and <br>  attempts to convert
it into legacy Java Key Store(JKS) format due to the <br>  requirement to support OpenJDK 8. <br>  OpenJDK 11 and up support both legacy and PKCS11 formats.<br>- ca-certificate-java lists all available certificates in the keystore using <br>  Java
keytool, filters certificate aliases and compares the list with the <br>  system certificates. <br>  An input file containing &#39;+debian:&lt;certificate-file-name&gt;&#39; for addition and <br>  &#39;-debian:&lt;certificate-file-name&gt;&#39; is
generated and passed to import utility.<br>  Import utility updates /etc/ssl/certs/java/cacerts and sets updated<br>  certificate alias to &#39;debian:&lt;certificate-file-name&gt;&#39;<br>  Note: Import utility only updates certificates with <br>  &#
39;debian:&lt;certificate-file-name&gt;&#39; alias<br><br>Requirements<br><br>In order to remove dependency on Java, the certificate import tool must:<br>- List certificate aliases<br>- Add or update certificate in Java Key Store<br>- Convert PKCS12
store to JKS format<br>- Load certificate in PEM format<br>- Retain any user&#39;s certificates in Java Key Store<br><br>Implementation<br><br>This functionality can be implemented using the following Python packages:<br>- python3-pyjks: Java Key Store
format support [4]. It supports loading, <br>  manipulation and serialization of the JKS files. <br>  It is needed for  requirements 1 and 2.<br>- python3-oscrypto: PKCS12 and X509 support [3]. The package depends on <br>  OpenSSL 3.0. The package
supports loading PKCS12 certificate store and <br>  extracting certificates along with SafeBag aliases. <br>  It is needed for requirements 3 and 4.<br><br>ca-certificates-java will install the  /usr/sbin/ca-certificates-java tool.<br><br>It will
accept following options:<br>- sync &lt;password&gt; &lt;input-file&gt; - synchronize the keystore<br>- list &lt;password&gt; – list certificate aliases in the keystore<br>- convert &lt;password&gt; &lt;oldstore&gt; &lt;newstore&gt; – convert the
keystore into <br>  JKS format.<div><br></div><div>Best  Regards, <br></div><div>  Vladimir.</div><div><br>[1] <a href="https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java">https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java</a><

[2] <a href="https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1998065">https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1998065</a><br>[3] <a href="https://launchpad.net/ubuntu/+source/oscrypto">https://launchpad.

net/ubuntu/+source/oscrypto</a><br>[4] <a href="https://launchpad.net/ubuntu/+source/pyjks">https://launchpad.net/ubuntu/+source/pyjks</a><br></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 that Java trust
roots are always in sync with the machine? Then we can make a very
simple ca-certificates-java package in line with Alpine and more
complex and ugly for the legacy Java support.

This will require some changes to the packaging of Java 8 (or all
other JDKs), as at the moment all JDKs share the same cacerts files.

[1] https://tracker.debian.org/pkg/p11-kit
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929685#42

On Wed, Feb 22, 2023 at 9:22 AM Emmanuel Bourg <ebourg@apache.org> wrote:

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 for OpenJDK 8 (

with a dedicated ca-certificate-java8 package maybe). This way installing openjdk-17 would not drag in python dependencies.

Emmanuel Bourg

Le 2023-02-07 20:12, Vladimir Petko a écrit :

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-certificate-java certificate import tool to Python to break the dependency cycle.

Rationale

The certificate import tool in ca-certificate-java is written in Java.
This is a constant source of bugs [1] and requires updates (including stable release updates [2]) whenever a new JDK version comes out. Switching certificate import to Python will remove the maintenance load and break
a cyclic dependency.

Existing Functionality

ca-certificates-java synchronizes content of Java keystore /etc/ssl/certs/java/cacerts with trusted certificates in PEM format located in /etc/ssl/certs using jks-keystore hook registered with ca-certificates package.

During hook invocation or post installation following actions are performed: - ca-certificates-java checks the format of /etc/ssl/certs/java/cacerts and
attempts to convert it into legacy Java Key Store(JKS) format due to the
requirement to support OpenJDK 8.
OpenJDK 11 and up support both legacy and PKCS11 formats.
- ca-certificate-java lists all available certificates in the keystore using
Java keytool, filters certificate aliases and compares the list with the
system certificates.
An input file containing '+debian:<certificate-file-name>' for addition and
'-debian:<certificate-file-name>' is generated and passed to import utility.
Import utility updates /etc/ssl/certs/java/cacerts and sets updated
certificate alias to 'debian:<certificate-file-name>'
Note: Import utility only updates certificates with
'debian:<certificate-file-name>' alias

Requirements

In order to remove dependency on Java, the certificate import tool must:
- List certificate aliases
- Add or update certificate in Java Key Store
- Convert PKCS12 store to JKS format
- Load certificate in PEM format
- Retain any user's certificates in Java Key Store

Implementation

This functionality can be implemented using the following Python packages:
- python3-pyjks: Java Key Store format support [4]. It supports loading,
manipulation and serialization of the JKS files.
It is needed for requirements 1 and 2.
- python3-oscrypto: PKCS12 and X509 support [3]. The package depends on
OpenSSL 3.0. The package supports loading PKCS12 certificate store and
extracting certificates along with SafeBag aliases.
It is needed for requirements 3 and 4.

ca-certificates-java will install the /usr/sbin/ca-certificates-java tool.

It will accept following options:
- sync <password> <input-file> - synchronize the keystore
- list <password> – list certificate aliases in the keystore
- convert <password> <oldstore> <newstore> – convert the keystore into
JKS format.

Best Regards,
Vladimir.

[1] https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java
[2] https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1998065
[3] https://launchpad.net/ubuntu/+source/oscrypto
[4] https://launchpad.net/ubuntu/+source/pyjks

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 seem to be
checked anywhere. If we use p11-kit, then it will not be present and
something might break in the future. In this case we will have to
replace p11-kit with our own tool.

Best Regards,
Vladimir.

On Wed, Feb 22, 2023 at 9:22 AM Emmanuel Bourg <ebourg@apache.org> wrote:

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 for OpenJDK 8 (

with a dedicated ca-certificate-java8 package maybe). This way installing openjdk-17 would not drag in python dependencies.

Emmanuel Bourg

Le 2023-02-07 20:12, Vladimir Petko a écrit :

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-certificate-java certificate import tool to Python to break the dependency cycle.

Rationale

The certificate import tool in ca-certificate-java is written in Java.
This is a constant source of bugs [1] and requires updates (including stable release updates [2]) whenever a new JDK version comes out. Switching certificate import to Python will remove the maintenance load and break
a cyclic dependency.

Existing Functionality

ca-certificates-java synchronizes content of Java keystore /etc/ssl/certs/java/cacerts with trusted certificates in PEM format located in /etc/ssl/certs using jks-keystore hook registered with ca-certificates package.

During hook invocation or post installation following actions are performed: - ca-certificates-java checks the format of /etc/ssl/certs/java/cacerts and
attempts to convert it into legacy Java Key Store(JKS) format due to the
requirement to support OpenJDK 8.
OpenJDK 11 and up support both legacy and PKCS11 formats.
- ca-certificate-java lists all available certificates in the keystore using
Java keytool, filters certificate aliases and compares the list with the
system certificates.
An input file containing '+debian:<certificate-file-name>' for addition and
'-debian:<certificate-file-name>' is generated and passed to import utility.
Import utility updates /etc/ssl/certs/java/cacerts and sets updated
certificate alias to 'debian:<certificate-file-name>'
Note: Import utility only updates certificates with
'debian:<certificate-file-name>' alias

Requirements

In order to remove dependency on Java, the certificate import tool must:
- List certificate aliases
- Add or update certificate in Java Key Store
- Convert PKCS12 store to JKS format
- Load certificate in PEM format
- Retain any user's certificates in Java Key Store

Implementation

This functionality can be implemented using the following Python packages:
- python3-pyjks: Java Key Store format support [4]. It supports loading,
manipulation and serialization of the JKS files.
It is needed for requirements 1 and 2.
- python3-oscrypto: PKCS12 and X509 support [3]. The package depends on
OpenSSL 3.0. The package supports loading PKCS12 certificate store and
extracting certificates along with SafeBag aliases.
It is needed for requirements 3 and 4.

ca-certificates-java will install the /usr/sbin/ca-certificates-java tool.

It will accept following options:
- sync <password> <input-file> - synchronize the keystore
- list <password> – list certificate aliases in the keystore
- convert <password> <oldstore> <newstore> – convert the keystore into
JKS format.

Best Regards,
Vladimir.

[1] https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java
[2] https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1998065
[3] https://launchpad.net/ubuntu/+source/oscrypto
[4] https://launchpad.net/ubuntu/+source/pyjks

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 for OpenJDK 8 (with a dedicated
ca-certificate-java8 package maybe). This way installing openjdk-17
would not drag in python dependencies.

Emmanuel Bourg

Le 2023-02-07 20:12, Vladimir Petko a écrit :

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-certificate-java certificate import
tool to
Python to break the dependency cycle.

Rationale

The certificate import tool in ca-certificate-java is written in Java.
This is a constant source of bugs [1] and requires updates (including
stable
release updates [2]) whenever a new JDK version comes out. Switching certificate import to Python will remove the maintenance load and break
a cyclic dependency.

Existing Functionality

ca-certificates-java synchronizes content of Java keystore /etc/ssl/certs/java/cacerts with trusted certificates in PEM format
located
in /etc/ssl/certs using jks-keystore hook registered with
ca-certificates
package.

During hook invocation or post installation following actions are
performed:
- ca-certificates-java checks the format of /etc/ssl/certs/java/cacerts
and
attempts to convert it into legacy Java Key Store(JKS) format due to
the
requirement to support OpenJDK 8.
OpenJDK 11 and up support both legacy and PKCS11 formats.
- ca-certificate-java lists all available certificates in the keystore
using
Java keytool, filters certificate aliases and compares the list with
the
system certificates.
An input file containing '+debian:<certificate-file-name>' for addition
and
'-debian:<certificate-file-name>' is generated and passed to import
utility.
Import utility updates /etc/ssl/certs/java/cacerts and sets updated certificate alias to 'debian:<certificate-file-name>'
Note: Import utility only updates certificates with 'debian:<certificate-file-name>' alias

Requirements

In order to remove dependency on Java, the certificate import tool
must:
- List certificate aliases
- Add or update certificate in Java Key Store
- Convert PKCS12 store to JKS format
- Load certificate in PEM format
- Retain any user's certificates in Java Key Store

Implementation

This functionality can be implemented using the following Python
packages:
- python3-pyjks: Java Key Store format support [4]. It supports
loading,
manipulation and serialization of the JKS files.
It is needed for requirements 1 and 2.
- python3-oscrypto: PKCS12 and X509 support [3]. The package depends on OpenSSL 3.0. The package supports loading PKCS12 certificate store and extracting certificates along with SafeBag aliases.
It is needed for requirements 3 and 4.

ca-certificates-java will install the /usr/sbin/ca-certificates-java
tool.

It will accept following options:
- sync <password> <input-file> - synchronize the keystore
- list <password> - list certificate aliases in the keystore
- convert <password> <oldstore> <newstore> - convert the keystore into
JKS format.

Best Regards,
Vladimir.

[1] https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java
[2] https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1998065 [3] https://launchpad.net/ubuntu/+source/oscrypto
[4] https://launchpad.net/ubuntu/+source/pyjks

<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt'>
<p>Hi Vladimir,</p>
<p>Thank you for tackling this annoying issue.</p>
<p>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 for OpenJDK 8 (
with a dedicated ca-certificate-java8 package maybe). This way installing openjdk-17 would not drag in python dependencies.</p>
<p>Emmanuel Bourg</p>
<p><br /></p>
<p id="reply-intro">Le 2023-02-07 20:12, Vladimir Petko a &eacute;crit&nbsp;:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div id="replybody1">
<div dir="ltr">
<div>Dear Maintainers,&nbsp;</div>
<div>&nbsp;</div>
<div>Would it be possible to consider a proposal to break dependency of ca-certificates-java on the installed JVM?</div>
<div>&nbsp;</div>
Abstract<br /><br />ca-certificates-java package contains a circular dependency with Java that<br />causes issues during openjdk installation. <br />I am proposing switching the ca-certificate-java certificate import tool to<br />Python to break the
dependency cycle.<br /><br />Rationale<br /><br />The certificate import tool in ca-certificate-java is written in Java. <br />This is a constant source of bugs [1] and requires updates (including stable <br />release updates [2]) &nbsp;whenever a new
JDK version comes out. Switching <br />certificate import to Python will remove the maintenance load and break<br />a cyclic dependency.<br /><br />Existing Functionality<br /><br />ca-certificates-java synchronizes content of Java keystore <br />/etc/
ssl/certs/java/cacerts with trusted certificates in PEM format located <br />in /etc/ssl/certs using jks-keystore hook registered with ca-certificates<br />package. <br /><br />During hook invocation or post installation following actions are performed:<
br />- ca-certificates-java checks the format of /etc/ssl/certs/java/cacerts and <br />&nbsp; attempts to convert it into legacy Java Key Store(JKS) format due to the <br />&nbsp; requirement to support OpenJDK 8. <br />&nbsp; OpenJDK 11 and up support
both legacy and PKCS11 formats.<br />- ca-certificate-java lists all available certificates in the keystore using <br />&nbsp; Java keytool, filters certificate aliases and compares the list with the <br />&nbsp; system certificates. <br />&nbsp; An
input file containing '+debian:&lt;certificate-file-name&gt;' for addition and <br />&nbsp; '-debian:&lt;certificate-file-name&gt;' is generated and passed to import utility.<br />&nbsp; Import utility updates /etc/ssl/certs/java/cacerts and sets updated<
br />&nbsp; certificate alias to 'debian:&lt;certificate-file-name&gt;'<br />&nbsp; Note: Import utility only updates certificates with <br />&nbsp; 'debian:&lt;certificate-file-name&gt;' alias<br /><br />Requirements<br /><br />In order to remove
dependency on Java, the certificate import tool must:<br />- List certificate aliases<br />- Add or update certificate in Java Key Store<br />- Convert PKCS12 store to JKS format<br />- Load certificate in PEM format<br />- Retain any user's certificates
in Java Key Store<br /><br />Implementation<br /><br />This functionality can be implemented using the following Python packages:<br />- python3-pyjks: Java Key Store format support [4]. It supports loading, <br />&nbsp; manipulation and serialization of
the JKS files. <br />&nbsp; It is needed for &nbsp;requirements 1 and 2.<br />- python3-oscrypto: PKCS12 and X509 support [3]. The package depends on <br />&nbsp; OpenSSL 3.0. The package supports loading PKCS12 certificate store and <br />&nbsp;
extracting certificates along with SafeBag aliases. <br />&nbsp; It is needed for requirements 3 and 4.<br /><br />ca-certificates-java will install the &nbsp;/usr/sbin/ca-certificates-java tool.<br /><br />It will accept following options:<br />- sync &
lt;password&gt; &lt;input-file&gt; - synchronize the keystore<br />- list &lt;password&gt; &ndash; list certificate aliases in the keystore<br />- convert &lt;password&gt; &lt;oldstore&gt; &lt;newstore&gt; &ndash; convert the keystore into <br />&nbsp;
JKS format.
<div>&nbsp;</div>
<div>Best&nbsp; Regards,&nbsp;</div>
<div>&nbsp; Vladimir.</div>
<div><br />[1] <a href="https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java" target="_blank" rel="noopener noreferrer">https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java</a><br />[2] <a href="https://bugs.launchpad.net/ubuntu/+
source/ca-certificates-java/+bug/1998065" target="_blank" rel="noopener noreferrer">https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1998065</a><br />[3] <a href="https://launchpad.net/ubuntu/+source/oscrypto" target="_blank" rel="
noopener noreferrer">https://launchpad.net/ubuntu/+source/oscrypto</a><br />[4] <a href="https://launchpad.net/ubuntu/+source/pyjks" target="_blank" rel="noopener noreferrer">https://launchpad.net/ubuntu/+source/pyjks</a></div>
</div>
</div>
</blockquote>
<p><br /></p>

</body></html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 JKS keystore will
have no nōn-Java users, and soon as the JRE is there it’ll
be regenerated.

This all won’t make bookworm any more either, so no need to
be hasty.

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**************************************************** /⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:  ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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-certificates. If the same CA was present in the pre-built
list, then ca-certificates-java needs to be updated at the same time.

Best Regards,
Vladimir.

On Wed, Feb 22, 2023 at 10:30 AM Thorsten Glaser <t.glaser@tarent.de> wrote:

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 about doing it the “low-tech” way:

– ship a minimal JKS keystore with bin:ca-certificates-java,
generated at build time, that contains a manually vetted
list of roots, perhaps just what’s relevant for Debian
– use a Recommends to get at a JRE
– with trigger, generate a full keystore, once a JRE is there

(The shipped one would need to be in /usr/share/!(doc) and
copied so overwriting it with the generated one works and
we’ll probably need to track hashes of shipped ones so we
can honour admin choices to override the keystore if needed.)

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**************************************************** /⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
╳ HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 about doing it the “low-tech” way:

– ship a minimal JKS keystore with bin:ca-certificates-java,
generated at build time, that contains a manually vetted
list of roots, perhaps just what’s relevant for Debian
– use a Recommends to get at a JRE
– with trigger, generate a full keystore, once a JRE is there

(The shipped one would need to be in /usr/share/!(doc) and
copied so overwriting it with the generated one works and
we’ll probably need to track hashes of shipped ones so we
can honour admin choices to override the keystore if needed.)

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**************************************************** /⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:  ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**************************************************** /⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:  ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 /usr/lib/jvm" causes the import to run
before the package is configured and results in a failure to install
[1]. I wonder if we can use some non-file trigger for that from the
postinst script? But this will require updating all JDKs (?)
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?
Or am I getting too confused here?

[1] https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1998697


On Wed, Feb 22, 2023 at 10:59 AM Thorsten Glaser <t.glaser@tarent.de> wrote:

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 JKS keystore will
have no nōn-Java users, and soon as the JRE is there it’ll
be regenerated.

This all won’t make bookworm any more either, so no need to
be hasty.

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**************************************************** /⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
╳ HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 (20230103ubuntu1~ppa3) ...
Setting up libreoffice (1:7.5.0~rc3-0ubuntu1) ...
Processing triggers for libreoffice-common (1:7.5.0~rc3-0ubuntu1) ... Processing triggers for mailcap (3.70+nmu1ubuntu1) ...
Processing triggers for desktop-file-utils (0.26-1ubuntu4) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...
Processing triggers for gnome-menus (3.36.0-1ubuntu3) ...
Processing triggers for ca-certificates-java (20230103ubuntu1~ppa3) ...
No JRE found. Skipping Java certificates setup.
Setting up openjdk-17-jre-headless:amd64 (17.0.6+10-0ubuntu1) ... update-alternatives: using /usr/lib/jvm/java-17-openjdk-amd64/bin/java
to provide /usr/bin/java (java) in auto mode
update-alternatives: using
/usr/lib/jvm/java-17-openjdk-amd64/bin/jpackage to provide
/usr/bin/jpackage (jpackage) in auto mode
update-alternatives: using
/usr/lib/jvm/java-17-openjdk-amd64/bin/keytool to provide
/usr/bin/keytool (keytool) in auto mode
update-alternatives: using
/usr/lib/jvm/java-17-openjdk-amd64/bin/rmiregistry to provide /usr/bin/rmiregistry (rmiregistry) in auto
mode
update-alternatives: using
/usr/lib/jvm/java-17-openjdk-amd64/lib/jexec to provide /usr/bin/jexec
(jexec) in auto mode
Setting up default-jre-headless (2:1.17-74) ...
Setting up openjdk-17-jre:amd64 (17.0.6+10-0ubuntu1) ...
Setting up libreoffice-wiki-publisher (1.2.0+LibO7.5.0~rc3-0ubuntu1) ... Setting up libreoffice-nlpsolver (0.9+LibO7.5.0~rc3-0ubuntu1) ...
Setting up default-jre (2:1.17-74) ...
Setting up libreoffice-script-provider-bsh (1:7.5.0~rc3-0ubuntu1) ...
Setting up libreoffice-script-provider-js (1:7.5.0~rc3-0ubuntu1) ...

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.

Best Regards,
Vladimir.

[1] https://launchpad.net/~vpa1977/+archive/ubuntu/ca-certificates-lowtech

On Wed, Feb 22, 2023 at 11:51 AM Thorsten Glaser <t.glaser@tarent.de> wrote:

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 solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**************************************************** /⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
╳ HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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, please get some input
from people who know better about dpkg triggers.

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**************************************************** /⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:  ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 multiple openjdk versions are
updated.

Please get well!!!!!

Best Regards,
Vladimir.


On Fri, Feb 24, 2023 at 8:47 AM Thorsten Glaser <t.glaser@tarent.de> wrote:

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, please get some input
from people who know better about dpkg triggers.

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**************************************************** /⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
╳ HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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, that is. (And
this should not break with older ca-certificates-java, like in jessie/stretch-ELTS.)

Please get well!!!!!

Thank you.

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**************************************************** /⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:  ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 problems with installation and OpenJDK 20 packages
install successfully. If this change is ok to go forward, I will raise
merge requests on Salsa for doko to integrate it.
The issue is the migration procedure - those packages have to be
published together to avoid any nasty surprises.

Summary of changes:
- remove dependency on jre from ca-certificates-java
- leave only trigger call to update_certs in postinstall of ca-certificates-java
- remove setup_path function (we are guaranteed to have working java
in the path)
- call update-certificates-java trigger after update-alternatives in
every jre-headless postinstall script

Potential problem:
- update-certificates-java trigger logs appearing multiple times when
different openjdk versions are installed at the same time

Best Regards,
Vladimir

[1] https://launchpad.net/~vpa1977/+archive/ubuntu/ca-certificates-lowtech




On Fri, Feb 24, 2023 at 8:59 AM Thorsten Glaser <t.glaser@tarent.de> wrote:

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, that is. (And
this should not break with older ca-certificates-java, like in jessie/stretch-ELTS.)

Please get well!!!!!

Thank you.

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**************************************************** /⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
╳ HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 now that are not targetting the release,
and only small targetted fixes, not big changes).

- call update-certificates-java trigger after update-alternatives in
every jre-headless postinstall script

Is this REALLY necessary? AIUI triggers it shouldn’t, with
the correct invocations. Please do talk to people who know
about triggers well.

Potential problem:
- update-certificates-java trigger logs appearing multiple times when >different openjdk versions are installed at the same time

dpkg should merge them, but even if not, triggers must be
omnipotent anyway, so that’s not a problem.

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**************************************************** /⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:  ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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_configure` (configure.c 635) - trig_activate_packageprocessing(). This happens before postinst script
is ran at configure.c:677 and is too early for this use-case.
- File triggers. Those will be called after unpacking a file. This
would be brittle as we have an implicit dependency on the file
creation and too early for this use case.
- Explicit triggers through dpkg-trigger. This option allows to call
the trigger from the postinstall script. If we set the await flag when triggering, the openjre will not get installed until trigger finishes.
Please correct if I have missed some option here.

I have just realised that keystore conversion produces .dpkg_new file,
which with this approach will have to be copied back manually.

Best Regards,
Vladimir.


On Fri, Feb 24, 2023 at 6:21 PM Thorsten Glaser <t.glaser@tarent.de> wrote:

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 now that are not targetting the release,
and only small targetted fixes, not big changes).

- call update-certificates-java trigger after update-alternatives in
every jre-headless postinstall script

Is this REALLY necessary? AIUI triggers it shouldn’t, with
the correct invocations. Please do talk to people who know
about triggers well.

Potential problem:
- update-certificates-java trigger logs appearing multiple times when >different openjdk versions are installed at the same time

dpkg should merge them, but even if not, triggers must be
omnipotent anyway, so that’s not a problem.

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**************************************************** /⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
╳ HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)