[JENKINS-67886] WARNING com.trilead.ssh2.crypto.PEMDecoder decode

[jenkins-infra-bot]

We get this log very often:
WARNING com.trilead.ssh2.crypto.PEMDecoder decode
com.trilead.ssh2.cryptoPEMDecoder.decode method is deprecated, use com.trilead.ssh2.cryptoPEMDecoder.decodeKeyPair instead.

I suspect it is through the SCM polling events.  I've tried switching to RSA keys for my svn+ssh setup but get the same logs.

Ideas?

---

Originally reported by channyboy, imported from: WARNING com.trilead.ssh2.crypto.PEMDecoder decode

• assignee: jvz
• status: Open
• priority: Minor
• component(s): ssh-credentials-plugin
• resolution: Unresolved
• votes: 0
• watchers: 2
• imported: 20251215-193512

Raw content of original issue

We get this log very often:
WARNING com.trilead.ssh2.crypto.PEMDecoder decode
com.trilead.ssh2.cryptoPEMDecoder.decode method is deprecated, use com.trilead.ssh2.cryptoPEMDecoder.decodeKeyPair instead.

I suspect it is through the SCM polling events.  I've tried switching to RSA keys for my svn+ssh setup but get the same logs.

Ideas?

• environment: Docker LTS Jenkins 2.319.3 subversion rsa

[jenkins-infra-bot]

arost:

• Original comment link
• Raw content of original comment:

  Same problem here. I think it is caused by the "svnkit" dependency of the subversion plugin. As of version 1.10.1, svnkit uses a method of the trilead-ssh2 API that is now deprecated, leading to the warning.
  
  As far as I can see, svnkit ceased using that method with the latest release 1.10.5. So, bumping the svnkit dependency of the subversion plugin to 1.10.5 should fix this issue.
  

Same problem here. I think it is caused by the "svnkit" dependency of the subversion plugin. As of version 1.10.1, svnkit uses a method of the trilead-ssh2 API that is now deprecated, leading to the warning.

As far as I can see, svnkit ceased using that method with the latest release 1.10.5. So, bumping the svnkit dependency of the subversion plugin to 1.10.5 should fix this issue.

[jenkins-infra-bot]

arost:

• Original comment link
• Raw content of original comment:

  Re-building the subversion plugin (2.15.1) with svnkit 1.10.5 does fix the problem.
  
  However, there is a dependency conflict in the "slf4j" dependencies (svnkit requires 1.7.32, whereas Jenkins is at 1.7.26). Force-downgrading to 1.7.26 leads to a thread leak with thousands of these entities:
  "Piping consumer" #695 daemon prio=5 os_prio=0 cpu=4284,52ms elapsed=51713,78s tid=0x00007f6518170000 nid=0x62ce waiting on condition  [0x00007f6501032000]
     java.lang.Thread.State: TIMED_WAITING (sleeping)
          at java.lang.Thread.sleep(java.base@11.0.11/Native Method)
          at org.tmatesoft.svn.core.internal.io.svn.StreamLogger.lambda$new$0(StreamLogger.java:56)
          at org.tmatesoft.svn.core.internal.io.svn.StreamLogger$$Lambda$464/0x0000000800d38c40.run(Unknown Source)
          at java.lang.Thread.run(java.base@11.0.11/Thread.java:829)
  Possibly this is related to the forced downgrade.
  
  So, at this point it seems that changing the log level of com.trilead.ssh2.cryptoPEMDecoder is the least intrusive workaround. Eventually, the problem will disappear when the subversion plugin switches to svnkit 1.10.5 or later.
  
   
  

Re-building the subversion plugin (2.15.1) with svnkit 1.10.5 does fix the problem.

However, there is a dependency conflict in the "slf4j" dependencies (svnkit requires 1.7.32, whereas Jenkins is at 1.7.26). Force-downgrading to 1.7.26 leads to a thread leak with thousands of these entities:

"Piping consumer" #695 daemon prio=5 os_prio=0 cpu=4284,52ms elapsed=51713,78s tid=0x00007f6518170000 nid=0x62ce waiting on condition  [0x00007f6501032000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
        at java.lang.Thread.sleep(java.base@​11.0.11/Native Method)
        at org.tmatesoft.svn.core.internal.io.svn.StreamLogger.lambda$new$0(StreamLogger.java:56)
        at org.tmatesoft.svn.core.internal.io.svn.StreamLogger$$Lambda$464/0x0000000800d38c40.run(Unknown Source)
        at java.lang.Thread.run(java.base@​11.0.11/Thread.java:829)

Possibly this is related to the forced downgrade.

So, at this point it seems that changing the log level of com.trilead.ssh2.cryptoPEMDecoder is the least intrusive workaround. Eventually, the problem will disappear when the subversion plugin switches to svnkit 1.10.5 or later.