Re: [tomcat-native] branch 1.2.x updated: Align default pass phrase prompt with HTTPd
Chris, On 2023/06/26 19:50:39 Christopher Schultz wrote: > Michael, > On 6/26/23 13:11, micha...@apache.org wrote: > > This is an automated email from the ASF dual-hosted git repository. > > > > michaelo pushed a commit to branch 1.2.x > > in repository https://gitbox.apache.org/repos/asf/tomcat-native.git > > > > > > The following commit(s) were added to refs/heads/1.2.x by this push: > > new 8049561c8 Align default pass phrase prompt with HTTPd > > 8049561c8 is described below > > > > commit 8049561c86c3270b86dfd484fd07f1e8627d6b41 > > Author: Michael Osipov > > AuthorDate: Mon Jun 26 18:05:40 2023 +0200 > > > > Align default pass phrase prompt with HTTPd > > I'm close to a -1 on this, ant it entirely comes down to something > stupid that people should definitely NOT do, but they probably actually > do: script the injection of a password into the startup process because > #securityReasons and their startup process looks specifically for the > text "Enter password". > > Think expect(1) or similar being used to enter a password automatically > when, really, the password should not be required for an automated process. > > I think I'm okay with changing this for 2.x but 1.x is just too set in > its ways at this point. I think you are misunderstanding something here. There is no functional change. The pass phrase popup has always been there. All I did is to align the message prompt, nothing else. If you want a decent solution one needs to port the SSLPassPhraseDialog from mod_ssl. I took a look, a lot of work, mostly not work the pain. The pass phrase prompt is only relevant when you start interactively from the terminal, if your process starts detached, it won't work anyway. I have tried here on HP-UX and FreeBSD, both failed because stdin is not connected to a tty. Can you re-explain your position based on these, new facts? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-native] branch 1.2.x updated: Align default pass phrase prompt with HTTPd
Please also read my BZ issue: https://bz.apache.org/bugzilla/show_bug.cgi?id=64826 Nothing new here... - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66670] Add SSLHostConfig#certificateKeyPasswordFile
https://bz.apache.org/bugzilla/show_bug.cgi?id=66670 --- Comment #3 from Remy Maucherat --- There are property sources to do property replacement in server.xml. For example: https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/digester/ServiceBindingPropertySource.java (that's the only exotic one that is included in the Tomcat sources, though ;) ). -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66670] Add SSLHostConfig#certificateKeyPasswordFile
https://bz.apache.org/bugzilla/show_bug.cgi?id=66670 --- Comment #4 from Michael Osipov --- (In reply to Remy Maucherat from comment #3) > There are property sources to do property replacement in server.xml. For > example: > https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/ > digester/ServiceBindingPropertySource.java (that's the only exotic one that > is included in the Tomcat sources, though ;) ). Yeah, but obviously not straight forward for the user and requires a change in the setup on the target server which is not desired in my case. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 8.5.x updated: Align with 9.0.x onwards (fixes failing test)
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/8.5.x by this push:
new 4f04558f14 Align with 9.0.x onwards (fixes failing test)
4f04558f14 is described below
commit 4f04558f1421cd8279b09f9571bddb30572d55ef
Author: Mark Thomas
AuthorDate: Tue Jun 27 11:49:28 2023 +0100
Align with 9.0.x onwards (fixes failing test)
---
test/org/apache/tomcat/util/net/TestCustomSslTrustManager.java | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/test/org/apache/tomcat/util/net/TestCustomSslTrustManager.java
b/test/org/apache/tomcat/util/net/TestCustomSslTrustManager.java
index b8b21b788e..f2afd93806 100644
--- a/test/org/apache/tomcat/util/net/TestCustomSslTrustManager.java
+++ b/test/org/apache/tomcat/util/net/TestCustomSslTrustManager.java
@@ -123,8 +123,7 @@ public class TestCustomSslTrustManager extends
TomcatBaseTest {
if (trustType.equals(TrustType.NONE)) {
Assert.assertTrue(rc != 200);
-Assert.assertNotNull(res);
-Assert.assertTrue(res.toString().isEmpty());
+Assert.assertNull(res.toString());
} else {
Assert.assertEquals(200, rc);
Assert.assertEquals("OK-" + TesterSupport.ROLE, res.toString());
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Buildbot success in on tomcat-8.5.x
Build status: Build succeeded! Worker used: bb_worker2_ubuntu URL: https://ci2.apache.org/#builders/36/builds/535 Blamelist: Mark Thomas , remm Build Text: build successful Status Detected: restored build Build Source Stamp: [branch 8.5.x] 4f04558f1421cd8279b09f9571bddb30572d55ef Steps: worker_preparation: 0 git: 0 shell: 0 shell_1: 0 shell_2: 0 shell_3: 0 shell_4: 0 shell_5: 0 compile: 1 shell_6: 0 shell_7: 0 shell_8: 0 shell_9: 0 Rsync docs to nightlies.apache.org: 0 shell_10: 0 Rsync RAT to nightlies.apache.org: 0 compile_1: 1 shell_11: 0 Rsync Logs to nightlies.apache.org: 0 -- ASF Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 10.1.x updated: Improve Javadoc
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 10.1.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/10.1.x by this push:
new 26555450d3 Improve Javadoc
26555450d3 is described below
commit 26555450d3c2e12d639e09c72de9bcf65e381680
Author: Mark Thomas
AuthorDate: Tue Jun 27 13:11:57 2023 +0100
Improve Javadoc
---
java/jakarta/el/ELResolver.java | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/java/jakarta/el/ELResolver.java b/java/jakarta/el/ELResolver.java
index ad5f268c53..cdc933bd4d 100644
--- a/java/jakarta/el/ELResolver.java
+++ b/java/jakarta/el/ELResolver.java
@@ -62,13 +62,15 @@ public abstract class ELResolver {
}
/**
- * Obtain the type of the given property on the given object using the
given context.
+ * Obtain the most generally acceptable type that may be used to set the
given property on the given object using
+ * the given context.
*
* @param context The EL context for this evaluation
* @param base The base object on which the property is to be found
* @param property The property whose type is to be returned
*
- * @return the type of the provided property
+ * @return the most general type that maybe used to set the provided
property or {@code null} if the resolver is
+ * read-only.
*
* @throws NullPointerException If the supplied context is
null
* @throws PropertyNotFoundException If the base/property combination
provided to the resolver is one that the
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 9.0.x updated: Improve Javadoc
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/9.0.x by this push:
new b00c5c80b4 Improve Javadoc
b00c5c80b4 is described below
commit b00c5c80b4c5bb16e409e43922990ad56f0b9437
Author: Mark Thomas
AuthorDate: Tue Jun 27 13:11:57 2023 +0100
Improve Javadoc
---
java/javax/el/ELResolver.java | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/java/javax/el/ELResolver.java b/java/javax/el/ELResolver.java
index b426d0ace4..59c568ec39 100644
--- a/java/javax/el/ELResolver.java
+++ b/java/javax/el/ELResolver.java
@@ -62,13 +62,15 @@ public abstract class ELResolver {
}
/**
- * Obtain the type of the given property on the given object using the
given context.
+ * Obtain the most generally acceptable type that may be used to set the
given property on the given object using
+ * the given context.
*
* @param context The EL context for this evaluation
* @param base The base object on which the property is to be found
* @param property The property whose type is to be returned
*
- * @return the type of the provided property
+ * @return the most general type that maybe used to set the provided
property or {@code null} if the resolver is
+ * read-only.
*
* @throws NullPointerException If the supplied context is
null
* @throws PropertyNotFoundException If the base/property combination
provided to the resolver is one that the
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch 8.5.x updated: Improve Javadoc
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/8.5.x by this push:
new 54ff8b3240 Improve Javadoc
54ff8b3240 is described below
commit 54ff8b3240f47dab6cae1e48119fbebb92a180b7
Author: Mark Thomas
AuthorDate: Tue Jun 27 13:11:57 2023 +0100
Improve Javadoc
---
java/javax/el/ELResolver.java | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/java/javax/el/ELResolver.java b/java/javax/el/ELResolver.java
index b426d0ace4..59c568ec39 100644
--- a/java/javax/el/ELResolver.java
+++ b/java/javax/el/ELResolver.java
@@ -62,13 +62,15 @@ public abstract class ELResolver {
}
/**
- * Obtain the type of the given property on the given object using the
given context.
+ * Obtain the most generally acceptable type that may be used to set the
given property on the given object using
+ * the given context.
*
* @param context The EL context for this evaluation
* @param base The base object on which the property is to be found
* @param property The property whose type is to be returned
*
- * @return the type of the provided property
+ * @return the most general type that maybe used to set the provided
property or {@code null} if the resolver is
+ * read-only.
*
* @throws NullPointerException If the supplied context is
null
* @throws PropertyNotFoundException If the base/property combination
provided to the resolver is one that the
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat] branch main updated: Improve Javadoc
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new 191df1c2d6 Improve Javadoc
191df1c2d6 is described below
commit 191df1c2d6373a7842c7d59744829618ad194bd1
Author: Mark Thomas
AuthorDate: Tue Jun 27 13:11:57 2023 +0100
Improve Javadoc
---
java/jakarta/el/ELResolver.java | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/java/jakarta/el/ELResolver.java b/java/jakarta/el/ELResolver.java
index 49f6a5a105..c356fb379d 100644
--- a/java/jakarta/el/ELResolver.java
+++ b/java/jakarta/el/ELResolver.java
@@ -60,13 +60,15 @@ public abstract class ELResolver {
}
/**
- * Obtain the type of the given property on the given object using the
given context.
+ * Obtain the most generally acceptable type that may be used to set the
given property on the given object using
+ * the given context.
*
* @param context The EL context for this evaluation
* @param base The base object on which the property is to be found
* @param property The property whose type is to be returned
*
- * @return the type of the provided property
+ * @return the most general type that maybe used to set the provided
property or {@code null} if the resolver is
+ * read-only.
*
* @throws NullPointerException If the supplied context is
null
* @throws PropertyNotFoundException If the base/property combination
provided to the resolver is one that the
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66670] Add SSLHostConfig#certificateKeyPasswordFile
https://bz.apache.org/bugzilla/show_bug.cgi?id=66670 --- Comment #5 from Christopher Schultz --- (In reply to Michael Osipov from comment #2) > * From code, this will not work, XML only True, but not really relevant. If you want to re-use passwords (or files), you can do that in your code pretty easily. > * Most people don't even know system identifiers or DTDs at all Also true, but this is standard XML and not some weird hand-wavy thing that Tomcat invented like "property sources". > * What will happen if the file contains a line separator? Will it be > stripped automatically? I haven't done extensive testing, but I believe exotic whitespace will be preserved. So if you have a trailing newline in your file, then your password will also have a trailing newline. So be careful. But you'd have to do that, anyway. If Tomcat were to implement a "use this file here" attribute resolver, then we would not want to be doing things like trimming whitespace or anything like that, either. (In reply to Remy Maucherat from comment #3) > .../ServiceBindingPropertySource This was going to be my next suggestion. I only recently discovered this capability existed and I fully intend to start playing-around with it because our current build process requires us to build locally in each environment to get e.g. database credentials into the right place in context.xml. But... I think the ServiceBindingPropertySource only works with applications, not with server.xml, right Rémy? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-native] branch 1.2.x updated: Align default pass phrase prompt with HTTPd
Michael, On 6/27/23 04:06, Michael Osipov wrote: Chris, On 2023/06/26 19:50:39 Christopher Schultz wrote: Michael, On 6/26/23 13:11, micha...@apache.org wrote: This is an automated email from the ASF dual-hosted git repository. michaelo pushed a commit to branch 1.2.x in repository https://gitbox.apache.org/repos/asf/tomcat-native.git The following commit(s) were added to refs/heads/1.2.x by this push: new 8049561c8 Align default pass phrase prompt with HTTPd 8049561c8 is described below commit 8049561c86c3270b86dfd484fd07f1e8627d6b41 Author: Michael Osipov AuthorDate: Mon Jun 26 18:05:40 2023 +0200 Align default pass phrase prompt with HTTPd I'm close to a -1 on this, ant it entirely comes down to something stupid that people should definitely NOT do, but they probably actually do: script the injection of a password into the startup process because #securityReasons and their startup process looks specifically for the text "Enter password". Think expect(1) or similar being used to enter a password automatically when, really, the password should not be required for an automated process. I think I'm okay with changing this for 2.x but 1.x is just too set in its ways at this point. I think you are misunderstanding something here. There is no functional change. The pass phrase popup has always been there. All I did is to align the message prompt, nothing else. If you want a decent solution one needs to port the SSLPassPhraseDialog from mod_ssl. I took a look, a lot of work, mostly not work the pain. The pass phrase prompt is only relevant when you start interactively from the terminal, if your process starts detached, it won't work anyway. I have tried here on HP-UX and FreeBSD, both failed because stdin is not connected to a tty. Can you re-explain your position based on these, new facts? No new facts, here, and I totally understand what you have done: change the text "only". But, expect(1) literally expects specific text. If I have a script that says: === expect "Enter password :" send $password === Then my script stops working because "Enter password :" has changed to "Enter pass phrase:". So after umpteen years, the text is changing and that could break 20 years of scripts written for that specific text. I have not actually tried using expect(1) with this prompt. Does it actually fail? The whole point of expect(1) is to simulate a console and provide input to the process, so I suspect that it will work for the same reasons it's worked for the past 30 years. Did you actually try using expect(1), if did you just "nohup catalina.sh run" or something similar? -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66670] Add SSLHostConfig#certificateKeyPasswordFile
https://bz.apache.org/bugzilla/show_bug.cgi?id=66670 --- Comment #6 from Remy Maucherat --- (In reply to Christopher Schultz from comment #5) > But... I think the ServiceBindingPropertySource only works with > applications, not with server.xml, right Rémy? These property sources are first and foremost for server.xml. For example this is used for the vault that some customers wanted to have sensitive stuff placed these instead of directly in server.xml ( https://github.com/web-servers/tomcat-vault/blob/main/INSTALL.md ). (of course, it's not really more secure, I know) -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-native] branch 1.2.x updated: Align default pass phrase prompt with HTTPd
On 2023/06/27 14:13:37 Christopher Schultz wrote: > Michael, > > On 6/27/23 04:06, Michael Osipov wrote: > > Chris, > > > > On 2023/06/26 19:50:39 Christopher Schultz wrote: > >> Michael, > >> On 6/26/23 13:11, micha...@apache.org wrote: > >>> This is an automated email from the ASF dual-hosted git repository. > >>> > >>> michaelo pushed a commit to branch 1.2.x > >>> in repository https://gitbox.apache.org/repos/asf/tomcat-native.git > >>> > >>> > >>> The following commit(s) were added to refs/heads/1.2.x by this push: > >>>new 8049561c8 Align default pass phrase prompt with HTTPd > >>> 8049561c8 is described below > >>> > >>> commit 8049561c86c3270b86dfd484fd07f1e8627d6b41 > >>> Author: Michael Osipov > >>> AuthorDate: Mon Jun 26 18:05:40 2023 +0200 > >>> > >>> Align default pass phrase prompt with HTTPd > >> > >> I'm close to a -1 on this, ant it entirely comes down to something > >> stupid that people should definitely NOT do, but they probably actually > >> do: script the injection of a password into the startup process because > >> #securityReasons and their startup process looks specifically for the > >> text "Enter password". > >> > >> Think expect(1) or similar being used to enter a password automatically > >> when, really, the password should not be required for an automated process. > >> > >> I think I'm okay with changing this for 2.x but 1.x is just too set in > >> its ways at this point. > > > > I think you are misunderstanding something here. There is no functional > > change. The pass phrase popup has always been there. All I did is to align > > the message prompt, nothing else. If you want a decent solution one needs > > to port the SSLPassPhraseDialog from mod_ssl. I took a look, a lot of work, > > mostly not work the pain. The pass phrase prompt is only relevant when you > > start interactively from the terminal, if your process starts detached, it > > won't work anyway. I have tried here on HP-UX and FreeBSD, both failed > > because stdin is not connected to a tty. > > > > Can you re-explain your position based on these, new facts? > > No new facts, here, and I totally understand what you have done: change > the text "only". > > But, expect(1) literally expects specific text. If I have a script that > says: > > === > expect "Enter password :" > > send $password > === > > Then my script stops working because "Enter password :" has changed to > "Enter pass phrase:". > > So after umpteen years, the text is changing and that could break 20 > years of scripts written for that specific text. > > I have not actually tried using expect(1) with this prompt. Does it > actually fail? The whole point of expect(1) is to simulate a console and > provide input to the process, so I suspect that it will work for the > same reasons it's worked for the past 30 years. > > Did you actually try using expect(1), if did you just "nohup catalina.sh > run" or something similar? I think you have the point here. As written, I tried no-tty option, yes one of was nohup. Let me try that with py-expect and get back to you tomorrow. I still wonder who would actually use that. M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-native] branch 1.2.x updated: Align default pass phrase prompt with HTTPd
Michael, On 6/27/23 10:37, Michael Osipov wrote: On 2023/06/27 14:13:37 Christopher Schultz wrote: Michael, On 6/27/23 04:06, Michael Osipov wrote: Chris, On 2023/06/26 19:50:39 Christopher Schultz wrote: Michael, On 6/26/23 13:11, micha...@apache.org wrote: This is an automated email from the ASF dual-hosted git repository. michaelo pushed a commit to branch 1.2.x in repository https://gitbox.apache.org/repos/asf/tomcat-native.git The following commit(s) were added to refs/heads/1.2.x by this push: new 8049561c8 Align default pass phrase prompt with HTTPd 8049561c8 is described below commit 8049561c86c3270b86dfd484fd07f1e8627d6b41 Author: Michael Osipov AuthorDate: Mon Jun 26 18:05:40 2023 +0200 Align default pass phrase prompt with HTTPd I'm close to a -1 on this, ant it entirely comes down to something stupid that people should definitely NOT do, but they probably actually do: script the injection of a password into the startup process because #securityReasons and their startup process looks specifically for the text "Enter password". Think expect(1) or similar being used to enter a password automatically when, really, the password should not be required for an automated process. I think I'm okay with changing this for 2.x but 1.x is just too set in its ways at this point. I think you are misunderstanding something here. There is no functional change. The pass phrase popup has always been there. All I did is to align the message prompt, nothing else. If you want a decent solution one needs to port the SSLPassPhraseDialog from mod_ssl. I took a look, a lot of work, mostly not work the pain. The pass phrase prompt is only relevant when you start interactively from the terminal, if your process starts detached, it won't work anyway. I have tried here on HP-UX and FreeBSD, both failed because stdin is not connected to a tty. Can you re-explain your position based on these, new facts? No new facts, here, and I totally understand what you have done: change the text "only". But, expect(1) literally expects specific text. If I have a script that says: === expect "Enter password :" send $password === Then my script stops working because "Enter password :" has changed to "Enter pass phrase:". So after umpteen years, the text is changing and that could break 20 years of scripts written for that specific text. I have not actually tried using expect(1) with this prompt. Does it actually fail? The whole point of expect(1) is to simulate a console and provide input to the process, so I suspect that it will work for the same reasons it's worked for the past 30 years. Did you actually try using expect(1), if did you just "nohup catalina.sh run" or something similar? I think you have the point here. As written, I tried no-tty option, yes one of was nohup. Let me try that with py-expect and get back to you tomorrow. I still wonder who would actually use that. Yes, doing this kind of thing is definitely stupid because if you are going to put your password into a script, you may as well just put it in the #&$*% configuration file, but there are still dumb reasons for things like Tomcat Vault[1] to exist. I just don't want to suddenly break a bunch of installations for something trivial like the spelling of an output message. -chris [1] https://github.com/web-servers/tomcat-vault - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-native] branch 1.2.x updated: Align default pass phrase prompt with HTTPd
On 2023/06/27 14:44:46 Christopher Schultz wrote: > Michael, > > On 6/27/23 10:37, Michael Osipov wrote: > > On 2023/06/27 14:13:37 Christopher Schultz wrote: > >> Michael, > >> > >> On 6/27/23 04:06, Michael Osipov wrote: > >>> Chris, > >>> > >>> On 2023/06/26 19:50:39 Christopher Schultz wrote: > Michael, > On 6/26/23 13:11, micha...@apache.org wrote: > > This is an automated email from the ASF dual-hosted git repository. > > > > michaelo pushed a commit to branch 1.2.x > > in repository https://gitbox.apache.org/repos/asf/tomcat-native.git > > > > > > The following commit(s) were added to refs/heads/1.2.x by this push: > > new 8049561c8 Align default pass phrase prompt with HTTPd > > 8049561c8 is described below > > > > commit 8049561c86c3270b86dfd484fd07f1e8627d6b41 > > Author: Michael Osipov > > AuthorDate: Mon Jun 26 18:05:40 2023 +0200 > > > >Align default pass phrase prompt with HTTPd > > I'm close to a -1 on this, ant it entirely comes down to something > stupid that people should definitely NOT do, but they probably actually > do: script the injection of a password into the startup process because > #securityReasons and their startup process looks specifically for the > text "Enter password". > > Think expect(1) or similar being used to enter a password automatically > when, really, the password should not be required for an automated > process. > > I think I'm okay with changing this for 2.x but 1.x is just too set in > its ways at this point. > >>> > >>> I think you are misunderstanding something here. There is no functional > >>> change. The pass phrase popup has always been there. All I did is to > >>> align the message prompt, nothing else. If you want a decent solution one > >>> needs to port the SSLPassPhraseDialog from mod_ssl. I took a look, a lot > >>> of work, mostly not work the pain. The pass phrase prompt is only > >>> relevant when you start interactively from the terminal, if your process > >>> starts detached, it won't work anyway. I have tried here on HP-UX and > >>> FreeBSD, both failed because stdin is not connected to a tty. > >>> > >>> Can you re-explain your position based on these, new facts? > >> > >> No new facts, here, and I totally understand what you have done: change > >> the text "only". > >> > >> But, expect(1) literally expects specific text. If I have a script that > >> says: > >> > >> === > >> expect "Enter password :" > >> > >> send $password > >> === > >> > >> Then my script stops working because "Enter password :" has changed to > >> "Enter pass phrase:". > >> > >> So after umpteen years, the text is changing and that could break 20 > >> years of scripts written for that specific text. > >> > >> I have not actually tried using expect(1) with this prompt. Does it > >> actually fail? The whole point of expect(1) is to simulate a console and > >> provide input to the process, so I suspect that it will work for the > >> same reasons it's worked for the past 30 years. > >> > >> Did you actually try using expect(1), if did you just "nohup catalina.sh > >> run" or something similar? > > > > I think you have the point here. As written, I tried no-tty option, yes one > > of was nohup. > > Let me try that with py-expect and get back to you tomorrow. I still wonder > > who would actually use that. > > Yes, doing this kind of thing is definitely stupid because if you are > going to put your password into a script, you may as well just put it in > the #&$*% configuration file, but there are still dumb reasons for > things like Tomcat Vault[1] to exist. I just don't want to suddenly > break a bunch of installations for something trivial like the spelling > of an output message. I did now play around with expect(1), the original one. I can confirm your fears. expect(1) does block when the expected line changes. Question is how big the change is that someone uses which broken setup. Would you accept the compromise that if someone complain we'd roll back in 1.2.x? Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-native] branch 1.2.x updated: Align default pass phrase prompt with HTTPd
Michael, On 6/27/23 12:55, Michael Osipov wrote: On 2023/06/27 14:44:46 Christopher Schultz wrote: Michael, On 6/27/23 10:37, Michael Osipov wrote: On 2023/06/27 14:13:37 Christopher Schultz wrote: Michael, On 6/27/23 04:06, Michael Osipov wrote: Chris, On 2023/06/26 19:50:39 Christopher Schultz wrote: Michael, On 6/26/23 13:11, micha...@apache.org wrote: This is an automated email from the ASF dual-hosted git repository. michaelo pushed a commit to branch 1.2.x in repository https://gitbox.apache.org/repos/asf/tomcat-native.git The following commit(s) were added to refs/heads/1.2.x by this push: new 8049561c8 Align default pass phrase prompt with HTTPd 8049561c8 is described below commit 8049561c86c3270b86dfd484fd07f1e8627d6b41 Author: Michael Osipov AuthorDate: Mon Jun 26 18:05:40 2023 +0200 Align default pass phrase prompt with HTTPd I'm close to a -1 on this, ant it entirely comes down to something stupid that people should definitely NOT do, but they probably actually do: script the injection of a password into the startup process because #securityReasons and their startup process looks specifically for the text "Enter password". Think expect(1) or similar being used to enter a password automatically when, really, the password should not be required for an automated process. I think I'm okay with changing this for 2.x but 1.x is just too set in its ways at this point. I think you are misunderstanding something here. There is no functional change. The pass phrase popup has always been there. All I did is to align the message prompt, nothing else. If you want a decent solution one needs to port the SSLPassPhraseDialog from mod_ssl. I took a look, a lot of work, mostly not work the pain. The pass phrase prompt is only relevant when you start interactively from the terminal, if your process starts detached, it won't work anyway. I have tried here on HP-UX and FreeBSD, both failed because stdin is not connected to a tty. Can you re-explain your position based on these, new facts? No new facts, here, and I totally understand what you have done: change the text "only". But, expect(1) literally expects specific text. If I have a script that says: === expect "Enter password :" send $password === Then my script stops working because "Enter password :" has changed to "Enter pass phrase:". So after umpteen years, the text is changing and that could break 20 years of scripts written for that specific text. I have not actually tried using expect(1) with this prompt. Does it actually fail? The whole point of expect(1) is to simulate a console and provide input to the process, so I suspect that it will work for the same reasons it's worked for the past 30 years. Did you actually try using expect(1), if did you just "nohup catalina.sh run" or something similar? I think you have the point here. As written, I tried no-tty option, yes one of was nohup. Let me try that with py-expect and get back to you tomorrow. I still wonder who would actually use that. Yes, doing this kind of thing is definitely stupid because if you are going to put your password into a script, you may as well just put it in the #&$*% configuration file, but there are still dumb reasons for things like Tomcat Vault[1] to exist. I just don't want to suddenly break a bunch of installations for something trivial like the spelling of an output message. I did now play around with expect(1), the original one. I can confirm your fears. expect(1) does block when the expected line changes. Question is how big the change is that someone uses which broken setup. Would you accept the compromise that if someone complain we'd roll back in 1.2.x? I'd prefer to just not change it. I know that sounds maybe insanely hesitant and smacks of "nothing can ever change" but this /could/ represent a very important very breaking change to some users. We don't have a policy of "never change anything, never break anything" but because of the specific interactions in this case, I view the text of this message almost like a public software interface (i.e. API). Changing that requires some serious consideration whether the ends (conformity) justify the means/implications (potential breakage). What's the motivation for the change? Just to match httpd? What if nginx had a different prompt? I know we are more closely-related to httpd, but it's not like we have to match *either* product. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
