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 <micha...@apache.org>
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
